Ten eerste termgebruik. Er is een belanrijk verschil tussen tags en elementen. Een element is het geheel van starttag, sluittag, content en attributen. Vooral in html zijn tag en element heel verschillende dingen, die je wellicht in de war kunnen brengen als je op DOM niveau (javascript) ermee omgaat. Sommige elementen hebben bijvoorbeeld geen sluittag, zoals meta, img en link. Dat zal de meesten wel bekend zijn. Er zijn ook elementen die helemaal geen tags hoeven te hebben. Zo zijn (in html) de tbody tags niet verplicht, maar het element is er altijd. Ook zijn de tags van het html en body element niet verplicht. Ook die elementen zijn er altijd, ook al hoeven de tags niet in je source te staan.

Een tweede is validatie, de html 4.01 validator is zeker niet heilig. In SGML, waar html 4.01 op is gebaseerd, is het mogelijk om elementen op een manier af te sluiten wat syntactisch erg lijkt om de xml empty element tag constructie. iets als foo en . Probleem is alleen dat geen enkele grote browser dit geimplementeerd heeft. Het zou xhtml syntax overigens ook niet backwardss compatible maken, want dan zou die ene laatste “>” als data worden getoond (na een plaatje bijvoorbeeld). Deze constructie staat bekend als SGML Null End Tag (NET).

Grtz

@ Jeroen: jazeker! De discussie begon toen één van de medewerkers de lijst een mailtje stuurde met een “reminder” om geen XHTML te gebruiken in productie-projecten. Hij gaf aan dat code pas écht XHTML is als het wordt geserveerd als “application/xhtml+xml”, maar Internet Explorer kan hiet niet mee omgaan. Vaak wordt daarom gekozen om een XHTML-document te serveren als “text/html”, maar daarbij wordt de code simpelweg geïnterpreteerd als HTML-code.
Resultaat: je hebt eigenlijk helemaal geen case-sensivity, geen namespaces en geen omgeving die “XML-aware” is. Je code is overgeleverd aan de gratie van de error-handling van je browser, die van de XHTML “tagsoup” wat moois moet maken.

De reacties hierop waren gemengd. De één vond dat de gebruiker “dan maar een echte browser moest gebruiken” (Firefox of Opera bijvoorbeeld), terwijl de ander zei dat “we geen producten voor onszelf maken”. Na wat heen-en-weer mailen was men het er wel over eens dat de klant beslist, maar dat het onze taak als developers is om de juiste keus te maken als de klant niet over genoeg technische kennis of inzicht beschkt om te beslissen.

Uiteindelijk is er geen sluitende conclusie getrokken, maar wellicht komt dat nog eens (met een biertje erbij ofzo ;-)). Ik denk in ieder geval dat het (met het ook op usablilty, accessability en compatibility) een wezenlijk onderdeel van ons werk als webontwikkelaars is om goed na te denken over wat je naar de gebruiker stuurt en ik vond het dan ook een interessante discussie op de lijst.

Hebben jullie de validatie van jullie Rails views ook geautomatiseerd en zo ja hoe?

Cheers

Bedoel je de validatie bij (bijvoorbeeld) de W3C Validation Service?

http://www.marklunds.com/articles/one/313
http://www.railslodge.com/plugins/431-assert-valid-markup