XHTML 2.0: tja ... wat vind je ervan?

Pagina: 1
Acties:
  • 139 views sinds 30-01-2008
  • Reageer

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Na de introductie van XML was HTML nogal een logisch slachtoffer van alle XML gerelateerde toestanden. Het grote ideaal is een HTML met een duidelijke, consequente syntax en de mogelijkheid om alle XML gerelateerde tools en standaarden ook in de HTML wereld te gebruiken. Dit kan grote voordelen hebben. Als een web-pagina in XHTML (Strict) geschreven is, kan je bijvoorbeeld veel makkelijker deze pagina transformeren, of delen ervan gebruiken op een andere site.

Op zich klinkt dat allemaal best aardig, maar het zal niemand ontgaan dat XML streng is. In de XML wereld is well-formedness (correcte XML syntax) heiliger dan de paus en validness (correcte structuur ten op zichte van een schema voor een bepaalde XML standaard) is ook iets waar je bij voorkeur niet aan moet komen.

Naast de strenge syntax heeft XML ook principes op het gebied van data modellering. Samen met de introductie van de XML syntax wordt de structuur van HTML flink op de schop genomen. XHTML 1.1 kende bijvoorbeeld al geen soepelere Transitional variant meer naast de Strict versie. Sommige constructies zijn geschrapt, andere opnieuw ontworpen, andere toegevoegd.

De acceptatie van XHTML is voor zover ik dat kan overzien echter nog vrij beperkt. Alleen geeks die schijt hebben aan bezoekers met oude browsers gebruiken XHTML, uiteraard in combinatie met leuke CSS2 frutsels.

Maar toen....

Mocht je je al doodgeschokken zijn door XHTML en de doodlopende weg van het oude HTML, dan begin je waarschijnlijk ter plekke te degenereren bij het zien van de working draft van XHTML 2.0. De working group krijgt meer en meer principes en schijnt hierbij absoluut niet bang te zijn voor het shockeren van de gemiddelde HTML klopper.

XHTML 2.0 gaat namelijk verder dan ooit. Veel aanpassingen zijn goed te beredeneren en vanuit een formeel oogpunt wel zeer begrijpelijk (vanuit dat oogpunt kan ik er ook zeker van genieten), maar ik vraag me nu toch wel heel serieus af (en dat doe ik niet snel !) in hoeverre een XHTML 2.0 wat lijkt op de huidige working draft de acceptatie van het hele XHTML gebeuren zal bevorderen.

Met name voor de eenvoudige hobbiest, huisvader, computerende puber, opa of oma wordt het wel erg lastig om een goede website in elkaar te zetten met de laatste standaarden. Op zich vind ik strictheid geen enkel probleem, maar past het wel in de aard van HTML? Het wordt zo langzamerhand eigenlijk nog aantrekkelijker om een verplichtte 'gecompileerde' vorm van XHTML in te voeren, waarbij compilers kunnen helpen om de pagina's correct te maken. Dit heeft uiteraard grote nadelen, maar je kan je afvragen of zonder het verplicht stellen van het gebruik van dergelijke tools je kan verwachten dat er erg veel correcte pagina's geschreven gaan worden.

Wat vinden jullie van deze laatste stappen van de HTML working group?

Bronnen die je zou kunnen raadplegen om de aanpassingen te bekijken:

XHTML 2.0: The Latest Trick
The Absent Yet Present Link
XHTML 2.0 W3C Working Draft 5 August 2002

(Merk trouwens op dat de HTML Working Group Chair in Nederland zit bij het CWI in Amsterdam, dus als je echt zwaar geschokt bent, kan je nog een demonstratie organiseren ofzo ;) ).

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Hum, even zoeken als je op vakantie bent geweest |:( .

[rml][ xhtml] XHTML 2.0 preview[/rml]

Misschien dat hij open mag blijven omdat ik niet direct XHTML 2.0 wil bespreken, maar meer een stelling gerelateerd aan XHTML 2.0 in de groep gooi ;) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • DizzyWeb
  • Registratie: Februari 2001
  • Laatst online: 01-09 14:31

DizzyWeb

Ondertiteld

HTML is altijd behoorlijk laagdrempelig geweest, en ik denk ook dat het dat gewoon moet blijven..... Strict, prima... Maar geef de gebruiker wel de mogelijkheid om de keuze te maken...

Dat vind ik ook een van de grote krachten van (X)HTML, je kan het zo moeilijk maken als je wil....

Dalijk word moeilijk maken een plicht om het goed te doen...

En ik denk niet dat dat een goede zaak is...

Verwijderd

[nohtml]
mbravenboer schreef op 18 augustus 2002 @ 21:09:
Na de introductie van XML was HTML nogal een logisch slachtoffer van alle XML gerelateerde toestanden. Het grote ideaal is een HTML met een duidelijke, consequente syntax en de mogelijkheid om alle XML gerelateerde tools en standaarden ook in de HTML wereld te gebruiken. Dit kan grote voordelen hebben. Als een web-pagina in XHTML (Strict) geschreven is, kan je bijvoorbeeld veel makkelijker deze pagina transformeren, of delen ervan gebruiken op een andere site.

Op zich klinkt dat allemaal best aardig, maar het zal niemand ontgaan dat XML streng is. In de XML wereld is well-formedness (correcte XML syntax) heiliger dan de paus en validness (correcte structuur ten op zichte van een schema voor een bepaalde XML standaard) is ook iets waar je bij voorkeur niet aan moet komen.
Het grootste nadeel van de HTML structuur is volgens mij dat het niet altijd mogelijk is om de pagina direct om te zetten naar een DOM structuur, die nog exact hetzelfde is. Daarom moet je nog kunstgrepen toepassen om dit weer te corrigeren.

Een XML document kun je zonder problemen omzetten naar een DOM model, en weer terug. Vooral bij dat laatste is in het geval van HTML geen garantie dat je document nog hetzelfde is. Het voordeel van de strakkere syntax en well-formedness is natuurlijk dat het lichter, sneller en makkelijker is voor parsers, editors en validators.
Naast de strenge syntax heeft XML ook principes op het gebied van data modellering. Samen met de introductie van de XML syntax wordt de structuur van HTML flink op de schop genomen. XHTML 1.1 kende bijvoorbeeld al geen soepelere Transitional variant meer naast de Strict versie. Sommige constructies zijn geschrapt, andere opnieuw ontworpen, andere toegevoegd.
In principe is XHTML 1.1 weer iets losser geworden dan XHTML 1.0 Strict, aangezien het weer mogelijk is gemaakt om zonder problemen weer target attributes te gebruiken. XHTML 2.0 zal ook opgebouwd zijn uit modules, en die planning is er ook voor zaken als bijboorbeeld CSS3. Dat heeft zo zijn voordelen boven het gebruik van een vast DTD/XML Schema/Relax NG schema. Je zit niet meer met talloze elementen en attributes die je eigenlijk niet eens gebruikt.

Ik zou haast zeggen dat XHTML 1.1 makkelijker is om aan te leren dan XHTML 1.0 Strict. Maar met XHTML 2.0 worden ook de elementen en attributes stevig aangepakt, wat met XHTML 1.1 en lager nog redelijk meeviel.
De acceptatie van XHTML is voor zover ik dat kan overzien echter nog vrij beperkt. Alleen geeks die schijt hebben aan bezoekers met oude browsers gebruiken XHTML, uiteraard in combinatie met leuke CSS2 frutsels.
XHTML is wel een standaard van het WWW Consortium, maar op het internet wordt meestal nog met HTML 4, of zelfs 3.2 gewerkt. Hoeveel HTML tutorials zijn er wel niet waarin staat dat je, om een ander font te krijgen, <font> tags moet gebruiken. Wat dat betreft mogen ze dit tutorials wel van het internet halen. Dat is net alsof je geleerd wordt dat de aarde plat is.
Maar toen....

Mocht je je al doodgeschokken zijn door XHTML en de doodlopende weg van het oude HTML, dan begin je waarschijnlijk ter plekke te degenereren bij het zien van de working draft van XHTML 2.0. De working group krijgt meer en meer principes en schijnt hierbij absoluut niet bang te zijn voor het shockeren van de gemiddelde HTML klopper.
Ik schrik er absoluut niet van, het is immers helemaal niet gezegd dat HTML helemaal moet verdwijnen. Ik hoop eigenlijk dat deze dingen naast elkaar blijven bestaan, zodat iedereen kan doen waar hij zin in heeft.
De principes die ze hebben zijn volgens mij wel terecht, data hoor je weer te geven met behulp van de elementen die ervoor bedoeld zijn. Op die manier kunnen browsers die misschien geen CSS ondersteunen er toch nog iets van maken.
XHTML 2.0 gaat namelijk verder dan ooit. Veel aanpassingen zijn goed te beredeneren en vanuit een formeel oogpunt wel zeer begrijpelijk (vanuit dat oogpunt kan ik er ook zeker van genieten), maar ik vraag me nu toch wel heel serieus af (en dat doe ik niet snel !) in hoeverre een XHTML 2.0 wat lijkt op de huidige working draft de acceptatie van het hele XHTML gebeuren zal bevorderen.
Het is inderdaad nog een working draft, maar ik denk dat ze de meeste stappen die ze al gemaakt hebben wel gaan doorzetten. Dat is misschien wat extreem, maar ik hoop dat ze daarbij niet uit het oog verliezen dat het logisch moet zijn voor de code klopper, en dat de mogelijkheden net zo ruim blijven als bij HTML/XHTML <2.0. Het gaat erg ver, en de stap ten opzichte van XHTML 1.1 is erg groot, maar het is volgens mij wel een nuttige stap. We gaan er ook veel op vooruit.
Met name voor de eenvoudige hobbiest, huisvader, computerende puber, opa of oma wordt het wel erg lastig om een goede website in elkaar te zetten met de laatste standaarden. Op zich vind ik strictheid geen enkel probleem, maar past het wel in de aard van HTML? Het wordt zo langzamerhand eigenlijk nog aantrekkelijker om een verplichtte 'gecompileerde' vorm van XHTML in te voeren, waarbij compilers kunnen helpen om de pagina's correct te maken. Dit heeft uiteraard grote nadelen, maar je kan je afvragen of zonder het verplicht stellen van het gebruik van dergelijke tools je kan verwachten dat er erg veel correcte pagina's geschreven gaan worden.
Het zou op zich al logisch moeten zijn dat ook HTML pagina's well-formed moeten zijn. Het is wel makkelijk om bij alinea's de afsluitende p-tag weg te laten, maar met zowel HTML, Javascript en CSS is het vaak een slechte gewoonte. XHTML 1.0 Transitional is niet moeilijk te leren, het is een goed opstapje in de richting van nette HTML documenten. Handige tools zijn er overigens al, de nieuwere editors maken een pagina bij voorkeur al well-formed. Ze zetten bijvoorbeeld alvast de tags neer om al je geopende tags weer te sluiten.
Wat vinden jullie van deze laatste stappen van de HTML working group?
Het meeste heb ik er hierboven wel van gezegd, het is een prima stap, zolang het een optie blijft. Met XHTML 2.0 is er definitief geen backward compatibility meer met XHTML 1.1 en voorgaande HTML versies. Wat ik wel jammer vind is dat er in de working draft te weinig wordt geschreven over andere XML dialecten als SVG, en zaken als Xlink, Xforms, of Xframes.

De samenwerking en scheiding door middel van namespaces is denk ik hetgeen wat de toekomstige markup languages zo veelzijdig kan maken. Ik denk dat er nog wel een lange weg te gaan is voor alle puzzelstukjes een beetje in elkaar gaan vallen.

Op dit moment lijkt het me duidelijk dat voor de huis, tuin en keuken HTML'er niet interessant is om zich hierin te gaan verdiepen. HTML voldoet voor hen, en is makkelijk te leren.

Ik hoop wel dat de browser developers er wel genoeg aandacht in gaan stoppen, want dit is toch net weer iets anders dan de voorgaande HTML versies. Het is een ideaal moment om de volledige standaard te gaan implementeren en ondersteunen, zodat we niet altijd achter de feiten aan hoeven lopen, en dat de ene browser het weer anders doet dan de andere.

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Cheatah: In principe is XHTML 1.1 weer iets losser geworden dan XHTML 1.0 Strict
Op enkele details wellicht, maar het wegvallen van Transitional is natuurlijk wel een vrij grote stap. Losser tov 1.0 Strict ok, maar het grote geheel is er zeker niet soepeler op geworden.
Ik zou haast zeggen dat XHTML 1.1 makkelijker is om aan te leren dan XHTML 1.0 Strict. Maar met XHTML 2.0 worden ook de elementen en attributes stevig aangepakt, wat met XHTML 1.1 en lager nog redelijk meeviel.
Tja, img is deprecated bijvoorbeeld, br wordt vervangen, href op alle elementen enz. De vorige versies waren meestal kleine bijschavingen, maar dit is gewoon een enorme schoonmaakbeurt. Ik. kan me in alle aanpassingen best vinden, maar als ik de gebrekkige acceptatie van XHTML 1.x zie, vrees ik het ergste voor XHTML 2.0. W3C kan wel allemaal prachtige principes hebben, maar het contact met de developer moet niet verloren gaan. Ik had liever een bug-fix release van 1.1 gezien, met voorbeeld fixes voor het niet accepteren van andere namespace declaraties en dergelijke.
Ik schrik er absoluut niet van, het is immers helemaal niet gezegd dat HTML helemaal moet verdwijnen. Ik hoop eigenlijk dat deze dingen naast elkaar blijven bestaan, zodat iedereen kan doen waar hij zin in heeft.
Op zich is dat uiteraard wel zo, maar aan het oude HTML zal niet meer gewerkt worden. Op het gegeven moment is deze taal al zolang niet meer onderhouden dat je wellicht zowat verplicht zult worden om XHTML te gaan gebruiken. Op zich geen probleem: ik vind XHTML absoluut positief, maar HTML'en wordt zo toch een stuk minder eenvoudig voor 'dummies'.
Wat ik wel jammer vind is dat er in de working draft te weinig wordt geschreven over andere XML dialecten als SVG, en zaken als Xlink, Xforms, of Xframes.
Dat is imho een groot gebrek van het hele schema en doctype gebeuren van het W3C. DTDs hadden ze alleen op de compost-hoop moeten gooien als je serieus standaarden wilt gaan mixen. Zelfs bij W3C XML Schema is het combineren van standaarden niet ideaal (theoretisch bewezen in een taxonomie van XML Schema talen). Tot nu toe worden er nog speciale DTDs gemaakt voor de diverse mogelijke mixen, wat werkelijk een gruwel is.

Ik denk dat het hele meta gebeuren in een XML document (schema specificatie, namespaces, encoding, versioning, entiteiten, stylesheet declaraties en andere processing instructions) is op dit moment gewoon waardeloos geregeld is. Het zou weleens goed zijn als ze daar eens wat meer aandacht aan besteden. Met name de W3C XML Schema declaraties in XML documenten zijn gewoon een chaos.

Er staat dus niet voor niets een RELAX NG linkje in m'n signature ;) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • Soultaker
  • Registratie: September 2000
  • Laatst online: 07:40
Persoonlijk denk ik dat het een goede zaak is om standaarden streng na te leven; uiteindelijk wordt de kwaliteit van de websites daar beter door (omdat ze, in principe, altijd hetzelfde werken op alle browsers, in tegenstelling tot wat met HTML vaak het geval was).

Voor een serieuze webdesigner is het niet zo veel moeilijker om valid XHTML te schrijven; er zijn zoals gezegd ook zat utillities om daar mee te helpen. Ik heb het idee dat het in ieder geval (veel) eenvoudiger is om een valid, well-formed XML bestand in elkaar te zetten dan een HTML bestand te maken dat vervolgens aangepast moet worden tot het op alle gangbare browsers werkt. Het maken van volledig aparte versies voor verschillende browsers is toch al een vreselijk onproductief karwei. Met XHTML ben je daar (in theorie!) vanaf.

Tenslotte; de "eenvoudige hobbiest, huisvader, computerende puber, opa of oma" zit nooit hard-core HTML/XML code in te kloppen, maar gebruikt Microsoft Frontpage Express (of iets vergelijkbaars) en dat programma kan net zo goed XHTML genereren als HTML, zonder dat de gebruiker zich er aan moet aanpassen. Dit geldt natuurlijk ook voor professionelere ontwikkelaars, die bijvoorbeeld het WYSIWYG-gedeelte van DreamWeaver gebruiken.

Kortom; ik zie grote voordelen en weinig problemen. Het enige bezwaar is dat het nog jaren kan duren voordat de oude standaarden dusdanig verouderd zijn dat ze niet meer ondersteund (hoeven) worden en XHTML 1 en 2 voorlopig dus alleen maar weer extra mark-up formaten zijn.

  • oh,when?
  • Registratie: April 2000
  • Niet online

oh,when?

...

zo. ik heb me totnutoe in beide discussies nog een beetje afzijdig gehouden, vooral omdat ik nog geen tijd heb gehad om de xhtml2 working draft door te lezen. nu vannacht is dat er toch eindelijk van gekomen, en ik heb ook redelijk wat linkjes gevolgd en gelezen, om zo toch een duidelijk beeld te kunnen vormen wat het allemaal inhoud, zeker ten opzichte van de huidige html dialecten.

Ten eerste wil ik een reactie plaatsen op het bericht dat 'de drempel veel hoger komt te liggen'. Op het eerste gezicht lijkt dit ook zo, gezien de omschrijvingen in de working draft, maar om eerlijk te zijn lijkt het allemaal mee te vallen. Wat niet moet worden vergeten is dat het W3C niet de popi-jopies zijn van het internet. Zij zijn niet de gangmakers op jouw webdevmeetingkje, en dat pretenderen ze ook niet. Wat ze wel zijn ( revenge of the nerds deel 6..iemand? ;) ) ze zijn de makers van de specificaties. Wat zoiets wil zeggen als het verschil tussen een handleiding voor jouw super-hifi de luxe stereoset, en een schema van de printplaat in diezelfde stereo. De ene handleiding vertelt hoe je de stereo moet gebruiken, en de andere maakt duidelijk aan degene die hem moet repareren ( als je hem weer eens hebt mishandeld op datzelfde webdevmeetingje ) hoe jouw stereo in elkaar zit.

Ik zie een paar dingen in de working draft die ik zeker wel interesant vind, de seperatie van onderdelen zoals frames, events en formulieren in de andere xml broertjes XFrames, Xevents en XForms. De invoering en standaardisering naar XML is opmerkelijk te noemen, zeker als je gaat kijken dat de eerste recommendation in februari 98 is gepubliceerd. Door die seperatie en dus modulaire opbouw van XHTML is het aan de ene kant juist _laagdrempelig_ ( is dat nederlands? ) geworden, simpelweg omdat je niet alles 'in een taaltje' hebt zitten. Aan de andere kant moet je nu wel meer _verschillende_ onderdelen gaan bestuderen. Ik vraag me af wie er echt tijd en zin heeft om eerst XHTML2 te gaan lezen, dan op naar CSS3, en even tussen lippen door op naar de verschillende DOM Level 3 ( Validation, Load and Save en Abstract Schema ). Dan hebben we natuurlijk nog XForms, Xevents, XLink en als je dan nog echt tijd over hebt kun je altijd nog even XML Schema en SVG doorlezen. Zo, ik zie je over 4 jaar wel ;)

En die knipoog is dan wel op zijn plaats, maar om realistisch te zijn. Ik denk dat we in onze handen mogen wrijven als we daadwerkelijk in 2006 echt met al deze technologieen werken. Simpelweg om het feit dat niet iedereen pats boem overstapt naar XHTML om de simpele reden dat er nog geen ondersteuning vanuit de gebruiker en/of browersmaker is.

Kijk naar CSS2, ook uit 98. En nog steeds is er geen enkele browser die het volledig ondersteunt. Kijk naar de implementatie van de verschillende talen, en je ziet dat er nog steeds browserverschillen zijn ( of zelfs bugs, zoals we pasgeleden nog achter kwamen [rml][ css] boxmodel verschillen Moz/IE[/rml] ).

Als ik puur naar een praktisch / zakelijk oogpunt ernaar kijk is het nu helemaal nog niet interesant om naar de recommendations te kijken. Het blijft ook wel een beetje 'academisch gepruttel' natuurlijk ( no flame intended ;) ) Ik kan begrijpen dat het designtechnisch mooier is om <section> te hebben dan een <div> en ook de namespaces zijn interesant maar voor jan-boerelul webbouwer op drie hoog maakt dat niet veel uit. Die snapt toch al niet wat structuur inhoud en ziet een <div> als een vervanging voor zijn tabelletje ( een goed voorbeeld kwam in de andere thread voorbij )

En nu heb ik puur een praktische opmerking, en dat is het bandbreedte 'probleem' Want hoewel een 'well formed XML document' qua semantiek even mooi is als penelope cruz in abre los ojos, het is niet bepaald compact te noemen. Is het niet dadelijk zo dat de grootte van jouw document procentueel gezien juist _toeneemt_ simpelweg omdat je meer ruimte nodig hebt om je structuur te beschrijven.

How is that for brainfood? :)

[ Voor 0% gewijzigd door oh,when? op 19-08-2002 07:25 . Reden: naampjes goed geschreven ]

"You're only as good, as what you did last week."


  • Soultaker
  • Registratie: September 2000
  • Laatst online: 07:40
oh,when? schreef op 19 augustus 2002 @ 07:22:
En nu heb ik puur een praktische opmerking, en dat is het bandbreedte 'probleem' Want hoewel een 'well formed XML document' qua semantiek even mooi is als penelope cruz in abre los ojos, het is niet bepaald compact te noemen. Is het niet dadelijk zo dat de grootte van jouw document procentueel gezien juist _toeneemt_ simpelweg omdat je meer ruimte nodig hebt om je structuur te beschrijven.
Kan best zijn, maar dat lijkt me geen probleem. Ten eerste leven we in de tijd van breedband internet; met al die ongeoptimaliseerde plaatjes op websites, flash animaties, streaming audio enzovoorts, maakt een wat grotere XHTML file nauwelijks uit.

Daarbij kun je XML natuurlijk prima compressen; met gzip/deflate (wat is 't?), wat door de meeste recente browsers standaard wordt ondersteunt of met behulp van een binair XML formaat (waar naar mijn weten nog geen breed geaccepteerde standaard voor is).

Ik heb trouwens het idee, dat met het gebruik van externe CSS, de totale grote van webpagina's kleiner zijn geworden dan met traditionele HTML, omdat je je layout-elementen niet elke keer hoeft te herhalen. Hetzelfde zou het geval kunnen zijn met client-side XML transformaties. Voordat dat echter goed werkt...
Pagina: 1