Selector, identiteit, class, specificiteit: hoe overleef ik de nieuwe klassenstrijd?

Inline-style

Soms zie je css gebruikt worden op dezelfde manier als in het verleden de opmaak-tags van html:

Bij elke tag staat de css die bij die tag hoort: een inline-style. Een Nederlandse naam hiervoor bestaat, voor zover ik weet, niet. Omdat de css gelijk achter de tag staat, hoef je verder niet aan te geven, bij welk html-element de css hoort.

Dat is dan ook het enige voordeel. Als je iets wilt veranderen, moet je dat nog steeds op achtduizend plaatsen doen. De bestanden zijn nog steeds groter dan nodig. Bovendien kunnen dingen als :hover nooit werken met een inline-style. Enz., enz.

Een inline-style kan wel uiterst handig zijn bij het maken van een pagina, om even snel iets uit te proberen, of om erachter te komen waarom de foto van ome Piet pertinent weigert naast z'n echtgenote tante Klazina te blijven staan, maar steeds bovenop de foto van de buurvrouw springt. (Disclaimer: dit is slechts een verzonnen voorbeeld. Elke overeenkomst met de werkelijkheid berust op toeval.)

Stijlregels

Met uitzondering van de methode hierboven, waarbij de css gelijk achter de bijbehorende tag staat, moet op een of andere manier worden duidelijk gemaakt, bij welk element bepaalde css hoort. Dit gebeurt met behulp van een stijlregel (in het Engels style rule). Bij zowel een stijlblok in de head van een pagina als bij een extern stijlbestand gebeurt dit op dezelfde manier.

Een stijlregel is altijd op dezelfde manier opgebouwd:

Tussen de accolades staat de eigenlijke css. Dat zijn altijd één of meer eigenschappen met bijbehorende waarde of waarden. Vóór de openings-accolade staat de eigenlijke selector. Deze bepaalt, waarvoor de css geldt, en om dat deel gaat het hier. De css die tussen de accolades staat, heeft geen invloed op waar de css voor bedoeld is. De selector selecteert, waar de css voor geldt.

Enkelvoudige selector

In bovenstaande regel is de selector de p. Deze hoort bij het element <p>. De selector is gewoon de naam van het element, zonder de < en >. Bij een <p> houd je dan dus een p over, bij een <div> div, bij een <h1> h1, enz.

Omdat in de bovenstaande regel alleen een p staat, heet dit een enkelvoudige selector. Enkelvoudig, omdat er maar één element wordt genoemd. Selectors kunnen enorm ingewikkeld worden, dit is de meest simpele vorm.

Deze selector is heel eenvoudig. Dat is lekker makkelijk, maar het nadeel is dat hij heel grof is. Omdat er geen enkele beperking is, geldt deze selector voor álle <p>'s. Zonder uitzondering. Heel vaak is dat te grof, omdat bijvoorbeeld niet alle tekst dezelfde kleur moet krijgen, dezelfde lettergrootte, enz.

Meerdere selectors

Het komt vaak voor dat meerdere elementen dezelfde css moeten krijgen:

Dit is maar heel weinig css, maar als er ook nog een border, outline, enz. bij komen, wordt dit natuurlijk onwijs veel. Gelukkig kun je in één stijlregel meerdere selectors gebruiken:

In de onderste regel staat precies hetzelfde als in de drie afzonderlijke regels daarboven. De drie selectors worden gewoon achter elkaar gezet, vóór de eerste accolade, gescheiden door een komma. Je kunt zo een onbeperkt aantal selectors dezelfde css geven.

Let er wel op dat je de komma niet vergeet. Zonder komma krijg je een Gecombineerde selector, zoals gelijk hieronder wordt beschreven, en dat is heel wat anders dan twee afzonderlijke selectors.

Gecombineerde selector

Ook in Nederland wordt deze selector vaak met zijn Engelse naam aangeduid: descendant selector. 'Descendant' betekent 'afstammeling'. Bij selectors, html, en dergelijke wordt een indeling gebruikt, die heel erg lijkt op die van een familie.

In bovenstaande regel is de selector div h2. De standaard-lettergrootte van een <h2> wordt verkleind tot 1,2 em. Maar dit geldt hier niet voor élke <h2>. Omdat h2 volgt op een div en een spatie, geldt het hier alleen voor een <h2> die binnen een <div> staat.

De h2 is een 'descendant', een afstammeling, van de div. <h2>'s die buiten een <div> staan, worden niet beïnvloed door deze regel, omdat ze niet aan de voorwaarde van de selector voldoen: ze zijn geen afstammeling van een <div>.

Op deze manier is het mogelijk om, met twee stijlregels, alle <h2>'s rood te maken, behalve als ze binnen een <div> staan. Die maak je met behulp van een tweede regel groen:

Door op zo'n manier elementen te combineren krijg je al iets meer mogelijkheden. Dit kan in theorie heel diep gaan:

Een <abbr>, maar alleen als die binnen een <strong> staat, maar alleen als die <strong> binnen een <span> staat, maar alleen als die <span> binnen een <p> staat, maar alleen als die <p> binnen een <div> staat. Alleen als aan ál deze voorwaarden is voldaan, geldt deze regel.

Toch zijn deze gecombineerde selectors nog steeds vaak veel te grof. Want wat als je alleen elke tweede <h2> binnen een <div> groen wilt maken? Of alleen de zevende, maar niet in élke <div>?

Daarvoor moeten we het element in een class indelen of het 'n naam geven, een identiteit.

Name

Het gebruik van name wordt al meer dan tien jaar afgeraden. Het is helemaal nooit bedoeld geweest voor css. Tot de dag van vandaag kom je het regelmatig tegen bij een link, zodat die link als anker kan worden gebruikt. Een anker is een plaats ergens binnen een pagina, waar naartoe kan worden gelinkt:

En dan elders op de pagina (of in iets andere vorm op een andere pagina):

Door op 'hiero' in de onderste regel te klikken, schiet de browser naar het anker in de bovenste regel. Dit wordt al meer dan tien jaar afgeraden. Wat mij betreft komt hier na de revolutie vijf jaar mosselen opduiken in Zeeland op te staan. Met zuurstofflessen, want ik ben de rotste niet.

Ik noem name hier, omdat nog steeds met grote regelmaat op forums de vraag verschijnt, waarom css niet werkt. Onbegrijpelijk, want 'het is toch goed aan name gekoppeld'. Simpel antwoord: omdat het er helemaal niets mee te maken heeft. En het gebruik van name voor ankers wordt dus al meer dan tien jaar afgeraden. Naar een id kun je ook een anker maken, en nog veel meer.

name mag alleen nog worden gebruikt bij het verzenden van bepaalde onderdelen van een formulier (<form>) naar de server. De server heeft dat nodig om bepaalde onderdelen van het formulier te kunnen verwerken. Daarnaast wordt name nog gebruikt bij <map> en <param>. Afgezien van deze drie toepassingen is er geen enkele reden om name te gebruiken. Nergens voor. Nooit. Denk aan de mosselen.

Class

Een class is te vergelijken met een schoolklas. Een schoolklas bestaat uit een (groot) aantal kinderen. Een class bestaat uit een (groot) aantal elementen. En zoals kinderen uit een klas hetzelfde krijgen te leren, krijgen die elementen allemaal precies dezelfde css. (Voordat woeste ouders beginnen te klagen: bij kinderen wordt dat hopelijk wel enigszins individueel aangepast.)

Om een element lid te maken van een class, moet je het element in de html indelen in een class:

De bijbehorende stijlregel:

Om aan te geven dat tekst de naam van een class is, wordt die in de css voorafgegaan door een punt. p.tekst wil dus zeggen: alle <p>'s die de class-naam 'tekst' hebben. Dat kan één <p> zijn, maar het kunnen er ook driehonderd of drieduizend zijn (hoewel er dan waarschijnlijk betere manieren zijn, maar dat voert hier te ver).

Je mag zo vaak als je wilt dezelfde class gebruiken op een pagina, ook met verschillende soorten elementen. Als je ook een <h1> met dezelfde kleuren hebt als de p.tekst hierboven, komt die er gewoon bij te staan in de css:

De verschillende selectors worden gescheiden door een komma, net als bij meerdere selectors zonder class.

Ook de gecombineerde of descendant selector kun je gebruiken:

Deze css is geldig voor álle <p>'s met class="tekst". Daarnaast is hij geldig voor de <h2>'s met class="tekst", maar alleen als die binnen een <div> staan. Dit werkt precies hetzelfde als bij alle gecombineerde selectors.

Ook een stijlregel als de volgende is mogelijk:

Nu wordt élk element, ongeacht welke soort het is, met een class="tekst" aangesproken. De punt geeft aan dat het om een class gaat, en omdat er geen enkel element voor staat, worden automatisch álle elementen verondersteld.

Selectors met een class kunnen ook gewoon worden gecombineerd met selectors met een id. Pardon, een id?

id

Als de hele klas een musical aan het zingen is, is het fantastisch als ze allemaal netjes de maat houden en zo. Hoe meer ze hetzelfde doen, hoe beter het is. De klas gedraagt zich, en moet zich gedragen, als een class.

Maar als er een spreekbeurt gehouden moet worden, is het wat onhandig als de hele klas naar voren rent en hetzelfde verhaal begint op te dreunen. Bij een spreekbeurt horen we liever een individu, iemand met een eigen persoonlijke identiteit, een id, niet de hele class.

Om degene die de spreekbeurt gaat houden aan te kunnen spreken, moet die een naam, een eigen identiteit, hebben. Bij kinderen uit een klas is dat een jongens- of meisjesnaam, bij css heet dat een id.

id is een afkorting van identity. Het belangrijkste verschil met een class is dat een id maar één keer gebruikt mag worden op een pagina. Ook al zijn het verschillende elementen, ze mogen toch niet dezelfde id hebben.

Anders dan bij kinderen met dezelfde naam uit één klas, kun je bij een technische taal prima regelen dat er geen twee id's met dezelfde naam op één pagina staan: gewoon verbieden. Kinderen met dezelfde naam kun je ook wel verbieden, maar dat levert toch al snel ernstige ethische en juridische problemen op.

Het is vrij makkelijk om twee keer dezelfde id te gebruiken op één pagina. Soms gaat dat goed, soms levert dat een volledig verstoorde pagina op. Daar is weinig zinnigs over te zeggen: het ligt eraan, waar de dubbele id toevallig staat, aan de gebruikte browser, enz. Voor het voorkomen van dit soort fouten is een validator ideaal.

Een validator controleert een taal op syntactische fouten: fouten tegen de regels. 'Intelligente' fouten worden meestal niet gevonden. Een afschuwelijke kleurencombinatie wordt enthousiast gevalideerd. Maar iets als een dubbele id vinden, daar is een validator erg goed in.

html kan worden gevalideerd op validator.w3.org.

css kan worden gevalideerd op jigsaw.w3.org/css-validator.

Om een element een id te geven, moet je het in de html gewoon de naam van een id geven:

De bijbehorende stijlregel:

Om aan te geven dat tekst de naam van een id is, wordt het in de css voorafgegaan door een #. p#tekst wil dus zeggen: de <p> die de id 'tekst' heeft. Dat kan per definitie maar één <p> per pagina zijn. Ook andere elementen op dezelfde pagina mogen niet diezelfde id hebben. Op andere pagina's van dezelfde site mag wel weer dezelfde id worden gebruikt.

Je kunt selectors met een class en met een id gewoon combineren in dezelfde stijlregel. Als je ook een <h1> met dezelfde kleuren hebt als de p#tekst hierboven, komt die er gewoon bij te staan in de css:

Dit werkt precies hetzelfde als bij alle meerdere selectors.

Ook de gecombineerde of descendant selector kun je gebruiken:

Deze css is geldig voor álle <p>'s met class="tekst". Daarnaast is hij geldig voor de <h2>'s met class="tekst", maar alleen als die binnen een <div> staan. Die <div> moet bovendien een id="header" hebben.

<h2>'s binnen een <div> met bijvoorbeeld een id="footer" (div#footer), of een <div> zonder id, worden niet aangesproken door deze regel. Dit werkt verder precies hetzelfde als bij alle gecombineerde selectors.

Ook een stijlregel als de volgende is mogelijk:

Nu wordt het element met id="tekst", ongeacht welke soort het is, aangesproken. De # geeft aan dat het om een id gaat, en omdat er geen enkel element voor staat, maakt de soort element niet uit. Maar ook hier mag maar één element op een pagina dezelfde id hebben. Zoiets is handig om bijvoorbeeld alle div#footer's op alle pagina's dezelfde css te geven.

Wanneer een class en wanneer een id?

Daar is weinig over te zeggen, wat niet wegneemt dat er complete bibliotheken over vol zijn geschreven door classici en idealisten.

Het belangrijkste verschil is dat je een id maar één keer mag gebruiken op een pagina, en een class zo vaak als je wilt.

Verder heeft een id meer specifiteit, maar dat speelt nauwelijks een rol bij het kiezen voor id of class.

Een echt verschil is het gebruik als anker. Een anker is een plaats binnen een pagina, waar naartoe kan worden gelinkt vanuit dezelfde pagina of vanaf een andere pagina. Elk element met een id kan als anker worden gebruikt:

Naar deze <h2> kan vanaf elke plek op de pagina worden gelinkt:

Vanaf een andere plek op internet zet je er de naam van de pagina en eventueel ook nog de naam van de site bij.

Als een element ook als anker wordt gebruikt, kun je dus beter een id dan een class gebruiken.

Verder is het eigenlijk vooral een kwestie van voorkeur. Ik gebruik bijvoorbeeld een id bij de inhoudsopgave bovenaan de pagina's met uitleg. Een inhoudsopgave mag maar één keer op de pagina staan. Daarom lijkt een id hier meer op z'n plaats. En omdat ik html en css ontzettend vaak valideer, krijg ik gelijk een melding als ik per ongeluk twee keer de id 'inhoud' zou gebruiken.

Veel sitebouwers gebruiken ook id's als 'header' en 'footer'. De hele header staat in een <div> met id="header", en de footer in een <div> met id="footer". Dat maakt het een stuk makkelijker om de weg te vinden in de stylesheet (het bestand met de css).

(html5 komt met een hele serie nieuwe elementen met namen als header, footer, menu, en dergelijke. Dit maakt in de toekomst het gebruik van dingen als een <div> met id="header" overbodig. Belangrijkste is dat pagina's hierdoor veel beter toegankelijk gaan worden voor spraakbrowsers en dergelijke, en dus ook voor zoekmachines. Alle browsers ondersteunen deze nieuwe elementen al, behalve Internet Explorer 8 en eerder. Voor deze oudere browsers kunnen deze elementen bruikbaar worden gemaakt door het gebruik van wat JavaScript.)

Geldige namen

Een naam moet met een hoofd- of kleine letter beginnen. Na die beginletter mogen cijfers, verbindingsstreepjes ('-', hyphen in het Engels) en onderstrepingen ('_', underscore in het Engels) worden gebruikt.

Daarnaast mogen ook dubbele punten en punten worden gebruikt. Maar dit kun je beter niet doen, omdat bijvoorbeeld een JavaScript-bibliotheek als jQuery daar problemen mee zou hebben.

In feite is het dus heel simpel: beginnen met een letter en alleen letters, cijfers, verbindingsstreepje en onderstreping gebruiken.

Persoonlijk gebruik ik altijd kleine letters in namen voor een class of id. In het verleden, en mogelijk nog steeds, maakten sommige browsers onderscheid tussen kleine letters en hoofdletters. Er zijn op dat gebied ook verschillen tussen Windows en alle andere besturingssystemen. En de meeste computertalen maken ook verschil tussen hoofd- en kleine letters.

Hoe het tegenwoordig precies zit, weet ik niet. Om problemen te vermijden gebruik ik gewoon alleen kleine letters. Je kunt ook alleen hoofdletters gebruiken. Of een combinatie. Als het maar steeds hetzelfde is, dan weet je zeker dat er geen problemen ontstaan in een of andere exotische browser of een buitenaards besturingssysteem.

Een veel gebruikte combinatie van hoofd- en kleine letters heet in goed Nederlands CamelCase (een Nederlandse vertaling bestaat, voor zover ik weet, niet). Hierbij begint elk deel van een naam met een hoofdletter. Iets als hoofdtitel wordt dan hoofdTitel of HoofdTitel.

Persoonlijk vind ik het beter om áltijd kleine letters te gebruiken, omdat je al snel een hoofdletter kunt vergeten. En hoofd-titel is volgens mij minstens even duidelijk als HoofdTitel. Maar goed, dit is voornamelijk een kwestie van persoonlijke voorkeur en van zorgvuldig werken.

Beschrijvende namen

Het is geen goed idee de naam van een html-tag te gebruiken als naam voor een class of id. In het verleden gaf dat problemen in sommige browsers. Daarnaast is het hoogst verwarrend. Het verschil tussen body en .body in een stijl is maar één puntje verschil in schrijfwijze. Maar in de uitwerking is het het verschil tussen het element <body>, dus de hele pagina, en de class "body", dus alleen de elementen met een class="body". Een wereld van verschil.

Het gebruik van dit soort namen voor classes en id's maakt css uiterst moeilijk te begrijpen en is vragen om fouten. Het missen van één rottig puntje kan eindeloze zoekpartijen naar een fout opleveren.

Een hele leuke, die steeds terugkomt op forums, is het gebruik van namen als "groene-knop" en "rode-knop". Als je deze code leest, is nog wel te begrijpen welk element er wordt bedoeld. Alleen, als je later besluit om 'rood' en 'groen' om te wisselen, omdat dat toch mooier is, zit je dus tot in de eeuwigheid met code die eigenlijk alleen voor een kleurenblinde nog is te volgen. Elke keer moet je eraan denken dat div#groene-knop de rode knop is, en omgekeerd.

Een aardige variant op bovenstaande is die met namen als "span-1", "span-2", (...), "span-327". Over zeven maanden weet je echt niet meer, wat voor soort span span-37 is. Terwijl je over zeven maanden nog wel weet wat de bedoeling van <span class="waarschuwing"> is. En heb ook een beetje medelijden met anderen die jouw code moeten lezen, zoals bij vragen op een forum het geval is...

Het is dus beter om geen naam te kiezen, die voor iets staat dat later veranderd kan worden, zoals een kleur of een positie. De naam 'rechter-kolom' lijkt in eerste instantie prima. Tot je je realiseert dat het met css kinderlijk eenvoudig is om de rechterkolom aan de linkerkant neer te zetten, omdat dat toch beter blijkt te zijn. Hier kan zelfs kleurenblindheid geen redding meer bieden.

Betere namen beschrijven wat het element doet, het zijn beschrijvende namen. Een naam als 'sidebar' is goed, want sidebar zal altijd aan de zijkant staan. De kans dat een sidebar plotsklaps in het midden wordt neergezet, is niet heel erg groot. 'Menu', 'header', 'footer' zijn ook goede namen. De kans dat een header opeens footer wordt, is ook niet zo heel erg groot.

<code class="html">(...)</code> en <code class="css">(...)</code> zijn prima. De tag maakt duidelijk dat het code is, en de class maakt duidelijk wat voor soort code het is. En met behulp van css kun je eventueel het verschil accentueren. De kans dat html plotsklaps in css verandert, is ook niet heel erg groot.

De combinatie van de juiste html-tags en de juiste namen van id's en classes maakt code echt 'n heel stuk begrijpelijker. En voorkomt mede daardoor conflicten tussen verkeerd gebruikte namen.

Conflicten tussen namen van classes en id's kun je ook helpen voorkomen door namen in te delen in groepen. Zo begint op mijn eigen site - tenzij dat echt niet anders kan - elke id die als anker binnen de pagina wordt gebruikt met 'a-'. Die begin 'a-' is gereserveerd voor deze 'lokale' id's. Id's die op meerdere pagina's kunnen worden gebruikt, beginnen nooit met 'a-'.

Dit voorkomt dat ik voor een anker een id kies, die al wordt gebruikt in een externe stylesheet. En dat voorkomt dus weer eindeloze zoekpartijen: ik begrijp het niet, ik heb hier alleen maar 'n anker, en er verschijnt opeens een marge aan de bovenkant... Dat soort dingen. (Ja, klopt, hier spreekt de afdeling Schade en Schande en Wijs worden.)

Terzijde: als je in de code van mijn eigen site kijkt, zie je dat ook ik soms zondig. Een van de redenen is dat ik net een echt mens lijk. Daarnaast is het soms heel lastig een echt beschrijvende naam te vinden. Ik gebruik bijvoorbeeld <code>. Met behulp van css heb ik die een bepaalde opmaak gegeven. De onderste regel moet echter een grotere marge krijgen.

Met de nieuwste css-selectors zou dat waarschijnlijk wel zonder extra class-naam te regelen zijn, maar die worden nog niet goed ondersteund. Dus geef ik de onderste regel een class="onder".

<code class="css"> en <code class="html"> klopt meestal op mijn site. Maar soms smokkel ik en gebruik 'css' in plaats van 'html'. Om nou voor die hele enkele keer dat 'css' beter uitkomt (niet vet en nog wat kleine verschillen), terwijl het om html gaat, wéér 'n hele class of iets soortgelijks te gaan verzinnen... Maar er zijn goede argumenten om dat wel te doen, geef ik direct toe.

(Aanvulling: omdat nieuwere delen van de site inmiddels inderdaad gebruik maken van nieuwere selectors en dergelijke, zijn er steeds meer pagina's op de site, waarop bovenstaande dingen niet meer voorkomen.)

Bij de lay-out-voorbeelden op mijn site gebruik ik namen als 'links' en 'rechts' voor de kolommen. Maar hier zijn dat beschrijvende namen: het gaat om voorbeelden waarbij de linkerkolom per definitie altijd links blijft staan, want anders zou het geen voorbeeld van een linkerkolom meer zijn.

Class én id

Vaak is een combinatie van een class en een id handig. Je zou bijvoorbeeld een serie tabellen dezelfde basis-opmaak kunnen geven. Alle tabellen krijgen dezelfde class, en via die class dezelfde css. En vervolgens zou elke tabel een eigen id kunnen geven, en via die id een eigen kleur. Dat wordt dan zoiets in de html:

En in de bijbehorende css:

Dit kan heel veel css uitsparen, omdat je op deze manier de gemeenschappelijke kenmerken van elementen in één stijlregel kunt opgeven. Vervolgens geef je de afwijkende eigenschappen voor elke id apart op.

Hierboven krijgen alle tabellen met class="algemeen" een aantal eigenschappen, waaronder een zwarte border. Voor de tabellen die een andere kleur border moeten krijgen, geef je dat vervolgens via een id aan.

Meerdere classes

Een element kan ook probleemloos meerdere classes krijgen:

of een id én meerdere classes:

In de css wordt zo'n element op precies dezelfde manier benaderd, als wanneer het maar één class of id zou hebben. Voor bovenstaande div gelden al deze stijlregels:

Dit geeft de mogelijkheid om, door verschillende classes aan verschillende elementen te geven, met relatief weinig css veel combinaties te maken. <div class="een twee drie"> komt er anders uit te zien dan <div class="twee drie vier">, omdat ze niet dezelfde set stijlregels krijgen.

Alleen moet je hierbij wel oppassen voor de zogenaamde classitis: een overdaad aan classes. Het is niet de bedoeling dat je elke mogelijke eigenschap en elke mogelijke waarde een eigen class gaat geven, want dan krijg je iets als:

Dan is het simpeler om gewoon de verouderde html-tags te blijven gebruiken voor de opmaak, want de css levert dan nog nauwelijks voordelen op en is uiterst onduidelijk. Voor de zekerheid: dit is geen advies om die verouderde troep te blijven gebruiken, maar een advies om niet een overdaad aan classes aan te maken.

(Terzijde: zijn er nog meer besmettelijke ziektes? Ja. Divitis. Een overdaad aan divs. Soms zie je dat élk element in een div wordt gezet, of dat nou nodig is of niet. Je kunt door de divs de body niet meer zien. Hoe ingewikkelder de code, hoe groter de kans op moeilijk te vinden fouten, en hoe moeilijker het voor derden is de code te begrijpen.)

Je kunt ook in de css classes combineren. De namen van de classes worden gewoon tegen elkaar gezet. De betreffende stijlregel geldt dan alleen voor een element, dat álle classes heeft:

Deze regel geldt voor <div class="een twee drie">, maar niet voor <div class="een"> of <div class="twee drie">, want alleen de eerste div uit dit rijtje heeft alle drie de classes. De regel geldt ook voor <div class="een twee drie vier vijf">, want ook deze heeft alle drie de benodigde classes.

De volgorde van de classes is hierbij niet van belang. De volgorde mag in de html anders zijn dan in de css, als ze maar allemaal aanwezig zijn.

Zoiets kan soms handig zijn. Ik heb een pagina met huizen die een zwembad hebben, huizen die een garage hebben, en huizen die een zwembad én een garage hebben, zodat de auto makkelijk gewassen kan worden.

De zwembadhuizen staan in een div die een rode border moet krijgen. De huizen met een garage krijgen een groene border. En de huizen met zwembad én garage moeten een blauwe border krijgen. De html:

Met deze twee classes kan ik toch drie verschillende borders geven:

De huizen in divs met class="zwembad garage" krijgen, op grond van de eerste regel, een rode border. Op grond van de tweede regel krijgen ze een groene border. En die regel wint van de eerste, omdat hij later komt in de css en evenveel specificiteit heeft. Dus de tweede regel overrulet de eerste.

De derde regel komt nog later in de css en overrulet dus de bovenste twee regels (en heeft meer specificiteit). Uiteindelijk krijgen de divs met een class="zwembad garage" dus een blauwe border, zonder dat ik daar een extra class voor nodig heb. En als de garage afbrandt, hoef ik alleen maar de class "garage" weg te halen om de border rood te maken.

Ook een id en een class kun je in de css combineren, maar dat is zelden zinvol. De volgende html is voor álle headers binnen een site:

Een kleurencombinatie waarmee je zelfs de meest gemotiveerde kleuter wegjaagt, maar dat maakt voor de css niets uit.

Als ik nu één header heb met <div id="header" class="saai">, zal deze div gewoon de css van bovenstaande regel gebruiken. Maar de volgende regel wordt alleen door déze div gebruikt:

Deze header ziet er dus hetzelfde uit als de andere headers, maar de achtergrond is wit. En omdat in de selector een id én een class staan, heeft die regel meer specificiteit dan de stijlregel met alleen de id. Het maakt dus niet uit of hij voor of na de regel met alleen de id komt: hij overrulet altijd de regel met alleen de id. Hij heeft meer specificiteit.

Syntactische fouten

Syntactische fouten zijn fouten tegen de regels van de taal, hier de html en/of de css. Zolang er nog syntactische fouten in je html of css zitten, is het echt volstrekt zinloos naar andere oorzaken van problemen te gaan zoeken. Een fout helemaal bovenin je pagina kan tot de wildste dingen onderin je pagina leiden.

Als op een forum een vraag binnenkomt, wordt vaak de code bekeken. Heel vaak blijken daar dan fouten in te zitten. Als je daar dan op wijst, krijg je met grote regelmaat als reactie dat die fout echt niets te maken heeft met het probleem. Ik vind dat heel knap. Ik durf te zeggen dat ik toch wel enige ervaring heb, en ik kan dat nooit zeggen. En ook anderen die veel ervaring hebben in het oplossen van problemen, beginnen altijd met syntactische fouten eruit te halen.

Het kan natuurlijk zijn dat er een of ander ondergronds, geheim circuit is van Toegepaste Voodoo Voor Websites Met Fouten of zoiets dat ik niet ken, maar zonder zo'n soort occult genootschap kun je nooit zeggen dat een fout niets met je probleem te maken heeft. Kortom: eerst die fouten eruit, anders heeft het echt geen enkele zin naar de dingen verderop in deze tekst te kijken.

De meeste fouten tegen de syntax van html en css kunnen door een validator worden gevonden. Dat zijn dus overtredingen van de regels. Als je zelf twee elementen over elkaar heen zet, maar je houdt je aan de regels, wordt dat niet gevonden, want dat is geen syntactische fout. Dat is gewoon de soort stommiteit waar mensen nou eenmaal in grossieren (rustig, ik heb het ook over mezelf, grinnik).

html kan worden gevalideerd op validator.w3.org.

css kan worden gevalideerd op jigsaw.w3.org/css-validator.

Als alle fouten eruit zijn en je css werkt nog niet, zoals het zou moeten, is er mogelijk een kans dat je hieronder eventueel de oorzaak zou kunnen vinden.

Standaardwaarden en default stylesheet

Veel elementen hebben standaardwaarden, die automatisch worden gebruikt. Maar zodra met behulp van css een andere waarde wordt opgegeven, wordt die andere waarde gebruikt. Een waarde opgegeven met behulp van css wint áltijd van een eventuele standaardwaarde.

Overigens zitten er nogal wat verschillen tussen de diverse browsers wat betreft sommige standaardwaarden. Bijvoorbeeld de standaard-padding en -marge in een lijst (<ul> en <ol>) verschilt enorm tussen de verschillende browsers. <abbr> heeft in sommige browsers standaard een border, in andere niet.

Die verschillen worden deels veroorzaakt, omdat elke browser een ingebouwd standaard (Engels: default) stijlbestand heeft. Zodra op een andere manier een stijl wordt opgegeven, wint die áltijd van het ingebouwde stijlbestand.

Een voorbeeld van zo'n default stylesheet is te vinden op de site van w3c.

Verschillen in weergave tussen verschillende browsers, terwijl je geen css voor dat deel van de weergave hebt opgegeven, hebben vaak met verschillende standaardwaarden te maken. Als je bijvoorbeeld bij een lijst zelf padding en marge opgeeft, zie je dat de weergave plotsklaps hetzelfde is in de diverse browsers. In vrijwel elke goede handleiding kun je bij de betreffende eigenschappen waarschuwingen vinden voor dit soort verschillen in standaardwaarden.

Stylesheet van gebruiker

Ook een gebruiker kan zelf een stijlbestand opgeven. Als zo'n stijlbestand aanwezig is en de bouwer van de site zelf geen css heeft opgegeven, wordt de css van de gebruiker gebruikt. Maar zodra de bouwer css heeft opgegeven, wint deze.

Omdat dit een stijlbestand is dat, als het al aanwezig is, van gebruiker tot gebruiker verschilt, zal het weinig problemen opleveren. De gebruiker kent het en weet dus wat het doet, en de bouwer weet niet eens dat het bestaat. Het is alleen handig om te weten dat het kán bestaan. Dit is bijvoorbeeld de reden dat het in de regel goed is, om te zorgen voor een voorgrondkleur én een achtergrondkleur, en niet alleen maar een van die twee.

Als de gebruiker, bijvoorbeeld omdat ze moeite heeft met contrast, zelf kleuren opgeeft, kan het misgaan als de tekstkleur van de bouwer en de achtergrondkleur van de gebruiker worden gebruikt. Het contrast kan dan te laag zijn, of zelfs volledig ontbreken, als beide kleuren toevallig hetzelfde zijn.

In principe wint de css van de bouwer dus. Daar is één uitzondering op: als de gebruiker !important heeft gebruikt, wint de bijbehorende stijlregel van de gebruiker altijd. Ook als de bouwer !important heeft gebruikt, wint het !important van de gebruiker.

Overigens heeft de gebruiker ook nog de mogelijkheid om JavaScript te injecteren. Dat kan bijvoorbeeld met behulp van de extensie greasemonkey bij Firefox. Ik heb dat verder niet uitgeprobeerd, maar ik neem aan dat de JavaScript dan ook wint. Kortom: nooit alleen op css vertrouwen voor het overbrengen van belangrijke dingen.

Overerving

In het Engels: inheritance.

Elementen erven vaak, maar niet altijd, de eigenschappen van één of meer voorouders. En net als bij echte families kan dat tot forse ruzies leiden. 'Die dochter van jou lijkt op je moeder'. 'Hoe kom je erbij. Ze heeft dat van jouw grootvader. En heb je al 'ns naar jezelf gekeken?'

Als een element binnen een ander element staat, is dat element een kind van het buitenste element. En dat buitenste element heet, je raadt het al, de ouder. Zo heb je ook kleinkinderen, grootouders, enz.

Als een element een afstammeling is van een ander element, kan het soms eigenschappen erven van dat andere element. Bijvoorbeeld de regelhoogte wordt van een <div> doorgegeven aan alle <p>'s, <span>'s, enz. binnen de <div>. Hetzelfde geldt voor de voorgrondkleur: de kleur van tekst en dergelijke.

Maar niet alles wordt doorgegeven. Een border bijvoorbeeld wordt niet doorgegeven aan de kinderen. Elke goede handleiding over css zal bij elke eigenschap opgeven, of die erfelijk is of niet.

Overerving verschilt dus van eigenschap tot eigenschap bij css. Ook zonder dat je dat verder in de css apart aangeeft, worden sommige eigenschappen doorgegeven aan kinderen.

Zodra je zelf css voor een bepaalde eigenschap van een element opgeeft, wint die altijd van overerving.

Je kunt wel met behulp van de gecombineerde selector een bepaalde eigenschap beperken tot de kinderen van één of meer specifieke elementen.

Volgorde van uitvoeren

Bij css worden de afzonderlijke stijlregels volgens een strikte volgorde uitgevoerd. Ook dit is niet heel erg ingewikkeld, maar je moet het wel even weten. Als je bijvoorbeeld een externe stylesheet gebruikt én een stijlblok in de <head> van de pagina, en er zitten tegenstrijdige stijlregels in, welke wint er dan?

Specificiteit

Ik zou ooit graag nog 'ns een spoedcursus vrij worstelen volgen en daarna 'n halfuurtje alleen willen doorbrengen met degene die deze naam heeft bedacht. In het Engels specificity, niet echt veel makkelijker te typen. En probeer 't 'ns uit te spreken op 'n feestje, als je geen geheelonthouder bent... Lijkt me een duidelijke kandidaat voor de met spoed op te richten Raad voor de Tongbescherming.

Specificiteit is het gewicht dat een bepaalde selector, en daardoor de bij de selector horende css, heeft. Selectors met meer specificiteit overrulen selectors met minder specificiteit. De specificiteit kun je berekenen met behulp van bepaalde regels. En nou ik toch al aan het mopperen was: die regels zijn naar mijn mening nodeloos ingewikkeld gemaakt. Bovendien is de uitleg in de specificatie ook nog 'ns onduidelijk en veel te beknopt.

Hierdoor is er heel veel verkeerde informatie over specificiteit in omloop. Het overgrote deel van de handleidingen over het berekenen van specificiteit, zelfs op bekende sites, is gewoon ronduit onjuist. Waarom dat zo is, kun je lezen bij Wat is er mis met de gebruikelijke manier van specificiteit berekenen?

Na deze vrolijke inleiding begrijp je misschien al, waarom ikzelf vrijwel nooit de specificiteit bereken. Gewoon even uitproberen is vrijwel altijd veel makkelijker, sneller en aangenamer.

In essentie is specificiteit heel simpel. Het aantal (pseudo-)elementen, (pseudo-)classes, attribuut-selectors en id's wordt geteld. Elk van die onderdelen heeft meer of minder gewicht. Door de totalen te vergelijken en rekening te houden met het gewicht van de afzonderlijke soorten, kun je de specificiteit bepalen. Hoe hoger de specificiteit, hoe meer gewicht de selector en dus de bijbehorende stijl heeft.

Als je denkt dat de selector te weinig specificiteit heeft, kun je gewoon even één of meer elementen toevoegen aan het begin van de selector. Meestal is er nog wel 'n <body> of <div#content> of zoiets vrij. Stel dat je denkt dat de specificiteit van de volgende selector te laag is, en dat die daarom niet werkt:

Als je voor de p wat ouders van de <p> neerzet (die zullen er vrijwel altijd zijn), krijgt de selector meer specificiteit:

Door het toevoegen van body, div#content en div#footer zijn er drie elementen en twee id's bijgekomen. Als de regel nu wel werkt, weet je vrijwel zeker dat het aan een te lage specificiteit lag dat hij eerst niet werkte.

Overigens moet je selectors altijd zo kort mogelijk houden. Het verwerken van selectors kost tijd, maar dat is met de tegenwoordige krachtige computers eigenlijk geen probleem meer. Wat nog wel een probleem is, is de leesbaarheid van de code. Als je specificiteit op wilt lossen door steeds langere selectors te gebruiken, kun je beter een spaghetti-restaurant beginnen. Spaghetti in een restaurant is prima (als de kok kan koken), spaghetti in code leidt altijd tot geestelijke verstopping en virtuele buikloop.

De volgende selector komt uit het horizontale uitklapmenu op deze site. In dit geval kon de selector eigenlijk niet korter vanwege alle :hover's:

Het ontrafelen van dit soort selectors levert geen bijdrage aan het Bruto Nationaal Geluk van Nederland. Als het dus enigszins kan: houdt selectors zo kort mogelijk.

Blind vertrouwen op specificiteit is niet goed. Zeker in het verleden hadden sommige browsers (ik ga hier niet zeggen dat dat Internet Explorer 6 was) problemen met het juist toepassen van de regels. En ook een toevoeging als !important kan de specificiteit beïnvloeden.

Daarnaast is de berekening van specificiteit in elke nieuwe versie van css steeds 'n heel klein beetje veranderd. Logisch dat makers van browsers daar problemen mee hadden. Als jij een berekening maakt volgens css 2.1, en de browsermaker heeft css2 gebruikt, kun je al 'n klein verschil hebben.

Het zal duidelijk zijn, waarom ik meestal gewoon even uitprobeer. Maar voor de echte doorzetters de rekenregels, zoals die er op dit moment uit schijnen te zien. Ik gebruik daarvoor css 2.1, want css3 is nog in ontwikkeling, en tijdens die ontwikkeling zijn daar al kleine veranderingen in de manier van berekenen in aangebracht. (Op het moment dat ik dit schrijf is de manier van berekenen weer hetzelfde als die in css 2.1. Zucht.)

!important, een css-steenpuist op je achterste

Duidelijk een geval van verdringing. Was ik !important haast vergeten. Alsnog.

!important is als een steenpuist op je achterste. Je bent je steeds hinderlijk bewust van zijn aanwezigheid, hij kan op de meest vreemde plaatsen in je lichaam voor problemen zorgen, hij belemmert je enorm in je flexibiliteit en het is niet echt een verrijking van je lichamelijke mogelijkheden. De steenpuist heeft ook nog met !important gemeen, dat ze beide voor vreselijke kleuren, enorme overflow, en andere ongewenste eigenschappen op de meest onverwachte plaatsen en de meest ongelegen momenten kunnen zorgen.

Een nettere vergelijking voor als je niet tegen een steenpuist op je zitvlak kunt: een stijlregel die zichzelf !important vindt, lijkt heel erg op mensen die zichzelf belangrijk vinden. Ze richten beide rampen aan en zijn beide onuitstaanbaar. !important is zeg maar wat mensen als Balkenende en Verhagen in de politiek zijn: je hebt er niets aan, maar als ze er zijn, veroorzaken ze problemen.

(Satanische grijns: dat is het leuke van eigen teksten schrijven. Kun je erin kwijt wat je wilt. En klagen heeft geen nut, want het is gratis en ik verplicht geen enkele CDA-aanhanger om mijn uitleg te lezen. En al helemaal niet om het met me eens te zijn.)

Het gebruik van !important maakt een stijlbestand uiterst moeilijk te volgen. Het wint overal van, zelfs van een inline-style. Als er 'n probleem is, zoek je je ongans naar de oorzaak. Kilometers verderop blijkt dan in de stylesheet een stijlregel te zitten, die zichzelf zo ontzettend !important vindt, dat hij als de Opstelten van de css over alles en iedereen heen walst.

Los daarvan wordt het niet in alle browsers goed afgehandeld. Ik ga niet zeggen dat oudere versies van Internet Explorer !important op weerzinwekkende wijze mishandelden. Na mijn fantastische cursus Holistisch Positivistisch Denken voor de Spiritueel Aangelegen Webmaster omschrijf ik het zo: Internet Explorer 7 en later handelen !important (vrijwel) goed af.

(Ja zeg, ik móét wel zeggen dat die cursus goed was. Ik kan toch moeilijk zeggen dat ik zo stom ben geweest me te laten tillen voor 2000 euro om op het weerzinwekkende tijdstip van vijf uur 's ochtends bij volle maan in m'n blootje in de vrieskou rond de Heilige Eik te mogen dansen. Kostte ook nog 'n bekeuring wegens schennis van de openbare eerbaarheid. Agent was 'n typisch geval van spiritualiteitsvernauwing.)

Lezers die gevoelig zijn voor subtiele, kleine aanwijzingen, hebben mogelijk al opgemerkt hoe ik over !important denk: niet gebruiken. Bagger. Weg ermee! En ik ben niet de enige die er zo over denkt.

important! is alleen zinvol in de stylesheet van een gebruiker. Het kan ervoor zorgen dat de stylesheet van de gebruiker altijd wint, wat belangrijk kan zijn voor mensen die bijvoorbeeld een grotere letter willen, of meer contrast. Of om snel te kijken of die stijlregel misschien wel werkt, als je er even !important bij zet, tijdens het testen.