[ASP.NET] Valid xhtml strict output

[BlackHawkDesign]

Beste tweakers,

Achtergrond
Ik heb tot nu toe voor webtoepassingen alleen PHP gebruikt. Echter komt er soms een tijd dat je verplicht bent voor ASP.NET te kiezen. Voorheen heb ik altijd geprobeerd zo netjes mogelijk te coden en ik vind het heel erg belangrijk dat me html output ook netjes xhtml strict is. Door zoveel mogelijk aan die standaard te houden werkt mijn code vaak in veel browsers gelijk al en moet in sommige gevallen een vies trucje uitgehaald worden. Ik ben niet pro PHP ofzo en ik ben dus best bereidt om te kiezen voor ASP.NET. Echter zit ik met wat dingetjes

Probleem
Ik wil graag weer werken volgens de xhtml standaard. Ook wil ik graag dat ik zelf de output zoveel mogelijk schrijf. Die meuk die microsoft visual studio genereert vind ik echt te goor voor woorden. Het gebruikt soms echt te veel tags terwijl dit helemaal niet nodig is.

Na wat googelen kwam ik al tegen dat je ASP.NET kan instellen volgens xhtml te werken. Echter krijg ik nog steeds 1 waarschuwing over het stukje: <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUJNzgzNDMwNTMzZGQ0ZYMB5f7QTOolx7o7H7JD5YBQcA==" />

Kan ik hier nog wat aan doen of is deze echt nodig en niet aan te passen?
Hoe pleur ik zoveel mogelijk van dat genereermodus uit?

Overige vragen
Ik veel tuts en boeken kom ik vaak stukken tegen hoe je met asp webcomponenten kan aanmaken. Zoals onderdelen van formulieren, buttons, invoerveldjes. Ik snap eerlijk gezegd de zin hier niet van.. Je kan toch zelf ook in html intikken: <input type='text' name='somename' value=''/> ?? Of mis ik iets belangrijks?

Daarnaast wordt mij steeds verteld dat het gebruik van <% %> tags niet slims is en vermeden dient te worden. Echter snap ik niet goed waarom. Vervolgens kom ik het wel tegen in alle boeken waar dit gezegd wordt.

Hopelijk kunnen jullie mij wat inzicht in deze dingen geven.

p.s Ik werkt met c# variant van asp.net

[boe2]

Ik veel tuts en boeken kom ik vaak stukken tegen hoe je met asp webcomponenten kan aanmaken. Zoals onderdelen van formulieren, buttons, invoerveldjes. Ik snap eerlijk gezegd de zin hier niet van.. Je kan toch zelf ook in html intikken: <input type='text' name='somename' value=''/> ?? Of mis ik iets belangrijks?

Je mist het OO principe wat, denk ik
- hergebruiken van componenten, bespaart je veel tijd en is efficienter. Je component is ook direct bruikbaar als object in je code, zonder dat je ze eerst moet gaan opzoeken en casten (je doet eigenlijk dubbel werk)
- Eenvoudig genereren van content. Stel je voor dat je per item in een database een invoerveld + validator + "send" knop nodighebt die altijd bij elkaar horen, verspreid over meerdere pagina's. Ga jij dan iedere keer die 3 velden individueel aanmaken en de nodige waarden manueel invullen?

Het gepreek over hoe xhtml overrated is laat ik aan anderen over

[ Voor 8% gewijzigd door boe2 op 04-03-2009 11:17 ]

[roy-t]

BlackHawkDesign schreef op woensdag 04 maart 2009 @ 10:12:

Probleem
Ik wil graag weer werken volgens de xhtml standaard. Ook wil ik graag dat ik zelf de output zoveel mogelijk schrijf. Die meuk die microsoft visual studio genereert vind ik echt te goor voor woorden. Het gebruikt soms echt te veel tags terwijl dit helemaal niet nodig is.

Na wat googelen kwam ik al tegen dat je ASP.NET kan instellen volgens xhtml te werken. Echter krijg ik nog steeds 1 waarschuwing over het stukje: <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUJNzgzNDMwNTMzZGQ0ZYMB5f7QTOolx7o7H7JD5YBQcA==" />

Als je met ASP.Net gaat werken kun je het beste visual webdeveloper 2009 Express Edition downloaden (gratis). Dan heb je er meteen een nette IDE omheen zitten met syntax highlighting en debugging.
VWD-E maakt iig standaard XHTML transitional documenten aan.

Ik heb even de fout opgezocht en als je strict gebruikt ipv transitional is dit de fout:

code:

Line 12, Column 119: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.
…g2NmRkqu/ribmPkIyS7P8cSJK5cLjbOi0=" />

✉ 
The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element. 

One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").

Het input element staat binnen een form en binnen een div enige oplossing die ik zo zou zien is om er <p></p> om heen te zetten en kijken of dat werkt.


Is er een reden waarom je XHTML strict gebruikt en niet XHTML transitional?

(ik snap trouwens niet waarom <input> in trans. wel 'bloot' in een form mag staan en in strict niet, zal wel iets te maken hebben met de stijl eisen die strict heeft)


Edit: ik was er al vrij zeker van, maar: als je in Visual Web Developer express rechts boven in het volgende uit-klap blokje vind:

Kun je ipv XHTML1.1transitional gewoon XHTML1.1 kiezen (dat is XHTML1.1 strict).

Dan zou de website moeten 'compilen' naar iets wat wel klopt

(das mooi want ik ben net met VWD-E begonnen en nu kan ik mooi HTML4.01 strict websites gaan maken )

[ Voor 9% gewijzigd door roy-t op 04-03-2009 12:06 ]

[BlackHawkDesign]

Dat was niet de fout die ik kreeg. Ik had misschien slimmer even kunnen aangeven wat de fout was. De fout is dat een ID niet mag beginnen met een _. Ik werk met strict zodat de code helemaal valid is. Echter heb ik niet zon groot probleem om een stapje terug te doen naar trans.

Echter is dit onder de trans doctype ook al een warning en ik ben nog niet eens begonnen met coden. Oftewel: Als ik straks serieus aan het coden ben, dan probeer ik me netjes aan die standaard te houden, maar als .Net gewoon invalid html code ernaast ramt dan heeft het nog geen fuck zin...

Het belangrijk dat de site draait in alle browsers. Ik wil straks niet onnodig veel tijd kwijt zijn om uit te zoeken waarom hij wel in IE werkt en niet in de rest omdat me tools zich niet aan de standaarden houden...

EDIT: Ik gebruik nu visual studio 2008, begrijp ik goed dat dat ding wel beter ze best doet? Die code wordt toch door het .NET framework gegenereert?

[ Voor 9% gewijzigd door BlackHawkDesign op 04-03-2009 12:16 ]

[Niemand_Anders]

BlackHawkDesign schreef op woensdag 04 maart 2009 @ 12:11:
Dat was niet de fout die ik kreeg. Ik had misschien slimmer even kunnen aangeven wat de fout was. De fout is dat een ID niet mag beginnen met een _. Ik werk met strict zodat de code helemaal valid is. Echter heb ik niet zon groot probleem om een stapje terug te doen naar trans.

Echter is dit onder de trans doctype ook al een warning en ik ben nog niet eens begonnen met coden. Oftewel: Als ik straks serieus aan het coden ben, dan probeer ik me netjes aan die standaard te houden, maar als .Net gewoon invalid html code ernaast ramt dan heeft het nog geen fuck zin...

Het belangrijk dat de site draait in alle browsers. Ik wil straks niet onnodig veel tijd kwijt zijn om uit te zoeken waarom hij wel in IE werkt en niet in de rest omdat me tools zich niet aan de standaarden houden...

EDIT: Ik gebruik nu visual studio 2008, begrijp ik goed dat dat ding wel beter ze best doet? Die code wordt toch door het .NET framework gegenereert?

asp.net kent het principe van page adaptor waarmee het mogelijk is om bepaalde zaken naar je hand te zetten. Een voorbeeld hoe je een PageAdapter kunt maken kun je vinden bij 'System.Web.UI.SessionPageStatePersister' en de configuratie van de page adapter zodat deze automatisch door Page wordt gebruikt kun je vinden bij bij 'System.Web.UI.PagePersister'.

Daarnaast is XHTML inmiddels dood verklaard door Mozilla, Opera, Apple en Nokia aangezien zij momenteel bezig zijn met HTML 5. XHTML levert niet betere rendering op dan HTML. XHTML enforced echter wel dat tags correct genest worden en daarmee worden onduidelijkheden voorkomen. Echter als jij in HTML besluit om een listitem niet af te sluiten, dan is dat jouw beslissing als programeur. ASP WebForms zijn XML based en listitems zullen (tenzij je een adapter gebruikt) dan ook netjes afgesloten worden.

Het gebruik van underscores in benamingen van ID's of input element names heeft nog nooit tot problemen geleid met rendering van html (het gaat om een hidden input veld, dus wat valt er te renderen?) of in gebruik met javascript (ajax).

Afhankelijk van het soort website wat je wilt maken is misschien ASP.NET MVC gemakkelijker om te beginnen omdat deze standaard al met verschillende view engines komt waarmee het mogelijk is de volledige html output zelf te genereren.

Daarnaast is het denk ik niet geheel onverstandig om ook even een goed asp.net (MVC) boek aan te schaffen, want daarmee kun je eenvoudig voorkomen dat je bepaalde zaken verkeerd aanleert. En hoewel PHP en ASP.NET beide (X)HTML output uitspugen en op de server draaien houd daar eigenlijk de vergelijking tussen de twee meteen op.

[BlackHawkDesign]

Oke jij zegt dus nu: die standaarden handel laten varen is dood en gewoon content laten genereren door asp.

Maar wat ik me nu een beetje afvraag:

- Werken dan het gene wat ik maak, ook netjes en automatisch in alle browsers en niet alleen in IE?
- Blijft de code nog wel overzichtelijk? Aangezien ik gewend ben, javascript in javascript files te stoppen, css in css files etc, maar vervolgens zie ik dat asp gewoon al die zooi door elkaar genereert in de output. Dan wordt het ook niet echt overzichtelijk of wel. Krijg je nu ook geen ongewenste effecten?

Hoe ervaar jij deze punten dan?

Ik vind momenteel asp.net echt klote wat dat betrefd, maar ik weet van mezelf dat dat komt omdat het nieuw voor me is. Ik moet het totaal plaatje zien..

Dat van die mvc heb ik idd wel gemist in me php. Ik ga dat eens installeren en kijken hoe dat bevalt.

P.s: Heb je nog een boek wat je kan aanraden?

[Janoz]

roy-t schreef op woensdag 04 maart 2009 @ 11:58:
Het input element staat binnen een form en binnen een div enige oplossing die ik zo zou zien is om er <p></p> om heen te zetten en kijken of dat werkt.

Gewoon maar p gebruiken is natuurlijk symptoombestrijding. Gewoon de tag gebruiken die er voor bedoeld is. Formuliervelden binnen een form hoor je te groeperen met een fieldset.


Blijft het probleem van de gegenereerde hidden input staan natuurlijk. Ikzelf heb er nu ook last van in mijn huidige JSF project. Onze HTML wordt zo net en compliant mogelijk opgemaakt, alleen die verekte hidden input wordt altijd precies voor de sluittag van het form gerendered. Op die manier wordt het voor ons redelijk lastig om onze pagina's gevalideerd te krijgen.

[RobIII]

Janoz schreef op donderdag 05 maart 2009 @ 13:21:
[...]

Gewoon maar p gebruiken is natuurlijk symptoombestrijding. Gewoon de tag gebruiken die er voor bedoeld is. Formuliervelden binnen een form hoor je te groeperen met een fieldset.

Kun je groeperen in een fieldset; maar een <p> is (wanneer semantisch gewenst) net zo "goed".

quote: http://www.w3.org/TR/html401/interact/forms.html#h-17.10

The FIELDSET element allows authors to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible.

[ Voor 39% gewijzigd door RobIII op 05-03-2009 14:05 ]

[BlackHawkDesign]

Ikzelf heb er nu ook last van in mijn huidige JSF project. Onze HTML wordt zo net en compliant mogelijk opgemaakt, alleen die verekte hidden input wordt altijd precies voor de sluittag van het form gerendered. Op die manier wordt het voor ons redelijk lastig om onze pagina's gevalideerd te krijgen.

Ja dat is ook een beetje wat me gewoon irriteert. Maar ik ben dus niet de enige die dus vindt.

Bouwen jullie zelf de controls? Of maken jullie gebruik van die asp web controls?

[Niemand_Anders]

BlackHawkDesign schreef op donderdag 05 maart 2009 @ 12:29:
Oke jij zegt dus nu: die standaarden handel laten varen is dood en gewoon content laten genereren door asp.

Nee, wat ik zeg is dat je niet super zwaar moet focussen op XHTML omdat alle grotere browser fabrikanten (muv Microsoft) XHTML obsolete hebben verklaart. Zoals gezegd zal geen enkele browser een probleem hebben met een element id welke begint met een underscore. De problemen van vroeger werden vooral veroorzaakt door verkeerd geimplementeerd box models en HTML welke voor meerdere interpretaties vatbaar waren. XHTML heeft veel web devvers er bewust gemaakt van het correct nesten. Dat zorgt ervoor dat browsers correct redenderen. WebForms renderen in HTML volgens XML spelregels. Dat komt voor 98% overeen met de XHTML standaard van het W3C.

Overigens is er nog geen enkele browser welke ook XHTML (Application/xhtml+xml) begrijpt. Alle bekende browsers renderen XHTML als HTML. Dat is ook een van de redenen dat de meeste browser fabrikanten er weer vanaf willen.

Maar wat ik me nu een beetje afvraag:
- Werken dan het gene wat ik maak, ook netjes en automatisch in alle browsers en niet alleen in IE?

Ja*, want zoals gezegd zal geen enkele browser problemen met de hidden viewstate. Ze hoeven er immers niets mee te doen. Alle javascript engines welke ik heb gezien hebben geen problemen als een ID begint met een underscore. Meestal komt dit omdat de DOM parsers op XML zijn gebaseerd en in XML mogen ID's wel met een underscore beginnen.

Ik ontwikkel al vanaf 2001 in asp.net en als ik een klacht ontvang dat iets niet werkt is dat nog nooit gekomen door de HTML, maar omdat een web service niet correct werkt. En mocht om de een of andere reden de output een probleem vormen, dan is dat vrijwel altijd op te lossen middels control en/of page adapters. Zo had een intermediairs bureaus zijn medewerkers el-cheapo PDA's gegeven. Echter deze konden alleen maar overweg met een combinatie van CHTML en HTML 3.2. Voor een amerikaanse partner hebben wij adapters geschreven voor de Chello Media Micro sites (in Nederland vooral bekend dat de UPC digital settop boxen). Okk daar wordt HTML 3.2 gebruikt in combinatie met custom javascript objecten (o.a. voor navigatie (druk nu op de rode toets). Zelden tot nooit is het nodig de page of control aan te passen.

- Blijft de code nog wel overzichtelijk? Aangezien ik gewend ben, javascript in javascript files te stoppen, css in css files etc, maar vervolgens zie ik dat asp gewoon al die zooi door elkaar genereert in de output. Dan wordt het ook niet echt overzichtelijk of wel. Krijg je nu ook geen ongewenste effecten?

Over welke code heb je het nu? De code welke je ziet in de IDE (VS) of de HTML output?
De viewstates en postbacks (vooral herkenbaar via de DoPostback javascript functie) rendering en verwerking worden voor je gedaan. Via de asp.net ajax toolkit (download even de source) kun je goed zien hoe je vanuit (user)controls scripts kunt toevoegen aan de page in de vorm van een link element (via o.a. de ScriptManager)

Dan het antwoord betreffende de HTML output. Alles wat wordt gegenereerd zal 'rommeliger' zijn dan iets wat je met de hand schrijft. Echter vergeet niet dat de HTML output is bedoelt voor de browser en die zal het een zorg zijn of de HTML nu wel overzichtelijk is of niet. Want voor de werking maakt het toch niet uit of het javascript in de page wordt opgenomen of gelinked? Hetzelfde geldt voor het gebruik van whitespace in HTML.

Ik vind momenteel asp.net echt klote wat dat betrefd, maar ik weet van mezelf dat dat komt omdat het nieuw voor me is. Ik moet het totaal plaatje zien..

Programmeren volgens de Microsoft methode heeft als belangrijkste requirement dat de programmeur in staat is om zaken te delegeren. Een concept dat ook sterk aanwezig is in Java. Delegatie houd ook in dat je over bepaalde zaken minder zeggenschap hebt.

Heb je weleens een O/R mapper gebruikt. 10 tegen 1 dat je handmatig efficientere queries kunt schrijven. Toch maakt het gebruik van de O/R mapper onderhoud van business objecten eenvoudiger. Eenzelfde iets zul je ook ervaren als je gebruik maakt van controls.

Dat van die mvc heb ik idd wel gemist in me php. Ik ga dat eens installeren en kijken hoe dat bevalt.

Er zijn ook voldoende MVC toolkits voor PHP beschikbaar. Echter omdat omdat MVC niet werkt vanuit pages heb je daar ook geen last van de viewstate. Echter dat houd ook in dat je nog maar weinig WebControls kunt gebruiken. Echter hebben ze in asp.net MVC wel geprobeert het gedrag van WebForms te emuleren. Omdat MVC vanuit zichzelf niets gegeneerd heb je zoals ik al eerder aangaf meer controle over de output. Via het MvcContrib project is ook een velocity engine aanwezig welke veel overeenkomsten heeft metde bekende PHP template frameworks.

P.s: Heb je nog een boek wat je kan aanraden?

Zelf ben ik erg tevreden over de 'Pro' serie van Apress (de geel/zwarte boeken) en de 'Developers for Developers' serie van wrox (de dikke rode boeken met lelijke mannen op de voorkant). Voor Design patterns verwijs ik je naar de website [url=http://www.dofactory.com/Framework/Framework.aspx]www.dofactory.com[/quote] waar je voor 80 dollar echt veel waar voor je geld krijgt.

En natuurlijk kent GOT zijn eigen boeken optic.

[Janoz]

Euhmmm...

Ik kan met zekerheid zeggen dat we niet de asp web controls gebruiken.

..huidige JSF project..

JSF = Java Server Faces.

Ik kan wel vertellen dat we naast faces 1.2 ook rich en tomahawk gebruiken en dat we zelf wat facelets toevoegen, maar we gana absoluut geen componenten from scratch bouwen tenzij er een keiharde noodzaak is.

Eigenlijk is het hidden field op dit moment het enige dat bij ons een beetje vervelend is. Voor de rest wordt er keurige html gegenereerd. Het enige dat me stoort is dat alles via Post moet lopen en dat dit zelfs voor de linkjes geldt. Grote probleem daarbij is dat onze pagina's ook zonder javascript zouden moeten werken. Feitelijk komt het er dan op neer dat alle linkjes perse een submit button moeten zijn die we vervolgens weer terugstylen naar iets dat er uit ziet als een linkje.

[Sebazzz]

Niemand_Anders schreef op donderdag 05 maart 2009 @ 14:28:
[...]

Nee, wat ik zeg is dat je niet super zwaar moet focussen op XHTML omdat alle grotere browser fabrikanten (muv Microsoft) XHTML obsolete hebben verklaart.

Bron?

Zoals gezegd zal geen enkele browser een probleem hebben met een element id welke begint met een underscore.

Wel als het als XML geparsed wordt, rekening houdend met het XML Schema. Daarin kan je definiëren welke tekens er in een element of attribuut voor mogen komen. Alleen niet iedere browser heeft er last van.

Overigens is er nog geen enkele browser welke ook XHTML (Application/xhtml+xml) begrijpt. Alle bekende browsers renderen XHTML als HTML. Dat is ook een van de redenen dat de meeste browser fabrikanten er weer vanaf willen.

Dat is ook klinkklare onzin, zeker zonder bron. Praktisch iedere browser behalve Internet Explorer rendert XHTML verzonden als text/html als HTML ja, maar verzonden als application/xhtml+xml gewoon als XML! Probeer zelf maar. Ik weet niet waar je die onzin uit trekt.

roy-t schreef op woensdag 04 maart 2009 @ 11:58:
[...]
Is er een reden waarom je XHTML strict gebruikt en niet XHTML transitional?

Transitional is voor? Jawel, transisitionele code. Dus overgang van oud naar nieuw. Nieuwe websites ontwikkel je nooit in een transitional doctype maar altijd in strict. Bovendien is de kans dat IE het dan goed rendert, als de site valid is, groter.

(ik snap trouwens niet waarom <input> in trans. wel 'bloot' in een form mag staan en in strict niet, zal wel iets te maken hebben met de stijl eisen die strict heeft)

Zie hierboven, transitional, dus losser.

Kun je ipv XHTML1.1transitional gewoon XHTML1.1 kiezen (dat is XHTML1.1 strict).

XHTML 1.1 kent geen verschillende doctypes meer. Alleen 1 doctype: XHTML 1.1. Dat zou je als strict op kunnen vatten ja, maar dat is niet wat jij doet want jij hebt het ook over 'XHTML 1.1 transitional' en dat bestaat niet. XHTML 1.1 is echter vanwege de browser support niet aan te raden. Dan kan je XHTML 1.0 gebruiken maar dat is halfbrakke XML dus dan zou ik in ieder geval HTML 4.01 Strict gebruiken.

[ Voor 4% gewijzigd door Sebazzz op 05-03-2009 14:59 ]

[Niemand_Anders]

Vanwege tijd gebrek laat ik hier even het dubel quoten achterwege..

Sebazzz schreef op donderdag 05 maart 2009 @ 14:58:
[...]
Bron?

Mozilla, Nokia, Apple en Opera zijn gezamelijk begonnen met de HTML 5 specificatie en hebben aangegeven dat zij XHTML 2.0 niet zullen gaan implementeren. Dat noem ik een specificatie obsolete verklaren. Naast HTML5 hebben ze ook XHTML 5 gespecificeerd, maar die specificatie heeft niets te maken met xhtml 1.x of 2.0. XHTML5 is HTML5 in XML notatie. That's it, niets meer en niets minder.

[...]
Wel als het als XML geparsed wordt, rekening houdend met het XML Schema. Daarin kan je definiëren welke tekens er in een element of attribuut voor mogen komen. Alleen niet iedere browser heeft er last van.

Volgens de XML specificatie is het id attribute een IDREF wat weer een NMTOKENS is. NMTokens is een (willekeurige) combinatie van letters, cijfers, punt, dash en een underscore. In de XML specificatie is nergens opgenomen dat een naam NIET met een underscore mag beginnen. Dat is namelijk puur een restrictie in XHTML.


[quote]
[...]
Dat is ook klinkklare onzin, zeker zonder bron. Praktisch iedere browser behalve Internet Explorer rendert XHTML verzonden als text/html als HTML ja, maar verzonden als application/xhtml+xml gewoon als XML! Probeer zelf maar. Ik weet niet waar je die onzin uit trekt.
[/qoute]
MSIE, Firefox en Opera geven helemaal niet aan dat ze XHTML kennen (accept-header in request). Van Webkit weet ik niet of deze hem meer stuurt, maar Konqueror stuurt hem in elk geval niet mee. En zonder 'application/xhtml+xml' in de accept header mag de server hem dus ook niet zo terug serveren. Dat is zo gespecificeerd in de HTTP specificatie.


Weet je zeker dat een Firefox of Opera XML kan renderen? Probeer het maar eens met een eigen gemaakt XML document met daarin opgenomen <?xml-stylesheet href="style.css" type="text/css" ?>. Ik ben nog geen enkele browser tegen gekomen welke dat kan. Echter als ik er type="text/xsl" van maak en de xml omzet naar xhtml begrijpt de browser het wel.

Of nog leuker download de strict DTD en pas eens een paar elementen aan zodat bijvoorbeeld een input element wel op elk niveau mag staan. Vergeet dan in de doctype niet de system specificatie te veranderen naar public met een referentie waar je de nieuwe DTD hebt opgeslagen. Heb dit namelijk al begin 2006 een keer getest (waarbij ik de 'br' tag had hernoemd naar 'break') en gingen eigenlijk alle browsers van de standards compliant mode terug naar de quirks mode ondanks dat ik mij 100% aan de custom DTD hield. En ondanks dat ik in CSS had opgegeven dat het break element een block element was, werd deze totaal genegeerd.

Ik zal de test binnenkort nogmaals een keer herhalen als het hier (op werk) wat rustiger wordt. Misshien dat de browsers op dat punt weer een stuk verder zijn. Als dat het geval mocht zijn bied ik je direct mijn excuses aan.

[...]
Transitional is voor? Jawel, transisitionele code. Dus overgang van oud naar nieuw. Nieuwe websites ontwikkel je nooit in een transitional doctype maar altijd in strict. Bovendien is de kans dat IE het dan goed rendert, als de site valid is, groter.

Je code schrijven volgens de strict specificatie maakt de kans niet groter dat IE correct renderd. Het is puur en alleen de XML notatie welke dubbele interpretatie voorkomt welke ervoor zorgt dat alle browsers de HTML praktisch op dezelfde manier renderen. Als je HTML 4 op dezelfde manier schrijft als hoe je je xhtml schrijft dan rendert de browser hem net zo goed. In HTML 5 mag je zelfs de trailing slash gebruiken in lege elementen.

[...]
XHTML 1.1 kent geen verschillende doctypes meer. Alleen 1 doctype: XHTML 1.1. Dat zou je als strict op kunnen vatten ja, maar dat is niet wat jij doet want jij hebt het ook over 'XHTML 1.1 transitional' en dat bestaat niet. XHTML 1.1 is echter vanwege de browser support niet aan te raden. Dan kan je XHTML 1.0 gebruiken maar dat is halfbrakke XML dus dan zou ik in ieder geval HTML 4.01 Strict gebruiken.

Vraagje: Hoe lang is xhtml al uit en hoeveel browsers hebben 1.1 al geimplementeerd.
Tweede vraag: Hoeveel browsers hebben xhtml 1.0 geimplementeerd en wanneer was die uitgekomen.
Het antwoord op deze twee vragen geeft eigenlijk al (in combinatie met de drafts van HTML 5) aan waarom ik aangaf dat browser fabrikanten xhtml obsolete hebben verklaard.

Voor zover ik weet heeft alleen de W3C Amaya browser echte XML rendering. Het renderen van de tweakers homepage duurt in Amaya ongeveer 45 seconden. Alle browsers voor het publiek hebben hebben een ingebouwde 'tag list' van hoe deze gerenderd moeten worden en het gedrag ervan. Dankzij die lijst worden webpages in enkele secondes geladen. Het nadeel is dat de browser niet weet hoe om te gaan met custom elementen en deze worden dan volgens de SGML specificatie negeren. Amaya was in 2006 ook de enigste render engine welke wel de custom DTD gebruikte.

En daarmee kom ik weer terug op mijn statement dat XHTML door browsers gewoon als HTML in XML notatie wordt beschouwd.

Referenties zijn W3C en WhatWG documenten.