Fronteers — vakvereniging voor front-end developers

Webrichtlijn 1: Scheiding tussen structuur en vormgeving (R-pd.1.1)

Het leek ons leuk (Gelukkig nieuwjaar overigens!) om een discussie aan te zwengelen over de webrichtlijnen van de overheid. Niet in het wilde weg: wat vind je nou van die richtlijnen, maar juist per richtlijn: hoe waardevol, correct, belangrijk is hij? 125 richtlijnen, iedere week 1. Zo zijn we wel even bezig! :P Deze week de eerste richtlijn: Houd structuur en vormgeving zoveel mogelijk gescheiden: gebruik HTML of XHTML voor de structuur van de site en CSS voor de vormgeving ervan. (R-pd.1.1)

Wanneer wijk jij af van deze richtlijn? Wanneer plaats je CSS wel rechtstreeks in een HTML bestand? Wat vind je van het toestaan van HTML of XHTML (de discussie over versienummers komt later...)? Wanneer is het lastig om deze richtlijn na te leven? Kun jij je vinden in alle voordelen of zie jij ook nadelen?

Reacties

1 D. van der Valk op 01-01-2008 om 13:24 uur:
In principe ben ik voor deze richtlijn, met de juiste headers scheelt het een hoop dataverkeer en je code is overzichtelijker.
Voor de rest zie ik er geen echte voordelen in.

Alleen in het geval dat ik iets voor het internet schrijf en weet dat mensen graag in de bron kijken (paginaspecifieke css, bijvoorbeeld een css tutorial) plaats ik alles netjes vlak voor </head>.
2 Sander op 02-01-2008 om 00:13 uur:
Ik wijk af van deze richtlijn wanneer de klant bv. zelf achtergrondafbeeldingen wil kunnen uploaden. Het gaat dan dus niet om content, maar opmaak (dus CSS), maar wordt wel beheerd vanuit het CMS. In zo'n geval gebruik ik een good ol' inline style-attribuut (ai, doem & verderf) en enkel voor de bewuste property.
Het zou ongetwijfeld netter zijn om het CSS bestand dynamisch te maken, maar dit is gewoon makkelijker.

Iets soortgelijks doe ik overigens ook wanneer d.m.v. JavaScript bv. een link moet worden ingevoegd waarvan de tekst ook vanuit het CMS beheerd kan worden.
3 Paul op 02-01-2008 om 10:06 uur:
Vaak wanneer er een combinatie is van javascript die dynamisch elementen toevoegd. Ik heb gemerkt dat het meegeven van een class problemen kan geven terwijl het meegeven van een style attribute vaak wel goed werkt.
4 Michel Vos op 02-01-2008 om 10:30 uur:
Vanuit onze opdrachtgevers heb ik een aantal maal te maken gehad met deze richtlijnen. In mijn ervaring is dit een van de makkelijkste om na te leven.

Het wordt echter zoals reeds aangegeven lastiger op het moment dat er met javascript wordt gewerkt. Sommige selectoren vanuit CSS werken om wazige redenen soms niet en dan ben je al snel overgeleverd aan inline hacks.

Desalniettemin moet imho ten alle tijden worden getracht de scheiding tussen CSS en HTML zoveel mogelijk aan te brengen.
5 BARTdG op 02-01-2008 om 10:55 uur:
Ik haal uit de richtlijn niet dat je geen inline styles zou mogen gebruiken. Er wordt alleen gesteld dat css zijn grootste waarde, heeft als het dmv een extern bestand gelinkt wordt.

Het scheiden van structuur en vormgeving zit 'm daarom vooral in het niet meer gebruiken van i- en b-tags etc. en het niet gebruiken van tables voor layout. Voor dat soort dingen gebruik je de taal css. De manier waarop vind ik van minder belang.

Hoewel ik in de praktijk geen inline styles gebruik, vind ik niet dat ik, als het een keertje moet, zondig tegen deze richtlijn.
6 Krijn op 02-01-2008 om 13:25 uur:
Helemaal met BARTdG eens, hoewel b en i ook niet per se verkeerd zijn :)

@Paul: zou je kunnen uitleggen wat je bedoelt?

Hoe zit het trouwens met de keuze tussen HTML of XHTML? Hebben klanten, opdrachtgevers en/of CMS'en ondertussen al door dat XHTML niet werkt?
7 Kor Dwarshuis op 02-01-2008 om 14:29 uur:
Ik ben voor de scheiding. Zo!

Echter vanuit een performance oogpunt, zou het soms beter zijn om CSS (en javascript) in de html op te nemen, zo beweert "High Performance Web Sites. 14 Steps to Faster-Loading Web Sites. Essential Knowledge for Frontend Engineers. O'Reilly (Steve Souders)". Heb ik net gelezen, erg leuk boek.
8 Sander v. L. op 02-01-2008 om 15:47 uur:
Over de richtlijn zelf: Aan de ene kant vind ik dat de richtlijn zoals gesteld nog iets te veel 'weasel-words' bevat. "Zoveel mogelijk"? Voor iets dat puur een basis principe is? (Let wel, het gaat er bij deze richtlijn puur om dat je HTML en CSS gebruikt waar deze voor bedoeld zijn, en dus geen layout probeert te forceren met HTML. Er wordt nog niets gezegd over wel of niet inline, en zelfs niet over dat behaviour (JavaScript) ook apart moet.)
Aan de andere kant: uitzonderingen bestaan natuurlijk altijd, dus zo'n regel moet ook niet te absoluut gesteld worden. Het is lastig daar de juiste balans in te vinden; dat hebben we bij de diplomeringscommissie ook al gezien.


Over de bijgevoegde vragen en verdere discussie:
- CSS plaats je rechtstreeks in een bestand als je deze on the fly genereert en het te veel extra rompslomp zou zijn om een dynamisch gegenereerd extern CSS bestand aan te maken. Denk aan eenmalige gepersonaliseerde kleurenschema's (bijvoorbeeld "voorbeeld" pagina's in een CMS, voordat de uiteindelijke keuze wordt opgeslagen), of soms in 'animaties'. Ik probeer in dergelijke situaties echter nog altijd wel de CSS rules dynamisch te maken (in een <style> block in de <head>) en de classes in de HTML statisch te houden.

- XHTML kan grote voordelen hebben, en voor de paar dozijn bedrijven die een volledige XML workflow hebben, en informatie met XSLT transformeren van de ene representatie naar de andere, moet je XHTML natuurlijk absoluut niet gaan verbieden. Het is fantastisch dat zij dit zo kunnen gebruiken, en de correcctheid van hun XML kunnen garanderen. Echter, in 99% van de situaties is de 'XHTML' die op het internet staat niets meer dan faux-HTML, en hoewel dit straks met XHTML5 'gelegaliseerd' gaat worden, hou je als webdeveloper zowel jezelf als de klant voor gek door te denken dat dit voordelen heeft.

- Echte "nadelen" aan deze richtlijn ken ik niet, maar als ik af en toe een paar kleine veranderingen moet maken aan een legacy site, dan zou ik graag willen dat ik de kennis over alle voordelen totaal zou kunnen vergeten, zodat ik niet de neiging zou hebben alles vanaf de grond af aan te herschrijven. :)

- @Kor: Totdat je Google, digg, of wikipedia bent is dat een geval van premature-optimization. Het voordeel van miniem snellere laadtijd weegt niet op tegen het nadeel van slechter onderhoudbare code. Ja, de extra connectie die browsers moeten maken heeft enig effect, maar tientallen andere dingen die je kan doen (bv. caching op alle levels) hebben een veel groter effect, en toch doe je die voor de meeste websites ook niet - gewoon omdat de sites niet groot genoeg zijn om je hier zorgen over te maken.
9 Kor Dwarshuis op 02-01-2008 om 18:19 uur:
@Sander: ik ben het met je eens. Ik plaats de css dan ook mooi in een extern bestand en als ik straks 60 miljoen hits per dag krijg, dan ga ik wel weer nadenken hoe het verder moet...
10 BARTdG op 02-01-2008 om 19:54 uur:
Dan include je 't met PHP :P

(Heb ik wel eens gedaan. Ik weet niet eens meer waarom, maar ik had een goede reden.)
11 dingenontwerper op 03-01-2008 om 10:36 uur:
Zijn [strong] en [em] tags die je in je content gebruikt niet nuttig voor SEO?
12 Peter Wouda op 03-01-2008 om 11:00 uur:
<strong> en <em> -tags kunnen volgens de richtlijnen gewoon gebruikt worden, want dat zijn eigenlijk geen opmaak-tags, maar ze geven aan wat voor soort tekst het is. Een visuele-webbrowser als Firefox en Internet Explorer zal een <strong>-tekst bijvoorbeeld 'vet' tonen, terwijl een spraak-browser de tekst extra luid zal laten horen. De <strong>-tag heeft dan ook de voorkeur t.o.v. de <b>-tag die meer alleen voor visuele browsers geldt.
Een andere voordeel van externe style-sheets is dat je voor elk type uitvoer-apparaat (mobieltje, computer, pda, spraak-browser, printer) een speciale stylesheet kunt maken, die dezelfde content op diverse manieren toont. Dit pleit dus vóór scheiding.
13 Fons op 03-01-2008 om 15:19 uur:
Naast alle praktische en handige bijdragen zou ik een subtiele maar niet ongebelangrijke theorerische invalshoek willen toevoegen. Scheiding tussen structuur en vormgeving valt niet precies samen met scheiding tussen (X)HTML en CSS. Er zijn tal van vormgevingsaspecten die je onmogelijk in CSS kwijt kunt. Bijvoorbeeld: De vormgever kan besluiten alle mannennamen blauw te maken en de meisjesnamen roze. Geen probleem met CSS. Maar hij kan ook besluiten mannennamen in de linker kolom en meisjesnamen in de rechter kolom te zetten. CSS biedt in het laatste geval geen gemnakkelijke oplossing. Ander voorbeeld: Zijn de teksten op buttons en labels van formuliervelden inhoud, structuur of vormgeving?
Een vormgever bepaalt hoe de inhoud dient te worden gepresenteerd en daarvoor is CSS niet altijd voldoende. Waar ligt precies de grens tussen inhoud, structuur en vorm? Dat is niet altijd duidelijk in verschillend vanuit verschillende perpectieven. Maar het is wel een belangrijke vraag als het gaat om onderhoudbaarheid en herbruikbaarheid van inhoud, structuur en vorm. Als je de grens legt op de scheidng (X)HTMNL - CSS dan leg je jezelf vast op één bepaald visie op het verschil tussen structuur en vorm. Daarom is ooit XSLT uit gevonden. Je kunt je dan afvragen wat je in de XML representeert en wat in de XSLT templates of CSS. Een discussies en gedachtes daarover gaan dan echt over scheiding tussen inhoud, structuur en vorm en veel minder over het gebruik van technieken. Als het gaat om herbruikbaarheid en onderhoudbaarheid van inhoud, structuur en vorm is het gebruik van XSLT mijns onziens belangrijker dan CSS.
Zijn er onder de fronteers nog mensen die graag en veelvuldig gebruik maken van XSLT, of ben ik de enige?
14 Krijn op 03-01-2008 om 15:41 uur:
@Fons; jij bent dus meer van de 4 lagen? Hoe los je met XSLT als extra tussenstap het probleem van de jongens- en meisjesnamen op? Of is het probleem dat de vormgever denkt in "een linker en rechter kolom"?
Ik denk dat ik structuur en inhoud vrij dicht bij elkaar vind liggen, maar dat kan ook liggen aan gebrek aan kennis van XSLT. Uiteindelijk moet het toch (X)HTML worden op het web?
15 Marcel op 08-01-2008 om 10:06 uur:
Ik gebruik(te) serverside XML/XSLT waar vervolgens HTML uit kwam die ik met een CSS stylesheet zijn stijl gaf. Wat Fons zegt over de naam links en rechts plaatsen al naar gelang het geslacht van de persoon, geen issue: een XSL-CHOOSE construct in de XSLTemplate is voldoende om de HTML volgorde aan te passen.

Maar, is dat weleens nodig? Een naam (P-tag bijvoorbeeld) kan je links en rechts floaten. Geef als CLASS attribuut op dat het "male" of "female" is, en je bent er.

Goed, ontopic. De richtlijnen zijn niet onredelijk. Ze zijn makkelijk na te leven als je technologie (ontwikkelstraat) het ook ondersteunt.

Het enige waar ik een opmerking bij wil plaatsen is inline CSS. Dit is altijd te voorkomen door een betere oplossing te gebruiken. Ik heb eigenlijk alleen maar problemen gehad met inline stijlen, omdat deze achteraf lastig terug te vinden zijn. Tenminste.. ikzelf weet van een 3-jaar oude site niet meer waar en waarom ik bepaalde uitzonderingen heb toegepast. En voor een enkele "display: block", inline in een diep verborgen tag in een of andere obscure pagina is het niet altijd de moeite waard om dit volledig te documenteren.
Plaats een reactie