Fronteers — vakvereniging voor front-end developers

Webrichtlijn 67 & 68: Richtlijnen voor het gebruik van CSS

CSS dient in gelinkte bestanden geplaatst te worden en niet gemengd te worden met de HTML broncode. (R-pd.9.1) Pagina's dienen bruikbaar te blijven wanneer CSS door een webbrowser niet ondersteund wordt. (R-pd.9.2)

Wanneer vind jij dat je CSS wel mag mengen met HTML? Met andere woorden; wanneer zijn <style> (zonder @import) en style="" verdedigbaar?

Wat gebruik je liever; <link rel="stylesheet" href="foo.css"> of <style>@import url('foo.css');</style>? Of ontwijk je @import vanwege een andere regel?

Hoe vaak test jij gemaakte templates of sites terwijl stylesheets uit staan? Welke tools gebruik je daarvoor? En waar let je dan op?

Gebruik jij trouwens nog steeds CSS hacks en/of filters om bijvoorbeeld Netscape en IE5 voor de Mac te ontzien? Of vinden we IE6 en IE7 met een paar conditional comments tegenwoordig al genoeg extra werk?

De webrichtlijnen maken er geen richtlijn van, maar print stylesheets (rel="stylesheet" media="print" dus) worden wel genoemd. Gebruiken we die ondertussen ook allemaal? En vind je dan dat alle pagina's perfect printbare equivalenten moeten hebben, of is het voor sommige pagina's (zoals een homepage) minder belangrijk? Hoe bepaal je trouwens hoe je de print stylesheet opzet? In hoeverre wordt hier (ook) een design voor gemaakt en over nagedacht?

En om af te sluiten met een flauw puntje: tabellen voor lay-out. Hoe vaak heb jij zin om het op te geven? ;)

Reacties

1 Erwin Hofman op 10-12-2008 om 17:18 uur:
Het komt nauwelijks voor dat ik inline CSS gebruik. Ik streef ernaar dat opmaak en content zoveel mogelijk gescheiden is. Bij uitzondering, wanneer de opmaak van een element ook echt een uitzondering is op de presentatie van andere elementen, wil ik het nog wel eens toepassen, maar in de opleverstadium gooi ik de css-declaraties uiteindelijk toch in het extern stijlblad.

Een print stylesheet voeg ik minstens toe in applicaties (zoals een helpdesk/ticketsysteem, CMS et cetera).
Voor websites zorg ik dat overbodige elementen niet getoond worden (zoals zoek of inlogformulieren) en dat de website op een A4-formaat past.

Overigens zwicht ik nooit en te nummer voor tabellen. Een klant verwacht kwaliteit en dus puzzel ik liever een uur (of zelfs 2) langer door dan dat ik tabellen in ga zetten. Daarnaast geeft een goed resultaat mbv van semantische html icm CSS me meer voldoening dan iets opbouwen in tabellen, wat mij in dit stadium waarschijnlijk zelfs minder goed af zal gaan.
2 David Hund op 10-12-2008 om 18:00 uur:
Ik gebruik vrijwel altijd een link voor Stylesheets, dit is een gewoonte geworden en ik denk er niet meer echt over na. Ik ben op de hoogte van de IE render-stop met @imports en ik dacht dat er nog een issue mee was (vergeten welke).

Inline CSS gebruik ik bijna nooit, met name vanwege het feit dat dit binnen de kortste keren onbeheersbaar wordt.

Iets wat je nog niet noemde Krijn is style die door Javascript geset kan worden. IMHO is de beste optie nog altijd een extra classname toevoegen of verwijderen op elementen (bij bv. JS effecten). Soms echter gebruik ik de betreffende Library optie: bv. setStyle() voor Prototype.js of css() voor jQuery. Het nadeel hiervan is uiteraard dezelde mix van 'behaviour' en 'presentation' en de verminderde beheersbaarheid.

Print stylesheets maak ik ook bijna altijd. Ik houd dat altijd heel simpel en gebruik een soort reset.css: schakel alle onzin-op-papier dingen uit enz. Ook maak ik vaak alle text serif en een puntje groter. Daarnaast alles in Zwart/Wit. Soms doe ik leuke extraatjes zoals de href vermelden naast de link.

Print stylesheets en no-css check ik via de FireBug FireFox extentie. Kan/wil niet meer zonder.

En terug naar tabellen?! Ik zou het lastiger vinden om sites met tabellen te maken, dan zonder...
3 Sander A op 11-12-2008 om 03:04 uur:
Ik gebruik soms nog wel style="...", maar alleen voor het geval dat de klant achtergronden via het CMS wil kunnen beheren. Alle overige background-properties zet ik dan in het externe CSS-bestand, maar alleen de bewuste 'background-image' plaats ik dan inline.
4 Boye op 11-12-2008 om 10:20 uur:
Imports probeer ik over 't algemeen te vermijden...elke @import is immers ook weer 'n extra HTTP request. Inline styles voor een background-image eigenschap (zoals Sander aangeeft) kan ik me wel mee identificeren.

Wat betreft CSS hacks/work-arounds; ik heb in een duister verleden weleens gebruik gemaakt van het <style> element (op basis van de user agent) om bijv. specifieke browser quirks af te vangen, dan blijft je algemene CSS document in ieder geval valide. Tegenwoordig zijn ’t hoofdzakelijk MSIE gerelateerde mankementen die ik tegenkom welke met conditional comments prima te tackelen zijn, maar ook hier probeer ik niet teveel op terug te vallen.

Wanneer je overigens gelaagd bouwt en de lay-out in kwestie niet al te exotisch is kan je er wel vanuit gaan dat hetgeen ook zonder CSS ondersteuning duidelijk te bekijken is, dit controleer ikzelf meestal met de bekende Mozilla developer toolbar (disable styles > all styles)

Verder doe ik net als David regelmatig een beroep op de CSS functionaliteit van bijv. een jQuery om elementen te beïnvloeden, naar mijn mening is Unobtrusive JavaScript essentieel als je gelaagd gaat bouwen.

Zoals menig ontwikkelaar doe ik met tabellen het liefst geen zaken. Maar als het gaat om tabulaire data (statistieken o.i.d.) ben ik de moeilijkste niet en trek ik een tabel uit de kast (wel met summary attribuut en bijbehorend caption element overigens) … om vervolgens snel mijn handen te wassen.
5 Marc op 11-12-2008 om 10:27 uur:
Het gebruik van tabellen is een andere richtlijn, dus eigenlijk drijf ik een beetje af hier, maar toch: Boye, waarom zou je je handen moeten wassen nadat je een tabel hebt gebruikt voor tabulaire data? Daar zijn ze toch voor? Zeker als je alle bijbehorende tags en attributes goed inzet... niks om je voor te schamen.
6 Boye op 11-12-2008 om 10:40 uur:
daar heb je een punt Marc....maar toch heb ik 't idee dat ik immoreel bezig ben ;) (wat waarschijnlijk veroorzaakt wordt door de troubles die tabellen mij in 't verleden hebben bezorgt)
7 Krijn op 11-12-2008 om 10:43 uur:
Zet dat immorele gevoel maar overboord ;)
8 Sander v L op 11-12-2008 om 21:42 uur:
David noemde het hierboven al, maar het in JavaScript rechtstreeks manipuleren van element.style (al dan niet via een library) is een van de laatste grote zondes waar ook front-enders die bij de tijd zijn zich nog te vaak aan vergrijpen. Dat je styling nou toevallig via JavaScript manipuleert wil niet zeggen dat de afsplitsing van layout informatie niet langer nuttig is. Ik vind het zelf dan ook erg belangrijk JavaScript altijd className te laten manipuleren, en de effecten hiervan in je stylesheet te beschrijven.
Nou zijn er natuurlijk altijd aspecten te bedenken waar dat niet praktisch is (eigenlijk alles wat dynamisch is, al dan niet geanimeerd), en totdat de Animation en Transition CSS modules wijd geïmplementeerd zijn zul je hier vaak niet onderuit kunnen; maar ik zou in ieder geval willen oproepen om waar het wel kan het gebruik van directe manipulatie van het style attribuut te vermijden.

Verdere punten:
<style>@import</style> gebruik ik nooit; naar mijn idee is het gebruik hiervan voornamelijk nog een overblijfsel van het tijdperk dat Netscape 4 nog een probleem was (want die negeerde @import zo lekker, zodat je geen N4 crashes kreeg als je 'geavanceerde' dingen deed in CSS).
Ik ben er wel fan van (geweest?) (kleine) hiërarchieën van stylesheets elkaar te laten @importen (dus begin met een pagina-specifieke stylesheet, die de benodigde globalere stylesheets laadt), voornamelijk omdat dit zeer schoon opgebouwd en goed te onderhouden was, maar de negatieve effecten hiervan op de performance zijn helaas te snel duidelijk merkbaar (omdat erlke stylesheet eerst geparsed moet worden voordat de volgende geladen kan worden), dus ik ben heir eigenlijk weer volledig van afgestapt.

CSS rechtstreeks in de pagina of in een <style> block gebruik ik redelijk vaak tijdens prototyping. In hele grote sites waar je regels puur voor een enkele pagina hebt kan het af en toe een lastige afweging zijn of je die nou in een aparte stylesheet wil zetten (extra http request), of wil toevoegen aan een globalere stylesheet (extra laad-tijd voor alle pagina's), of in dat <style> block laat staan. Het in de <style> laten staan is uiteindelijk nooit de juiste keuze, maar ik kan traagheid bij het verwijderen hieruit wel begrijpen.

Ik test standaard alles wat ik bouw met CSS uitgeschakeld (view -> page style -> no style e.a.). De structuur die ik dan terugzie geeft naar mijn mening een goed beeld van hoe een screenreader (of een google!) de pagina ziet, en moet gewoon perfect zijn.

Print stylesheets zijn voor mij (te vaak) een afterthought, hoewel het ook sterk aan de omgeving ligt waar je in werkt. Bij web applicaties is zeer weinig vraag naar het printen hiervan, terwijl intranet sites bij grote bedrijven bijna vaker op papier dan op het scherm lijken te worden gelezen.
9 Timidfriendly op 21-01-2009 om 08:33 uur:
Ik maak nog steeds gebruik van de ie6 * html "filter" ;-) and the ie7 *+html filter, simple weg omdat ik dat apart stylesheet conditional comment een onoverzichtelijk gedoe vind.

Het is mij meerdere keren overkomen dat ik vergeten ben om in de IE specifieke CSS bestand te kijken als iets raars gebeurt in IE. Ik vind het overzichtelijker als alle browser specifieke aanpassingen direct naast de algemene selectors staan.

Print stylesheets kan zeer algemeen blijven en meet een paar kleine aanpassingen heb je in no-time een site specifieke print stylesheet.
10 Ron van den Boogaard op 22-01-2009 om 19:28 uur:
Inline styles? gewoon nooit. Het is niet maintainable.

Altijd alles link, nooit @import. Is een gewoonte en de beste methode volgems mij.

Ik test altijd wel zonder stylesheets, meer vanwege SEO dan accessibility (niet zoveel verschil trouwens), maar met zaken als Yahoo Grids moet je daar toch wel een concessies doen.
Yahoo grids vereist veel IE hacks vanwege de verschillen in rendering van de em. Dan hangt het van de klant af of ik conditional comments gebruik. Liever wel, maar niet altijd gewenst.

Print stylesheets zie ik nooit een ontwerp voor. Probeer altijd zo dicht mogelijk op het originele design te blijven. Dus als daar een lettertype gedefinieerd staat gebruik ik dat ook. Alle overbodige stuff er uit gooien en vragen of men google ads meegeprint wil hebben :) Over het grote geheel wil iedereen wel zijn site kunnen printen.

En hoewel ik regelmatig zin heb om het op te geven en met monitoren te gaan gooien is er geen haar op mijn hoofd die erover denkt om een tabel voor de lay-out te gebruiken. Tabellen zijn voor tabulaire data. Period.
11 Ron van den Boogaard op 22-01-2009 om 19:32 uur:
spellcheckers are for whimps
12 Nick op 09-03-2010 om 18:39 uur:
Voor fast prototyping gebruik ik nog wel eens inline styles, gewoon omdat dit fast is, zodra het geen prototyping meer is sheid ik het van de structuur.

Testen zonder css aan is bij mij een gewoonte geworden, meestal ook omdat ik skiplink navigatie in me websites zet. Ik hou er ook van om alles lekker onder elkaar netjes en gestructureerd te zien, dit geeft ook in mijn mening een goed beeld van hoe screen readers and search engines je document zien, alles strak/netjes en gestructureerd onder elkaar, met basic skiplink navigatie erin is ook gewoon geil om te zien. ;)

Ik heb voor mezelf ook een soort van procedure gemaakt. Wat ik altijd doe is als ik een design van de designers krijg is snel de gehele structuur van de website neerleggen (op basis van belangrijkheid), zodra de structuur goed is neergezet ga ik pas over naar de vormgeving. :)

Aparte print styles komen helaas bij mij niet zo veel voor, en dat heeft meer met de tijd die we voor een specifiek project hebben te maken, ik probeer dit altijd er toch wel in te fietsen, maar er wordt meestal tijdens het design proces niet aan gedacht. Denk dat ikzelf hierop meer moet gaan hameren bij de designers. ;)
Plaats een reactie