Fronteers — vakvereniging voor front-end developers

Webrichtlijn 4: Gebruik HTML 4.01 of XHTML 1.0 (R-pd.2.1)

Gebruik HTML 4.01 of XHTML 1.0 volgens de W3C specificaties voor de markup van overheidswebsites. (R-pd.2.1)

Wat doe je als je van een partij als eis krijgt XHTML 1.1 te gebruiken? Zoek je dan gewoon die mooie Doctype? Of ga je steigeren?

Hoe is je ervaring met back-end ontwikkelaars en/of CMS pakketten? Welke problemen kom je wanneer tegen? Wanneer "laat je over je heen lopen" en wanneer niet?

Hoe is de verdeling tussen HTML 4.01 en XHTML 1.0 in je werk? Heb je een persoonlijke voorkeur? Waarom? Hoe ver ga je als je voor een bepaalde smaak hebt gekozen? Laat je een <br /> toe in HTML 4.01? Of een <br> in een XHTML 1.0 document? Waarom zou het iets uitmaken als alles als text/html wordt verstuurd en browsers het toch als een tag-soepzooitje zien?

En is deze hele discussie-en misschien de richtlijn zelf-nog wel relevant met HTML 5 in het verschiet?

Reacties

1 Tom-Eric op 22-01-2008 om 08:39 uur:
Ik gebruik zelf het liefste HTML 4.01 en probeer XHTML 1.0 en 1.1 altijd te vermijden. De meestgebruikte browser (IE) ondersteunt het niet, en zal het in de nabije toekomst ook niet gaan ondersteunen.

Ook heeft HTML 4.01 voordelen. Niet alleen wordt het makkelijker om Javascript te schrijven, omdat je gewoon gebruik kan maken van innerHTML, maar je kan documenten renderen vaak sneller omdat je browser aan "incremental rendering" kan doen. Daarbij is de kans op Yellow Screen's Of Death volledig afwezig; zelfs de blogs van XHTML advocaten hadden hier in het verleden nog wel een enkele keer last van.

Wat helaas een probleem is geworden is dat populaire open source projecten (in mijn geval voornamelijk Wordpress en Ruby on Rails) standaard XHTML uitpoepen en vaak niet eens de optie hebben om dit te veranderen. Soms ga ik net zo lang door met 'hacken' tot ik de laatste /> omgezet heb naar een >, maar de laatste tijd gebruik ik, puur om tijd te sparen, het HTML 5 doctype.
2 Sander op 22-01-2008 om 10:38 uur:
Als ik de keus heb: altijd HTML 4.01 Strict, en dan ook echt volledig strict; geen <br /> die er tussendoor komt. Maar zoals Tom-Eric noemt, het is lastig dat een groot aantal 'standaad' componenten vaak XHTML output willen genereren, en veel vaker kom je binnen voor onderhoud van een site waar (zonder veel kennis over voor- en na-delen) gekozen is voor een XHTML doctype en syntax. In dat geval heb ik opgegeven om die keus terug te laten draaien. Ik geef m'n spiel over waarom in de toekomst beter HTML 4.01 Strict gebruikt kan worden (meestal redelijk effectief), maar laat de faux-XHTML site zoals die is, en probeer m'n syntax XHTML-achtig te houden. Als ik op een dergelijke site script nodig heb, dan is dat gewoon script dat uitgaat van een HTML context. XHTML op het web is een verloren zaak. (Ik ben in de echte wereld nog nooit een application/xhtml+xml site tegengekomen.)

Ik zou nog geen HTML5 doctype gebruiken: teminste niet tenzij het op een persoonlijke site is. Het is nog te vroeg om HTML5 voor klanten te gebruiken, imo. Er is geen enkele zekerheid dat de parsing rules niet nog verder wijzigen voordat er straks een candidate recommendation uit komt rollen, en tot die tijd zal je dus op zeer korte termijn je HTML5 sites moeten kunnen aanpassen.

Ik kan me eerlijk gezegd geen goede voorstelling maken bij het idee van een "eis" om "XHTML 1.1 te gebruiken".
Ik vermoed dat ik in ieder geval zou proberen om de opdrachtgever te laten inzien dat dit verkeerd is. Maar als dat niet lukt, en de opdrachtgever voet bij stuk houdt? Ik denk dat ik dat onder het kopje "XHTML op het web is een verloren zaak" zou gooien, en het zonder al te veel gewetensbezwaren als tagsoup met een nog iets verkeerdere doctype zou behandelen.
3 Kilian Valkhof op 22-01-2008 om 12:18 uur:
Met het risico een flameware over me heen te krijgen: ik gebruik xhtml strict. Waarom? Het maakt voor browsers niks uit, maar /ik/ vind de xml-stijl syntax prettiger werken.

De meeste van mijn klanten kan het weinig schelen of ik html, xhtml of word gebruik (zolang het er maar goed uit ziet) dus op dat punt kan ik lekker mijn eigen gang gaan. Is het wel een punt dan gebruik ik gewoon hun gewenste doctype. Mochten ze voor xhtml 1.1 met een echt goede reden komen (theoretisch, eh :p ) dan zou ik dat gebruiken.

Of ik in de toekomst html5 of xhtml5 ga gebruiken weet ik nog niet...;) Ik denk wel dat dat nog zo ver weg is dat we daar nu nog niet de richtlijnen op hoeven aanpassen. Ik stel zo voor dat de richtlijn in een aantal jaar veranderd wordt in "html 4.01, xhtml 1.0 of html5" met /hopelijk/ de stricte versies.
4 Raph de Rooij op 22-01-2008 om 15:48 uur:
@Sander: Je schrijft: "Ik ben in de echte wereld nog nooit een application/xhtml+xml site tegengekomen"

Neem eens een kijkje op http://advies.overheid.nl/. Die site is live sinds augustus 2004 en het gebruik ervan heeft, voor zover ik weet, nog niet tot problemen geleid. Wel een browser gebruiken die overweg kan met application/xhtml+xml, uiteraard.

Er is destijds voor gekozen voor application/xhtml+xml en XHTML 1.1 om na te gaan of het praktisch haalbaar is met een site waaraan een groot aantal redacteuren zelfstandig bijdragen leveren.

Toen bleek dat het mogelijk was, hadden we meteen ook een beeld van de meerwaarde ten opzichte van text/html. Die was er praktisch niet, dus Sander heeft wel een punt met zijn keuze voor HTML 4.01 Strict.
Aan de andere kant: gebruik van XHTML in combinatie met text/html heeft geen zwaarwegende nadelen. Inhoudelijk is het een interessante discussie, maar de relevantie ervan wordt naar mijn mening zwaar overschat.

Veel belangrijker vindt ik de keuze tussen Transitional en Strict. Daarover kunnen we pas over twee weken gaan discussiëren...
5 Krijn op 22-01-2008 om 17:07 uur:
Hoewel het zeker nog niet handig is om de HTML 5 DOCTYPE ook echt te gebruiken, zijn de HTML 5 Working Draft en een document met de verschillen tussen HTML 4 (XHTML 1) en HTML 5 overigens een paar minuten geleden wel gepubliceerd op w3.org.
6 Arjan op 22-01-2008 om 19:45 uur:
Ik nu gebruik vrijwel altijd HTML4.01 Strict. XHTML heeft geen echte voordelen voor 99 procent van de sites op dit moment, je kunt met HTML4.01 exact hetzelfde.

Het wordt pas leuk als SVG en MathML en andere op XML gebaseerde standaarden gecombineerd kunnen worden. Dit is op het moment gewoon nog niet goed mogelijk.

XHTML verzonden als HTML is vanuit een standaarden oogpunt natuurlijk als vloeken in de kerk, maar het maakt niet veel mensen iets uit.

Ik ben niet zo een muggenzifter dat ik <br />s weer in <br> ga proberen te veranderen, die door het CMS zijn uitgespuugd. Browsers weten er mee om te gaan, al druist het tegen de standaarden in. Maar daar gaat het uiteindelijk om: het resultaat in de browser.

Overigens een verkeerde benaming in de blog post, text/html vs application/xhtml+xml gaat niet over tagsoup. Tagsoup is als je dit soort dingen verkeerd doet: <a><strong></a></strong> of als je een afsluitende tag vergeet. Je pagina toevertrouwen aan de tagsoup parser kan verraderlijk zijn als je een ietwat complexere CSS gebruikt, of een DOM script.
7 Victor op 22-01-2008 om 20:32 uur:
Tja, uiteindelijk doet het er weinig toe. Zolang je maar een strict document type volgt (en dus geen transitional, wat je in het geval van een nieuwe pagina/site al niet zou moeten gebruiken) en jezelf dan ook daadwerkelijk aan het gekozen type houdt (dus niet een beetje van beide). Als je een CMS hebt dat XHTML uitspuugt, heeft het geen zin om hier heel koppig een HTML 4.01 doctype boven te plaatsen. En als je liever de XML syntax gebruikt, moet je gewoon lekker een XHTML doctype gebruiken (al zal het uiteindelijk toch door een SGML parser gaan, die strikt genomen de self-closing tags als malformed ziet). Al met al is het een vrij zinloze discussie, aangezien er veel belangrijkere zaken zijn waar we ons druk om moeten maken.

Overigens is XHTML 1.1 zonder het bijbehorende content-type nooit goed te praten. Je gaat dan tegen de specificatie in die je vol trots claimt te gebruiken.
8 Sander op 22-01-2008 om 23:49 uur:
Raph: http://advies.overheid.nl/zoek/?q=%00%ef%bf%bf (met dank aan Philip Taylor die datzelfde trucje net eerder vandaag op Shelley uithaalde). :)

Erm, maar dat is een zijweggetje. Ik weet natuurlijk dat er application/xhtml+xml sites bestaan, en bezoek er persoonlijk ook wel een paar. Maar met "de echte wereld" in deze context bedoelde ik sites van organisaties die ons als front-enders inhuren.
Je kan natuurlijk zeggen dat de overheid zo'n organisatie is, maar aan de andere kant, je geeft zelf al aan dat dit puur als experiment gedaan is, dus ik weet niet of dat telt. :)


@Krijn: mogen we alsjeblieft een preview functie, of een handleiding voor hoe je hier links maakt? Ik weet het echt niet meer met al deze slecht-gedocumenteerde vage tekst-gebaseerde syntaxen. Is het dubbelequote-linktekst-dubbelequote-dubbelepunt-url, of linktekst-haakjeopen-url-haakjesluiten of, of.... (En hoe is dat simpeler dan <a href>?)
9 Sander op 23-01-2008 om 00:23 uur:
Ik gebruik op m'n werk altijd XHTML 1.0, veelal Transitional, maar soms ook Strict. Ik weet dat XHTML feitelijk een wassen neus is zonder de juiste MIME-type, maar het is min of meer een soort erfenis en ook wel gewoonte.
In principe zou ik graag weer overstappen op HTML, al vind ik net als Kilian de wat striktere grammatica die bij XHTML hoort wel aangenaam. Nu is die natuurlijk ook mogelijk in HTML, afgezien van de self closing tags. Het is maar net hoe streng je voor jezelf bent als het gaat om het afsluiten van tags waarbij dat niet per se hoeft.

Wat betreft de Transitional DocType: sommige backend systemen zijn wat minder strict, waardoor er bij een stricte DTD meer kans is dat na implementatie alsnog geen valide documenten worden opgeleverd.
Ook bij de keuze tussen Strict en Transitional geldt natuurlijk dat je zelf kunt bepalen hoe streng je voor jezelf bent binnen de grenzen van de gekozen DTD. Het feit dat je bv. een Transitional DocType gebruikt wil immers niet zeggen dat je <font> en bgcolor= moet gebruiken ;-)
10 Sander op 23-01-2008 om 00:27 uur:
Oh ja, ik ben dus die ene Sander (arme sloeber zonder fancy linkje op z'n naam, daar ben ik nog voor aan het sparen) en niet die andere. Duidelijk toch...

;-)
11 Raph de Rooij op 23-01-2008 om 08:17 uur:
@Sander, die op 22-01-2008 om 23:49 uur schreef: http://advies.overheid.nl/zoek/?q=%00%ef%bf%bf (met dank aan Philip Taylor die datzelfde trucje net eerder vandaag op Shelley uithaalde). :)

Volgens mij verdient dit een nadere toelichting. Wat doet het, wat bewijst het en wat heeft het te maken met Philip Taylor en Shelly (die van http://realtech.burningbird.net, neem ik aan?)

Overigens sluit je af met een verzoek aan Krijn waarbij ik me aansluit. Daaraan zou ik nog willen toevoegen dat een groter (of resizable TEXTAREA element, in hoogte en breedte) ook een uitkomst zou zijn.
12 Krijn op 23-01-2008 om 09:19 uur:
@Arjan: ik had het over als tagsoup zien (behandelen/parsen).

@Sander: een handleiding voor het toevoegen van markup in een comment zal ik deze week toevoegen.
HTML in de database druist een beetje in tegen het principe van m'n CMS. Vandaar dat 'een simpele' <a href> niet toegestaan is. Sorry :)

@Raph: het bewijst dat XHTML op het web niet werkt ;)
En in Safari 3 zijn alle textareas gewoon resizable. Andere browsers hebben resize nog niet geïmplementeerd.
13 Sander (met link) ;) op 23-01-2008 om 10:01 uur:
@Raph: zoals Krijn zegt - hoewel dat ietwat kort door de bocht gaat. Wat het bewijst is dat het in de huidige opzet van die site mogelijk is dat een gebruiker content genereert die niet aan de eisen van XML voldoet, waarna gelijk de hele pagina plat ligt. (En tenzij je van alle content-editors eist dat ze niet-IE browsers gebruiken, zullen ze dat waarschijnlijk niet doorhebben, dus zullen de bezoekers de hinder ondervinden.)
Ook al heeft de application/xhtml+xml mimetype in het verleden "nog niet toch problemen geleid", op de lange termijn zal dit bijna zeker toch gaan gebeuren, omdat er aan de server kant niet voldoende wordt gechecked.

Philip en Shelley doen niet echt ter zake, behalve dan dat ze toevallig net een gerelateerde discussie hadden op Anne's weblog waar Philip diezelfde input de XML binnen wist te smokkelen d.m.v. de zoek pagina.
Zie http://annevankesteren.nl/2008/01/ie-lock-in#comment-6392 en verdere comments.


@Krijn: alvast bedankt!
14 Raph de Rooij op 23-01-2008 om 10:59 uur:
@Krijn: dit bewijst volgens mij nog niet dat XHTML op het web niet werkt, alleen dat je een parsing fout kan veroorzaken door de URL te hacken. Wat is eigenlijk het risico dat verbonden is aan het tonen van een dergelijke fout, zoals Philip Taylor stelt in zijn reactie (te vinden op http://annevankesteren.nl/2008/01/ie-lock-in#comment-6394)?
Aanvullend daarop: welke invoer in het zoekveld leidt tot een foutmelding? ï¿¿ in elk geval niet...

@Sander-met-link: Ik ben het helemaal eens met Shelley op http://annevankesteren.nl/2008/01/ie-lock-in#comment-6392: "Because of this, I know immediately when I've done something wrong in a post, and can fix it quickly. I suppose an environment that forgives errors is more amenable, but probably leads to crappy sites."
Philip Taylor toont met zijn exercitie hooguit aan dat er op het punt van foutafhandeling enige ruimte is voor verbetering, maar dat het zwaarwegend genoeg is om XHTML te diskwalificeren ontgaat me volledig.

Het mooie van het huidige front-end web development is dat het voor een belangrijk deel een zoektocht is naar het optimum en dat die zoektocht zelf ons verder brengt, niet zozeer het resultaat op korte termijn. Het heeft miljarden gekost om een paar mensen op de maan te laten lopen; het praktische nut van die paar wandeltochten is veertig(!) jaar na dato nog steeds te betwijfelen. Maar de exercitie heeft wel degelijk een bijdrage geleverd aan de algemene ontwikkeling van onze diersoort in de afgelopen 46 jaar.
John F. Kennedy had helemaal gelijk toen-ie in 1962 zei: "[...]Why choose this as our goal? And they may well ask why climb the highest mountain? Why, 35 years ago, fly the Atlantic? Why does Rice play Texas? We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills[...]".

Als je er iets van leert kan zelfs een mislukking succesvol zijn. Ik pleit er dus voor om vooral door te gaan met uitzoeken, proberen, falen, opnieuw proberen en uiteindelijk slagen. Juist die manier van vooruitgang boeken maakt front-end web development zo'n interessant vakgebied, toch? En als je het er niet mee eens bent: vooral de laatste versie gebruiken van softwareproduct X ('vernieuwd en nu nog beter' zeggen de marketeers van X)...
15 Krijn op 23-01-2008 om 11:14 uur:
Vandaar dat ik die zin ook afsloot met een ";)".

Ik heb in 2004 een tijdje gespeeld met application/xhtml+xml (ondertussen voor de zekerheid allemaal als text/html), maar toen ik in 2005 begon met de ontwikkeling van mijn CMS heb ik na een hoop wikken en wegen gekozen voor HTML 4.01 strict voor alle HTML dat het naar de browser stuurt. Nog geen spijt van gehad, en ik denk ook niet dat ik dat ooit ga krijgen.
16 Sander (met link) ;) op 23-01-2008 om 12:19 uur:
@Raph: Jij weet wel wanneer je iets fout hebt gedaan, maar ik neem aan dat jij niet de enige bent die content voor advies.overheid.nl genereert, noch dat je dagelijks alle pagina's op de hele site controleert. (Shelley kan dat wel, maar jij niet; en zelfs Shelley heeft third-party content die problemen kan opleveren.)
Gebruiken alle content editors van de site een browser die de content door de XML parser gooit? En wordt er nergens automatisch content van een third-party geladen?
Als niet aan die volwaarden is voldaan, dan bestaat de mogelijkheid dus (het voorkomen waarvan op de lange termijn de 100% kans zal benaderen) dat je content op de site krijgt die een dergelijke "yellow-screen-of-death" zal veroorzaken, die gedurende enige tijd niet opgemerkt zou worden, en waar normale gebruikers dus de dupe van zouden zijn.

Dat deze voorbeeld foutmelding door een gehackte zoek-opdracht wordt veroorzaakt doet hierbij niet ter zake; het is een testcase om aan te tonen dat input niet voldoende wordt gevalideerd om geschikt te zijn voor output naar XML.
17 Sander op 23-01-2008 om 12:24 uur:
(Overigens ben ik het verder wel volledig met je eens qua zoektocht e.a.; hoewel mijn ervaring met zoektochten die code opleveren die in productie wordt opgenomen beduidend minder is. Ik wilde aan het begin van de eeuw ooit onderzoeken of frames echt niet toch nuttig zouden kunnen zijn; de conclusie was en volmondig "neen" - en van wat ik toen heb geleerd heb ik nog steeds profeit, maar ondertussen is de tijd om de site volledig te herschrijven en al die frames ongedaan te maken nog steeds niet gevonden.)
18 Egor Kloos op 25-01-2008 om 10:23 uur:
Ik ga even niet in op de HTML vs. XHTML. Die onzin heb lang achter me gelaten. (Ik heb mijn zegje gedaan: http://dutchcelt.nl/weblog/why_html_does_not_matter/)

CMS'en zijn nog steeds behoorlijk brak, daar kan nog veel in vebeterd worden. Gelukkig laten steeds meer systemen toe dat de templates kunnnen worden aangepast. Wel blijft Javascript en probleem omdat deze vaak niet of anders heel moeilijk aan te passen is, laat staan verwijderen/vervangen.

HTML5 speelt de komende jaren totaal geen rol en ik vraag me af of het er uberhaubt ooit komt. Ik wil het wel gebruiken, het is een fantastische ontwikkeling.
19 Roderick van Domburg op 15-06-2008 om 21:14 uur:
Bij Nedforce ontwikkelen wij pagina's volgens de Webrichtlijnen. Het team dat de Webrichtlijnen ontwikkelt heeft duidelijk verstand van zaken: de punten zijn zeker best practices en bovendien goed onderlegd. Dat begrijpen cliënten ook. Afwijken en kiezen voor XHTML 1.1 moet ik dan ook nog meemaken.

XHTML is een logisch vervolg op HTML in een Internetwereld die wordt gedomineerd door XML. Ondanks brakke browserondersteuning is het "the better thing to do". Of toch niet? Ik vind het een verwarrend statement van W3C om te starten met de ontwikkeling van HTML5 als respons op die slechte ondersteuning.

Het grootste probleem van W3C als standaardenorganisatie is dat het nooit heeft begrepen hoe die standaarden te forceren. Wat dat betreft kunnen ze een beter voorbeeld nemen aan ISO.
Plaats een reactie