Fronteers — vakvereniging voor front-end developers

Webrichtlijn 9: Cascading Style Sheets (CSS) Level 2.1

Gebruik CSS Level-2.1 volgens de W3C specificatie voor het vormgeven van overheidswebsites. (R-pd.2.6)

Eindelijk 'ns wat anders dan dat geneuzel over markup :) Laten we het eens gaan hebben over de presentatie van een website; Cascading Style Sheets.

De voordelen van CSS zijn voor iedereen ondertussen waarschijnlijk wel bekend, maar het is niet verkeerd om ze nog eens door te nemen.

CSS Level 3 wordt afgeraden, dus volgens de richtlijn mogen we alleen de volgende selectors gebruiken:

Wie gebruikt er al selectors uit CSS Level 3? Wat zijn daarbij je ervaringen?

Hoe ga je om met IE-only stijlen als zoom: 1; en filter: alpha(opacity=25);? Gebruik je die gewoon, ondanks dat ze niet in de standaard zijn opgenomen? Dezelfde vraag natuurlijk voor word-wrap: break-word;, -moz-opacity, -o-background-size en andersoortige eigenschappen die je niet weg kunt moffelen achter een conditional comment.

En kan iedereen zich trouwens vinden in de drie groepen browsers die de Webrichtlijnen onderscheidt?

Zien we deze richtlijn als een beperking? Of als een handvat waar we wat aan hebben? Wanneer vind jij dat CSS Level 3 of modules daarvan ook toegestaan mogen worden?

Reacties

1 Marcel op 19-02-2008 om 10:17 uur:
Je past toe wat je kan gebruiken voor jouw doelgroep.

Een grote web-applicatie die door duizenden random mensen wereldwijd bezocht kan worden hoort volledig compatible te zijn met tenminste IE6 (dus geen fancy CSS selectors) en zelfs IE5 als je ook de trageren der bevolking wilt bedienen - dit zijn immers ook klanten.

Pas als je controle hebt over het gebruik van de browser (dus: je kan eisen stellen aan de gebruikers) ben je vrij te doen wat je wilt.

Dat kan uiteraard een intranet zijn, maar ook een blog bijvoorbeeld, waarop je alleen een bepaalde groep mensen (Opera gebruikers?) wilt bereiken.

Zelf houd ik het bij CSS2 voor zover dit wordt ondersteund door IE7. Ik maak dan ook vooral web-apps waarbij we als bedrijf eisen stellen aan de gebruiker. De gebruikers werken niet met IE6, niet met Firefox en ook niet met IE8 wanneer die uit komt.

Dus nee, de richtlijnen zijn geen beperking, gebruikers en hun browser-voorkeuren zijn de beperkende factor. En tja, daar moeten we nou eenmaal rekening mee houden ;-)
2 Sander op 19-02-2008 om 12:15 uur:
Ik ben het niet compleet eens met Marcel dat gebruikers een beperkende factor zijn. Ja, natuurlijk, alle functionaliteiten moeten werken in IE6. Maar er zit een helehoop ruimte boven de pure functionaliteiten. Niet essentiële verfijningen zijn perfect om met geavanceerde selectors beschikbaar te maken aan de mensen die er al ondersteuning voor hebben, en je volgt het idee van progressive enhancement (the fscking IE8 meta element be damned) zodat dit waarschijnlijk in de toekomst ook voor de andere mensen beschikbaar zal komen, zonder dat je er iets voor hoeft te doen. (Dit heeft voor mij overigens van IE6 naar IE7 meerdere malen perfect zo gewerkt, waar ik met attribute selectors net iets meer kon bieden, maar het niet de moeite waard was een aparte class te inserten om dit voor IE6 ook aan te bieden.)

Qua CSS3 selectoren heb ik een aantal keren :last-child gebruikt, hoewel de grootste beperking daarmee altijd is geweest dat deze niet dynamisch geupdate werd in Gecko (e.a.? eigenlijk nooit getest in Opera...)
Met een beetje gelukkig verdwijnt die beperking in 1.9 (aka Firefox 3; zag tenminste vanochtend een bugmailtje waarin de relevante patch r+/sr+ kreeg, dus fingers crossed), en dan zal ik hier zeker meer gebruik van gaan maken. (Een voorbeeld is bij lijsten items met bij elk item een omhoog en omlaag knop. Omlaag doet niets bij het laatste item. Kan geen kwaad dat de knop dan te zien is, maar als je hem met een :last-child selector weg kan halen is dat wel zo netjes.)

Ik zit ook met smart te wachten op de nth-child pseudo-class (die ook met die patch mogelijk zou moeten gaan worden in Gecko, hoewel ik niet ver genoeg heb gelezen om te weten of dit daadwerkelijk gelijk beschikbaar zal zijn, of dat dit alleen backend support toevoegt). Fantastisch dat acid3 hierop test - dat betekent waarschijnlijk dat alle browsers deze binnen een jaar of twee zullen ondersteunen.

In het algemeen ben ik van mening dat het acceptabel is om alle CSS3 modules die zich in candidate recommendation fase bevinden te gebruiken (de webrichtlijnen zouden echt het concept van "modules" moeten doorkrijgen - CSS3 is niet één specificatie, maar een groot aantal, ieder op een eigen punt van de support timeline), zelfs als bestaat er nog geen browser support voor. De specificatie is leidend. Dus color, media queries, en UI (selectors is een beetje een raar geval, omdat die van CR terug is gegaan naar WD om o.a. :contains() eruit te knikkeren) zouden wat mij betreft (bij behoefte eraan) zonder problemen gebruikt kunnen worden. Zolang er maar niet op vertrouwd wordt op een manier die browsers (gebruikers) uitsluit.


Verder...
Oh, ik gebruik als ik er even mee kan wegkomen browser-specific CSS extensions alleen als ze syntactisch geldige CSS zijn. Dus wel -moz-opacity (lang geleden in de tijd dat normaal opacity nog niet werkte in Gecko), maar geen filter. Soms heb je (binnen de parameters van het project) geen "keus", en dan moffel je de IE-syntax zover mogelijk weg zodat normale browsers het nooit zullen hoeven te parsen, maar het is eigenlijk al jaren geleden dat mij dat voor het laatst is overkomen.
Overigens hou ik -moz-, -o-, -khtml- e.a. alleen voor eigen gebruik - nooit in commerciële sites, want een expliciete aanname bij alle vendor-specifieke properties is dat ze nog niet "af" zijn, en dus zonder waarschuwing sterk kunnen veranderen (meestal n.a.v. veranderingen in de specificatie, soms om bugs in de implementatie op te lossen). Dat is acceptabel als je deze veranderingen volgt en voor de komende 5 jaar gegarandeerd toegang hebt tot de site om je CSS onmiddelijk te fixen, maar bij commerciële sites kan ik daar als freelancer natuurlijk niet op vertrouwen, en ik vind het niet acceptabel een mogelijke opvolger met de problemen van zo'n keus te laten zitten.

Zo... dat was m'n halve lunch-pauze. Hrm, voortaan misschien ietsjes korter van stof proberen te zijn... :)
3 Egor Kloos op 19-02-2008 om 14:46 uur:
Ik gebruik geen CSS3 selectoren. Je laat de klant een risico lopen dat het selector niet wordt ondersteund. Wie zegt dat het CSS3 voorstel (draft) niet wordt veranderd of dat browsers er afstand van doen? Daarnaast gebruik ik geen ongedocumenteerde selector-hacks zoals "* html", dat zou gewoon dom zijn.

Op ten duur ga je wel deze CSS3 aanvullingen meenemen. Bij brede browser ondersteuning kun je implementatie overwegen, mits er ook onafhankelijke documentatie (W3C) voor bestaat. Let wel dat er verschil bestaat tussen 'drafts' en 'recommendations'.

Wat de 3 groepen browsers betreft kan ik wel me wil in vinden. Wel jammer van het subjectieve taal gebruik. Ook is het tijdsgebonden. Mobiele browsers en desktop browsers zullen straks niet van elkaar te onderscheiden zijn en dan blijft er weinig over van IE's dominantie. In mijn beleving streven deze richtlijnen naar een agnostische aanpak waarij de specifieke browser van onderschikte belang is. Welke populair is is qua taak belangrijk maar structureel niet. Duurzaamheid is impliciet browser ongebonden.

De regel om CSS3 selectoren af te raden is daarom goed. En basis dat duidelijk gedocumenteerd is en goed is uitgewerkt is noodzakelijk. Alles daarboven is voor eigen rekening, of liever de klant z'n rekening.
4 Sander A op 20-02-2008 om 01:38 uur:
@Marcel
"Zelf houd ik het bij CSS2 voor zover dit wordt ondersteund door IE7. Ik maak dan ook vooral web-apps waarbij we als bedrijf eisen stellen aan de gebruiker. De gebruikers werken niet met IE6, niet met Firefox en ook niet met IE8 wanneer die uit komt."

Als ik het goed begrijp is de eis die gesteld wordt dus niet dat JavaScript ondersteund wordt of Flash 9 ofzo, maar een specifieke browser (IE7).
Is dat niet precies de werkwijze die ertoe geleid heeft dat Microsoft nu meent dat het, met de komst van IE8, een version switch moet introduceren?
5 Marcel op 20-02-2008 om 10:36 uur:
@Sander A:

Ik ben niet tegen op die version switch moet ik zeggen - persoonlijk ben ik er nog wel van gecharmeerd, zeker met het oog op web-applicaties die ter aller tijde compatible kunnen blijven. Straks met IE8 en beyond kunnen we gewoon aangeven dat de applicatie in IE6-mode moet draaien.

Dan krijgen we dus de updates en security van de nieuwe browser (IE8, IE12, whatever) en kunnen we ook applicaties die al enige jaren oud zijn blijven gebruiken zonder dagen lang te spenderen om alle schermen werkende te krijgen in alle gangbare browsers.

Dus ja, we zeggen gewoon "gebruik IE7". En de reden daarvoor is simpel: Microsoft IE en Mozilla Firefox doen beide hun eigen ding. Ze zijn niet voorspelbaar genoeg in hun doen en laten. Ze zeggen beide misschien CSS2 te ondersteunen, maar doen dat op hun eigen manier. Ze zeggen beide PNG te ondersteunen maar doen dat beide op hun eigen manier (werkt animated PNG al in FF?).
6 Kilian Valkhof op 20-02-2008 om 11:51 uur:
Met dit kan je heel goed progressive enhancement toepassen. Je standaard layout en functionaliteit kun je prima met css2.1 bouwen. Leuke kleine extra dingetjes gebruik ik zonder moeite css3 voor. maar dus enkel voor niet-missie-kritieke onderdelen. Volgens mij is dat ook de essentie van deze richtlijn.

Dat onderscheid tussen browsers is volgens mij theoretisch leuk maar weinig relevant: je moet er voor zorgen dat je site werkt in de browsers van je doelgroep, ongeacht in welke groep hij zich bevind.

Ik gebruik IE specifieke dingen als filter en zoom zeer geregeld, deze zijn goed gedocumenteerd, veranderen niet en bieden wel een oplossing voor een aantal problemen zonder dat andere browsers daar last van hebben (immers, ze staan in conditional comments). Ik ben het dan ook niet eens met Egor, in mijn ie stylesheet kan ik best * html gebruiken om onderscheid te maken tussen ie6 en ie7. Scheelt weer een pagerequest en blijft ook gegarandeerd werken.

CSS properties met vendor-prefix gebruik ik enkel zoals Sander A ze gebruikt. omdat ze nog kunnen veranderen enkel op sites waar ik ten alle tijden volledige controle over heb.

Overigens kunnen we een flink aantal selectors uit die opsomming nog steeds niet gebruiken, dus waar hebben we het nou helemaal over... ;)
7 Egor Kloos op 21-02-2008 om 00:04 uur:
@Killian

Ik blijft tegen * html. Daarentegen gebruik ik wel html>body om een pagerequest te voorkomen.

De ene is gedocumenteerd en de andere is verzonnen. * html bleek toevallig te werken en nu moeten de browsers deze hack blijven ondersteunen.

We roepen altijd dat Microsoft beter hun best moet doen, helemaal mee eens. Echter, het is ook zo dat zij deze hack in IE7 moesten proppen omdat zogenaamde 'web standards' pagina's anders zou breken.
8 Sander A op 21-02-2008 om 11:15 uur:
@Egor:
Als MS zorgt dat IE hetzelfde niveau behaald als Fx, Op en Sf qua ondersteuning van de webstandaarden, dan hoeven ze die * html, of zijn IE7-evenknie, helemaal niet meer te ondersteunen.
Deze 'hacks' (tussen aanhalingstekens, want het is wel degelijk een correcte CSS-selector) worden gebruikt om onderscheid te maken tussen browsers. Je kunt er dus denk ik van uitgaan dat sites waarin dit gebruikt wordt ook rekening houden met andere browsers, hoogstwaarschijnlijk Fx. IEx kan bij die sites dus terugvallen op de CSS-definities die voor de meer standaards compliant browsers zijn opgegeven.
9 Egor Kloos op 22-02-2008 om 09:25 uur:
@Sander A

Ik wist niet dat er een DOM element bestaat waarin het HTML node staat. Weet je hoe die heet? Dan zoek ik het even op.
10 Sander A op 22-02-2008 om 11:34 uur:
@Egor:
Ja, die heet * ;)

Maar goed, niemand weet dus hoe die vreemde schil in IE heet, vandaar de *
Maar dat er een fout zit in de implementatie van de DOM wil niet zeggen dat * html en *:first-child+html geen valide CSS selector zijn. #myID is ook een valide selector, zelfs wanneer er geen element is met id="myID".
11 Egor Kloos op 22-02-2008 om 12:53 uur:
Excuses voor mijn sarcasme, hierboven. Er zit inderdaad iets om de HTML heen, technisch weet ik het ook niet helemaal. Anyway.

Het gaat mij er slechts om dat in CSS en HTML deze magische "asterisk" bovenlaag niet is beschrijven. Niet zo vreemd eigenlijk omdat deze 'laag' eigenlijk voor de browser is bedoeld en niet voor de front-end. Hoewel raar is er qua syntax niet al teveel aan de hand. Validatie is niet wat mij dwars zit.

Wat mij dwars zit is dat er een hack is verzonnen die toevallig werkte en nu een ongedocumenteerde standaard is. Dat browsers nieuwer dan IE6 deze hack achteraf altijd moeten inbouwen (oftewel negeren) en testen is in mijn ogen een gevaarlijk precedent.
CSS en HTML documentatie hebben dergelijk browser elementen nooit beschreven, Mircosoft heeft zichzelf lelijk in de vingers gesneden. Niets nieuws eigenlijk.

Persoonlijk weiger ik zulke vage hacks toe te passen. De holly hack refereert aan een niet bestaand HTML element en het is gevaarlijk om assumpties te maken over hoe dergelijke hacks in de toekomst zullen werken. Zo kom je nooit van Quirksmode af. Gebruik work-a-rounds die werken binnen goed omschreven standarden. Moeilijk is het niet, er zijn alternatieven zat.
12 Krijn op 22-02-2008 om 13:50 uur:
CSS selectors zijn niet alleen voor HTML, vandaar dat * html gewoon een goede selector is.

En de bugjes bij het parsen van nadruk met een * en een * zijn verholpen (hoop ik). Ik heb de reacties die daarover gaan even verwijderd.
13 Sander A op 22-02-2008 om 14:28 uur:
@Egor:
Een beetje sarcasme op z'n tijd kan geen kwaad.

"Dat browsers nieuwer dan IE6 deze hack achteraf altijd moeten inbouwen (oftewel negeren) en testen is in mijn ogen een gevaarlijk precedent."

Zoals ik in een eerdere post probeerde duidelijk te maken speelt dat bij deze 'hacks' niet. Althans niet meer zodra IE een vergelijkbaar niveau bereikt als bv. Firefox.
Dit is niet vergelijkbaar met andere IE-only zaken zoals window.event waarbij IE niet de standaard ondersteund, maar alleen zijn eigen variant. IE-only sites die daar gebruik van maken hebben geen fallback voor browsers die zich wel aan de standaarden houden, waaronder hopelijk ook toekostige versies van IE.
Het gebruik van * html #myID {} suggereert echter dat er ook een #myID {} is, wat wel door standards compliant browsers wordt herkend. Wat heeft * html anders voor zin?

@Krijn: Dat hoop ik ook! ;-)
14 Egor Kloos op 22-02-2008 om 17:14 uur:
@Sander

Ik ben helemaal met je eens, en ik bestrijd het allemaal niet. Ik vind het gewoon een slecht idee om in een selector elementen te gebruiken die niet goed of helemaal niet zijn beschreven.
15 Raph de Rooij op 26-02-2008 om 08:31 uur:
@Sander: Je schrijft: "de webrichtlijnen zouden echt het concept van "modules" moeten doorkrijgen. CSS3 is niet één specificatie, maar een groot aantal, ieder op een eigen punt van de support timeline"

Het concept van modules gaan de Webrichtlijnen pas door krijgen op het moment dat één van die modules de status van 'recommendation' krijgt; dat is het moment waarop we er iets mee aanmoeten. Verder begrijp ik de bedoeling van de opmerking niet helemaal, vrees ik. Ik ben bekend met http://w3.org/Style/CSS/current-work.html#CSS3.
Nog geen enkele van de modules is op dit moment een 'candidate recommendation'. Wellicht bieden, in het kader van de Webrichtlijnen, CSS Snapshots enig houvast. Maar het is nog te vroeg om daar iets zinnigs over te zeggen...

Overigens, over CSS3 wordt in de huidige versie van de Webrichtlijnen maar weinig gezegd, anders dan dat het een nog in ontwikkeling zijnde standaard is. Om die reden wordt het gebruik van CSS3 (nog) niet wordt aangemoedigd.
De WebrichtlijnenToets gaat er echter niet rigide mee om en keurt het niet fout (dat is dus niet hetzelfde als goedkeuren...) als CSS wordt gebruikt die voldoet aan het huidige CSS3 profiel van de validator.
16 Sander op 26-02-2008 om 11:35 uur:
@Raph: Je zegt dat nog geen enkele module een candidate recommendation is, maar Media Queries, CSS Color Level 3 en CSS Basic User Interface zijn dat wel. (En CSS Ruby en CSS TV Profile 1.0, maar die zijn voor ons niet van belang.)
Bovendien zijn Paged Media, Print, Text en Selectors in het verleden candidate recommendation geweest, dus ook die hadden op dat moment gebruikt kunnen worden.

Bedoelde je "proposed recommendation" i.p.v. "candidate recommendation"? If so, dan is dat naar mijn mening een veel te laat punt in het proces voor ons als front-enders om op te wachten, en dus ook voor de webrichtlijnen.
Voordat een W3C document tegenwoordig naar proposed recommendation kan moet er eerst een extreem uitgebreide test suite beschikbaar zijn (omdat er anders niet kan worden aangetoond dat er twee 'interoperable' implementaties zijn (dit is een van de dingen die vroeger niet bestonden in het W3C proces, wat ons zulke slecht gespecificeerde recommendations als CSS 2 en vooral HTML 4.01 heeft opgeleverd)), wat letterlijk jaren extra kost. CSS 2.1 is bijvoorbeeld nog steeds jaren verwijderd van Proposed Recommendation doordat die test suite zoveel tijd kost, en toch is CSS 2.1 het document dat iedere front-ender moet kennen, en dat door iedere browser wordt geïmplementeerd.


Mijn originele opmerking waarvan jij de bedoeling niet begrijpt ging over de begeleidende teksten op de webrichtlijnen site - http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/richtlijnen/#css-3 - zoals bijvoorbeeld: "Vanwege het nog in ontwikkeling zijn van de CSS Level-3 specificatie en het belang van het gebruik van open standaarden wordt het gebruik van CSS Level-3 echter afgeraden."
Dat is naar mijn mening iets dat gebruikers van de webrichtlijnen die verder niet bekend zijn met het W3C proces een sterk verkeerd beeld voorschotelt. Er zijn modules van CSS 3 die absoluut nog niet gebruikt moeten worden (waarvan het gebruik sterk afgeraden moet worden) zoals bijvoorbeeld de line module, en er zijn modules van CSS 3 die zonder problemen wel gebruikt kunnen worden (of in ieder geval waarvan het gebruik niet afgeraden moet worden), zoals de voorgenoemde modules die nu in candidate recommendation zijn.

(Ter verduidelijking nog: Wat mij betreft hoeven de richtlijnen zelf dus niets te zeggen over CSS3/modules, maar de handleiding zou accurater moeten zijn.)
17 Anne van Kesteren op 07-03-2008 om 15:36 uur:
Ik ben het niet eens met deze richtlijn. CSS evolueert. Het kent geen versies. Ik stel voor dat jullie het hierop baseren:

http://www.w3.org/TR/css-beijing/
Plaats een reactie