Box-shadow in IE9 en andere browsers

[_Thanatos_]

Sinds FF4, O10 en IE9 (en C?) worden de W3C-notaties van box-shadow opgepikt, dus de browsermakers zijn redelijk zelfverzekerd over de implementatie ervan. Toch heb ik een ernstig verschil gevonden tussen wat IE9 doet en wat alle andere browsers [met de W3C-notatie] doen. Ik gebruik dus géén vendor-voorvoegsels.

De code is heel straightforward. Zorg dat je eoa divje hebt, en zet deze style erop:

Cascading Stylesheet:

div { border-radius: 10px; box-shadow: 0 0 4px #000; }

En klaar. Werkt in O10, FF4 en IE9.

Maar zie ook het verschil! Wat is er in vredesnaam aan de hand?
Voor de mensen die het niet zelf willen proberen, een screenie:


Het verschil blijft bestaan als je geen border-radius gebruikt. Ook het gebruik van een spread, of een andere offset in de box-shadow werkt prima, maar lost niet het verschil op. Met een grotere blur-radius wordt het in IE9 minder een lijntje, en meer een echte schaduw, maar er blijft een verschil in blur-radius bestaan van zeker 100%.

Hoe lossen we dit op? Want zo is box-shadow niet bruikbaar in IE9...

[Caelorum]

Simpel, conditional statements:
<!--[if IE 9]>

@Bosmonster: Nouja, het is een oplossing ^^

[ Voor 59% gewijzigd door Caelorum op 08-04-2011 16:57 ]

[Bosmonster]

Ok... even een hele nieuwe post:

IE9 faalt gewoon met box-shadow

(what else is new)

[ Voor 167% gewijzigd door Bosmonster op 08-04-2011 17:03 ]

[_Thanatos_]

Conditional comments zijn smerig. En falen of niet, het moet gewoon gaan werken, hoe je het ook wendt of keert. Visual design, klanten, het bekende verhaaltje

Als je iets als Modernizr gebruikt, krijg je doodleuk terug dat box-shadow gewoon werkt, dus daar kun je niet op selecteren. Je kunt een box-shadow ook niet overrulen door een background-image, zeker niet als de achtergrond áchter de shaduwbox niet effen is, en ook niet als de achtergrond ín de schaduwbox niet effen is.

Ik zou het hooguit met een script kunnen oplossen. Een script dat de spread van de blur opkrikt als IE9 draait... Vies, maar zou weleens kunnen werken.

[ Voor 4% gewijzigd door _Thanatos_ op 08-04-2011 17:27 ]

[Bosmonster]

Dan zijn conditional comments een stuk minder vies hoor..

[Caelorum]

Bosmonster schreef op vrijdag 08 april 2011 @ 17:34:
Dan zijn conditional comments een stuk minder vies hoor..

En hoogst waarschijnlijk sneller (niet onderbouwd).
O en nog belangrijker: Niet afhankelijk van of iemand script uitvoering heeft aanstaan in de browser of niet.
En misschien nog belangrijker: Ook staat dat niet in de weg voor bijv. een print stylesheet of voor kleurenblinden etc. Gewoon een andere stylesheet inladen, met een script dat wordt geladen wordt dat wel wat lastiger.

[ Voor 42% gewijzigd door Caelorum op 08-04-2011 18:04 ]

[_Thanatos_]

Maargoed, ik zie nu conditional comments en een script als workaround... Ik zie liever een oplossing. Iemand hier die creatief is en lateraal kan denken? Het wil bij mij ff niet gebeuren

Een CSS-expression kan ik nog bedenken, maar weet nog niet wat/hoe.

[ Voor 15% gewijzigd door _Thanatos_ op 08-04-2011 22:15 ]

[Peter]

Een combinatie van box-shadow en border-radius properties werkt hier zonder enig probleem in Internet Explorer 9, zowel in de final als eerdere DPs. Het resultaat is gelijk aan Chrome. Ik vermoed dat er elders in je code een probleem zit of dat de property overschreven wordt.

test-case

[_Thanatos_]

@Peter
Toch in de schaduw in FF4 beduidend dikker (factortje 2) dan in IE9. Gek genoeg renderen in jouw test case O11 en IE9 wel weer hetzelfde...

[Makkelijk]

Er zitten ook verschillen tussen firefox en chrome in box-shadow en text-shadow overigens. Maar ik heb nog nooit zo'n groot verschil als dit voorbeeld gezien. Ik denk dat het sterk afhangt van de kleur.

[Fish]

Of draai per ongeluk je in een of andere compatability mode

[RetroTycoon]

Je hebt een doctype gespecificeerd, hè

[Bosmonster]

Peter schreef op zaterdag 09 april 2011 @ 09:48:
Een combinatie van box-shadow en border-radius properties werkt hier zonder enig probleem in Internet Explorer 9, zowel in de final als eerdere DPs. Het resultaat is gelijk aan Chrome. Ik vermoed dat er elders in je code een probleem zit of dat de property overschreven wordt.

test-case

Had het vorige week ook al even geprobeerd, maar IE maakt de schaduw beduidend kleiner dan de andere browsers. Een simpele use case voor TS is dus die 0/0 afstand, maar met een paar pixel blur, voor een gelijke schaduw aan alle kanten van je element.

In IE9 krijg je dat simpelweg niet fatsoenlijk voor elkaar.

[_Thanatos_]

Toch heb ik vreemd genoeg ook situaties gezien waarbij er tussen FF en IE9 geen goed zichtbaar verschil zit. Dat had vgs mij te maken met de positionering van de schaduw...

[MoietyMe]

_Thanatos_ schreef op maandag 11 april 2011 @ 10:37:
Toch heb ik vreemd genoeg ook situaties gezien waarbij er tussen FF en IE9 geen goed zichtbaar verschil zit. Dat had vgs mij te maken met de positionering van de schaduw...

Zoals Bosmonster dus al aangeeft

Overigens vind ik het beschamend hoe weinig HTML 5 IE9 ondersteund. Op deze manier heb je er nog niks aan.

[ Voor 14% gewijzigd door MoietyMe op 11-04-2011 11:12 ]

[_Thanatos_]

Ik ben nog ff verder wezen rommelen, ik ben tot dit gekomen:

Cascading Stylesheet:

div {
  box-shadow: 0 0 4px #000;
  box-shadow: 0 0 8px #000\9;
}

Lekker vies he?
Blijkt dat IE9 nog steeds die tweede regel parst, en alle andere browser blijkbaar niet. Het is een gevaarlijke, want je kunt niet redelijkerwijs weten wanneer een andere browser ook opeens de tweede regel gaat oppikken, zeker gezien Chrome en nu ook Firefox zichzelf volautomatisch updaten...

Ook merkte ik dat hoewel IE9 de schaduw te dun maakt, maakt FF4 em eigenlijk te dik. Opera, Chrome, Safari en zelfs FF36 maken de schaduw allemaal iets dunner dan FF4, en iets dikker dan IE9.

[Bosmonster]

Das wel ranzig, en gebruik overigens toch bijna altijd rgba bij css3-declaraties. Heb je nog wat meer controle over hoe het eruit komt te zien (Vaak is alleen zwart te donker bijvoorbeeld en zo kun je tenminste de opacity ook nog wat instellen).

[ Voor 26% gewijzigd door Bosmonster op 11-04-2011 15:27 ]

[martijn2008]

Ik gebruik voor schaduw altijd plaatjes, om dat hele gezeik met browsers te omzeilen. Is dat fout/minder mooi? Waarschijnlijk wel trager, of niet? En wat is nu het probleem met de <!--[if IE 9]>
Of begrijp ik het niet? Dat zal wel weer

[MoietyMe]

rgba of hex maakt niet uit. Ook het box-model is niet bekend bij IE9 zo schijnt.

Geen offset


15px offset

[Bosmonster]

rgba was ook niet bedoeld als oplossing

Ben wel benieuwd naar je html/css dat dat boxmodel niet klopt in IE9 overigens...

[ Voor 50% gewijzigd door Bosmonster op 11-04-2011 16:24 ]

[MoietyMe]

@Bosmonster: nee dat snap ik, maar dacht dat IE dat misschien ook anders zou behandelen.

HTML:

<!DOCTYPE html>
<html lang="nl">
    <head>
        <title>box-shadow</title>
        <link rel="stylesheet" type="text/css" href="core.css">
    </head>
    <body>
        <div id="hex">
            <p>HEX-color</p>
        </div>
        <div id="rgba">
            <p>RGBA-color</p>
        </div>
    </body>
</html>

Cascading Stylesheet:

div {
    margin: 20px;
    padding: 10px;
    width: 100px;
    height: 100px;
    border-radius: 5px;
}

div#rgba {
    box-shadow: 0 0 5px rgba(0,0,0,1);
}

div#hex {
    box-shadow: 0 0 5px #000;
}

De offset CSS lijkt me verder wel duidelijk dan.

[Bosmonster]

Weet je zeker dat je IE niet een tikkie uitgezoomd staat? Font-rendering is ook kleiner.

[MoietyMe]

Bosmonster schreef op maandag 11 april 2011 @ 16:55:
Weet je zeker dat je IE niet een tikkie uitgezoomd staat? Font-rendering is ook kleiner.

Damn, staat op 95%

Dan pakt hij het box-model wel inderdaad.

Dom

[Bosmonster]

Njah, uiteindelijk gaat het om die schaduw en die blijft ruk onder IE9...

[dragontje124]

is dit nou niet juist waar die vendor-voorvoegsels voor zijn?

[PainkillA]

ik gebruik altijd PIE (http://css3pie.com/). Daarmee kan ik voor de basic layout zaken als schaduw, verloopjes en ronde hoeken eenvoudig uit de voeten. Zorgt er ook voor dat het ie7 compatible is.

ie7 en 8 gebruiken dan een javascript (htc bestand) en alle andere browsers hun native ondersteuning daarvoor.

[crisp]

PainkillA schreef op maandag 11 april 2011 @ 21:43:
ik gebruik altijd PIE (http://css3pie.com/). Daarmee kan ik voor de basic layout zaken als schaduw, verloopjes en ronde hoeken eenvoudig uit de voeten. Zorgt er ook voor dat het ie7 compatible is.

ie7 en 8 gebruiken dan een javascript (htc bestand) en alle andere browsers hun native ondersteuning daarvoor.

Dergelijke 'truuks' moet je gewoon niet willen. Zeker met een wat complexere HTML-structuur maken behaviors de pagina nog trager (en ie7 en 8 staan al niet bekend om hun snelheid)...

[Bosmonster]

Daarnaast lost dat dit probleem voor IE9 niet op.

Die HTC's zijn idd retetraag en staan bovendien nogal haaks op het principe van progressive enhancement. Het is een beetje ouderwets.

[_Thanatos_]

Ik heb nog ff een comprehesive overzicht gemaakt van box-shadow in allerlei browsers... Er zijn wel meer verschillen dan alleen tussen FF4, IE9 en de rest

http://home.thany.nl/apps/BoxShadows/

/edit
Updated, je kunt nu browsers aan-/uitvinken

[ Voor 12% gewijzigd door _Thanatos_ op 12-04-2011 11:25 ]

[MoietyMe]

Mooi overzicht, +1

[PainkillA]

Bosmonster schreef op dinsdag 12 april 2011 @ 08:38:
Daarnaast lost dat dit probleem voor IE9 niet op.

Die HTC's zijn idd retetraag en staan bovendien nogal haaks op het principe van progressive enhancement. Het is een beetje ouderwets.

volledig mee eens dat het traag is maar wat nu als de klant persee schaduwen rondingen etc wil? Afbeeldingen zijn erg vervelend om te onderhouden, aanpassen , uitsnijden en spriten en het scheelt al gauw heel wat requests. Dan liever ie7 en ie8 wat trager en een enorm snelle site voor safari, chrome, firefox, ie9 en opera + dat je veel sneller kan ontwikkelen door niet elk klein gradientje of schaduw wat verschilt apart moet gaan uitsnijden.

Wat is dan eigenlijk wel de oplossing? Gewoon css3 gebruiken en de css2 browsers maar laten leven zonder de extra opmaak?

[RetroTycoon]

Zo lost zelfs Twitter het tegenwoordig op (en ik ook )

Dan hadden ze maar een fatsoenlijke browser moeten installeren (ze zijn gebruikers en beheerders )

[ Voor 48% gewijzigd door RetroTycoon op 12-04-2011 18:22 ]

[PainkillA]

RetroTycoon schreef op dinsdag 12 april 2011 @ 18:22:
Zo lost zelfs Twitter het tegenwoordig op (en ik ook )

Dan hadden ze maar een fatsoenlijke browser moeten installeren (ze zijn gebruikers en beheerders )

waren klanten maar zo openminded en makkelijk Maar nee er wordt altijd geantwoord met het moet gewoon goed staan overal.

[RetroTycoon]

PainkillA schreef op dinsdag 12 april 2011 @ 18:24:
[...]


waren klanten maar zo openminded en makkelijk Maar nee er wordt altijd geantwoord met het moet gewoon goed staan overal.

Gelukkig heb ik geen klanten, maar develop omdat het kan Hoewel de Latijn | Vertaalhulp zeker ook in het onderwijs gebruikt wordt gezien de referers, heb ik nog geen klachten over ronde hoekjes of slagschaduwen gezien

edit-
En de eerste die net heeft doorgeklikt mag zich melden (Piwik Live Visitors ftw!)

[ Voor 8% gewijzigd door RetroTycoon op 12-04-2011 18:40 ]

[joostvanpinxten]

T gaat een beetje offtopic, aangezien het hier over de verschillen in de box-shadow gaat. En ik heb er op geklikt, maar uiteraard weet ik niet of ik de eerste was. Erg subtiel gebruik gemaakt van je ronde hoekjes trouwens, ongeveer 1px?

Verder kan ik in je vertaalhulp alleen definities krijgen in het Engels, terwijl er ook staat dat het in het Nederlands kan?

[on-topic]
Waar staat trouwens de definitie van box-shadow vastgelegd? Want het ziet er wel uit alsof er verschillende interpretaties mogelijk zijn.

edit:

Om niet helemaal het topic te kapen:
@t.coenraad: ja, nu zie ik het... niet heel intuitief de eerste keer :-)
@8088 ja, had 'm ondertussen ook al gegoogled. Zo 's door gaan lezen.

[ Voor 16% gewijzigd door joostvanpinxten op 12-04-2011 19:02 ]

[RetroTycoon]

joostvanpinxten schreef op dinsdag 12 april 2011 @ 18:53:
T gaat een beetje offtopic, aangezien het hier over de verschillen in de box-shadow gaat. En ik heb er op geklikt, maar uiteraard weet ik niet of ik de eerste was. Erg subtiel gebruik gemaakt van je ronde hoekjes trouwens, ongeveer 1px?

Verder kan ik in je vertaalhulp alleen definities krijgen in het Engels, terwijl er ook staat dat het in het Nederlands kan?

[on-topic]
Waar staat trouwens de definitie van box-shadow vastgelegd? Want het ziet er wel uit alsof er verschillende interpretaties mogelijk zijn.

3px radius zijn dat, 1px brede border en de box-shadow is 2px. Oh, en dat Nederlands krijg je er automatischvergoogletranslate bij als je op het Engels klikt of het icoontje

[8088]

joostvanpinxten schreef op dinsdag 12 april 2011 @ 18:53:
Waar staat trouwens de definitie van box-shadow vastgelegd? Want het ziet er wel uit alsof er verschillende interpretaties mogelijk zijn.

http://www.w3.org/TR/css3-background/#box-shadow

[joostvanpinxten]

Voor zover ik tot nu begrepen heb moet de dropshadow (offsetx offsety blur-radius spread-radius) afstand = spread-radius + blur-radius hebben vanaf de projectie van het object waar de schaduw op moet vallen.

Ik heb het alleen bekeken voor het specifieke geval (0 0 4px 4px #000) waar in al duidelijk onderscheid zit tussen diverse browsers. Door te tellen in Photoshop waar de waarde #000 begint tot (en niet met) de pixel waar weer #fff staat en dan het aantal pixels te nemen wat daartussen zit:

FF 4.0 geeft dan 10 pixels
Opera 11.10 geeft dan 8 pixels
IE 9 preview geeft helemaal geen borders...
IE 9 latest build vertik ik om nu te testen omdat daarvoor heel mijn pc opnieuw gestart moet worden
Chrome 10.0.648.204 heeft dan weer 6 pixels shadow

Ik heb nog geen twee browsers hetzelfde zien doen dus... De enige die in dit geval (qua pixelafstand) correct zou zijn, is Opera.

[dragontje124]

RetroTycoon schreef op dinsdag 12 april 2011 @ 18:36:
[...]

Gelukkig heb ik geen klanten, maar develop omdat het kan Hoewel de Latijn | Vertaalhulp zeker ook in het onderwijs gebruikt wordt gezien de referers, heb ik nog geen klachten over ronde hoekjes of slagschaduwen gezien

edit-
En de eerste die net heeft doorgeklikt mag zich melden (Piwik Live Visitors ftw!)

offtopic:
ben je een beetje laat mee zeg, die teksten heb ik net allemaal al vertaald

[Japius]

PainkillA schreef op dinsdag 12 april 2011 @ 18:16:
[...]

Wat is dan eigenlijk wel de oplossing? Gewoon css3 gebruiken en de css2 browsers maar laten leven zonder de extra opmaak?

Daar ben ik ook wel benieuwd naar. Vaak heeft de klant zelf geen idee hoe snel een site rendert. Inzet van een htc bestand kan snel en efficient zijn, en zelf heb je er geen last van omdat je geen IE gebruikt.

Nofi: Makkelijk om te zeggen dat een .htc niet wenselijk is, maar wat is een beter alternatief voor een flexibel box model met ronde hoeken? Extra elementen aan de DOM toevoegen, alleen voor de ronde hoekjes, vind ik ook maar een halve oplossing.

[RetroTycoon]

dragontje124 schreef op dinsdag 12 april 2011 @ 19:54:
[...]

offtopic:
ben je een beetje laat mee zeg, die teksten heb ik net allemaal al vertaald

offtopic:
Een beetje rondgoogelen op latijn vertaling vergilius ce 2011 en hij staat er ergens tussen. Of gewoon op mijn profiel klikken, kom je er ook

[crisp]

PainkillA schreef op dinsdag 12 april 2011 @ 18:16:
[...]

volledig mee eens dat het traag is maar wat nu als de klant persee schaduwen rondingen etc wil?

Allereerst zal je dan moeten achterhalen waarom de klant dat per-sé wil. Het is in ieder geval aan jou om uit te leggen wat de (on)mogelijkheden zijn en wat de nadelen van alternatieven zijn. Wij doen zelf iig ook aan progressive enhancement, oftewel: geen dropshadows en ronde hoekjes voor IE8 en lager. Ik heb er nog nooit een gebruiker over horen klagen (die weten waarschijnlijk toch niet beter totdat ze een modernere browser installeren ).

[R4gnax]

Japius schreef op dinsdag 12 april 2011 @ 20:28:
[...]

Makkelijk om te zeggen dat een .htc niet wenselijk is, maar wat is een beter alternatief voor een flexibel box model met ronde hoeken? Extra elementen aan de DOM toevoegen, alleen voor de ronde hoekjes, vind ik ook maar een halve oplossing.

Voor enkel IE8 kun je kun nog proberen wat met :before en :after te doen om elementen voor hoekjes te genereren. Dit werkt natuurlijk niet meteen onder IE6 en IE7, maar voor die browsers kun je vrij eenvoudig een CSS expression gebruiken die deze pseudo-elementen eenmalig aanmaakt als echte elementen en de rest aan de CSS layout engine overlaat.

Cascading Stylesheet:

.box {
  -ms-before: expression(
    ! this["-ms-before"] ? (
        this["-ms-before"] = document.createElement("before"),
        this.insertBefore(this["-ms-before"], this.firstChild),
        this["-ms-before"] = true,
        true
    ) : true
  );

  -ms-after: expression(
    ! this["-ms-after"] ? (
        this["-ms-after"] = document.createElement("after"),
        this.appendChild(this["-ms-after"]),
        this["-ms-after"] = true,
        true
    ) : true
}

.box before {
}

.box after {
}

De truc is de speciale property naam. Een verzonnen CSS property (wel met een nette vendor prefix, dank u) die niet aan een bepaalde refresh conditie gekoppeld zit. Zo zou deze expressie slechts éénmaal gedraaid moeten worden, de eerste keer dat een element dat net deze class toegekend heeft gekregen zichzelf rendert.

Je kunt echter een soort van race conditie krijgen waardoor de expressie nogmaal gedraaid wordt wanneer er een page reflow / repaint plaats vindt terwijl de expressie nog draaiende is. Dit voorkom je door eerst een boolean guard in een expando attribuut op het HTML element te zetten, voordat je expressie iets doet wat een reflow zou kunnen veroorzaken (zoals elementen aan de DOM toevoegen). Vanwege de wijze waarop JavaScript met truthy/falsy-ness omgaat kan deze guard ook gelijk handig dubbel dienst doen als tijdelijke variable.

Een CSS expression moet wel een JavaScript expressie bevatten en kan niet met een statement block overweg, dus je moet een beetje kunstelen met ternaire operators en door komma's gescheiden statements. Maar met een goede notatie kun je dat heel net en goed leesbaar houden.


Zelf heb ik deze oplossing in gebruik op alweer een aantal sites waaronder sites waar :before en :after ook in grote getalen gebruikt worden (tekstuele markers, icon sprites, etc.) en qua performance wil het alleen zeggen dat de initiele render fase een tikkie langer duurt. Daarna draait alles helemaal soepel.

[crisp]

R4gnax schreef op dinsdag 12 april 2011 @ 21:47:
[...]

Je kunt echter een soort van race conditie krijgen waardoor de expressie nogmaal gedraaid wordt wanneer er een page reflow / repaint plaats vindt terwijl de expressie nog draaiende is. Dit voorkom je door eerst een boolean guard in een expando attribuut op het HTML element te zetten, voordat je expressie iets doet wat een reflow zou kunnen veroorzaken (zoals elementen aan de DOM toevoegen). Vanwege de wijze waarop JavaScript met truthy/falsy-ness omgaat kan deze guard ook gelijk handig dubbel dienst doen als tijdelijke variable.

Ik gebruik(te) altijd this.runtimeStyle.behavior='none'

[R4gnax]

crisp schreef op dinsdag 12 april 2011 @ 22:02:
[...]

Ik gebruik(te) altijd this.runtimeStyle.behavior='none'

Wat eigenlijk hetzelfde bewerkstelligt, maar dan met een extern HTC file; een transformatie die slechts één keer mag draaien. Weet eerlijk gezegd niet zeker of HTC behaviors gevoelig zijn voor dezelfde race.

[ Voor 11% gewijzigd door R4gnax op 12-04-2011 23:03 ]

[Verwijderd]

Even ontopic:
Ik heb ook gemerkt dat IE9 (of eigenlijk IE in het algemeen) iets anders met CSS omgaat dan andere browsers, en om precies te zijn; strikter.

Voorbeeld:

Cascading Stylesheet:

div { color: #FFF; background-color: #000 }

IE geeft nu alleen witte tekst, terwijl de rest ook de zwarte achtergrond geeft. Het is geldige CSS en werkt in alle browsers, behalve IE. En dat komt omdat er geen ; (punt-komma) achter de laatste definitie staat.

Zo ook met css short codes, zoals #FFF ipv #FFFFFF en font: bold 12px/16px Arial;
Het is correcte CSS, maar IE vind het in sommige gevallen niet leuk.

Wat betreft de box-shadow (en text-shadow): dit is een bekend probleem, maar geen van de browsers gebruikt dezelfde methode om deze te genereren en zien er dus allemaal anders uit. En zeker in combinatie met border-radius, waardoor er dus 2 verschillende "scripts" worden gedraaid waarvan er (van beide) 4 verschillende zijn.

Wanneer CSS3 tot standaard komt zal dit probleem (hopelijk) zijn opgelost. Tot die tijd zullen we nog steeds voor elke browser een eigen stylesheet moeten maken

[crisp]

R4gnax schreef op dinsdag 12 april 2011 @ 23:03:
[...]


Wat eigenlijk hetzelfde bewerkstelligt, maar dan met een extern HTC file; een transformatie die slechts één keer mag draaien. Weet eerlijk gezegd niet zeker of HTC behaviors gevoelig zijn voor dezelfde race.

Niet voor externe HTC's hoor, maar voor behavior: expression(...);

[crisp]

Verwijderd schreef op dinsdag 12 april 2011 @ 23:43:
[...]
IE geeft nu alleen witte tekst, terwijl de rest ook de zwarte achtergrond geeft. Het is geldige CSS en werkt in alle browsers, behalve IE. En dat komt omdat er geen ; (punt-komma) achter de laatste definitie staat.

Zo ook met css short codes, zoals #FFF ipv #FFFFFF en font: bold 12px/16px Arial;
Het is correcte CSS, maar IE vind het in sommige gevallen niet leuk.

Dit heb ik nog niet meegemaakt, en wij laten de laatste puntkomma ook altijd weg (onze minifier doet dat) en gebruiken ook de korte kleur-notatie en font-shorthand.

[Bosmonster]

crisp schreef op dinsdag 12 april 2011 @ 21:20:
[...]

Allereerst zal je dan moeten achterhalen waarom de klant dat per-sé wil. Het is in ieder geval aan jou om uit te leggen wat de (on)mogelijkheden zijn en wat de nadelen van alternatieven zijn. Wij doen zelf iig ook aan progressive enhancement, oftewel: geen dropshadows en ronde hoekjes voor IE8 en lager. Ik heb er nog nooit een gebruiker over horen klagen (die weten waarschijnlijk toch niet beter totdat ze een modernere browser installeren ).

Ik heb er ook nog nooit een klant iets over horen zeggen, maar we melden het ook niet. Waar mogelijk (dus waar het puur grafisch is en niet functioneel) hanteren we CSS3 middels progressive enhancement voor ronde hoekjes en shadows. Vaak zijn dat soort dingetjes zo subtiel dat een klant het ook niet eens opvalt, als ze al met IE7 of 8 kijken natuurlijk.

En mochten ze het ooit opmerken, dan is het antwoord simpel: Oude IE's ondersteunen dat niet.