CSS3, vandaag den dag, niet doen.
Ik heb mij vandaag voor de eerste keer echt bezig gehouden met CSS3, tutorials uitgespit, screencasts bekeken, veel leuke dingen gezien, experimenten waarvan je nu nog niet het nut van inziet.
Wat mij vooral is opgevallen zijn de CSS vendor prefixes, veel tutorials die je de dag van vandaag ziet verschijnen - en begrijp me niet verkeerd, die echt wel de moeite zijn - maken meestal gebruik van de -webkit prefix.
Nu niet iedereen gebruikt Safari, er is natuurlijk keuze genoeg aan browsers, en de meesten gebruiken toch maar Firefox omwille van de hype van enkele jaren geleden!
Persoonlijk gebruik ik liever Opera - dat geheel terzijde - maar van de x-aantal CSS3 voorbeelden die ik vandaag gezien heb, was er geen enkele die de opera-prefix gebruikte, alhoewel die identiek zijn aan de -webkit prefix.
Onvoldoende kennis, luiheid??
En sinds IE8 is er een tweede Microsoft prefix bijgekomen, voor IE 5.5 - IE7 gebruik men filter, vanaf IE8 -ms-filter.
Maar natuurlijk brengt ons dat bij het volgende dilemma
Je wenst met de vooruitgang mee te gaan, dus zullen volgende punten je even tot de werkelijkheid roepen:
- Wens je gebruik te maken van CSS3, mag het je geen reet meer interesseren dat vanaf nu je CSS “invalid” is
- Dus stel je wilt dit doen:
div.coolEffect {
-webkit-transition-property: opacity; /* safari */
-webkit-transition-duration: 2s;
-o-transition-property: opacity; /* Opera */
-o-transition-duration: 2s;
-moz-transition-property: opacity; /* FireFox */
-moz-transition-duration: 2s;
-ms-transition-property: opacity; /* IE */
-ms-transition-duration: 2s;
}
Je ziet het al, je moet voor elke engine apart dezelfde bepaling opnieuw gaan schrijven, gedaan met “CSS maakt je het leven eenvoudiger”, het verviervoudigt zich - Is er niet ooit een tijd geweest dat browser-sniffing als bad practise omschreven werd? Want eigenlijk komt het in principe daarop neer.
Ik ben volledig te vinden voor de vooruitgang met CSS3, eerder vandaag dan morgen, maar de browser prefixes moeten snel weg, ofwel ondersteuning, ofwel niet. De keuze nu om CSS3 te gebruiken zal zich beperken om kleine “coole” dingen te doen die juist dat beetje extra-touch geven aan een selectief aantal bezoekers, dus er moet al over nagedacht worden waar CSS3 te gebruiken.
Is het niet de bedoeling dat CSS3 het leven van de webdeveloper eenvoudiger zou moeten maken?, ik denk dat we er nog niet zijn, misschien morgen?
Gelezen: 1161 | CSS3, Testsuite, CSS







Op Monday 10 May 2010
Ik ben het met je eens. Ik zou ook heel graag al een aantal coole dingen gebruiken die met CSS3 zijn te realiseren, maar ik hou er ook zeker niet van dat mijn CSS bestand niet valide meer zal zijn. Vooral de mogelijkheid om andere lettertypes te gebruiken zal ik heel goed kunnen gebruiken.
Ik hoop ook dat de dag van morgen snel komt!
Op Monday 10 May 2010
Voor progressive enhancement is CSS3 zoals je zegt wel geschikt. Maar om het nu efficiënt te gebruiken wordt de CSS code er niet beter op.
Zelf maak ik als ik rounded corners wil hebben een css-class met die eigenschap en die hang ik dan (heel fout) aan de elementen die rounded corners moeten hebben. Niet mooi, maar altijd nog beter dan 8 regels in iedere class die het moet hebben.
Wat betreft die prefixes: Ja, die zijn vervelend, maar ik snap wel dat ze er zijn. De implementaties in de browsers verschillen nog of zijn niet compleet. Als alle browsers de hun huidige implementatie zonder prefix zouden doen, dan begint iedereen over een jaar weer te zeuren dat al hun harde werk van vorig jaar voor niets was. De implementatie is dan completer en daardoor zakt het design in elkaar.
Het is een beetje een slecht argument, want de meeste implementaties zijn ver compleet en de verschillen zijn maar klein, maar dat is nu eenmaal hoe het werkt. Het is dan ook een kwestie van beter iets dan niets!
Op Tuesday 11 May 2010
Als je echt compleet wil zijn moet je ook nog het volgende zetten:
transition-property: opacity;
transition-duration: 2s;
Kwestie van future proof te zijn. Eens de implementatie officieel is zullen die browser specifieke sytaxen vervallen.
Op Tuesday 11 May 2010
@Stijn, inderdaad, die was ik nog vergeten te vermelden, maar het kwam wel duidelijk over wat ik wilde duidelijk maken. Maar het is wel gek genoeg Opera en IE9 beta die alles ondersteunen (99%) en dat firefox, safari en chrome achter lopen, om dan te doelen op de future-proof syntax.
Op Tuesday 11 May 2010
@windvanger De vendor prefixes zijn erkend in de specs van css (zie hier) Dus in principe hoort een validator die syntax als valid te beschouwen.
Tegenwoordig wordt het systeem wel in vraag gesteld. Er was op quirksmode een uitgebreidde discussie over het laten vallen van de vendor prefixes, gevolgd door enkele alternatieve oplossingen omdat er toch problemen zijn met browser-specifieke implementaties zolang de standaard niet vast ligt.
Ondertussen wordt het nog extremer, ie mobile gaat de -webkit-text-size-adjust syntax implementeren (zie hier), wat eigenlijk weer zorgt voor een terugkeer van het oorspronkelijke probleem: zelfde syntax, andere interpretatie.
Op Thursday 20 May 2010
Noem het luiheid, maar van’t moment dat je uitzonderingen moet gaan schrijven per browser, haak ik af. Dit mag echt niet de manier zijn hoe CSS gebruikt wordt…
Op Thursday 20 May 2010
@Ben mee eens, maar ik zie dit niet echt als uitzonderingen. Uitzonderingen per browser betekend voor mij dat bepaalde attributen andere waardes per browser krijgen om het zelfde resultaat te krijgen. Zoals bij IE6 vaak het geval is. Dan haak ik af of zoek ik een work-around.
Gebruik de prefixes om sites bepaalde browsers een betere look te geven. De kritieke layout van een website doe je gewoon in CSS 2.1. En als je daarbij uitzonderingen moet maken dan is dat inderdaad niet hoe CSS gebruikt zou moeten worden.
Op Monday 12 July 2010
Structurele dingen als een menu met animaties zou ik er inderdaad nog niet mee gaan doen, maar hier en daar een kleine verfraaiing in css3 kan toch al wel denk ik hoor!
Op Wednesday 28 July 2010
Sja, ik loop nu tegen hetzelfde aan. Ik ben mijn blog een compleet redesign aan het geven en als webdesigner / developer wil je wel tot de voorhoede behoren. Dus dán maar die ellendige vendor prefixes. Er is echter wel een oplossing aan de horizon die het allemaal wat draaglijker maakt, namelijk LESS.css.
LESS is een soort CSS interpretor waardoor je eerder gedefinieerde variabelen en “mix-ins” kunt gebruiken binnen je classes. Met deze code maak je een mix-in die je kunt embedden in je classes om de transition properties te definieren aan de hand van parameters:
.transition(@property: all, @duration: 500ms, @ease: ease-in-out) {-moz-transition: @property @duration @ease;
-ms-transition: @property @duration @ease;
-o-transition: @property @duration @ease;
-webkit-transition: @property @duration @ease;
transition: @property @duration @ease;
}
a {
color: #F00;
.transition(color, 150ms);
}
a:hover {
color: #000;
}
Op Friday 27 August 2010
Helemaal eens met dit bericht. En wat te denken dat we net zover waren dat we met html/css/javascript de afzonderlijke disciplines gescheiden hadden. Wat doet een transition in css. Daar is toch javascript voor?
Op Thursday 09 September 2010
Nergens last van, laat PHP gewoon mijn CSS file parsen en /*{PREFIX*}*/ replacen afhankelijk van het browser…