Toekomstige versie XHTML nader bekeken

In een artikel op IBM DeveloperWorks kijkt een van de organisatoren van de XTech Conference 2006, een conferentie over internetstandaarden in Amsterdam, naar de nieuwe ontwikkelingen op het gebied van de opvolgers van de huidige HTML-standaarden. Met name de opvolger van de huidige XHTML 1.0-standaard wordt door de auteur onder de loep genomen.

XHTML 2.0 is niet onomstreden, aangezien deze standaard in veel opzichten afwijkt van de huidige HTML-standaarden, waardoor webontwikkelaars op veel gebieden hun manier van werken zullen moeten aanpassen. Het World Wide Web Consortium heeft als doel om met XHTML 2.0 enkele gebreken in de bestaande HTML-standaarden aan te pakken. Zo is het de bedoeling om betere mogelijkheden te bieden om de structuur in het XHTML-document vast te leggen, terwijl de presentatie wordt verzorgd door stylesheets. Daarnaast moet het eenvoudiger worden HTML-documenten te schrijven, moeten de documenten minder afhankelijk zijn van het apparaat waarop ze worden weergegeven en moet de noodzakelijkheid van scripting worden gereduceerd. Ook wil de organisatie dat XHTML 2.0 uitgebreidere mogelijkheden krijgt op het gebied van webforms. Dit wordt gerealiseerd door de XForms-standaard op te nemen in XHTML 2.0. Tot slot moet XHTML 2.0 beter geschikt zijn voor zogenaamde Semantic Web-applicaties. Dit wordt gerealiseerd door de mogelijkheid om metadata in het document op te nemen op een manier die erg veel lijkt op de RDF-standaard.

Omdat XHTML 2.0 niet syntactisch compatible zal zijn met de voorgaande HTML-standaarden, zal de volledige adoptie van deze nieuwe standaard niet op korte termijn gerealiseerd zijn. Doordat veel browsers wel in staat zijn om willekeurig XML dat wordt vormgegeven met CSS fatsoenlijk weer te geven, werkt de XHTML 2.0-standaard al wel redelijk in veel browsers. Enkele opvallende veranderingen die in het artikel worden besproken in XHTML 2.0 zijn de vervanging van de img-tag door de object-tag en de introductie van de section- en h-tag. Wanneer de definitieve versie van de XHTML 2.0-standaard wordt gepubliceerd is niet bekend.

Reacties (58)

[rogierslag]

Soms heb ik het idee dat het W3C toch wel eens wat te snel gaat met al hun standaarden. HTML 4.01 is nog dé meestgebruikte standaard (zeker zolang IE geen application/xml+xhtml ondersteund), maar erliggen al drie XHTML opvolgers klaar (nml 1.0 1.1 en nu dus 2.0). In principe lopen de ontwikkelaars van zowel websites als browsers dus altijd achter op de standaarden en hebben ze verrekt weinig tijd om alles te optimaliseren omdat de nieuwe standaard er al weer aankomt.

Waarom niet gewoon wat rustiger met die standaarden...

[chunkyRice]

De XHTML 1.0 standaard dateert van 26 januari 2000. De daaropvolgende versies bevatten slechts kleine wijzigingen. Lijkt me dus geen onoverkomelijk hoog tempo. Daarnaast betwijfel ik of HTML 4 vandaag de dag nog steeds de meest gebruikte standaard is. En aangezien XHTML te snappen valt door iedereen die met HTML 4 kan werken, maar wel aanmerkelijk betere code oplevert, lijkt het me niet zozeer een probleem alswel een kwestie van kaf en koren.

[Not Pingu]

HTML 4.01 is nog steeds de meestgebruikte standaard, enkel en alleen omdat de toegevoegde waarde van XHTML (dus uitbreidbaarheid via custom DTD's) zelden gebruikt wordt en XHTML dus overkill is voor veruit de meeste websites.

Well-formedness en dat soort dingen is leuk, maar dat kun je in HTML 4.01 ook perfect bereiken. Daar heb je XHTML niet voor nodig. Ik word doodziek van het leger kiddo's dat roept dat je XHTML moet gebruiken om de reden dat het nieuwer is. Dat is een klotereden om een techniek te gebruiken.

[Verwijderd]

Het doel van xhtml 1.0 was dan ook niet zozeer om veel beter te zijn dan html 4.01, maar om een groeipad mogelijk te maken.

[Verwijderd]

Nee. de browsers zijn gewoon te traag met het implementeren. Met name IE houd mijnsinziens de hele webinnovatie tegen. (kijk naar png dat pas na 10 jaar helemaal door onze grote vrienden van ms wordt ondersteund)

[Isnowiz]

Mja, het grote probleem met nieuwe standaarden is, dat browsers en websites altijd aan oude standaarden blijven plakken...

Een browser zal oude standaarden altijd blijven ondersteunen, omdat er websites zijn die deze standaard gebruiken... En ontwikkelaars hebben er vaak geen trek in om hun websites aan een nieuwe standaard te laten voldoen..

Dat is ook niet reeel, omdat bedrijven bijvoorbeeld iemand inhuren om eenmalig een website voor hun bedrijf te maken, en daar mee klaar... Zo'n bedrijf heeft totaal geen erg in standaarden...

Dat browsers altijd achter lopen met nieuwe standaarden, lijkt me logisch... Zodra een nieuwe standaard ingevoerd wordt, zijn er nog lang geen websites die volgens die standaard gemaakt zijn...

Het komt er volgens mij altijd op neer dat iedereen wacht tot een browser een keer met een implementatie komt van een nieuwe standaard, alvorens ontwikkelaars er mee aan de gang gaan...
Als een nieuwe standaard genoeg te bieden heeft, zullen website-ontwikkelaars echter genoeg druk uitoefenen aan de kant van browser-makers om die nieuwe standaard te implementeren...

[Olaf van der Spek]

Een browser zal oude standaarden altijd blijven ondersteunen, omdat er websites zijn die deze standaard gebruiken...

Het ondersteunen van een nieuwe standaard hoeft toch niet te betekenen dat je oude standaarden niet beer ondersteund?

[rtgo]

Maar dan moet je wel herkennen volgens welke standaard de pagina is gemaakt. En dat is een groot probleem omdat veel mensen dat niet in hun (x)html documenten zetten.

[Verwijderd]

Sla eens een bestandje op in GIF en PNG zet ze op dezelfde pagina met de achtergrond de kleur code van de GIF, eh? ok een klein brightness verschil, MIJN GOD! oftewel als je al PNG gebruik kan je ook gelijk je achtergrond een 1x1 pixel kleurtje geven anders gaat het mooi niet werken.

Dankjewel Microsoft!

[T-MOB]

En waarom leg je de zwarte piet dan gelijk bij MS? Voor zover ik weet wordt dat kleurverschil veroorzaakt door een niet zo doordachte keuze om gamma-correctie onderdeel te maken van PNG.

[Olaf van der Spek]

Sla eens een bestandje op in GIF en PNG zet ze op dezelfde pagina met de achtergrond de kleur code van de GIF, eh?

Waarom maak je de achtergrond dan niet gewoon transparant?

[Eskimootje]

Het is een mogelijkheid en hoeft niet, in de huidige browsers werkt het gewoon goed!

[Verwijderd]

IE ondersteunt doorzichtigheid in png niet, daar ben ik al eens tegenaan gelopen. Dacht ik mooi een pijltje met doorzichtige achtergrond gemaakt te hebben, werkte het niet op IE!

[eborn]

Dus ga je terug naar GIF, maar dat formaat kent weer geen alpha-kanaal, dus transparant is transparant

[StainlessSteel]

2.0 is de opvolger van 1.x, en zou dus in theorie ook gebruikt 'moeten' worden. (Firefox is toch ook bij versie 1.5, maar 1.5.0.1 en 1.6 liggen al bijna klaar.)

Daarnaast is het voor browsers niet zoveel moeite om up-to-date te blijven, want alles is goed gedocumenteerd en de wijzigingen zijn niet zo heel groot.

[eborn]

Even het feit daargelaten dat ook W3C foutjes maakt, leert de geschiedenis dat dit niet gebeurd Kijk maar naar zowel Firefox als Internet Explorer. Beide browsers houden zich niet overal aan de standaarden (ware het XHTML of CSS).

[Verwijderd]

Het geval dat de standaard vooruitloopt op de implementatie is m.i. juist een heel goed teken: het zorgt ervoor dat webcontent in de toekomst hopelijk beter uitwisselbaar wordt. De geschiedenis heeft in elk geval wel geleerd dat als de browserbouwers vooruit lopen op de standaarden (die eerst nog niet echt bestonden) dat het dan helemaal een grote rotzooi wordt...

[Verwijderd]

Ach, ontwikkelaars zijn meestal aan het denken aan versie 2 voordaat versie 1 af is (mind goes faster)

Wanneer er snel aan een nieuwe standaard gewerkt wordt, kun je ontwikkelingen in de toekomst voor zijn. Zo kunnen grote (en kleine ook natuurlijk) concerns de nieuwe standaard adopten, i.p.v. zelf weer iets nieuws te ontwikkelen. Met alle incompatibiliteiten van dien. Uiteindelijk is de client/consument hiermee beter af natuurlijk.

[BikkelZ]

Ik ben benieuwd, de meeste mensen zijn toch vooral geinteresseerd in dingen die er voor het oog beter uit zien, die worden het meeste gebruikt.

Een document logisch vormgeven staat bij een groot gedeelte van de HTML-opmakers niet eens op de agenda. Dus XHTML 2.0 lijkt ze in dat opzicht alleen maar tegen te werken.

[Verwijderd]

Ik ben web designer en developer. En wees gerust, als je voor een bedrijfje werkt dat z'n vak een beetje serieus neemt, dan hou je je toch wel zo strikt mogelijk aan de standaarden. Achteraf is alles makkelijker aan te passen, zeker bij wat grotere projecten waar je met meerdere mensen aan werkt en server-side code gebruikt. En met goed opgemaakte templates is iedereen tevreden.

En nog één van de grootste voordelenis dat wanneer je xhml correct gebruikt, de kans dat het in de verschillende browsers en platforms er verschillend uit ziet aanzienlijk daalt.

En wat deze xhtml 2 betreft, wil ik nog opmerken dat hij er op het eerste zicht toch nog wat logischer uit ziet dan zijn voorangers.

[Verwijderd]

Ik wil daar nog graag aan toevoegen dat een site dat in (correct geïmplementeerde) XMHTL is gebouwd, ook goed toegankelijk zijn voor slecht- en niet-zienden die gebruik maken van screen readers.

Dit is voor mij net zo belangrijk als een correcte weergave in de drie belangrijkste browsers (IE, FF en Opera). Niet omdat ik of iemand in mijn omgeving slechtziend ben, maar omdat ik wil dat zoveel mogelijk mensen plezier en/of nut hebben van mijn sites, en dan vind ik dat blinden en slechtzienden daarvan niet uitgesloten mogen zijn.

Vandaar dat ik mijn sites in XHTML 1.0 transtional bouw. T.Z.T. zal ik ofwel naar strict overstappen, of me aanleren om in XHTML2 te werken, afhankelijk van wat het eerst gaat komen.

[Blaise]

Met HTML kan je net zo goed een semantisch correcte website maken die zich aan alle standards houdt. Daar heb je echt niet XHTML voor nodig. Sterker nog: XHTML wordt niet correct ondersteund door IE6 (en lager), dus XHTML biedt geen enkel voordeel ten opzichte van HTML, behalve misschien als gimmick.

[Verwijderd]

XHTML definieert structuur niet opmaak. Dus hoe het er uit ziet boeit niet.

[wreed en link]

Als ik dit artikel goed lees is het juist de bedoeling van XHTML 2.0 om structuur en vormgeving duidelijker van elkaar te scheiden. Temeer omdat je met behulp van style sheets minder afhankelijk bent van het apparaat waarop het wordt weergegeven.

Desondanks vraag ik me af hoe implementatie hiervan gaat geschieden als browserontwikkelaars het al niet eens kunnen worden over implementatie van standaarden. Kan nog wel even duren voordat dit brede toepassing kan gaan vinden EN alle html-hacks voor backward compatibility de wereld uit zijn. Veel html-ontwerpers houden nu immers nog steeds rekening met een groot aantal browsers. IE5, IE6, IE5mac, Netscape4.6, Mozilla-compatibles, Opera5 enz enz....

[Scorpion1984]

Ik weet niet wat jij voor browser gebruikt, maar ik denk IE, want ik kom toch regelmatig sites tegen die totaal IE-only zijn. Om er maar een paar te noemen: hi(helft van de tekst is onleesbaar door positionering), t-mobile(inloggen werkt niet om 1 of andere vage reden), mijncz(werkt compleet niet in andere browsers dan IE). En dit waren maar een aantal van de grote sites, daarnaast zijn er nog bulten kleinere sites.

Ik betreur het dat zoveel mensen IE-only websites maken, en ik kan dat ook geen web-developers meer noemen. Het wordt idd niet makkelijker gemaakt door de vele verschillende implementatie in browsers.

[Verwijderd]

Bij dat soort sites vertellen dat ze een enorm potentieel aan klanten mislopen, het liefst onderbouwd met dikke cijfers en wat ze kunnen doen om het te verbeteren.

[TDeK]

@scorpion1984

Waarschijnlijk totaal off-topic, maar als Hi.nl bij jouw niet goed de plaatjes laat zien dan komt dat door de flash instelling van AdBlock. En wanneer je met Firefox naar T-Mobile.nl gaat en je klikt daar op Home, dan kom je toch gewoon binnen, alhoewel bijvoorbeeld het sturen van een e-mail op die site niet werkt via Firefox.

[Soultaker]

Dat is de theorie - in de praktijk is HTML een middel voor webdesigners om een grafisch ontwerp werkend te krijgen in Internet Explorer (andere browsers zijn mooi meegenomen).

BikkelZ heeft dan ook gelijk als hij stelt dat 'logisch vormgeven' bij veel auteurs van HTML-documenten niet hoog in het vaandel staat. Deze mensen gaan om die reden dan ook niet overstappen op een andere standaard; dat doen ze alleen als die ze helpt hun doel te realiseren.

[Verwijderd]

Gravitatie is ook een theorie, maar toch houden we er ons eraan in de praktijk.

[Joske Pauwels]

Information processing theory is ook een theorie en toch houden we ons er niet allemaal aan

Zulke nietszeggende uitspraken voegen niets toe, het is appels met peren vergelijken.

[mr._Anderson]

webdesigners om een grafisch ontwerp werkend te krijgen in Internet Explorer (andere browsers zijn mooi meegenomen).

Een beetje webdesigner kijkt toch ook wel naar FireFox tegenwoordig

[Fuzzillogic]

Hopelijk gaat dit er wel komen. En dat het strakker wordt aangehouden. Foute code? BAM, browser kapt ermee met een error, net zoals XHTML 1 nu al als deze netjes als application/xhtml+xml aangeleverd wordt.

Valid code, icm betere symantische aanwijzingen zou ook goed nieuws zijn voor zoekmachines. Als je beter te achterhalen is wat content, wat reclame en wat menu's zijn dan kunne zoekmachines gerichter indexeren.

Grootste struikelblok zal IE zijn. Jammer, want het lijkt erop dat het voor browserbouwers een koud kunstje zou zijn om dit te implementeren.

[crisp]

Error correction voor mallformed documents is juist wat HTML zo geschikt maakt voor gebruik op het net (en dat zal door de WHATWG ook gestandaardiseerd gaan worden voor HTML5)

[Fuzzillogic]

Een willekeurige programmeertaal laat ook geen syntaxfouten toe. Waarom browsers wel?

Voor zoekmachines lijkt het me echt een major PITA al die ranzige (MS Office) code die rondslingert. Valid code zou indexeren wel eens een stuk makkelijker en beter kunnen maken.

[nhimf]

Veel sites claimen tegenwoordig al XHTML te gebruiken, de overgrote meerderheid van deze sites is niet well-formed. Dat is de praktijk. Error-correction is dus blijkbaar noodzakelijk.

Je draait hier de zaken om.
Veel code is niet well-formed omdat de browser het accepteerd.
Iedereen schrijft well-formed code in C#, omdat (juist ja) C# geen syntax fouten toelaat.
Browsers laten dat wel toe en dus zullen mensen geen nette code schrijven (syntactisch gezien).

Veel mensen hebben zoiets van, als het werkt dan is het goed. En als een browser slechte code toe laat, hebben mensen te snel het idee dat het goed is.
Als alle (grote) browsers geen syntax fouten meer toelaten, dan is het probleem van slechte syntax snel verholpen.

[Verwijderd]

(X)HTML is geen programmeertaal, maar een opmaaktaal (markup language).

Oja, en dat rechtvaardigt het feit dat browsers onzin parsen?

[crisp]

Veel sites claimen tegenwoordig al XHTML te gebruiken, de overgrote meerderheid van deze sites is niet well-formed. Dat is de praktijk. Error-correction is dus blijkbaar noodzakelijk.
XHTML is een business failure

[eborn]

Omdat HTML ook door gebruikers gebruikt moet kunnen worden die minder kaas gegeten hebben van standaarden Neem een willekeurig CMS of ander systeem waarbij gebruikers content kunnen invoeren. Tot op heden is er geen goede manier om deze invoer 100% XHTML compliant te krijgen (helemaal niet als je met JavaScript/DHTML) editors gaat werken.

Om nog maar niet te spreken van mensen die direct Word-HTML in zulke editors plakken.

De enige manier om XHTML af te dwingen op dit soort sites is door geen HTML opmaak toe te staan of een verdomd slimme parser te schrijven die alle problemen voor je oplost.

[SnoW]

Een willekeurige programmeertaal laat ook geen syntaxfouten toe. Waarom browsers wel?

(X)HTML is geen programmeertaal, maar een opmaaktaal (markup language).

[Fuzzillogic]

@crisp: als pagina's zichzelf als application/xhtml+xml aankondigen dan mogen browser keiharde foutmeldingen teruggeven. En gelukkig doen ze dat al.

@eborn: dat is het probleem van de CMS-fabrikant. En wij hebben een IE-editor-based CMS gemaakt die gewoon valid XHTML als uitvoer geeft. Het kan dus wel.

Wat Word-HTML betreft: er zijn grenzen. De gebruikers daarvan mogen er eens op gewezen worden dat dat echt niet werkt.

De "fout" van HTML is SGML. HTML is te inconsequent, en SGML laat teveel toe. Een ramp om daar een goede parser voor te maken. Vandaar dat ze maar op error-tolerance zijn teruggevallen. Met XHTML zijn ze naar het veel eenduidigere en simpelere XML gegaan. Well-formed XML valt veel makkelijker te parsen en er is geen excuus om het niet tenminste well-formed te maken.

[mashell]

>Oja, en dat rechtvaardigt het feit dat browsers onzin parsen?
Ja! Het is de taak van de browser om het resultaat van de HTML file zo goed mogelijk weer te geven. Ook als daar fouten in zitten. Een browser is een hulpmiddel, geen scheidsrechter.

[Verwijderd]

Reactie op eborn
O_o waar heb ik mijn - simpele maar werkende - XHTML 1.0 compliant parser gelaten? ik dacht dat zoiets algemeen goed was, een BBcode parser die mooie code teruggeeft

edit: source is hier te vinden, hij is niet helemaal bug-free, zag ik zojuist

[Verwijderd]

In het licht van deze discussie was het waarschijnlijk interessanter geweest om een soort compiler voor XHTML te maken, dan een nieuwe XHTML standaard. Gecompileerde (binaire) XHTML code zou makkelijker kunnen worden ingelezen door een browser, het hoeft niet meer gevalideerd te worden en het zou het moeilijker maken om XHTML 'broncode' te jatten.

Hiermee zouden alle webdevelopment partijen erop vooruit gaan, maar nee... Ze komen met weer een nieuwe standaard die helaas toch nergens (fatsoenlijk) zal worden gebruikt, tenminste niet op de korte termijn. Op een gegeven moment moeten ze eens stoppen met standaarden schrijven en eens kijken naar de practische toepasbaarheid... Dat ze maar eens komen met een reference implementatie van een browser die dit allemaal feilloos ondersteunt.

[Verwijderd]

ignore

[Verwijderd]

declaratief programmeren heet dat.
Net als SMIL, XSLT, etc.

Markup is niet per definitie opmaak.
Denk bijvoorbeeld aan CML: Chemical Mark-up Language

[Biinjo]

Dat zouden ze kunnen doen door middel van de 'parse errors' ?
Als je in PHP 1 ding verkeert typt waardoor het niet op PHP lijkt, ligt je hele script op z'n gat. Als ze zoiets nou ook zouden introduceren voor XHTML. Zodra je een tag hebt die niet aan de XHTML-norm voldoet, gewoon de site niet verder parsen. Eerst de site compleet XHTML maken, dan wordt de website correct weer gegeven.

Voor de mensen die er moeite mee hebben zouden ze 'gewoon' HTML erin kunnen houden die dergelijke errors niet weergeeft.

*Ik bedenk me nu ineens dat een dergelijke error-melding misschien wel handig zou zijn als plugin voor browsers van webdevelopers?*

edit:
Bij nader inzien heeft mijn post niet erg veel toe te voegen aan dat wat al gezegd is..

[Sorcerer8472]

Waar ik wel benieuwd naar ben is het volgende: waarom iets veranderen (bijv. img-tag) als het gewoon goed en prima werkt in de praktijk?

Een voordeel dat een nieuwe xhtml-standaard wel zou kunnen hebben, is dat het dan écht niet meer uit maakt of je IE of Firefox gebruikt (mits developers van beide projecten een beetje goede zin hebben ).

[Verwijderd]

Je zou kunnen zeggen dat een Image gewoon een extern object is. Net zoals een PDF file, flash of whatever. Waarom iets apart behandelen wat eigenlijk hetzelfde is?

Maar het zou zeker even moeten wennen.

[Verwijderd]

Op zich heb je gelijk, maar persoonlijk vind ik het onduidelijk.
Ik vind het wel fijn dat je een image apart kunt aangeven, met het lezen van html zie je dan snel waar een plaatje staat.
Ik werk erg veel in kladblok als ik mijn eigen site ontwikkel en dan is het gewoon fijn.

Even voor de duidelijkheid, ik houd van recht toe recht aan sites zonder poespas en bewegende plaatjes. Een site is er voor de inhoud en niet anders (vind ik), vandaar dat ik aan kladblok genoeg heb.

[crisp]

Wat hier in dit artikel niet vermeld wordt is dat dit het 2e deel is van een geheelomvattend artikel over ontwikkelingen van nieuwe standaarden. Deel 1 neemt de ontwikkeling van HTML 5 door een samenwerkingsverband van browser-vendors (WHATWG) onder de loep. Delen hiervan (bijvoorbeeld CANVAS) hebben zelfs al implementaties in diverse browsers.

Ik deel de mening van de auteur in deel 2 - dat XHTML 2.0 de meeste kans maakt de nieuwe standaard te worden - niet. Naar mijn mening staat HTML 5 dichter bij de werkelijkheid en sluit het meer aan bij wat developers graag zouden willen zien

[Verwijderd]

Iedereen die wel eens web ontwikkeling heeft gedaan zal weten dat het splitsen van "design" en "code" een hot issue is wat erg gewenst is. Ontwikkel frameworks als .NET gaan in de goede richting, maar eigenlijk moet het bij de bron aangepakt worden: HTML.

[martijnvanegdom]

Nu haal je 2 dingen door elkaar.. HTML bevat opzich alleen opmaak code.. Ook XML en XHTML . Het zijn puur talen gericht op het weergeven van documenten.

In xml is niet de code gescheiden, die zit er niet in, puur alleen opmaak..

Ontwikkelplatforms als .NET veranderen niet XHTML, wat ze daar doen is een layer creeren tussen de code die de inhoud genereerd en tussen de markup language die de inhoud met weergeven. Wat dat betreft is XML al een heel eind.
Alleen XML is nog steeds niet fijn om te coden omdat XHTML gevonden directer werkt. En vooral de browsers willen nog weleens niet fijn doen..

[Verwijderd]

HTML bevat opzich alleen opmaak code.. Ook XML en XHTML . Het zijn puur talen gericht op het weergeven van documenten.

Opmaak != semantiek, en ik ga toch echt voor de tweede, en volgens mij volg ik daarin het W3C.

Ik gebruik zowel HTML als XHTML om de semantiek van mijn documenten te bepalen. De weergave wordt dan afgehandeld door stylesheets.

Volgens jouw instelling maakt het geen ruk uit of de titel van je document met een H1 of een FONT+B tag gedefinieerd wordt . En wat dacht je van screenreaders. Het lijkt me dat de functie van informatie dan belangrijker is als de weergave?

B vs. STRONG, oftewel HTML vs. XHTML (onjuist, ik weet het, maar met definities en doelstellingen wordt deze reply iets te lang)

EDIT: En

XML ... puur gericht op het weergeven

, daar klopt dus gewoon echt geen hol van. XML kent zelf niet eens de mogelijkheid om weergave te definiëren. Dat gebeurt met standaarden als CSS (kan direct toegepast worden) en XSL (omzetten naar XHTML wat wel een standaard weergave kent)

[martijnve]

als ze nu bij M$ tijdens het aanpassen van ie gelijk zorgen dat ze hier wel zich aan het standaard houden zie ik dit graag.

<offtopic>
het was met ie zo erg dat ik van mijn XHTML Strict pagina een aparte html 4.01 strict versie voor ie heb gemaakt.

dat was minder werk als al die workarounds
</offtopic>

[Rhapsody]

En dat is erg omdat??

Het gaat er uiteindelijk om dat je pagina werkt voor alle gebruikers danwel klanten, niet volgens welke versie die geschreven is.

Ik vind het allemaal maar zwaar overdreven, iedereen roept maar over semantiek en valid dit en valid zus... valid en xhtml zijn echt de buzzwords van de laatste tijd....

Natuurlijk ben ik van mening dat iedere ontwikkelaar danwel webdesigner geen rare fratsen moet uithalen qua code (en had dus ook liever gezien dat MS niet zou afwijken van de standaarden, maar dat is nu eenmaal zo) maar er wordt vaak een beetje te overdreven over gedaan mijns inziens.

[martijnvanegdom]

Het is erg omdat het veel tijd kost.. Heel veel tijd.. ALs alle browsers de specificaties precies zouden inplementeren dat kon gaan schrijven testen op 1 browser en klaar was ik..

Echter.. Nu moet ik :

Testen op IE,
Testen op FF,
Testen op Safari,

Hacken voor IE,
Testen op FF

Terug Hacken voor FF
Testen op FF

en dan nog eens dat proces voor Safari..

Nu is dit overtrokken maar wel ongeveer het idee.. En dat is zo jammer.. want TIJD IS GELD...

[StainlessSteel]

Ah, hier zat ik net op te wachten. Ik had enkele weken geleden via Slashdot part 1 al gelezen, en was al meteen zeer benieuwd naar de tweede editie.

[STIMPPYYY]

Het is dan wel niet compatible met HTML maar de code's verschillen niet zo heel veel met HTML.