HTML: keep the legacy of toch naar XHTML?

[crisp]

Marcj schreef op maandag 16 april 2007 @ 08:10:
[...]


In het framework die ik gebruik worden veel XML functies toegepast op de XHTML die gegenereerd wordt. Bijvoorbeeld om errors aan forms te toe te voegen die niet door de validatie komen.

Dat is natuurlijk prima; als je een XML-based back-end hebt zou ik ook gewoon XML-methoden gebruiken (in fact: je moet wel om wellformedness te kunnen garanderen).

[...]

Zie bovenstaande. Dit soort dingen kunnen veel lastiger met gewone HTML.

In een non-XML based back-end zal je inderdaad vaker met stringfuncties werken of met templates oid. Op zich prima voor de gemiddelde website, maar bij complexe transactie-systemen e.d. mischien een minder goed idee.

[...]


Draconische error handling vind ik juist ideaal om foute code op te sporen die anders wel een over het hoofd gezien kunnen worden (omdat de browser waarme je het meeste test het goed doet). Maar hierbij kunnen wel kleine foutjes zich voordoen met een andere browser waarme je minder hebt getest (of die je niet tot je beschikking hebt, ik heb hier bijvoorbeeld nergens Safari draaien).

Voor testing purposes is draconische error-handling een manier, maar zeker niet de enige manier om fouten op te sporen en ook niet noodzakelijk de beste; immers zegt het enkel iets over conformiteit van de syntax en meer niet. Sommige regels laten zich niet eens in een schema beschrijven en zijn dus op deze manier niet te checken (invalid nesting, specifieke regels voor atribuut-waarden).

Echter zodra je output naar de client gaat sturen wil je niet dat bij een fout de bezoeker geconfronteerd wordt met voor hem/haar onbegrijpelijke meldingen.

Ik ben wel met je eens dat er misschien eens een XHTML parser moet komen die voor bezoekers het beste van probeert te maken, maar dat er dan wel een developer versie is die wel alle errors geeft. Ik denk dat dat het beste van twee werelden is.

Het beste van 2 werelden is HTML en in je ontwikkelomgeving een plugin in je browser die fouten laat zien

Maar daarnaast moet je natuurlijk gewoon altijd valide HTML opleveren. Ter vergelijking, als je PHP gebruikt is de kans minstens zo groot dat er een foutje in je PHP zit die een error kan opleveren. Deze errors worden toch ook gewoon aan de gebruiker getoond (zij het misschien in de vorm van een HTTP 500 error)?

Nee, in een produktie-omgeving zet je error_reporting uit of laat je het silent loggen naar een logfile. De gebruiker toon je niet je PHP errors.

Dit zijn dingen waarop gewoon getest moet worden en dan vind ik het wel prettig dat er een documentatie ligt waarvan 100% duidelijk is hoe het geparst moet worden. Het is nu alleen nog jammer dat het niet overal goed geimplementeerd worden, maar zolang we niet van nieuwe technieken gebruik maken worden ze ook nooit beter ondersteund.

True, maar de kans op slagen door voort te bouwen op iets dat al algemeen geimplementeerd en geaccepteerd is is vele malen groter dan door met een compleet nieuwe incompatible specificatie te komen.

Al met al vind ik wel dat XHTML voor mij voordelen bied.

Ik heb daar nog geen argumenten voor gezien. Je kan net zo goed serverside XML-based werken en vervolgens gewoon HTML naar de client sturen. In feite doe je dat al voor al je IE-bezoekers, alleen is het mallformed HTML met een verkeerde DTD erboven

[Marcj]

crisp schreef op maandag 16 april 2007 @ 10:26:
[...]
Dat is natuurlijk prima; als je een XML-based back-end hebt zou ik ook gewoon XML-methoden gebruiken (in fact: je moet wel om wellformedness te kunnen garanderen).


[...]
In een non-XML based back-end zal je inderdaad vaker met stringfuncties werken of met templates oid. Op zich prima voor de gemiddelde website, maar bij complexe transactie-systemen e.d. mischien een minder goed idee.


[...]
Voor testing purposes is draconische error-handling een manier, maar zeker niet de enige manier om fouten op te sporen en ook niet noodzakelijk de beste; immers zegt het enkel iets over conformiteit van de syntax en meer niet. Sommige regels laten zich niet eens in een schema beschrijven en zijn dus op deze manier niet te checken (invalid nesting, specifieke regels voor atribuut-waarden).

Echter zodra je output naar de client gaat sturen wil je niet dat bij een fout de bezoeker geconfronteerd wordt met voor hem/haar onbegrijpelijke meldingen.


[...]
Het beste van 2 werelden is HTML en in je ontwikkelomgeving een plugin in je browser die fouten laat zien

Eens, maar toch zou ik wel graag wat meer duidelijkheid in de specificatie van HTML willen hebben. Het is mij bijvoorbeeld niet duidelijk wanneer een <p> beeindigd als je de </p> niet gebruikt.

[...]
Nee, in een produktie-omgeving zet je error_reporting uit of laat je het silent loggen naar een logfile. De gebruiker toon je niet je PHP errors.

Dat bedoel ik eigenlijk ook, maar dan nog is je website vaak wel stuk. Het framework die ik gebruik verwijst in de productieomgeving naar een HTTP 500 error pagina (die je eventueel zelf kunt definieren).

[...]
True, maar de kans op slagen door voort te bouwen op iets dat al algemeen geimplementeerd en geaccepteerd is is vele malen groter dan door met een compleet nieuwe incompatible specificatie te komen.

XHTML is natuurlijk niet volledig backwards compatible, maar nette HTML 4.01 is toch meestal heel eenvoudig om te zetten. Door het wellformed te maken ben je al een heel eind, maar je moet uiteraard wel met wat kleine dingen rekening houden. Daarnaast is het natuurlijk een kwestie van smaak, maar persoonlijk vind ik de XML vorm wel een veel nettere vorm die makkelijker te begrijpen en te parsen is. (Maar hierover zijn al vele discussies gevoerd en ik denk niet dat we hier over eens kunnen worden )

[...]
Ik heb daar nog geen argumenten voor gezien. Je kan net zo goed serverside XML-based werken en vervolgens gewoon HTML naar de client sturen. In feite doe je dat al voor al je IE-bezoekers, alleen is het mallformed HTML met een verkeerde DTD erboven

Een extra vertaalslag aan het eind maakt het natuurlijk wel wat trager. En wat IE met de website wil, ach, die houdt zich toch niet aan standaarden (al geef ik voor IE ook geen DTD mee), zolang hij maar werkt toch?

[Civil]

Marcj schreef op maandag 16 april 2007 @ 08:10:
[...]

Draconische error handling vind ik juist ideaal om foute code op te sporen die anders wel een over het hoofd gezien kunnen worden (omdat de browser waarme je het meeste test het goed doet). Maar hierbij kunnen wel kleine foutjes zich voordoen met een andere browser waarme je minder hebt getest (of die je niet tot je beschikking hebt, ik heb hier bijvoorbeeld nergens Safari draaien).

Ik ben wel met je eens dat er misschien eens een XHTML parser moet komen die voor bezoekers het beste van probeert te maken, maar dat er dan wel een developer versie is die wel alle errors geeft. Ik denk dat dat het beste van twee werelden is.

Dat lijkt me inderdaad stukken beter dan je bezoekers opzadelen met een gigantische error (niet te bezoeken pagina) omdat de software ergens een klein foutje heeft gemaakt. Je bezoeker zie je nooit meer terug (wat een *** site), terwijl die fout waarschijnlijk niet eens zo ernstig was en de browser had het prima kunnen weergeven waarschijnlijk.

Zelf developen in een hele strikte omgeving is natuurlijk prima, dat doe je binnen php waarschijnlijk ook. Maar jij gaat je bezoeker toch ook niet opzadelen met toevallige warnings die de software weergeeft. Die laat je loggen wellicht zodat je zo snel mogelijk de oorzaak kan achterhalen in de development omgeving om het vervolgens op te lossen.

Met andere woorden, een developer zou zijn browser op strict mode moeten kunnen zetten, zodat hij gewezen wordt op alle stomme fouten die hij maakt. De bezoeker zou ongehinderd de site moeten kunnen bezoeken.

[We Are Borg]

Marcj schreef op maandag 16 april 2007 @ 11:15:
En wat IE met de website wil, ach, die houdt zich toch niet aan standaarden (al geef ik voor IE ook geen DTD mee), zolang hij maar werkt toch?

Brrr, mijn nekharen gaan altijd recht overeind staan als ik dit soort dingen hoor. Antwoord voor mij is een absolute nee

Verder eens met civil. Daarnaast heb ik die stricte error check al in mijn browser gebakken, daar heb ik geen XHTML voor nodig.

[Marcj]

We Are Borg schreef op maandag 16 april 2007 @ 17:43:
[...]
Brrr, mijn nekharen gaan altijd recht overeind staan als ik dit soort dingen hoor. Antwoord voor mij is een absolute nee

Verder eens met civil. Daarnaast heb ik die stricte error check al in mijn browser gebakken, daar heb ik geen XHTML voor nodig.

Ik begrijp wat je bedoelt en verder probeer ik altijd zo netjes mogelijk te programeren (ben ook meer gespecialiseerd in java), maar ik heb al zovaak problemen gehad met IE, terwijl het in alle andere browsers die ik heb goed werkt, dat ik inmiddels zoiets heb van: zolang IE hetzelfde laat zien als Opera en Firefox vind ik het prima. Of ben ik de enige daarin? _{en zal ik maar weer verder gaan in java}

[Michali]

Voor IE wil je best wel eens wat minder net programmeren idd. Maar dat probeer ik dan wel voor de andere browsers zo veel mogelijk te verbergen, door middel van conditional comments bijvoorbeeld.


Even ontopic:

XHTML heb ik ook een tijdje gebruikt, maar toen ik er achter kwam dat ik het foutief toepaste ben ik toch weer terug naar HTML gegaan. Ik heb er op zich best wel wat van geleerd, maar ik streef toch wel het correcte te doen. XHTML probeer ik dan idd. ook alleen toe te passen als dit echt een vereiste is. Ik zie er anders ook geen voordelen van in.

Het niet laten zien van een pagina als er een foutje in zit kan naar mijn mening echt niet, eigenlijk. Er kan altijd iets breken op een bepaald gebied, mocht dit zo zijn, dan wil je natuurlijk dat klanten altijd nog zo veel mogelijk van je site kunnen bezoeken.

Voor pagina's waarbij het echt een vereiste is dat de data er zo correct mogelijk wordt weergegeven (lees: altijd correct is), zou het wel weer een uitkomst zijn. Als je markup dan fout is, dan kun je er ook vanuit gaan dat de gegevens niet kloppen en is het misschien beter dat de pagina in zijn geheel niet zichtbaar is, maar daar valt ook over te discussiëren natuurlijk. Dit soort situaties komen natuurlijk bijna niet voor, ik kan ook even geen voorbeeld bedenken.

[Fuzzillogic]

Civil schreef op maandag 16 april 2007 @ 17:32:
[...]

Dat lijkt me inderdaad stukken beter dan je bezoekers opzadelen met een gigantische error (niet te bezoeken pagina) omdat de software ergens een klein foutje heeft gemaakt. Je bezoeker zie je nooit meer terug (wat een *** site), terwijl die fout waarschijnlijk niet eens zo ernstig was en de browser had het prima kunnen weergeven waarschijnlijk.

Je legt de verantwoordelijkheid voor het goed weergeven nu dus bij de browser aan de client side. Lijkt mij een verkeerd uitgangspunt. De server heeft er maar voor te zorgen dat de data goed is. Scheelt waarschijnlijk ook weer een shitload aan allerlei security issues. Nog niet zo lang geleden kon je IE op zijn non-conforming smoeltje krijgen middels een (lege?) <input>-tag. Nou zeg ik niet dat dat in een XML-wereld niet kan voorkomen, maar een simpele parser is een eenvoudiger te schrijven parsers waar je beter het overzicht over houdt.

Verder: IE kan op een paar quirks na prima omgaan met XHTML 1.0 in text/html, hetgeen volgens de standaard is toegestaan. Het zou extreem wenselijk zijn als IE8 eindelijk eens stopt met het arrogant sturen van een "accept: */*"-header.

Niet dat er NU direct nut is bij XHTML tov HTML, hoewel voor embedded SVG wel al fijn, het nut van XML voor toekomstige uitbreidingen lijkt me toch vrij duidelijk. Desnoods wordt het renderen van een bepaalde namespaces door plug-in achtige oplossingen afgehandeld.

[crisp]

Fuzzillogic schreef op woensdag 18 april 2007 @ 23:59:
[...]

Je legt de verantwoordelijkheid voor het goed weergeven nu dus bij de browser aan de client side. Lijkt mij een verkeerd uitgangspunt.

Nee, de verantwoordelijkheid van de browser is om de content zo goed mogelijk weer te geven, zelfs als er fouten inzitten, en niet de gebruiker op te zadelen met een 'parse error'. Nogmaals: we praten hier over een opmaaktaal niet over een programmeertaal. Authoring is heel wat anders dan programmeren, als mijn buurvrouw Beb een pagina over haar poes wil maken dan moet ze dat kunnen met minimale kennis van (X)HTML en de tools die ze daarvoor beschikbaar heeft die waarschijnlijk niet XML-based zijn en dus geen wellformedness kunnen garanderen.

De server heeft er maar voor te zorgen dat de data goed is. Scheelt waarschijnlijk ook weer een shitload aan allerlei security issues. Nog niet zo lang geleden kon je IE op zijn non-conforming smoeltje krijgen middels een (lege?) <input>-tag. Nou zeg ik niet dat dat in een XML-wereld niet kan voorkomen, maar een simpele parser is een eenvoudiger te schrijven parsers waar je beter het overzicht over houdt.

Welke serverside talen werken enkel en puur volledig XML-based? Welke CMS-en en authoringtools? Hoeveel 3rd party contents providers kunnen hun content gegarandeerd wellformed aanleveren? En heb je daar ook altijd wel een keuze in?

Overigens is het crashen van een browser een bug maar niet noodzakelijk een security-issue.

Verder: IE kan op een paar quirks na prima omgaan met XHTML 1.0 in text/html, hetgeen volgens de standaard is toegestaan.

Maar de standaard stelt daar wel een hele reeks compatibility guidelines voor op die by no means volledig is. Ken jij alle verschillen tussen HTML en XHTML rendering en/of houden jouw tools daar volledig rekening mee?

Het zou extreem wenselijk zijn als IE8 eindelijk eens stopt met het arrogant sturen van een "accept: */*"-header.

Jij zou willen dat IE een expliciete voorkeur opgeeft voor text/html zoals Firefox een voorkeur opgeeft voor application/xhtml+xml. Ik zou zeggen: geen expliciete voorkeur = impliciet voorkeur voor text/html - dat is wat op dit moment het meest gebruikt wordt voor webdocumenten.

Overigens is content-negotiation echt niet zo simpel om goed toe te passen, je kan niet eenvoudig een XHTML-document omzetten naar HTML (of andersom for that matter) omdat er gewoonweg incompatibilities zijn (niet alleen in syntax maar ook op het gebied van DOM en CSS).
En enkel domweg op basis van een accept-header hetzelfde document met een andere mime-type versturen is enorm kortzichtig. Of eigenlijk gewoon fout en harmful zelfs.

Niet dat er NU direct nut is bij XHTML tov HTML, hoewel voor embedded SVG wel al fijn, het nut van XML voor toekomstige uitbreidingen lijkt me toch vrij duidelijk. Desnoods wordt het renderen van een bepaalde namespaces door plug-in achtige oplossingen afgehandeld.

Ik zie niet waarom je in een HTML-document geen XML-applicaties zou kunnen embedden, en voor zover ik weet zal HTML5 daar ook wel in voorzien (mogelijk zelfs zonder verplichting om XML-serialisatie voor het document zelf af te dwingen). Uitbreidingen kunnen dus prima XML-based zijn, en daar is inderdaad niets mis mee (je praat dan ook niet meer echt over authoring).

[Fuzzillogic]

crisp schreef op donderdag 19 april 2007 @ 10:51:
[...]

Nee, de verantwoordelijkheid van de browser is om de content zo goed mogelijk weer te geven, zelfs als er fouten inzitten, en niet de gebruiker op te zadelen met een 'parse error'. Nogmaals: we praten hier over een opmaaktaal niet over een programmeertaal. Authoring is heel wat anders dan programmeren, als mijn buurvrouw Beb een pagina over haar poes wil maken dan moet ze dat kunnen met minimale kennis van (X)HTML en de tools die ze daarvoor beschikbaar heeft die waarschijnlijk niet XML-based zijn en dus geen wellformedness kunnen garanderen.

Zeg eens, welke authoring tool vereist dat buurvrouw Bep zelf met de opmaakcodes gaat lopen klooien? Een correct document is de verantwoordelijkheid van de authoringtool. Of type jij je PDFjes ook met de hand?
Zelfs volledig client-side lukt het ons om een authoring tool te maken die gewoon netjes XHTML als uitvoer heeft. Sowieso welformed, en zolang je niet gaan copy/pasten vanuit drek als Word, blijft het ook valid.

Welke serverside talen werken enkel en puur volledig XML-based? Welke CMS-en en authoringtools? Hoeveel 3rd party contents providers kunnen hun content gegarandeerd wellformed aanleveren? En heb je daar ook altijd wel een keuze in?

Nieuwe wereld, nieuwe regels. Als browsers strakker worden in wat ze wel/niet willen verwerken, dan volgen die tools verdomd snel. En zo niet dan doet de concurrent het wel.

Overigens is het crashen van een browser een bug maar niet noodzakelijk een security-issue.

Maar wel sterk gerelateerd. Dus je wilt geen crasher-bugs.

Maar de standaard stelt daar wel een hele reeks compatibility guidelines voor op die by no means volledig is. Ken jij alle verschillen tussen HTML en XHTML rendering en/of houden jouw tools daar volledig rekening mee?

Neuh, en ik heb er ook eigenlijk nooit last van. Beetje spijkers op laag water zoeken, imo.

Jij zou willen dat IE een expliciete voorkeur opgeeft voor text/html zoals Firefox een voorkeur opgeeft voor application/xhtml+xml. Ik zou zeggen: geen expliciete voorkeur = impliciet voorkeur voor text/html - dat is wat op dit moment het meest gebruikt wordt voor webdocumenten.

Je kunt een wegingsfactor aangeven. Als IE zegt liever text/html te zien dan application/xhtml+xml dan is dat prima. Maar alleen "accept: */*" verdient een trap in de noten.

Overigens is content-negotiation echt niet zo simpel om goed toe te passen, je kan niet eenvoudig een XHTML-document omzetten naar HTML (of andersom for that matter) omdat er gewoonweg incompatibilities zijn (niet alleen in syntax maar ook op het gebied van DOM en CSS).
En enkel domweg op basis van een accept-header hetzelfde document met een andere mime-type versturen is enorm kortzichtig. Of eigenlijk gewoon fout en harmful zelfs.

En hoevaak komt dat voor? Stel je hebt een website, met 2 templates. Een XHTML en een HTML versie, elk met zijn eigen specifieke CSS. De content zelf is veelal vrij eenvoudig van structuur. Headinkjes, paragrafen, strong, tabelletje, plaatje.. Niet echt bijzonder schokkend om de XHTML-versie daarvan in de HTML-template te stoppen.

Ik zie niet waarom je in een HTML-document geen XML-applicaties zou kunnen embedden, en voor zover ik weet zal HTML5 daar ook wel in voorzien (mogelijk zelfs zonder verplichting om XML-serialisatie voor het document zelf af te dwingen). Uitbreidingen kunnen dus prima XML-based zijn, en daar is inderdaad niets mis mee (je praat dan ook niet meer echt over authoring).

En als je HTML in een XML-sectie wilt embedden? Kun je met CDATA-secties gaan klooien. Nee bedankt.

[crisp]

Fuzzillogic schreef op donderdag 19 april 2007 @ 11:47:
[...]

Zeg eens, welke authoring tool vereist dat buurvrouw Bep zelf met de opmaakcodes gaat lopen klooien? Een correct document is de verantwoordelijkheid van de authoringtool. Of type jij je PDFjes ook met de hand?

Ah, dus authoring moet maar volledig WYSIWYG worden (we weten allemaal wat er dan gebeurd met semantiek), en Beb mag niet Notepad gebruiken om op basis van het boek 'HTML for Dummies' wat uit te proberen? Copy/pasten van document fragments is ook uit den boze?
En sinds wanneer zijn Frontpage of Dreamweaver full blown XML-applicaties die wellformedness kunnen garanderen?

Zelfs volledig client-side lukt het ons om een authoring tool te maken die gewoon netjes XHTML als uitvoer heeft. Sowieso welformed, en zolang je niet gaan copy/pasten vanuit drek als Word, blijft het ook valid.

Ook gegarandeerd wellformed? En als ik daar wat misnested tags inschiet, krijg ik dan een parse-error? En als ik lekker anchors of forms in elkaar ga nesten (wellformed zegt nog niet altijd of iets valid is)?

[...]

Nieuwe wereld, nieuwe regels. Als browsers strakker worden in wat ze wel/niet willen verwerken, dan volgen die tools verdomd snel. En zo niet dan doet de concurrent het wel.

De wereld is morgen echt niet ineens helemaal anders. Als mensen zien welke horror XML-based authoring met zich meebrengt dan blijven ze toch gewoon bij HTML of misbruiken het gewoon weer op zo'n manier dat browsers niets anders kunnen dan de boel gewoon weer als tagsoup te gaan behandelen.
Dat plus het feit dat je ook altijd nog met legacy blijft zitten die je niet simpelweg kan negeren.

[...]

Maar wel sterk gerelateerd. Dus je wilt geen crasher-bugs.

Je wilt ueberhaupt geen bugs in welke applicatie dan ook, maar ook dat is een utopie.

[...]

Neuh, en ik heb er ook eigenlijk nooit last van. Beetje spijkers op laag water zoeken, imo.

Dat jij er geen last van hebt wil niet zeggen dat het niet zo is of dat het zelfs maar spijkers op laag water zoeken is. Je kan niet ontkennen dat HTML en XHTML op punten niet compatible met elkaar zijn en dus kan je dat ook niet negeren.

[...]

Je kunt een wegingsfactor aangeven. Als IE zegt liever text/html te zien dan application/xhtml+xml dan is dat prima. Maar alleen "accept: */*" verdient een trap in de noten.

En waarom verdient dat een trap in de noten? Waar staat beschreven waar een accept request-header aan moet voldoen? Of is het puur omdat het jou beter zou uitkomen?

[...]

En hoevaak komt dat voor? Stel je hebt een website, met 2 templates. Een XHTML en een HTML versie, elk met zijn eigen specifieke CSS. De content zelf is veelal vrij eenvoudig van structuur. Headinkjes, paragrafen, strong, tabelletje, plaatje.. Niet echt bijzonder schokkend om de XHTML-versie daarvan in de HTML-template te stoppen.

Ten eerste wil je niet 2 verschillende templates aanhouden voor dezelfde content, en wat als die content nou eens niet eenvoudig van structuur is? Je kan niet zomaar zeggen dat als iets in 80% (of 90% of zelfs 99.9%) van de gevallen werkt dat het dan wel goed is.

Je hebt het zelf over webbrowsers die geen bugs mogen hebben, en over opmaak die altijd 100% volledig wellformed moet zijn, maar je accepteert wel dat hier gewoon problemen kunnen (en zullen) ontstaan door incompatibilities?

[...]

En als je HTML in een XML-sectie wilt embedden? Kun je met CDATA-secties gaan klooien. Nee bedankt.

Waarom niet? Als ik XML als data-container wil gebruiken voor een HTML document (of een verzameling documenten, of HTML fragments) dan zie ik niet wat daar mis mee is.

[Fuzzillogic]

crisp schreef op donderdag 19 april 2007 @ 12:24:
[...]
Ah, dus authoring moet maar volledig WYSIWYG worden (we weten allemaal wat er dan gebeurd met semantiek), en Beb mag niet Notepad gebruiken om op basis van het boek 'HTML for Dummies' wat uit te proberen? Copy/pasten van document fragments is ook uit den boze?

In hoofdstuk in van "XHTML for Dummies" staat precies geschreven hoe je tags moet opbouwen. En dat kun je in een alinea doen, zonder uitzonderingen. Dat lukt je niet met HTML, of dan wordt de alinea al een aardig stuk langer.

En sinds wanneer zijn Frontpage of Dreamweaver full blown XML-applicaties die wellformedness kunnen garanderen?

Frontpage is opgevolgd door een tool die het al significant beter doet en DreamWeaver doet het ook erg netjes.

Wat je vergeet is dat specificatie en implementatie twee verschillende dingen zijn. Het is niet de taak van een browser om een document op correctheid te controleren. Een browser verwacht gewoon perfecte code, en met de specificatie in de hand weet een browser hoe hij dat moet renderen. Als een auteur/tool iets doet dat buiten de specs omgaat dan betekent dat niet dat een browser daar gelijk over moet gaan schelden en schreeuwen. Een hedendaagse browser zal het veelal een worst wezen als-ie een <p><table /></p> tegenkomt, ook al mag dat niet. Maar het kan ook zijn dat vanwege de interne structuur de browser zegt "bekijk het maar".

Dat een browser rekening moet gaan houden met afwijkingen van de specificatie dan kom je op een hellend vlak. Dat in HTML5 wordt aangegeven hoe om te gaan met diverse foutsituaties is leuk en aardig, maar het blijft een hellend vlak. En ik vind niet dat een browser zich daar druk om moet maken.

En waarom verdient dat een trap in de noten? Waar staat beschreven waar een accept request-header aan moet voldoen? Of is het puur omdat het jou beter zou uitkomen?

Niet alleen mij, gok ik zo. Ik heb nu speciaal voor IE een workaround moeten maken om het juiste content type te sturen. Het is iig typerend voor IE, en Microsoft in het algemeen, imo.
'accept: */*' zou net zo goed van een hex-editor kunnen komen, die alles, text of binary data, toch op een identieke manier behandelt en waar het dus inderdaad niet uitmaakt wat-ie binnenkrijgt.

Waarom niet? Als ik XML als data-container wil gebruiken voor een HTML document (of een verzameling documenten, of HTML fragments) dan zie ik niet wat daar mis mee is.

Ja zo kun je alles in een CDATA-sectie flikkeren. Het kan wel, maar je als je het niet doet dan is dat wel zo handig, en kun je er bijv. direct met XSLT mee aan de slag.

[crisp]

Fuzzillogic schreef op donderdag 19 april 2007 @ 13:02:
[...]


In hoofdstuk in van "XHTML for Dummies" staat precies geschreven hoe je tags moet opbouwen. En dat kun je in een alinea doen, zonder uitzonderingen. Dat lukt je niet met HTML, of dan wordt de alinea al een aardig stuk langer.

Volgens mij niet zo heel veel langer: "De volgende elementen kunnen geen content bevatten en hebben derhalve geen sluittag: <img>, <meta>, <br>, <hr> etc.

Voor XHTML heb je een compleet hoofdstuk nodig om uit te leggen waarom elke ampersand encoded moet zijn, wat de implicaties zijn van het feit dat <script> en <style> geen CDATA meer zijn maar PCDATA, dat je DOM-tree anders is wanneer je implicit tags weglaat afhankelijk van de content-type waarmee je het verstuurd, waarom je beter geen XML-declaration kan gebruiken, waarom <html> ineens de viewport bepaald en niet <body> en wat dat voor implicaties heeft mbt CSS etcetera. Kortom: geheel appendix C met nog een hoop andere zaken.

[...]

Frontpage is opgevolgd door een tool die het al significant beter doet en DreamWeaver doet het ook erg netjes.

Fijn, maar garandeerd dat wellformedness? En hand-authoring wordt verboden? Accessibility gaat verder dan alleen de consumer hoor.

Wat je vergeet is dat specificatie en implementatie twee verschillende dingen zijn. Het is niet de taak van een browser om een document op correctheid te controleren. Een browser verwacht gewoon perfecte code, en met de specificatie in de hand weet een browser hoe hij dat moet renderen.

Externe input kan je nooit vertrouwen, in fact: je kan en mag er niet vanuit gaan dat je input perfect is. Dat is een bijzonder stomme aanname.
Verder hebben browsers geen specificatie in de hand maar zijn ze een implementatie van een bepaalde versie van een specificatie.

Als een auteur/tool iets doet dat buiten de specs omgaat dan betekent dat niet dat een browser daar gelijk over moet gaan schelden en schreeuwen.

Waarom dan wel eruit klappen als ik in XHTML een ampersand vergeet te encoden (iets dat een parser meestal prima en zonder ambiguiteiten op kan lossen)?

Een hedendaagse browser zal het veelal een worst wezen als-ie een <p><table /></p> tegenkomt, ook al mag dat niet.

Strikvraag: wat voor DOM zou dat volgens jou opleveren? In HTML en in XHTML?

Maar het kan ook zijn dat vanwege de interne structuur de browser zegt "bekijk het maar".

Er zullen vast wel situaties zijn waarbij door de error-correctie het resultaat niet precies is wat je voor ogen had, maar dat kan je een parser niet aanrekenen.

Dat een browser rekening moet gaan houden met afwijkingen van de specificatie dan kom je op een hellend vlak. Dat in HTML5 wordt aangegeven hoe om te gaan met diverse foutsituaties is leuk en aardig, maar het blijft een hellend vlak. En ik vind niet dat een browser zich daar druk om moet maken.

Volgens jou zou een parser dus altijd "bekijk het maar" moeten roepen bij elke foutsituatie...

[...]

Niet alleen mij, gok ik zo. Ik heb nu speciaal voor IE een workaround moeten maken om het juiste content type te sturen.

Nee, je gaat willens en wetens een verkeerde content type opgeven zonder je document om te zetten naar HTML. Het is puur te danken aan het feit dat voor een deel HTML en XHTML syntax wel compatible is, maar dat had ook anders kunnen zijn (en soms loop je wel tegen compatibility problemen aan op die manier).

Het is iig typerend voor IE, en Microsoft in het algemeen, imo.
'accept: */*' zou net zo goed van een hex-editor kunnen komen, die alles, text of binary data, toch op een identieke manier behandelt en waar het dus inderdaad niet uitmaakt wat-ie binnenkrijgt.

Voor een browser maakt het ook niet uit wat hij binnenkrijgt; wat hij zelf niet kan behandelen biedt hij ter download aan. De accept header van Firefox eindigd ook met */*

[...]

Ja zo kun je alles in een CDATA-sectie flikkeren. Het kan wel, maar je als je het niet doet dan is dat wel zo handig, en kun je er bijv. direct met XSLT mee aan de slag.

XSLT moet je ook niet clientside willen doen, en anders pak je straks toch gewoon de XML-serialisatie van HTML5?

[Alex)]

Waarom zou ik verplicht met tools als Expression Web of Dreamweaver moeten werken, zodat ik maar geen foute code oplever? De hel... ik hou helemaal niet van WYSIWYG, met simpel Kladblok heb ik veel sneller een valid document opgezet dan met tools zoals Expression Web en Dreamweaver...

[Fuzzillogic]

crisp schreef op donderdag 19 april 2007 @ 13:40:
[...]

Volgens mij niet zo heel veel langer: "De volgende elementen kunnen geen content bevatten en hebben derhalve geen sluittag: <img>, <meta>, <br>, <hr> etc.

Voor XHTML heb je een compleet hoofdstuk nodig om uit te leggen waarom elke ampersand encoded moet zijn, wat de implicaties zijn van het feit dat <script> en <style> geen CDATA meer zijn maar PCDATA, dat je DOM-tree anders is wanneer je implicit tags weglaat afhankelijk van de content-type waarmee je het verstuurd, waarom je beter geen XML-declaration kan gebruiken, waarom <html> ineens de viewport bepaald en niet <body> en wat dat voor implicaties heeft mbt CSS etcetera. Kortom: geheel appendix C met nog een hoop andere zaken.

Hoho, je gaat nu de verschillen aanhalen. Voor iemand die alleen geinteresseerd is in XHTML boeit dat allemaal niets.

Fijn, maar garandeerdt dat wellformedness? En hand-authoring wordt verboden? Accessibility gaat verder dan alleen de consumer hoor.
[...]
Externe input kan je nooit vertrouwen, in fact: je kan en mag er niet vanuit gaan dat je input perfect is. Dat is een bijzonder stomme aanname.

Mijn punt is dat een browser alleen een correcte weergave garandeert (of althans poogt) bij een foutloos document. Het document hoeft niet foutloos de te zijn, maar dan kan de uitvoer in meer of mindere mate ook fouten bevatten.

Waarom dan wel eruit klappen als ik in XHTML een ampersand vergeet te encoden (iets dat een parser meestal prima en zonder ambiguiteiten op kan lossen)?

Ik had ooit eens de parameter 'reg' (van 'regio') als parameter in een link. Voel je hem al aankomen? Zit je toch mooi te kijken met je "meestal". Ik had google destijds met plezier in de noten willen trappen, want google escapet de ampersand dus niet.

Strikvraag: wat voor DOM zou dat volgens jou opleveren? In HTML en in XHTML?

tbody enzo, Interessant (not).

Volgens jou zou een parser dus altijd "bekijk het maar" moeten roepen bij elke foutsituatie...

Dat is een optie, maar ook dat maakt het parsen juist weer lastiger en complexer, want je moet dan weer een explicite controle gaan doen, terwijl ik zei dat dat nou net niet de bedoeling is.

Nee, je gaat willens en wetens een verkeerde content type opgeven zonder je document om te zetten naar HTML. Het is puur te danken aan het feit dat voor een deel HTML en XHTML syntax wel compatible is, maar dat had ook anders kunnen zijn (en soms loop je wel tegen compatibility problemen aan op die manier).

Wie zegt dat ik dan XHTML-code naar IE stuur? XHTML is prima om te zetten naar HTML. Dat kan vaak al met een regexje.

Voor een browser maakt het ook niet uit wat hij binnenkrijgt; wat hij zelf niet kan behandelen biedt hij ter download aan. De accept header van Firefox eindigd ook met */*

Er is ook niets mis met */*, als laatste optie. Maar Firefox geeft wel aan dat-ie liever text/html en application/xhtml+xml ziet dan */*. Dat doet IE niet.

XSLT moet je ook niet clientside willen doen, en anders pak je straks toch gewoon de XML-serialisatie van HTML5?

XSLT is prima geschikt voor ajax-achtige tools, waarbij je alleen de data doorstuurt. In fact, ik vind het dan vreemd als je kant-en-klaar HTML doorstuurt ipv de ruwe data. Met accessibility heeft het immers niets meer te maken.

[Fuzzillogic]

Alex) schreef op donderdag 19 april 2007 @ 13:48:
Waarom zou ik verplicht met tools als Expression Web of Dreamweaver moeten werken, zodat ik maar geen foute code oplever? De hel... ik hou helemaal niet van WYSIWYG, met simpel Kladblok heb ik veel sneller een valid document opgezet dan met tools zoals Expression Web en Dreamweaver...

Nee je bent helemaal niets verplicht. Maar ook met notepad kun je prachtige valid XHTML-documenten maken. In fact, het is eigenlijk niet eens meer werk. En als je een generic XML-ding gebruikt heb je het meteen al well-formed zonder dat je erbij hoeft na te denken.

[ Voor 3% gewijzigd door Fuzzillogic op 19-04-2007 15:29 ]

[Arnold]

XHTML1 serveren als text/html zit toch in de XHTML1 standaard ingebakken en is dus vanuit de standaard gezien niet fout? Iemand die dus liever XHTML1 schrijft ipv HTML maar dan dus als text/html is volgens de specificatie dan niet verkeerd bezig.
Of heb ik die verkeerd begrepen?
Het is bij XHTML1 dan dus niet verplicht met XML te werken (wat natuurlijk erg raar is eigenlijk...)

zie: http://www.w3.org/TR/xhtml1/#issues

[crisp]

Fuzzillogic schreef op donderdag 19 april 2007 @ 15:26:
[...]

Hoho, je gaat nu de verschillen aanhalen. Voor iemand die alleen geinteresseerd is in XHTML boeit dat allemaal niets.

Waarom zijn die verschillen niet relevant? Oh nee, wacht, we zouden alle legacy documenten toch weggooien dus dan is de klans dat iemand nog een voorbeeld tegenkomt dat gestoelt is op HTML ook al kleiner. Alle boeken ook maar verbranden?

[...]

Mijn punt is dat een browser alleen een correcte weergave garandeert (of althans poogt) bij een foutloos document. Het document hoeft niet foutloos de te zijn, maar dan kan de uitvoer in meer of mindere mate ook fouten bevatten.

Dus de draconische error-handling van XHTML mbt syntax-fouten mag van jou ook wel anders opgelost worden? Dan worden we het misschien toch nog eens eens

[...]

Ik had ooit eens de parameter 'reg' (van 'regio') als parameter in een link. Voel je hem al aankomen? Zit je toch mooi te kijken met je "meestal". Ik had google destijds met plezier in de noten willen trappen, want google escapet de ampersand dus niet.

Ik vraag me nu even af of de puntkomma voor entiteiten in XML nou wel of niet verplicht is (die is optioneel in SGML en dus HTML). Maar goed, dat was dus een minder goed gekozen voorbeeld. Dat Google het niet netjes doet doet hier niet echt ter zake: van Google mag je verwachten dat ze beter weten, voor mijn buurvrouw Beb is het echter erg lastige materie. Misschien moeten we de puntkomma maar verplicht maken zodat de kans op ambiguiteiten nog verder afneemt

[...]

tbody enzo, Interessant (not).

Toch wel interessant; bepaalde scripts kunnen aannames maken die in een andere rendermode ineens niet meer blijken te kloppen. Sure, die scripts zijn dan niet zo netjes geschreven, misschien was het wel een scriptje dat mijn buurvrouw Beb ergens vandeen heeft gehaald. Toch jammer dat "XHTML voor Dummies" daar geen hoofdstuk over had...
Gelukkig gebruiken hele volksstammen nog HTML-comments binnen script-tags, scheelt weer fouten op het moment dat ze die pagina's naar XHTML omzetten.

[...]

Dat is een optie, maar ook dat maakt het parsen juist weer lastiger en complexer, want je moet dan weer een explicite controle gaan doen, terwijl ik zei dat dat nou net niet de bedoeling is.

Stoppen bij de eerste error die je tegenkomt in plaats van proberen er iets van te maken was toch juist minder complex?

[...]

Wie zegt dat ik dan XHTML-code naar IE stuur? XHTML is prima om te zetten naar HTML. Dat kan vaak al met een regexje.

Ik probeer net uit te leggen dat dat niet altijd kan en dat het alleen daarom dus al een slecht idee is. Houdt het gewoon bij 1 markup-taal, en ja, dan valt XHTML af als optie.

[...]

Er is ook niets mis met */*, als laatste optie. Maar Firefox geeft wel aan dat-ie liever text/html en application/xhtml+xml ziet dan */*. Dat doet IE niet.

Nee dat zei ik toch ook? Maar waarom zou het ontbreken van de preference dan een probleem zijn? text/html lijkt me dan een hele goede kandidaat om als default te nemen als je zelf de keuze hebt uit text/html of application/xhtml+xml

[...]

XSLT is prima geschikt voor ajax-achtige tools, waarbij je alleen de data doorstuurt. In fact, ik vind het dan vreemd als je kant-en-klaar HTML doorstuurt ipv de ruwe data. Met accessibility heeft het immers niets meer te maken.

Ik vind XSLT daarvoor weer meestal overkill, en overigens levert dat vaak nog genoeg hoofdbrekens op in IE. Ik zeg ook niet dat kant-en-klare HTML wel een goede oplossing is (hoewel dat in de praktijk wel beter werkt en sneller is), maar in veel gevallen is een meer light-weight oplossing zoals JSON om data over te sturen ook een beter alternatief. Je clientside applicatie kan vervolgens prima zelf de opmaak daaromheen genereren.

[crisp]

GS2K1 schreef op donderdag 19 april 2007 @ 16:10:
XHTML1 serveren als text/html zit toch in de XHTML1 standaard ingebakken en is dus vanuit de standaard gezien niet fout? Iemand die dus liever XHTML1 schrijft ipv HTML maar dan dus als text/html is volgens de specificatie dan niet verkeerd bezig.
Of heb ik die verkeerd begrepen?
Het is bij XHTML1 dan dus niet verplicht met XML te werken (wat natuurlijk erg raar is eigenlijk...)

zie: http://www.w3.org/TR/xhtml1/#issues

Het is een MAY, maar eigenlijk ook met een hele dikke vette MAAR.
Dat iets in de praktijk lijkt te werken is eigenlijk geen goede reden om te zeggen dat het dus ook goed is. In feite is er de laatste jaren enkel maar meer bewijs gekomen dat het eigenlijk helemaal niet goed is en dat het zowel schade heeft opgeleverd voor HTML (niet volledig meer kunnen confirmeren aan de SGML standaard) als voor XHTML zelf (XHTML documenten authored met text/html in gedachten zullen in de meeste gevallen niet meer goed werken als ze als XHTML verstuurd zouden worden).

http://www.hixie.ch/advocacy/xhtml
http://lachy.id.au/log/2005/12/xhtml-beginners

[Arnold]

crisp schreef op donderdag 19 april 2007 @ 16:46:
[...]

Het is een MAY, maar eigenlijk ook met een hele dikke vette MAAR.
Dat iets in de praktijk lijkt te werken is eigenlijk geen goede reden om te zeggen dat het dus ook goed is. In feite is er de laatste jaren enkel maar meer bewijs gekomen dat het eigenlijk helemaal niet goed is en dat het zowel schade heeft opgeleverd voor HTML (niet volledig meer kunnen confirmeren aan de SGML standaard) als voor XHTML zelf (XHTML documenten authored met text/html in gedachten zullen in de meeste gevallen niet meer goed werken als ze als XHTML verstuurd zouden worden).

http://www.hixie.ch/advocacy/xhtml
http://lachy.id.au/log/2005/12/xhtml-beginners

De enige echte MAAR is eigenlijk dat als je gaat updaten naar application/xhtml+xml het toch allemaal wel kapot gaat en er dus werk aan de winkel zal zijn.

Maar als je dat niet van plan bent te doen, gaat het met text/html wel goed in alle moderne browsers en is het opzich fijn dat het meer strict werkt dan html (uppercase/lowercase, elementen afsluiten e.d.).

Ik ben het er mee eens dat het niet de bedoeling is van XHTML en dat je net zo goed HTML kan gebruiken, maar uiteindelijk als iemand het fijn vind om met XHTML text/html te werken moet hij dat zelf weten... XHTML is niet geworden wat het zou moeten zijn vooral door de geweldige support van Internet Explorer.

Nu Microsoft de HTML working group heeft gejoined ziet het er wel iets beter uit voor HTML5, maar ik blijf bang dat ze alles teveel backward compatible willen houden en dit uiteindelijk gaat zorgen voor brakke HTML5 support in IE.next en we nog jaren omwegen en "smerige" hacks moeten blijven gebruiken om alles cross-browser compatible, 99% volgens de standaarden te laten werken...

[Fuzzillogic]

crisp schreef op donderdag 19 april 2007 @ 16:34:
[...]
Waarom zijn die verschillen niet relevant? Oh nee, wacht, we zouden alle legacy documenten toch weggooien dus dan is de klans dat iemand nog een voorbeeld tegenkomt dat gestoelt is op HTML ook al kleiner. Alle boeken ook maar verbranden?

We gooien niks weg. Maar assembler interesseert mij ook bar weinig. Of dat AWT van Java <v1.2 nogal matig was. Je hoeft je daar niet in te verdiepen, tenzij je dat wilt. Er is gewoon iets nieuws, iets beters, dat alles wat ervoor was vervangt. Hetzelfde geldt voor de opvolger van HTML. Als je dat als je basis neemt, wat zou het jou dan aan je achterste roesten hoe men vroeger werkte?

Dus de draconische error-handling van XHTML mbt syntax-fouten mag van jou ook wel anders opgelost worden? Dan worden we het misschien toch nog eens eens

Met mijn voorbeeld van <p><table /></p> zal de browser in veel gevallen niet eens merken dat het fout is. Maar als er <p><table colspan=2></p> staat, dan begint een XML-parser wel te zeiken. Natuurlijk kun je die 'XML'-parser dan zo verbouwen dat-ie dit ook nog wel snapt, bijv. door te veronderstellen dat elk element automatisch is afgesloten als zijn parent wordt afgesloten. Maar als auteur moet je daar gewoon niet vanuit gaan. Het levert ambiguiteiten op.

Ik vraag me nu even af of de puntkomma voor entiteiten in XML nou wel of niet verplicht is (die is optioneel in SGML en dus HTML). Maar goed, dat was dus een minder goed gekozen voorbeeld. Dat Google het niet netjes doet doet hier niet echt ter zake: van Google mag je verwachten dat ze beter weten, voor mijn buurvrouw Beb is het echter erg lastige materie. Misschien moeten we de puntkomma maar verplicht maken zodat de kans op ambiguiteiten nog verder afneemt

Bingo! Precies dit soort "hm hoe zat het ook alweer? <p>, moest je die afsluiten? En <meta>?" Het is gewoon HANDIG als er eenduidige, simpele regels zijn. Zonder dat ik het nakijk durf ik wel te zeggen dat die puntkomma gewoon verplicht is in XML, en met een goede reden dus.

Toch wel interessant; bepaalde scripts kunnen aannames maken die in een andere rendermode ineens niet meer blijken te kloppen. Sure, die scripts zijn dan niet zo netjes geschreven, misschien was het wel een scriptje dat mijn buurvrouw Beb ergens vandeen heeft gehaald. Toch jammer dat "XHTML voor Dummies" daar geen hoofdstuk over had...
Gelukkig gebruiken hele volksstammen nog HTML-comments binnen script-tags, scheelt weer fouten op het moment dat ze die pagina's naar XHTML omzetten.

Er zijn nu ook bergen scripts uit 19nul die met document.all werken en toch nog rondzwerven. Dus dan zie je ook hier dat het handig zou zijn geweest als er destijds al één systeem zou zijn geweest. Maar HTML5 biedt de keuze tussen gecastreerde SGML en XML-varianten. Leren ze nooit van de fouten?

Stoppen bij de eerste error die je tegenkomt in plaats van proberen er iets van te maken was toch juist minder complex?

Wanneer is een error een error? Een error tegen de specificatie hoeft de parser niet perse op te vallen. Is het dan een error? Zie ook stukje hierboven.

Ik probeer net uit te leggen dat dat niet altijd kan en dat het alleen daarom dus al een slecht idee is. Houdt het gewoon bij 1 markup-taal, en ja, dan valt XHTML af als optie.

Nou ok, dan zijn we het erover eens dat er 1 markup-taal moet komen. Maar for the sake of uniformity, doe dat XML, en flikker alle legacy uit de standaard.

Nee dat zei ik toch ook? Maar waarom zou het ontbreken van de preference dan een probleem zijn? text/html lijkt me dan een hele goede kandidaat om als default te nemen als je zelf de keuze hebt uit text/html of application/xhtml+xml

Leg die voorkeur dan vast in de standaard. Dan nog lijkt het mij een slecht idee.

Ik vind XSLT daarvoor weer meestal overkill, en overigens levert dat vaak nog genoeg hoofdbrekens op in IE. Ik zeg ook niet dat kant-en-klare HTML wel een goede oplossing is (hoewel dat in de praktijk wel beter werkt en sneller is), maar in veel gevallen is een meer light-weight oplossing zoals JSON om data over te sturen ook een beter alternatief. Je clientside applicatie kan vervolgens prima zelf de opmaak daaromheen genereren.

Ligt eraan. JSON is leuk en aardig, maar je zult het niet standaard aantreffen in de browsers. En als je een server hebt die de data in XML-vorm aanbiedt, dan heb je weer een conversiestap nodig. XSL zit tegenwoordig vrij standaard in browsers. Ach het heeft zijn voors en tegens.

[crisp]

Fuzzillogic schreef op donderdag 19 april 2007 @ 17:33:
[...]

We gooien niks weg. Maar assembler interesseert mij ook bar weinig. Of dat AWT van Java <v1.2 nogal matig was. Je hoeft je daar niet in te verdiepen, tenzij je dat wilt. Er is gewoon iets nieuws, iets beters, dat alles wat ervoor was vervangt. Hetzelfde geldt voor de opvolger van HTML. Als je dat als je basis neemt, wat zou het jou dan aan je achterste roesten hoe men vroeger werkte?

Als de opvolger van HTML (zo goed mogelijk) backwards-compatible is met oude content dan zal ik HTML4 graag vergeten ja

[...]

Met mijn voorbeeld van <p><table /></p> zal de browser in veel gevallen niet eens merken dat het fout is. Maar als er <p><table colspan=2></p> staat, dan begint een XML-parser wel te zeiken. Natuurlijk kun je die 'XML'-parser dan zo verbouwen dat-ie dit ook nog wel snapt, bijv. door te veronderstellen dat elk element automatisch is afgesloten als zijn parent wordt afgesloten. Maar als auteur moet je daar gewoon niet vanuit gaan. Het levert ambiguiteiten op.

Ik bedoelde dit:

HTML:

<p><table><tr><td>foo</td></tr></table></p>

Invalid in zowel HTML4 (niet in HTML5 though ) als XHTML (maar wel well-formed), maar het levert de volgende DOM-tree op:
in HTML:

code:

P
TABLE
    TBODY
        TR
            TD
                #text

in XHTML:

code:

P
    TABLE
        TR
            TD
                #text

get my point?

[...]

Bingo! Precies dit soort "hm hoe zat het ook alweer? <p>, moest je die afsluiten? En <meta>?" Het is gewoon HANDIG als er eenduidige, simpele regels zijn. Zonder dat ik het nakijk durf ik wel te zeggen dat die puntkomma gewoon verplicht is in XML, en met een goede reden dus.

Die is inderdaad verplicht in XML, en feit is dat geen enkele browser de puntkomma als optioneel ondersteund. HTML5 maakt de puntkomma derhalve ook verplicht.

Punt met optional tags is dat je dat niet kan uitbannen omdat oude content er gebruik van maakt en huidige browsers daar nu ook support voor bieden. Ik denk echter niet dat je dergelijke minimalisaties als good practice moet beschouwen en ik vind ook dat de specificatie zou moeten aanraden om toch zoveel mogelijk "well-formed" te werken al is het alleen maar omdat fouten dan sneller opvallen (in het <p><table> verhaal was het voorbeeld valid HTML geweest als ik de </p> had weggelaten, maar wellicht had ik toch een andere DOM-tree voor ogen als ik niet had geweten dat <table> niet in <p> mag).

[...]

Er zijn nu ook bergen scripts uit 19nul die met document.all werken en toch nog rondzwerven. Dus dan zie je ook hier dat het handig zou zijn geweest als er destijds al één systeem zou zijn geweest. Maar HTML5 biedt de keuze tussen gecastreerde SGML en XML-varianten. Leren ze nooit van de fouten?

Je zou XML ook als een rigide gecastreerd SGML-derivaat kunnen zien natuurlijk HTML had van oorsprong misschien iets minder los opgezet moeten worden en zonder allerlei SGML-features als SHORTTAG die toch nooit geimplementeerd zijn. Optional tags hebben natuurlijk hun oorsprong vanuit het feit dat storage en bandwidth duur was in die tijd.
Ja, er is wel geleerd van die fouten, dus bepaalde features worden geschrapt. Enkel de features die wel supported waren en ook in het wild gebruikt zijn kan je niet zomaar schrappen in een opmaaktaal die backwards-compatible wenst te zijn.

document.all is een slecht voorbeeld in deze omdat je dan praat over propriety technologie.

[...]

Wanneer is een error een error? Een error tegen de specificatie hoeft de parser niet perse op te vallen. Is het dan een error? Zie ook stukje hierboven.

Ja, dat zijn allemaal errors, maar verschillende typen: parse-errors (syntax) vs conformance-errors. En inderdaad, de parser heeft niets te maken met de conformance rules, daar is een seperate conformance-checker voor nodig.

[...]

Nou ok, dan zijn we het erover eens dat er 1 markup-taal moet komen. Maar for the sake of uniformity, doe dat XML, en flikker alle legacy uit de standaard.

Ok, let's have it your way: we doen een compleet nieuwe markup-taal gebaseerd op XML
1) uiteraard kan dat niet een taal zijn die deels backwards-compatible is met HTML/XHTML1; mensen gaan het dan toch weer als tagsoup versturen omdat het dan meestal toch wel "werkt" (zie XHTML1) en het zou veels te verwarrend zijn.
2) om kans van slagen te hebben moet alles erop voorbereid zijn tegen de tijd dat het geintroduceerd wordt. Laten we maar aannemen dat het een absolute killer-technologie is en iedereen er op zit te wachten, early adoptie is belangrijk en dus moeten authoring-tools, CMS-en, content-providers, legacy systemen, serverside programmeertalen en niet te vergeten browsers er helemaal klaar voor zijn; we krijgen immers een compleet nieuw soort internet!
3) oh wacht, we zitten nog met legacy content; wat doen we daarmee? Och, dan zorgen we toch dat alle voornoemde systemen ook nog kunnen omgaan met die oude meuk. Maar voor hoelang?
4) Beb snapt er niets meer van, maar da's pech voor Beb

[...]

Leg die voorkeur dan vast in de standaard. Dan nog lijkt het mij een slecht idee.

Wat is een slecht idee? De aanname dat een client waarschijnlijk eerder text/html kan verwerken dan application/xhtml+xml is gezien de praktijk toch geen verkeerde lijkt me?

[...]

Ligt eraan. JSON is leuk en aardig, maar je zult het niet standaard aantreffen in de browsers. En als je een server hebt die de data in XML-vorm aanbiedt, dan heb je weer een conversiestap nodig. XSL zit tegenwoordig vrij standaard in browsers. Ach het heeft zijn voors en tegens.

JSON-support is voorgesteld om standaard opgenomen te worden in javascript2 en veel serverside talen ondersteunen het al native. XSL support in browsers is maar matig (nou ja, in ieder geval in IE omdat IE geen onderscheid kan maken tussen XHTML en XML en op z'n plaat gaat als je bijvoorbeeld named entities gebruikt die in XHTML volledig valid zijn). Daarnaast is het aantal systemen dat niet native met XML werkt behoorlijk groter dan het aantal systemen dat wel een volledige XML-backend heeft.

[crisp]

GS2K1 schreef op donderdag 19 april 2007 @ 16:59:
[...]


De enige echte MAAR is eigenlijk dat als je gaat updaten naar application/xhtml+xml het toch allemaal wel kapot gaat en er dus werk aan de winkel zal zijn.

Juist, dus kiezen voor XHTML zonder rekening te houden met de echte verschillen tov HTML, en XHTML gewoon als tagsoup (text/html) versturen is wat dat betreft weinig forwards-compatible. In fact: dat is de doodsteek geweest voor XHTML in de huidige vorm.

Maar als je dat niet van plan bent te doen, gaat het met text/html wel goed in alle moderne browsers en is het opzich fijn dat het meer strict werkt dan html (uppercase/lowercase, elementen afsluiten e.d.).

Dat is niet meer 'strict' maar puur een andere definitie van syntax. In jouw perceptie zijn die regels voor XHTML simpeler maar de praktijk wijst uit dat het gebruik van 'echt' XHTML juist ingewikkelder is, en een specificatie die je niet dwingt om een XHTML-document ook als zodanig te publiceren is een vrijbrief om toch te kunnen doen wat je wilt - daar gaat je 'strict' (en je ondermijnd daarmee dus andere specificaties).

Ik ben het er mee eens dat het niet de bedoeling is van XHTML en dat je net zo goed HTML kan gebruiken, maar uiteindelijk als iemand het fijn vind om met XHTML text/html te werken moet hij dat zelf weten... XHTML is niet geworden wat het zou moeten zijn vooral door de geweldige support van Internet Explorer.

Nee, XHTML is geworden wat het is - een soort dialect van HTML - doordat de spec niet 'strict' genoeg was op het gebied van mime-type. Daarnaast is XHTML op een verkeerde manier gehyped en volledig verkeerd begrepen.

Nu Microsoft de HTML working group heeft gejoined ziet het er wel iets beter uit voor HTML5, maar ik blijf bang dat ze alles teveel backward compatible willen houden en dit uiteindelijk gaat zorgen voor brakke HTML5 support in IE.next en we nog jaren omwegen en "smerige" hacks moeten blijven gebruiken om alles cross-browser compatible, 99% volgens de standaarden te laten werken...

Backwards-compatibility is belangrijk en de specificatie voorziet daarin. Microsoft's probleem is dat ze nu nog steeds met een render-engine zitten die nog niet eens compatible is met huidige specificaties, laat staan klaar is voor een nieuwe versie van HTML. IE is verantwoordelijk voor het feit dat veel pagina's op het web niet standards-compliant zijn en mogelijk straks gaan breken als ze HTML5 gaan ondersteunen en dat willen ze voorkomen door met speciale "opt-in" switches te gaan werken.

[Fuzzillogic]

crisp schreef op donderdag 19 april 2007 @ 23:34:
[...]
Als de opvolger van HTML (zo goed mogelijk) backwards-compatible is met oude content dan zal ik HTML4 graag vergeten ja

Ik zou C ook liever vergeten ja, maar helaas. Toch hindert mij dat niet met bijv. Java.

Ik bedoelde dit:

HTML:

<p><table><tr><td>foo</td></tr></table></p>

Invalid in zowel HTML4 (niet in HTML5 though ) als XHTML (maar wel well-formed), maar het levert de volgende DOM-tree op:
in HTML:

code:

P
TABLE
    TBODY
        TR
            TD
                #text

in XHTML:

code:

P
    TABLE
        TR
            TD
                #text

get my point?

Nee, want bijv. IE maakt er doodleuk dit van:

code:

P
    TABLE
        TBODY
            TR
                TD
                    #text

Die is inderdaad verplicht in XML, en feit is dat geen enkele browser de puntkomma als optioneel ondersteund. HTML5 maakt de puntkomma derhalve ook verplicht.

Oh? In dat geval zou er geen probleem zijn geweest. Maar dat was er toch. Rara.

Punt met optional tags is dat je dat niet kan uitbannen omdat oude content er gebruik van maakt en huidige browsers daar nu ook support voor bieden.

Dat soort dingen kun je prima oplossen met een nieuwe specificatie die geen last heeft van dergelijke legacy-meuk.

Je zou XML ook als een rigide gecastreerd SGML-derivaat kunnen zien natuurlijk

Ze hebben het tag/boom-principe van SGML genomen en van de rest gedacht: ok deze meuk is niet te handhaven en maakt het nodeloos complex. WEG ERMEE. As I said before: er is een reden dat XML populair is geworden ten koste van SGML. De eenduidige en eenvoudige structuur maakt dat software eenvoudig kan blijven, dat maakt dat er veel software voor is.

Het zou me dan ook niet verbazen als de huidige complexiteit die een browser moet bezitten om ueberhaupt een HTML webpagina weer te geven dan ook de reden is dat er eigenlijk maar een handje vol browsers zijn. Ik kan meer operating systems van belang opnoemen dan browsers. Teken aan de wand? Ik denk het wel.

Ja, dat zijn allemaal errors, maar verschillende typen: parse-errors (syntax) vs conformance-errors. En inderdaad, de parser heeft niets te maken met de conformance rules, daar is een seperate conformance-checker voor nodig.

Thin line in dit geval. colspan=2 is een syntax error, maar met een wat meer vergevingsgezinde parser opeens enkel nog een conformance error.

Ok, let's have it your way: we doen een compleet nieuwe markup-taal gebaseerd op XML
knip issues.

Ach weet je, het zou nog niet eens zo'n probleem zijn om bijv XHTML 1.1 met wat uitbreidingen op te nemen als namespace voor text-documents. Wat mij met name stoort is het totale gebrek aan specifieke support voor webapplicaties, qua GUI, in HTML5. En dat ze uitbreidingen aan de forms ook weer allemaal in de HTML-namespace flikkeren.

Ook Rome is niet in 1 dag gebouwd. Maar als de browser support bieden voor een next-gen iets, dan komen de content providers wel heel snel met toepassingen. Kijk maar al eens naar de enorme verscheidenheid van extensies voor Firefox/Thunderbird (XUL), en dat is dan nog maar een relatief klein platform.

[Superdeboer]

crisp schreef op vrijdag 20 april 2007 @ 00:06:
Juist, dus kiezen voor XHTML zonder rekening te houden met de echte verschillen tov HTML, en XHTML gewoon als tagsoup (text/html) versturen is wat dat betreft weinig forwards-compatible. In fact: dat is de doodsteek geweest voor XHTML in de huidige vorm.

Juist, en de doodsteek voor XHTML als application/xml+xhtml is die verrekte draconische foutafhandeling. Daar is hier in dit topic al erg veel over gezegd, maar ik wil er graag mijn visie aan toevoegen.

Stellen dat er voldoende capabele authoring tools zijn om well formedness voor je X(HT)ML document te garanderen en, dat in aanmerking nemende, menen dat XHTML de enige juiste route voor de toekomst is, is de identiteit van het huidige web miskennen. De vorm, omvang en populariteit van 'internet' als fenomeen van de afgelopen tien jaar is volledig, maar dan ook echt volledig te danken aan het feit dat werkelijk elke aap (en ook buurvrouw Bep) met een beetje moeite haar huisdier op haar persoonlijke homepage kon zetten. Internet kent zijn bestaansrecht in het feit dat iedereen daarmee op een podium van wereldformaat kan publiceren, zonder daar een instituut als een uitgever of een omroep voor nodig te hebben. Bep weet niet hoe ze aan dreamweaver komt. Bep weet niet hoe ze aan frontpage komt. Wat Bep wel kan, is dingen kopiëren uit de code van de site van haar beste vriendin. Ik durf de stelling wel aan dat negentig procent van alle webdevelopers zijn eerste site bij elkaar heeft gejat uit de bron van sites waar ze iets zagen dat ze mooi vonden. Zó is het internet ontwikkeld en zó groeit het vandaag nog steeds.

Niet door de vijf procent van alle contentschrijvers voor het web, die wel weten welke authoring tool ze nodig hebben om spec conformant documenten te genereren. Niet door mensen die weten dat ze zich met die tool níet druk hoeven te maken om character encoding en well formedness van hun document. Het internet is wat het vandaag is en zal zo verder groeien door mensen die zich niet alleen niet druk daarom maken, maar die het überhaupt niet weten. Die mensen jatten gewoon braaf iets uit andermans bron en plakken dat in hun eigen ding. Die groep mensen gaat gillend door het lint als hun code een vette parse error oplevert, simpelweg omdat ze geen idee hebben waarom dat gebeurt en ze dat ook niet kunnen leren. Denken dat iedereen het 'vanzelf wel leert' omdat XHTML simpeler basisregels heeft, is een utopie: die codekopieerders houden zich in het geheel niet met regels bezig. Zij kunnen HTML leren door vijf tutorials te lezen, zonder ooit van het W3C kennis te nemen. Ondertussen denk ik dat juist deze mensen het leeuwendeel van het internet gevuld hebben.

Niet zeuren over de door mij geroepen percentages, daar heb ik geen bron bij, dat zijn gewoon beelden for the sake of the argument. Wat ik maar aan wil geven, is dat het internet is wat het is, mede door mensen die volstrekt geen benul hebben wat ze doen. Juist het feit dat het huisdier van buurvrouw Bep online staat ondanks het feit dat zij niet belast is met enige inhoudelijke kennis, zorgt ervoor dat we nu allemaal internet hebben. Internet begon als iets van studenten en nerds, nu is het iets van elke wereldburger. De meeste wereldburgers weten niets van XML entities, character encoding en well formedness. Ze zullen dat de komende jaren niet leren. Ook leren ze niet wat een XML parse error is en waarom die zich laat zien. Tot slot leren ze niet welke tools ze moeten hebben om goede documenten te maken. Dat komt omdat ze het belang daar niet van inzien... simpelweg omdat ze geen enkel benul van het bestaan van dat alles hebben. Ik haal hier graag aan dat het gros van de mensen volstrekt niet weet hoe de motor van hun auto werkt maar ze weten wel hoe ze ermee van A naar B komen en daar gaat het ze om. Zo weten die mensen ook niet wat (X)HTML nou precies is, maar ze weten wel dat ze hun huisdier daarmee online krijgen en daar gaat het ze om.

Zoveel onkunde heeft bewezen een zeer succesvol medium te kunnen opbouwen, namelijk het internet zoals we dat vandaag de dag kennen. Zoveel onkunde kan naar mijn mening echter in geen vijftien jaar omgaan met de eisen die een goed gebruik van de XHTML-specificaties aan een web author stelt. Een standaard kan dan ook geen doel in zich zijn, maar moet altijd als middel beschouwd worden om tot het doel van de publicatie van content te komen. Het draait niet om de techniek, maar om de inhoud. De XHTML-standaard met draconische error maakt de inhoud echter ondergeschikt aan de techniek: een fout afgesloten tag maakt mijn hele wetenschappelijke publicatie onleesbaar. Een fout in mijn opmaak wordt gesanctioneerd met complete ontoegankelijkheid van mijn tekst. Iemand die echt gelooft dat een technologie met zulke uitgangspunten een toekomst heeft in een omgeving die groot geworden is door mensen als buurvrouw Bep, ontkent het echte karakter van het huidige internet mijns inziens.

[Alex)]

Wat is er mis met de huidige HTML-namespace uitbreiden? Waarom zou je een compleet nieuwe standaard moeten maken voor iets wat al een goede basis heeft?

Met HTML kun je prima dingen vormgeven, alleen zijn er wat hiaten ja. Maar waarom zou je die niet wegwerken met een nieuwe versie met een compleet andere syntax?

[Fuzzillogic]

@superdeboer: misschien is internet groot geworden door gepruts en jatwerk, maar ik ben van mening dat dat allang niet meer opgaat. Tante Bep gebruikt nu Word op een """webpagina""" te maken. En het is dan de taak van Word om er fatsoenlijke HTML van te brouwen.

Het veel gebruikte argument hier dat ook tante Bep een pagina voor de poes moet kunnen maken vind ik prima, maar tante Bep gaat tegenwoordig echt niet meer zelf in de HTML lopen rommelen. Daar geloof ik echt helemaal niets van.

Alex) schreef op vrijdag 20 april 2007 @ 01:20:
Wat is er mis met de huidige HTML-namespace uitbreiden? Waarom zou je een compleet nieuwe standaard moeten maken voor iets wat al een goede basis heeft?

Met HTML kun je prima dingen vormgeven, alleen zijn er wat hiaten ja. Maar waarom zou je die niet wegwerken met een nieuwe versie met een compleet andere syntax?

Precies. XML is al een bestaande techniek die zich ruimschoots bewezen heeft, compleet met namespaces en al. Kant-en-klaar. Kun je zo gebruiken.

Maar goed, afgezien van XML, zelfs het concept namespaces willen ze blijkbaar niet gebruiken in HTML5. En ze vergeten dus gemakshalve maar even een Application Markup Language. En dan noemen ze het het WebApplications 1.0 platform?

[crisp]

Fuzzillogic schreef op vrijdag 20 april 2007 @ 00:58:
[...]

Ik zou C ook liever vergeten ja, maar helaas. Toch hindert mij dat niet met bijv. Java.

toch jammer voor jou dan dat de wereld niet enkel en puur java is

[...]

Nee, want bijv. IE maakt er doodleuk dit van:

code:

P
    TABLE
        TBODY
            TR
                TD
                    #text

IE is dan ook een slecht voorbeeld want niet standards-compliant op dit punt (ook een reden waarom HTML5 <table> binnen <p> wel wil toestaan - teveel content die daar vanuit gaat)

[...]

Oh? In dat geval zou er geen probleem zijn geweest. Maar dat was er toch. Rara.

Hmmz, IE lijkt het wel te ondersteunen zonder puntkomma, rare jongens daar bij MS

[...]

Dat soort dingen kun je prima oplossen met een nieuwe specificatie die geen last heeft van dergelijke legacy-meuk.

En legacy-meuk dan maar laten wegrotten omdat nieuwe browsers met een nieuwe implementatie van de spec het niet meer ondersteunen? (ja, ik blijf dit punt aanhalen)

[...]

Ze hebben het tag/boom-principe van SGML genomen en van de rest gedacht: ok deze meuk is niet te handhaven en maakt het nodeloos complex. WEG ERMEE. As I said before: er is een reden dat XML populair is geworden ten koste van SGML. De eenduidige en eenvoudige structuur maakt dat software eenvoudig kan blijven, dat maakt dat er veel software voor is.

XML is ook prima als data-formaat, hoewel het in sommige gevallen wel erg verbose is.

Het zou me dan ook niet verbazen als de huidige complexiteit die een browser moet bezitten om ueberhaupt een HTML webpagina weer te geven dan ook de reden is dat er eigenlijk maar een handje vol browsers zijn. Ik kan meer operating systems van belang opnoemen dan browsers. Teken aan de wand? Ik denk het wel.

Ik kom op het volgende rijtje (en dan kijk ik alleen naar render-engines):

- Trident (IE)
- Gecko (Mozilla, Firefox)
- WebKit (Safari)
- KHTML (Konqueror)
- Merlin (Opera)

Qua operating systems die echt van belang zijn kom ik niet echt verder dan dit aantal hoor...

[...]

Thin line in dit geval. colspan=2 is een syntax error, maar met een wat meer vergevingsgezinde parser opeens enkel nog een conformance error.

uhm, HTML behoeft geen quotes om dergelijke attribute-values en verder is colspan een valid attribute - helemaal geen error dus...

[...]

Ach weet je, het zou nog niet eens zo'n probleem zijn om bijv XHTML 1.1 met wat uitbreidingen op te nemen als namespace voor text-documents. Wat mij met name stoort is het totale gebrek aan specifieke support voor webapplicaties, qua GUI, in HTML5. En dat ze uitbreidingen aan de forms ook weer allemaal in de HTML-namespace flikkeren.

Qua GUI-mogelijkheden moet je toch echt support hebben van browser-vendors. Overigens biedt XHTML2 ook niets extra's op dat gebied. Namespace-sharing-fobie is ook weer zo'n XML-trekje - wanneer is dat wel geoorloofd en wanneer niet? Mijn zoon is geadopteerd maar deelt wel mijn namespace - mag dat?

Ook Rome is niet in 1 dag gebouwd. Maar als de browser support bieden voor een next-gen iets, dan komen de content providers wel heel snel met toepassingen. Kijk maar al eens naar de enorme verscheidenheid van extensies voor Firefox/Thunderbird (XUL), en dat is dan nog maar een relatief klein platform.

Rome is ook niet in 1 dag platgebrand...

[Alex)]

Ik zie echt het nut niet van XML voor de GUI van een webapplicatie. Voor mij is XML puur een data-uitwisselingsformaat, niet een opmaakformaat. Daarvoor is HTML meer bedoeld, vind ik.

XML = data (en zou dus eigenlijk XDL of DEF ofzo moeten heten) en HTML = opmaak. En je kunt ze allebei prima uitbreiden, maar ga ze alsjeblieft niet mengen. Dat levert zo'n zooi op voor webbrowsermakers: ze moeten meer ondersteunen (XHTML <> HTML) wat vanzelf tot inconsistenties leidt.

Een parse error in een opmaaktaal is vervelend (teveel dikgedrukte tekst) maar het is niet anders. Kan gebeuren. Met een parse-error in een datataal zit het anders: daar kan dan de juistheid van de data niet worden gecontroleerd, dus dan is draconic error-handling wél belangrijk. Maar in een opmaaktaal? Alsjeblieft zeg...

[crisp]

Fuzzillogic schreef op vrijdag 20 april 2007 @ 01:34:
@superdeboer: misschien is internet groot geworden door gepruts en jatwerk, maar ik ben van mening dat dat allang niet meer opgaat.

Ik denk toch dat dat nog steeds opgaat: het leeuwendeel van de 'professionele' webdevelopers zijn nog steeds copy/paste cowboys zonder enige clue ...

Tante Bep gebruikt nu Word op een """webpagina""" te maken. En het is dan de taak van Word om er fatsoenlijke HTML van te brouwen.

O really?

Het veel gebruikte argument hier dat ook tante Bep een pagina voor de poes moet kunnen maken vind ik prima, maar tante Bep gaat tegenwoordig echt niet meer zelf in de HTML lopen rommelen. Daar geloof ik echt helemaal niets van.

Waarschijnijk doet ze dat niet nee, tenzij ze zichzelf er wat verder in verdiept en tot de ontdekking komt dat authoring-tools heden ten dage niet zaligmakend zijn...

[...]

Precies. XML is al een bestaande techniek die zich ruimschoots bewezen heeft, compleet met namespaces en al. Kant-en-klaar. Kun je zo gebruiken.

Bewezen grotendeels incompatible te zijn met het huidige internet ja; tegenwoordig zijn er zelfs RSS-feedreaders die maar error-correction toepassen...

Maar goed, afgezien van XML, zelfs het concept namespaces willen ze blijkbaar niet gebruiken in HTML5. En ze vergeten dus gemakshalve maar even een Application Markup Language. En dan noemen ze het het WebApplications 1.0 platform?

Tsja, jij hebt blijkbaar betere ideeën, dus snap ik niet waarom je hier op het forum blijft rondhangen
mailing-list

[crisp]

Superdeboer schreef op vrijdag 20 april 2007 @ 01:19:
[...]

Juist, en de doodsteek voor XHTML als application/xml+xhtml is die verrekte draconische foutafhandeling. Daar is hier in dit topic al erg veel over gezegd, maar ik wil er graag mijn visie aan toevoegen.

[...]

En ik kan niets anders zeggen dan dat dit volledig aansluit op mijn visie: het internet is openbaar en dient dus zo toegankelijk mogelijk te blijven, nu en in de toekomst...

[Anoniem: 69437]

Met het risico om allemaal dingen te zeggen die al verteld zijn, ik zou het prettig vinden als er in de toekomstige browserwereld wat meer browser-gerenderde (en dus user-themable!) GUI-elementen zouden kunnen komen voor webapps. Ik mis sliders, tabs, menu's, toolbars, frames, tabellen. Ik denk eigenlijk ook dat die widgets beter kunnen worden gecreëerd met javascript, omdat je in webapps toch meestal al met javascript bezig bent voor de afhandeling van events van diezelfde widgets. Vervolgens kan je XML, of wat voor structuur je maar wilt gebruiken voor data-uitwisseling.

Voor simpelere sites zoals we ze nu kennen met gewoon content+links kan dan HTML4.02 worden gebruikt, waarin alle verbeteringen zitten voor HTML die niets te maken hebben met dingen die nodig zijn voor "het web als applicatie-platform". Ik weet niet wat ze nog zouden willen verbeteren aan HTML als hypertext document-taal.

Als er een duidelijke scheiding komt tussen "Web1.5"-sites zoals we ze nu kennen, en een full-blown applicatie-taal gebaseerd op javascript met user-themable widgets, dan krijg je "echte" applicaties. Die applicaties integreren dan ook in ieders desktop-omgeving, of het nu Ubuntu, OSX, of Windows is.

Misschien nog een sterkere speculatie: wat als die webapps ook rootless kunnen gaan draaien! Dan krijg je heel simpel te bouwen server/client-software.

[ Voor 20% gewijzigd door Anoniem: 69437 op 20-04-2007 03:27 ]

[orf]

Wat zijn eigenlijk (realistisch) de te verwachten ontwikkelingen als je kijkt naar user agents?
Opera 9 ondersteund Event Streaming en ik verwacht eigenlijk redelijk gelijke implementaties van andere vendors.

Zijn er meer initiatieven op redelijke korte termijn te verwachten?

[crisp]

orf schreef op vrijdag 20 april 2007 @ 08:19:
Wat zijn eigenlijk (realistisch) de te verwachten ontwikkelingen als je kijkt naar user agents?
Opera 9 ondersteund Event Streaming en ik verwacht eigenlijk redelijk gelijke implementaties van andere vendors.

Zijn er meer initiatieven op redelijke korte termijn te verwachten?

Sommige initiatieven hoef je niet op te wachten hoor, Firefox ondersteund nu al bijvoorbeeld Javascript 1.7 en voor versie 3 staat Javascript 2.0 op de planning.
Opera ondersteund tegenwoordig ook WebForms 2.0 en verschillende vendors hebben al delen van WA 1.0 geimplementeerd w.o. <canvas>

[crisp]

Ik ben overigens behoorlijk sceptisch geworden omtrent de gang van zaken in de HTML WG. Er is wel behoorlijk wat support voor het adopteren van WA 1.0 als uitgangspunt, maar Chris Wilson (in naam van Microsoft) zit al behoorlijk dwars. Ik begin me ook af te vragen in hoeverre deze WG eigenlijk deels bestaat uit 'gesponserde deelnemers'.

Het gevaar bestaat dat MS straks via deze WG alsnog de 'browser-wars' voor zich probeert te winnen door het de competitie nagenoeg onmogelijk te maken de specificatie op dezelfde manier te implementeren als MS dat wil gaan doen...

[Arnold]

crisp schreef op dinsdag 24 april 2007 @ 00:44:
Ik ben overigens behoorlijk sceptisch geworden omtrent de gang van zaken in de HTML WG. Er is wel behoorlijk wat support voor het adopteren van WA 1.0 als uitgangspunt, maar Chris Wilson (in naam van Microsoft) zit al behoorlijk dwars. Ik begin me ook af te vragen in hoeverre deze WG eigenlijk deels bestaat uit 'gesponserde deelnemers'.

Het gevaar bestaat dat MS straks via deze WG alsnog de 'browser-wars' voor zich probeert te winnen door het de competitie nagenoeg onmogelijk te maken de specificatie op dezelfde manier te implementeren als MS dat wil gaan doen...

Chris Wilson zorgt er op deze manier ook voor dat HTML 5 toch wel verder naar achteren geschoven wordt.
Microsoft moet vanaf scratch beginnen eigenlijk. Gewoon IE.next de legacy breken met een compleet nieuwe complient engine, want wat ik begrijp is het toch "het breken van het verleden" waar ze bij MS te bang voor zijn toch?

[Anoniem: 2935]

Alex) schreef op vrijdag 20 april 2007 @ 01:40:
Ik zie echt het nut niet van XML voor de GUI van een webapplicatie. Voor mij is XML puur een data-uitwisselingsformaat, niet een opmaakformaat. Daarvoor is HTML meer bedoeld, vind ik.

Er zijn heel veel potentiele voordelen voor het gebruiken van een XML-gebaseerde taal voor het definieren van een GUI. Een GUI is vaak een hierarchische structuur van variaties op standaard UI-componenten. XML is met z'n tags en attributes wat mij betreft ideaal om zo'n structuur te definieren. Het is niet voor niets dat Backbase, Adobe, Mozilla en Microsoft allemaal die richting op zijn gegaan.

[Victor]

Alex) schreef op vrijdag 20 april 2007 @ 01:40:
Ik zie echt het nut niet van XML voor de GUI van een webapplicatie. Voor mij is XML puur een data-uitwisselingsformaat, niet een opmaakformaat. Daarvoor is HTML meer bedoeld, vind ik.

Je kunt met XML dan ook geen GUI voor een webapplicatie maken. Je kunt wellicht gebruik maken van een formaat dat gebouwd is op XML om GUI's mee voor te geven. XUL bijvoorbeeld.

HTML is overigens ook geen taal op GUI's mee te bouwen, HTML is een specificatie gebaseerd op SGML, wederom om data mee op te maken.

XML = data

XML is een opmaaktaal. Wat je er mee opmaakt is geheel aan jou.

En je kunt ze allebei prima uitbreiden, maar ga ze alsjeblieft niet mengen.

XHTML is XML... Dat is geen kwestie van mengen, je zit al in XML te werken.

Een parse error in een opmaaktaal is vervelend (teveel dikgedrukte tekst) maar het is niet anders. Kan gebeuren. Met een parse-error in een datataal zit het anders: daar kan dan de juistheid van de data niet worden gecontroleerd, dus dan is draconic error-handling wél belangrijk. Maar in een opmaaktaal? Alsjeblieft zeg...

HTML is een datataal. Semantiek enzo? Je omschrijft je data.

[Zr40]

crisp schreef op vrijdag 20 april 2007 @ 01:36:
En legacy-meuk dan maar laten wegrotten omdat nieuwe browsers met een nieuwe implementatie van de spec het niet meer ondersteunen? (ja, ik blijf dit punt aanhalen)

De legacy-meuk gaat niet spontaan niet meer werken als de nieuwe spec geïmplementeerd is. Zeker bij open source browsers wordt de legacy-meuk lang genoeg onderhouden. Zie bijvoorbeeld Gopher. Volgens Wikipedia zijn er nu minder dan 100 actieve Gopher servers. Toch werkt Gopher nog uitstekend in Firefox. (Bekijk gopher://gopher.floodgap.com/ maar eens.)

Zelfs al mocht een toekomstige browserversie ondersteuning voor legacy-meuk laten vallen, de oudere browsers blijven werken.

[ Voor 0% gewijzigd door Zr40 op 24-04-2007 12:45 . Reden: [url] verwijderd - React maakt er http:// van ]

[Zr40]

King_Louie schreef op dinsdag 24 april 2007 @ 11:46:
XML is een opmaaktaal. Wat je er mee opmaakt is geheel aan jou.
[...]
HTML is een datataal. Semantiek enzo? Je omschrijft je data.

Helaas, je hebt het verkeerd om.

XML beschrijft data, die je eventueel met XSLT kan opmaken.
HTML beschrijft al opgemaakte data. Wil je daar toch data uit halen, moet je (er van uit gaande dat de opmaak niet verandert) weten wat er op welke manier opgemaakt is.

[ Voor 13% gewijzigd door Zr40 op 24-04-2007 12:49 ]

[PolarBear]

GS2K1 schreef op dinsdag 24 april 2007 @ 09:33:
[...]
Microsoft moet vanaf scratch beginnen eigenlijk. Gewoon IE.next de legacy breken met een compleet nieuwe complient engine, want wat ik begrijp is het toch "het breken van het verleden" waar ze bij MS te bang voor zijn toch?

Microsoft zou gewoon Opera ofzo moeten kopen. Hebben ze een goede standard compliant, razendsnelle engine. En Trident laat je ouwe HTML meuk renderen. De engine van Opera is vrij klein, dus volgens mij zou het prima moeten kunnen.

[BasieP]

PolarBear schreef op dinsdag 24 april 2007 @ 12:45:
[...]


Microsoft zou gewoon Opera ofzo moeten kopen. Hebben ze een goede standard compliant, razendsnelle engine. En Trident laat je ouwe HTML meuk renderen. De engine van Opera is vrij klein, dus volgens mij zou het prima moeten kunnen.

probleem is dat je niet aan html kunt zien of het 'de oude html meuk' is, of 'nieuwe' html.

html is html, en een browser kan niet zien met welke engine deze gerenderd moet worden voor een goed resultaat.

[Zr40]

BasieP schreef op dinsdag 24 april 2007 @ 12:53:
[...]

probleem is dat je niet aan html kunt zien of het 'de oude html meuk' is, of 'nieuwe' html.

html is html, en een browser kan niet zien met welke engine deze gerenderd moet worden voor een goed resultaat.

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Dit geeft toch duidelijk aan dat 'HTML 4.01 Strict' gebruikt is

[BasieP]

Zr40 schreef op dinsdag 24 april 2007 @ 13:03:
[...]

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Dit geeft toch duidelijk aan dat 'HTML 4.01 Strict' gebruikt is

ja dus?
dit wil niet zeggen dat alle websites die dit niet hebben maar direct met de oude engine gerenderd moeten worden.

Sterker nog, ik ken websites met een super foutieve inhoud waar dat doctype boven staat. Deze zien er soms in IE zelfs prachtig uit.
Als je die renderd met een nieuwe engine (bijv opera engine, zoals jij voorstelde) dan zien ze er echt niet uit hoor.

andersom ook, je krijgt dan mensen die (net als nu) een website bouwen die het alleen voor IE doet, omdat ze geen doctype er boven zetten, en daardoor IE met zijn oude engine de site foutief renderd.

Als mensen willen dat een site werkt in zowel IE als complient browsers, dan krijgen ze dit nu echt wel voor elkaar. Echter is het probleem dat ze voor IE een berg hax moeten toepassen (of functionaltieit missen etc.)

Wanneer je IE 2 engines geeft, en ik wil lekker mijn site bouwen in html transitional, en IE besluit vervolgens dit met de oude engine te renderen schiet ik toch geen klap op?
Transitional is wat vrijer html, maar is nog steeds gebonden aan afspraken.

Als IE al van tevoren zegt 'ow transitional doe ik met oude engine' wat eigenlijk inhoud 'hey transitinal verkloot ik' . Wat is dan het grote nut van die hele standaard?

---

even om het probleem duidelijk te maken (en ja dit gaat dan idd niet meer over xhtml vs html)

probleem:
een groot deel van de sites die op het moment op internet staan voldoen niet aan welke standaard dan ook, maar zien er goed uit in IE.
IE weigerd standaarden te gebruiken, waardoor niemand deze sites in orde maakt. Dit geeft weer fouten in complient browsers

oplossing:
IE zijn engine laten updaten, zodat deze aan afspraken voldoet, zodat de webmasters gedwongen worden zich aan dezelfde standaarden te houden


IE voorzien van 2 engines lost niets op, omdat de oude websites dan hun code niet hoeven te wijzigen, en de complient browsers dus nog steeds foutieve code moeten zitten parsen. (wat uiteraard wel eens mis gaat)

King_Louie schreef op dinsdag 24 april 2007 @ 11:46:
...HTML is een specificatie gebaseerd op SGML....

xml ook

[ Voor 22% gewijzigd door BasieP op 24-04-2007 13:19 ]

[Anoniem: 69437]

Tja, transitional is deprecated meuk. Dat kan je dan het beste renderen met de deprecated render-engine. Strict is dan gewoon de simpelste manier om je site perfect cross-browser te laten werken. Strict is ook altijd de "huidige" html. Het is de html waarin je nieuwe documenten schrijft. Transitional is voor de transitie van deprecated naar nieuw.

En ik snap echt niet waarom transitional zoveel makkelijker zou moeten zijn dan strict. In veel gevallen komt het neer op <center> versus style="text-align:center".

---

Hoewel... transitional is nog altijd gestandaardiseerde deprecated meuk. Deze standaard-regels kunnen goed gerenderd worden door alle compliant render-engines.

Maar zodra de browser in 'quirks-mode' gaat, kan de oude render-engine gebruikt worden, aangezien die engine die sites 'goed' zal renderen.

[ Voor 23% gewijzigd door Anoniem: 69437 op 24-04-2007 13:24 ]

[Zr40]

BasieP schreef op dinsdag 24 april 2007 @ 13:11:
[...]

ja dus?
dit wil niet zeggen dat alle websites die dit niet hebben maar direct met de oude engine gerenderd moeten worden.

Sterker nog, ik ken websites met een super foutieve inhoud waar dat doctype boven staat. Deze zien er soms in IE zelfs prachtig uit.
Als je die renderd met een nieuwe engine (bijv opera engine, zoals jij voorstelde) dan zien ze er echt niet uit hoor.

Een verkeerde (of geen) doctype gebruiken is ook vragen om problemen. Nu was dat bij HTML niet zo'n ramp, omdat het allemaal backwards compatible is, maar dit is wel belangrijk nu er andere (en in de toekomst wellicht incompatible) versies zijn.

Ik kan aannemen dat alle HTML die momenteel geschreven wordt een doctype bevat. Is dat niet het geval, dan is de ontwikkelaar in kwestie dom bezig, of is zijn documentatie verouderd. Als verder alle nieuwe documenten doctypes bevatten, is het veilig om aan te nemen dat de doctype-loze documenten 'oud' zijn.

Overigens stelde PolarBear de engine van Opera voor. Ik heb hem slechts gequoted

[Michali]

Als er een doctype boven staat, dan geef je al aan dat je wat meer verstand van zaken hebt (hopelijk). Als je beweert dan je site volgens een bepaald document type is opgebouwd, dan mag IE van mij wel trachten zo veel mogelijk volgens de standaarden te renderen, aangezien je met dat document type ook aangeeft volgens een standaard te werken. Dit gebeurt nu overigens ook al bij het switchen tussen strict en quirks mode in IE.

Overigens kun je met transitional HTML er ook gewoon een doctype boven zetten. Dus ook daarmee kun je dan kiezen tussen de nieuwe en oude meuk, als je het op deze manier oplost.

[BasieP]

Michali schreef op dinsdag 24 april 2007 @ 13:24:
Als er een doctype boven staat, dan geef je al aan dat je wat meer verstand van zaken hebt (hopelijk). Als je beweert dan je site volgens een bepaald document type is opgebouwd, dan mag IE van mij wel trachten zo veel mogelijk volgens de standaarden te renderen, aangezien je met dat document type ook aangeeft volgens een standaard te werken. Dit gebeurt nu overigens ook al bij het switchen tussen strict en quirks mode in IE.

Overigens kun je met transitional HTML er ook gewoon een doctype boven zetten. Dus ook daarmee kun je dan kiezen tussen de nieuwe en oude meuk, als je het op deze manier oplost.

transitional != oud
geen doctype != oud
strict != nieuw

dat is ongeveer mijn punt..

Je kan niet aannemen dat een doctype aangeeft dat de inhoud ook aan die standaard voldoet.
je kan het wel eisen, maar dan moet je eigenlijk direct alles met de nieuwe engine parsen. Die houd zich toch netjes aan de standaard?

en wat quirks mode betreft.. waar is dat ding sowieso goed voor? het betekend zoveel als 'volgens geen enkele standaard', wat dus browsers de ruimte laat om hun eigen invulling te geven..
dit is iets wat je juist niet wilt.

kortom, sloop strict/transitional uit de doctype, en forceer gewoon dat alle sites volgens de huidige html standaard geparsed moeten worden. (dus wat nu strict is)

helaas denken ze er bij MS alleen wat anders over

[ Voor 17% gewijzigd door BasieP op 24-04-2007 13:42 ]

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 12:43:
[...]

Helaas, je hebt het verkeerd om.

XML beschrijft data, die je eventueel met XSLT kan opmaken.

Nee, met XSLT kun je het in een ander jasje gieten.

HTML beschrijft al opgemaakte data. Wil je daar toch data uit halen, moet je (er van uit gaande dat de opmaak niet verandert) weten wat er op welke manier opgemaakt is.

Je weet toch hoe het is opgemaakt? HTML heeft een specificatie welke een aantal elementen en attributen met een zekere betekenis definieert, die je kunt gebruiken om je data te omschrijven.

BasieP schreef op dinsdag 24 april 2007 @ 13:11:
xml ook

Joh? Ik vond ze al op elkaar lijken! Met die < en >...

[OkkE]

Er moet in mijn ogen iets gebeuren, waardoor het internet langzaam die tagsoep-websites kwijtraakt. Want op deze manier blijven die ranzige pagina's bestaan, en nog veel erger: komen er elke dag nieuwe gedrochten bij.

Ongeacht of er nu voor HTML5 gekozen wordt, of toch voor een XHTML, dat maakt me nog niet eens zo ontzettend veel uit. Wat ik belangrijker vind, is dat er een spec komt die door elke browser precies het zelfde gerenderd wordt.

Ik vind dat als er een DocType boven een document staat, je er van uit mag gaan dat de inhoud ook volgens die spec gemaakt is. En dus vind ik dat een website gemaakt in HTML4 Trans. met een HTML5 DocType "stuk" mag gaan in de nieuwe browsers.

Een probleem is wel hoe een browser moet omgaan met fouten in de opmaak. Ik zou het liefst willen dat een pagina niet werkt als er een fout in zit; puur om zo eindelijk eens "goede" websites te krijgen, helaas is dit totaal niet rëeel.

[BasieP]

OkkE schreef op dinsdag 24 april 2007 @ 14:03:
Ik vind dat als er een DocType boven een document staat, je er van uit mag gaan dat de inhoud ook volgens die spec gemaakt is. En dus vind ik dat een website gemaakt in HTML4 Trans. met een HTML5 DocType "stuk" mag gaan in de nieuwe browsers.

*kuch* backwards compatibility *kuch*

[Michali]

BasieP schreef op dinsdag 24 april 2007 @ 13:38:
[...]

transitional != oud
geen doctype != oud
strict != nieuw

dat is ongeveer mijn punt..

De eerst en laatste zeg ik ook niet. Het 2de is meestal wel het geval. Je geeft in ieder geval aan dat je geen weet van standaarden hebt en je ook geen idee hebt in welke standaard je document is geschreven, anders had je er wel een doctype boven gezet.

Je kan niet aannemen dat een doctype aangeeft dat de inhoud ook aan die standaard voldoet.
je kan het wel eisen, maar dan moet je eigenlijk direct alles met de nieuwe engine parsen. Die houd zich toch netjes aan de standaard?

Hier ben ik het niet met je eens. Als je in een document niet aangeeft naar welke standaard het voldoet, dan kun je er ook niet vanuit gaan dat het überhaupt aan een standaard voldoet. Het lijkt mij heel redelijk dat als iemand een doctype opgeeft, dan de browser dan bepaalt dat er in de pagina met standaarden rekening wordt gehouden. Of het nu transitional of strict is, dat maakt niet uit, het zijn beide vormen van een standaard.

en wat quirks mode betreft.. waar is dat ding sowieso goed voor? het betekend zoveel als 'volgens geen enkele standaard', wat dus browsers de ruimte laat om hun eigen invulling te geven..
dit is iets wat je juist niet wilt.

Quirks mode houdt in dat de browser rendert naar een oude implementatie van een standaard, die achteraf fout bleek te zijn (het ging volgens mij voornamelijk om het box model van CSS). Omdat toch veel pagina's hiervan afhankelijk zijn is dit er toch ingelaten. In strict mode worden nu wel de goede regels toegepast.

kortom, sloop strict/transitional uit de doctype, en forceer gewoon dat alle sites volgens de huidige html standaard geparsed moeten worden. (dus wat nu strict is)

helaas denken ze er bij MS alleen wat anders over

Strict of transitional, wat maakt het uit? Het enige verschil is dat je wat meer vrijheid qua syntaxis (en een paar extra toevoegingen) hebt, dat hoeft voor het renderen van de pagina niets uit te maken.

[Zr40]

King_Louie schreef op dinsdag 24 april 2007 @ 13:51:
[...]

Je weet toch hoe het is opgemaakt? HTML heeft een specificatie welke een aantal elementen en attributen met een zekere betekenis definieert, die je kunt gebruiken om je data te omschrijven.

Hoe weet je dat het volgende over fruit gaat?

HTML:

<ul>
  <li>Appel</li>
  <li>Peer</li>
  <li>Banaan</li>
</ul>

Het enige dat je weet is dat het een lijstje is. Natuurlijk kan je zeggen: 'het tweede lijstje in het derde paneel aan de linkerkant is een lijst van fruit', maar ben je afhankelijk van de opmaak. Als de data ergens anders geplaatst wordt (oftewel, andere opmaak) krijg je misschien opeens een lijst van groente in plaats van fruit.

XML:

<fruitLijst>
  <fruit>Appel</fruit>
  <fruit>Peer</fruit>
  <fruit>Banaan</fruit>
</fruitLijst>
<groentenLijst>
  <groente>Wortel</groente>
  <groente>Sla</groente>
  <groente>Tomaat</groente>
</groentenLijst>

Bij dit voorbeeld is duidelijk dat de lijst van fruit een lijst van fruit is. Als de volgorde omgedraaid is, is het nog steeds duidelijk dat het fruit geen groente is.

[Michali]

BasieP schreef op dinsdag 24 april 2007 @ 14:19:
*kuch* backwards compatibility *kuch*

Als een document volgens HTML 4 (of het nu transitional of strict is) is opgemaakt, en deze vervolgens (foutief) een HTML 5 doctype krijgt, dan hoeft de browser naar mijn mening ook geen rekening met standaarden te houden. Het document voldoet dan niet aan de standaard.

Echter is er in dit geval volgens mij wel een uitzondering, omdat de standaard definieert hoe er met foutieve HTML om gegaan moet worden. Dus in dat geval kun je wel gedefinieerd gedrag krijgen, ook al is het misschien niet helemaal hoe je het wilt.

Backwards compatibility heeft hier niets mee te maken imo. Een HTML 4 document behoort in de nieuwe browsers gewoon nog goed gerenderd te worden, mits er wel een juiste doctype boven blijft staan. Als je er ineens een HTML 5 doctype boven zet, dan vraag je gewoon om problemen.


En even over het opmaak verhaal. Per definitie zijn HTML en XML natuurlijk opmaaktalen. Ze hebben beide immers Markup Language in hun naam zitten, dat is niet voor niets. Om diezelfde reden is XSLT ook een opmaaktaal. HTML heeft gedefinieerde semantiek, dit heeft XML niet, omdat de elementen niet vooraf gedefinieerd zijn. Echter kan een XML document, als het voldoet aan een bepaald doctype, wel weer semantiek hebben, omdat je dan een vaste definitie van de elementen hebt/kunt hebben.

[ Voor 20% gewijzigd door Michali op 24-04-2007 14:39 ]

[Fuzzillogic]

Michali schreef op dinsdag 24 april 2007 @ 14:30:
[...]
Backwards compatibility heeft hier niets mee te maken imo. Een HTML 4 document behoort in de nieuwe browsers gewoon nog goed gerenderd te worden, mits er wel een juiste doctype boven blijft staan. Als je er ineens een HTML 5 doctype boven zet, dan vraag je gewoon om problemen.

Slecht voorbeeld, omdat alles wat geldige HTML4 is, ook geldige HTML5 zou worden.

Maar het weglaten van doctypes en versie-indicaties vind ik gewoon erg kortzichtig. Je impliceert daarmee dat HTML7 nog steeds volledig backwards compatible is met HTML4, m.a.w. dat er nooit enige legacy geschrapt kan worden. Het niet-schrappen van de legacy vind ik nu al bezwaarlijk, laat staan om daarmee te wachten tot in de eeuwigheid...

[BasieP]

mm ik had idd beetje verkeerd gelezen, ik meende dat OkkE bedoelde dat als je een geldig html4 document maakt, deze in een browser die html5 snapt niet correct weergegeven mocht worden.
wanneer er een html5 doctype boven staat moet ie idd aan die standaard voldoen. Correct.

[OkkE]

Zolang er backwards comparibillity is, zal het web helaas al die tag-troep websites niet kwijtraken. Eigenlijk zou Explorer gewoon de manier van renderen van een van de andere brosers moeten overnemen. True, een hoop websites zullen niet meer (geheel correct) werken, maar dat is nu toch al het geval voor alles behalve IE. Dat is denk ik wel de enige manier waarom we eindelijk eens verlost raken van die tag-troep wesites...

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 14:25:
[...]


Hoe weet je dat het volgende over fruit gaat?

HTML:

<ul class="fruit">
  <li>Appel</li>
  <li>Peer</li>
  <li>Banaan</li>
</ul>

[BasieP]

OkkE schreef op dinsdag 24 april 2007 @ 15:34:
Zolang er backwards comparibillity is, zal het web helaas al die tag-troep websites niet kwijtraken. Eigenlijk zou Explorer gewoon de manier van renderen van een van de andere brosers moeten overnemen. True, een hoop websites zullen niet meer (geheel correct) werken, maar dat is nu toch al het geval voor alles behalve IE. Dat is denk ik wel de enige manier waarom we eindelijk eens verlost raken van die tag-troep wesites...

backwards compatibility is het ondersteunen van een oudere standaard. Voor sites die sowieso al niet aan een standaard voldoen bestaat er niet zoiets als backwards compatibility

[OkkE]

BasieP schreef op dinsdag 24 april 2007 @ 15:53:
[...]

backwards compatibility is het ondersteunen van een oudere standaard. Voor sites die sowieso al niet aan een standaard voldoen bestaat er niet zoiets als backwards compatibility

True, maar je snapt wat ik bedoel:
Zolang websites met niet correcte HTML niet worden afgestraft, zullen er altijd genoeg mensen zijn die op die manier blijven bouwen. Dat bedoelde ik met mijn reactie, dat het niet echt backwards compatibility is, doet daar niets aan af.

[BasieP]

OkkE schreef op dinsdag 24 april 2007 @ 16:02:
[...]


True, maar je snapt wat ik bedoel:
Zolang websites met niet correcte HTML niet worden afgestraft, zullen er altijd genoeg mensen zijn die op die manier blijven bouwen. Dat bedoelde ik met mijn reactie, dat het niet echt backwards compatibility is, doet daar niets aan af.

daar ben ik het idd helemaal mee eens

[Zr40]

King_Louie schreef op dinsdag 24 april 2007 @ 15:49:
[...]

HTML:

<ul class="fruit">
  <li>Appel</li>
  <li>Peer</li>
  <li>Banaan</li>
</ul>

Ware het niet dat class doorgaans niet voor fruit gebruikt wordt, maar voor zaken als 'first', 'last', 'navlink', 'variation3' en dergelijke, om (via CSS) opmaak aan te geven.

[Anoniem: 69437]

Zr40 schreef op dinsdag 24 april 2007 @ 16:33:
[...]


Ware het niet dat class doorgaans niet voor fruit gebruikt wordt, maar voor zaken als 'first', 'last', 'navlink', 'variation3' en dergelijke, om (via CSS) opmaak aan te geven.

Tja, XML wordt doorgaans ook niet voor fruit gebruikt, maar voor andere semantische zaken.

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 16:33:
[...]


Ware het niet dat class doorgaans niet voor fruit gebruikt wordt, maar voor zaken als 'first', 'last', 'navlink', 'variation3' en dergelijke, om (via CSS) opmaak aan te geven.

Dat je in CSS class selectors hebt, doet niets af aan de functie van het class attribuut: gerelateerde elementen groeperen.

[Zr40]

Anoniem: 69437 schreef op dinsdag 24 april 2007 @ 16:57:
[...]

Tja, XML wordt doorgaans ook niet voor fruit gebruikt, maar voor andere semantische zaken.

Als zelfs een simpel voorbeeld wordt afgeschoten omdat het een voorbeeld is...

King_Louie schreef op dinsdag 24 april 2007 @ 17:44:
[...]

Dat je in CSS class selectors hebt, doet niets af aan de functie van het class attribuut: gerelateerde elementen groeperen.

De enige reden dat in HTML de class attribute bestaat, is CSS. Zie ook http://www.w3.org/TR/html401/struct/global.html#h-7.5.2:

The class attribute has several roles in HTML:
• As a style sheet selector (when an author wishes to assign style information to a set of elements).
• For general purpose processing by user agents.

Nee, dataverwerkende applicaties zijn geen user agents.

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 18:29:
De enige reden dat in HTML de class attribute bestaat, is CSS. Zie ook http://www.w3.org/TR/html401/struct/global.html#h-7.5.2:

Sorry, maar ik kan nergens uit die pagina opmaken dat class enkel bedoeld is voor CSS.

Lees voor de gein ook eens A Touch of Class

Nee, dataverwerkende applicaties zijn geen user agents.

Ja, dat zijn het wel. Vrijwel iedere client applicatie is een user agent te noemen.

[ Voor 10% gewijzigd door Victor op 24-04-2007 19:11 ]

[Zr40]

King_Louie schreef op dinsdag 24 april 2007 @ 18:40:
[...]

Sorry, maar ik kan nergens uit die pagina opmaken dat class enkel bedoeld is voor CSS.

Ik zie anders ook nergens dat class wel gebruikt kan worden voor andere zaken dan CSS.

Lees voor de gein ook eens A Touch of Class

Dat geeft toevallig precies aan wat ik bedoel.

(X)HTML is een opmaaktaal, waarbij feitelijk de opmaak de data is. Dit is duidelijk te zien aan de aanwezige opmaaktags: B, H1-H6, I, enz.. Niet-opmaakdata uit HTML documenten halen (scrapen) is ongeveer even gemakkelijk als niet-opmaakdata uit RTF of Word documenten (of welk documentformaat dan ook) halen. Natuurlijk is het mogelijk, maar je komt in de problemen als de opmaak veranderd wordt.

Bij XML definieer je je eigen documentstructuur (of gebruik je de gedefinieerde structuur van anderen). Je altijd zeker dat het een geldig document is, want ongeldige documenten valideren niet.

[...]

Ja, dat zijn het wel. Vrijwel iedere client applicatie is een user agent te noemen.

Dat betekent dat de generator van de DPCHs ook een user agent is.

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 19:41:
[...]

Ik zie anders ook nergens dat class wel gebruikt kan worden voor andere zaken dan CSS.

quote: http://www.w3.org/TR/html401/struct/global.html#h-7.5.2

For general purpose processing by user agents

Het feit dat het verder niets "doet", doet niets af aan de semantische waarde van goed gekozen class namen.

Dat geeft toevallig precies aan wat ik bedoel.

(X)HTML is een opmaaktaal, waarbij feitelijk de opmaak de data is. Dit is duidelijk te zien aan de aanwezige opmaaktags: B, H1-H6, I, enz.. Niet-opmaakdata uit HTML documenten halen (scrapen) is ongeveer even gemakkelijk als niet-opmaakdata uit RTF of Word documenten (of welk documentformaat dan ook) halen. Natuurlijk is het mogelijk, maar je komt in de problemen als de opmaak veranderd wordt.

Ik begrijp echt niet waar je naar toe wilt. De opmaak de data? Problemen als je de opmaak verandert?

Als jij andere elementen gaat gebruiken in je XML formaat heb je ook een probleem hoor, dan omschrijf je de data ook ineens anders.

Om maar even een voorbeeld uit dat artikel te gebruiken:

HTML:

<address class="email">[e-mail]</address>

XML:

<emailaddress>[e-mail]</emailaddress>

Of ik nou in mijn HTML m'n classname ineens verander in "foo", of in de XML het element van naam verander, maakt niets uit. De omschrijving van de data verandert.

Bij XML definieer je je eigen documentstructuur (of gebruik je de gedefinieerde structuur van anderen). Je altijd zeker dat het een geldig document is, want ongeldige documenten valideren niet.

Niet valide HTML documenten valideren ook niet hoor..?

Maar als jij een eigen XML formaat kan bedenken voor wat dan ook, dan kun je dat net zo goed implementeren in HTML door gebruik te maken van de juiste elementen en goed gebruik van de beschikbare attributen. Combineer dat met specifieke class namen, documenteer het geheel en je hebt een specificatie. Dit is namelijk precies hoe microformats werken.

Dat betekent dat de generator van de DPCHs ook een user agent is.

Als die generator een client voor een specifiek protocol is, dan is dat inderdaad een user agent. Al betwijfel ik het.

[BasieP]

jullie zitten nu xml met html te vergelijken waarbij zr40 aangeeft dat xml wel een echte data taal is, maareuh..
xhtml (waar dit topic over gaat) is toch net zo goed geen data taal als html?

in xhtml gebruik je net zo goed

HTML:

<div class="emailaddress">[e-mail]</div>

dus wat voegt xhtml toe aan html op dat vlak?

[Victor]

BasieP schreef op dinsdag 24 april 2007 @ 21:00:
jullie zitten nu xml met html te vergelijken waarbij zr40 aangeeft dat xml wel een echte data taal is, maareuh..
xhtml (waar dit topic over gaat) is toch net zo goed geen data taal als html?

Wat is XHTML dan wel volgens jou?

in xhtml gebruik je net zo goed

HTML:

<div class="emailaddress">[e-mail]</div>

Nee, je gebruikt niet een div, maar address. Een div biedt enkel structuur, geen semantische waarde.

Maar inderdaad, zo zou je dat in XHTML ook doen. XHTML voegt hier niets toe en XHTML hoeft hier ook niets toe te voegen.

[ Voor 6% gewijzigd door Victor op 24-04-2007 21:05 ]

[Zr40]

King_Louie schreef op dinsdag 24 april 2007 @ 20:09:
[...]
Ik begrijp echt niet waar je naar toe wilt. De opmaak de data? Problemen als je de opmaak verandert?

Elementen zijn data. In HTML hebben de elementen betrekking op opmaak - zie ook het lijstje dat je gequoted hebt. Oftewel, in HTML is de opmaak data.

Als jij andere elementen gaat gebruiken in je XML formaat heb je ook een probleem hoor, dan omschrijf je de data ook ineens anders.

Om maar even een voorbeeld uit dat artikel te gebruiken:

HTML:

<address class="email">[e-mail]</address>

XML:

<emailaddress>[e-mail]</emailaddress>

Of ik nou in mijn HTML m'n classname ineens verander in "foo", of in de XML het element van naam verander, maakt niets uit. De omschrijving van de data verandert.

[...]

Niet valide HTML documenten valideren ook niet hoor..?

HTML documenten met andere opmaak valideren, terwijl XML documenten met een andere structuur dat niet doen.

Maar als jij een eigen XML formaat kan bedenken voor wat dan ook, dan kun je dat net zo goed implementeren in HTML door gebruik te maken van de juiste elementen en goed gebruik van de beschikbare attributen. Combineer dat met specifieke class namen, documenteer het geheel en je hebt een specificatie. Dit is namelijk precies hoe microformats werken.

Dat is het hele idee van XML: specifieke, concrete formaten kunnen bedenken. Dat formaat definieer je in een XML Schema (.xsd).

Het verschil met de HTML class attribute hack is dat het een duidelijk en valideerbaar is, en het andere helemaal niet.

Als die generator een client voor een specifiek protocol is, dan is dat inderdaad een user agent. Al betwijfel ik het.

Die generator is een uitstekend voorbeeld van de gevolgen van wat we hier nu bespreken: het lezen van data uit HTML.
Klik eens rond op http://stats.distributed...._id=8&team=10313&source=y. Dat wordt allemaal verwerkt door die generator. In het verleden is de opmaak van de stats pagina's aangepast, waardoor de generator verkeerde dingen verwerkte.
Van die stats is overigens geen XML versie beschikbaar.

[Zr40]

BasieP schreef op dinsdag 24 april 2007 @ 21:00:
jullie zitten nu xml met html te vergelijken waarbij zr40 aangeeft dat xml wel een echte data taal is, maareuh..
xhtml (waar dit topic over gaat) is toch net zo goed geen data taal als html?

in xhtml gebruik je net zo goed

HTML:

<div class="emailaddress">[e-mail]</div>

dus wat voegt xhtml toe aan html op dat vlak?

Wat data betreft is er weinig verschil tussen HTML en XHTML. Zoals ik net zei, (X)HTML beschrijft opmaak, niet data.

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 21:09:
[...]

Elementen zijn data.

Nee, elementen bevatten en omschrijven data.

In HTML hebben de elementen betrekking op opmaak - zie ook het lijstje dat je gequoted hebt.

Als je met opmaak de weergave bedoelt, dan is het antwoord wederom nee. In HTML omschrijf (maak je op) dat de data een lijst vormt. Dat je browser toevallig weet dat ie dat ook als een lijst moet weergeven, heeft niets met HTML te maken.

Oftewel, in HTML is de opmaak data.

Nee dus.

HTML documenten met andere opmaak valideren, terwijl XML documenten met een andere structuur dat niet doen.

Ik kan voor jou een heel tolerant schema in elkaar draaien waarmee je geen idee hebt wat je kunt verwachten qua document opbouw, dus dat heeft er niets mee te maken.

Dat is het hele idee van XML: specifieke, concrete formaten kunnen bedenken. Dat formaat definieer je in een XML Schema (.xsd).

Ik weet waar XML voor bedoeld is en tevens wat schema's zijn en zelfs welke extensie ze gebruiken.

Het verschil met de HTML class attribute hack is dat het een duidelijk en valideerbaar is, en het andere helemaal niet.

Het enige verschil is dat HTML geen class names voorschrijft, terwijl jij in een schema dit wel vast zou kunnen leggen. Overigens betreft het hier geen "hack", maar een eigenschap van de taal.

Die generator is een uitstekend voorbeeld van de gevolgen van wat we hier nu bespreken: het lezen van data uit HTML.
Klik eens rond op http://stats.distributed...._id=8&team=10313&source=y. Dat wordt allemaal verwerkt door die generator. In het verleden is de opmaak van de stats pagina's aangepast, waardoor de generator verkeerde dingen verwerkte.
Van die stats is overigens geen XML versie beschikbaar.

Als ze de statistieken met een XML formaat hadden opgemaakt en dit zonder aan de auteur van de generator te laten weten hadden gewijzigd, was je tegen hetzelfde probleem aangelopen.

[Zr40]

King_Louie schreef op dinsdag 24 april 2007 @ 21:18:
Nee, elementen bevatten en omschrijven data.

En die data is bij HTML toevallig opmaak en tekst. Feit blijft dat HTML geen geschikt medium is voor dataoverdracht tussen software. Voor overdracht van data tussen software en mens, daarentegen...

[...]

Ik kan voor jou een heel tolerant schema in elkaar draaien waarmee je geen idee hebt wat je kunt verwachten qua document opbouw, dus dat heeft er niets mee te maken.

Eens. Dat het mogelijk is om te tolerante schema's te maken betekent niet dat het moet. Echter, bij HTML kan je helemaal geen schema's definieren, tolerant of niet.

Ik weet waar XML voor bedoeld is en tevens wat schema's zijn en zelfs welke extensie ze gebruiken.

Mooi zo.

Het enige verschil is dat HTML geen class names voorschrijft, terwijl jij in een schema dit wel vast zou kunnen leggen. Overigens betreft het hier geen "hack", maar een eigenschap van de taal.

Het is wel een hack om dat attribuut op deze manier te misbruiken.

Als ze de statistieken met een XML formaat hadden opgemaakt en dit zonder aan de auteur van de generator te laten weten hadden gewijzigd, was je tegen hetzelfde probleem aangelopen.

Nee. Als het XML formaat gewijzigd wordt, zou de generator niet stilletjes verkeerde data verwerken, wat wel gebeurt bij het wijzigen van de HTML opmaak.

[Victor]

Zr40 schreef op dinsdag 24 april 2007 @ 21:38:
[...]

Feit blijft dat HTML geen geschikt medium is voor dataoverdracht tussen software.

Dat is het eerste punt wat je maakt waar ik het volledig mee eens ben.

Eens. Dat het mogelijk is om te tolerante schema's te maken betekent niet dat het moet. Echter, bij HTML kan je helemaal geen schema's definieren, tolerant of niet.

HTML heeft al een schema (of eigenlijk de DTD).

Het is wel een hack om dat attribuut op deze manier te misbruiken.

Ik begin hier aardig moe van te woorden. Het is geen misbruik. Lees de specificatie.

Nee. Als het XML formaat gewijzigd wordt, zou de generator niet stilletjes verkeerde data verwerken, wat wel gebeurt bij het wijzigen van de HTML opmaak.

Tenzij jouw generator bewust de XML feed tegen het schema toetst, zal het net zo goed fout gaan.

Maar goed, wellicht dat de volgende informatie je er dan toch eindelijk van kan overtuigen dat HTML wel degelijk bedoeld is om data op te maken:

quote: http://www.ietf.org/rfc/rfc1866.txt

The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.

Zoals je ziet wordt hier letterlijk gezegd dat HTML bedoeld is om data (informatie) op te maken. Toegegeven, het is een hele brede opmaaktaal, die voor veel verschillende data ingezet kan worden.

En om dan maar meteen die scheve vergelijking met XML recht te zetten: XML an sich is helemaal niets. Het zegt niets, het omschrijft niets, het heeft geen waarde. Net als dat SGML dat niet heeft.

Maar, ga je nu SGML gebruiken om een opmaaktaal te definiëren (HTML bijvoorbeeld), dan krijgt het ineens wel betekenis. Dat jij XML kan gebruiken om specifiekere opmaaktalen te definiëren (en daar dus ook validatiemogelijkheden voor hebt), doet nog steeds niets af aan het doodeenvoudige feit, dat HTML, net als jouw eigen specificaties, een opmaaktaal is.

En om dan echt ieder laatste greintje misverstand weg te nemen: met opmaak bedoel ik het definiëren en omschrijven van de data, niet hoe het er uiteindelijk uit komt te zien.

[crisp]

Zr40 schreef op dinsdag 24 april 2007 @ 12:40:
[...]

De legacy-meuk gaat niet spontaan niet meer werken als de nieuwe spec geïmplementeerd is. Zeker bij open source browsers wordt de legacy-meuk lang genoeg onderhouden. Zie bijvoorbeeld Gopher. Volgens Wikipedia zijn er nu minder dan 100 actieve Gopher servers. Toch werkt Gopher nog uitstekend in Firefox. (Bekijk gopher://gopher.floodgap.com/ maar eens.)

De opzet van WA1.0/HTML5 is ook om backwards-compatible te blijven, maar daarvoor is het wel van belang dat de huidige implementaties goed beschreven worden inclusief deprecated features.

Zelfs al mocht een toekomstige browserversie ondersteuning voor legacy-meuk laten vallen, de oudere browsers blijven werken.

Dat durf ik te betwisten, want wie garandeerd mij dat ik over 100 jaar nog Firefox 2.x kan draaien op wat op dat moment doorgaat voor een computer? Derhalve is het juist belangrijk dat Firefox versie 89.3 ook nog HTML4 kan parsen en redeneren, en dus zal dat ook over 100 jaar nog in de dan geldende HTML specificatie beschreven moeten zijn.

BasieP schreef op dinsdag 24 april 2007 @ 12:53:
[...]

probleem is dat je niet aan html kunt zien of het 'de oude html meuk' is, of 'nieuwe' html.

html is html, en een browser kan niet zien met welke engine deze gerenderd moet worden voor een goed resultaat.

Op dit moment heb je eigenlijk 2 rendermodi (quirks vs standards-compliant) en 2 parsingmodi (HTML vs XHTML). Als je praat over rendering dan wordt de rendermodus voor HTML bepaald aan de hand van (indien aanwezig) de DTD (XHTML is altijd standards-compliance mode). De versie-identificatie in de DTD doet niet ter zake, een parser wordt geacht gewoon alles te kunnen behappen en wat hij niet snapt te skippen of fallback-content te laten zien.
Quirksmode rendering is eigenlijk ook niet eens een aparte rendermodus maar bepaald gewoon een paar uitzonderingen tov standards-compliantmode rendering.

MS is wel van plan om voor HTML5 een aparte rendermodus te introduceren (zeg maar "echt standards-compliant") en de huidige "standards-compliance" rendermodus te bevriezen qua bugs en features, andere browservendors achtten dit niet noodzakelijk.

De enige reden dat HTML5 nog een DTD dicteert is overigens juist om standards-compliant mode te triggeren. Verder is HTML5 backwards-compatible met voorgaande standaarden, dus is prima in staat om HTML<5 te renderen.

Zr40 schreef op dinsdag 24 april 2007 @ 18:29:
[...]
Nee, dataverwerkende applicaties zijn geen user agents.

HTML4 beschrijft niet de definitie van een "user agent". Je zou "user agent" dus ook kunnen interpreteren als een data-verwerkend geautomatiseerd proces. Ik ben van mening dat de specificatie bedoelt dat het een "general purpose" attribuut is dat o.a. gebruikt wordt als "hook" voor CSS, maar dat dat niet het enige doel is. Overigens kent HTML5 aan bepaalde classnames wel degelijk semantiek toe

King_Louie schreef op dinsdag 24 april 2007 @ 21:56:
[...]

HTML heeft al een schema (of eigenlijk de DTD).

Note dat alle vormen van schema's beperkingen hebben; je hebt een Turing-complete language nodig om volledig op conformiteit te kunnen checken.

Fuzzillogic schreef op dinsdag 24 april 2007 @ 14:45:
[...]

Slecht voorbeeld, omdat alles wat geldige HTML4 is, ook geldige HTML5 zou worden.

Maar het weglaten van doctypes en versie-indicaties vind ik gewoon erg kortzichtig. Je impliceert daarmee dat HTML7 nog steeds volledig backwards compatible is met HTML4, m.a.w. dat er nooit enige legacy geschrapt kan worden. Het niet-schrappen van de legacy vind ik nu al bezwaarlijk, laat staan om daarmee te wachten tot in de eeuwigheid...

Zolang er nog documenten zijn die gebruik maken van dergelijke legacy kan je het inderdaad niet schrappen uit de specificatie, enkel als 'deprecated' aanmerken en conformity-checkers een warning laten genereren.

[Anoniem: 69437]

crisp schreef op woensdag 25 april 2007 @ 01:05:
Dat durf ik te betwisten, want wie garandeerd mij dat ik over 100 jaar nog Firefox 2.x kan draaien op wat op dat moment doorgaat voor een computer? Derhalve is het juist belangrijk dat Firefox versie 89.3 ook nog HTML4 kan parsen en redeneren, en dus zal dat ook over 100 jaar nog in de dan geldende HTML specificatie beschreven moeten zijn.

Dat is het idee van vrije software en open standaarden. Aangezien Gecko en KHTML vrije software zijn, zal over 200 jaar die code nog steeds beschikbaar zijn. En aangezien de W3C-specs open zijn, is over 200 jaar die spec nog steeds te verkrijgen. Mocht er dan interest zijn om een stel 200-jaar oude documenten te lezen op een SPARC-256bit computer, dan kan de browser in een emulator worden gestart, of de render-engine geport worden, of een nieuwe render-engine geschreven worden.

Bovendien zal het document waarschijnlijk nog redelijk gerenderd worden door de quirks-mode van Firefox 2207, en anders is HTML in een text-editor zelfs nog redelijk te lezen.

Je zal op een gegeven moment toch wel wat deprecated meuk moeten laten vallen. Als elke 5 jaar een nieuwe HTML-versie uitkomt, heb je op een gegeven moment zoveel ballast dat het niet meer te onderhouden valt.

[ Voor 8% gewijzigd door Anoniem: 69437 op 25-04-2007 02:02 ]

[crisp]

Anoniem: 69437 schreef op woensdag 25 april 2007 @ 02:00:
[...]

Dat is het idee van vrije software en open standaarden. Aangezien Gecko en KHTML vrije software zijn, zal over 200 jaar die code nog steeds beschikbaar zijn. En aangezien de W3C-specs open zijn, is over 200 jaar die spec nog steeds te verkrijgen. Mocht er dan interest zijn om een stel 200-jaar oude documenten te lezen op een SPARC-256bit computer, dan kan de browser in een emulator worden gestart, of de render-engine geport worden, of een nieuwe render-engine geschreven worden.

Misschien is de code nog wel beschikbaar, maar is er ook iemand die die code ueberhaupt nog begrijpt en kan omzetten naar een werkend programma? iig zal dat aardig wat moeite kosten lijkt me, net zoals het nu voor een ervaren egyptoloog toch nog aardig wat moeite kost om hyroglyphen te ontcijferen (en dan zijn er zelfs nog oude geschriften die we helemaal niet meer kunnen begrijpen).

Bovendien zal het document waarschijnlijk nog redelijk gerenderd worden door de quirks-mode van Firefox 2207, en anders is HTML in een text-editor zelfs nog redelijk te lezen.

Maar snappen de mensen over tig jaar nog wel wat <strong> betekend, laat staan <h1> - kan je dat dan nog wel in context plaatsen?

Je zal op een gegeven moment toch wel wat deprecated meuk moeten laten vallen. Als elke 5 jaar een nieuwe HTML-versie uitkomt, heb je op een gegeven moment zoveel ballast dat het niet meer te onderhouden valt.

Als je elk jaar woorden die "toch amper nog gebruikt worden" uit het woordenboek schrapt en over tig jaar iemand een hedendaagse tekst laat lezen dan kan hij er waarschijnlijk niet meer echt wijs uit worden, en het woordenboek is dan ook niet echt meer een hulp... Legacy is waardevol en dus zeker geen ballast. 10 jaar geleden was een app van 2MB al huge, tegenwoordig is dat klein - die extra ballast kunnen we echt wel hebben hoor

[Anoniem: 69437]

crisp schreef op woensdag 25 april 2007 @ 02:24:
[...]
Misschien is de code nog wel beschikbaar, maar is er ook iemand die die code ueberhaupt nog begrijpt en kan omzetten naar een werkend programma? iig zal dat aardig wat moeite kosten lijkt me, net zoals het nu voor een ervaren egyptoloog toch nog aardig wat moeite kost om hyroglyphen te ontcijferen (en dan zijn er zelfs nog oude geschriften die we helemaal niet meer kunnen begrijpen).

Ik denk dat er over 200 jaar nog wel mensen zijn die alle oude Debian dvds hebben bewaard. Als iemand dan een tekst uit 2007 wil lezen, start die Debian 4 op in een emulator, en leest het document. Zeker met de virtualisatie-richting die we nu opgaan, denk ik niet dat er enig probleem zal zijn om hele oude meuk te draaien.

[...]
Maar snappen de mensen over tig jaar nog wel wat <strong> betekend, laat staan <h1> - kan je dat dan nog wel in context plaatsen?

Ik denk niet dat over 200 jaar de tags <html>, <head>, <body>, <h*>, of <p> veranderd zullen zijn. Dat is zo'n beetje de bare-bones van HTML. Buiten dat dit dus waarschijnlijk (al dan niet met styles disabled) redelijk zal worden gerenderd, is dit dus goed leesbaar voor de gemiddelde webdocument-kenner (en over 200 jaar is dat waarschijnlijk vanwege de afwezigheid van papier de inhoud van het basisschoolvak begrijpend lezen).

Daarnaast begrijp ik zonder kennis van het web ook wel wat "Crap, wat een <strong>klote</strong>taal is HTML toch." betekent. Iemand uit de toekomst zal meer moeite hebben met het plaatsen van "crap" en "klote", dan "strong".

[...]

Als je elk jaar woorden die "toch amper nog gebruikt worden" uit het woordenboek schrapt en over tig jaar iemand een hedendaagse tekst laat lezen dan kan hij er waarschijnlijk niet meer echt wijs uit worden, en het woordenboek is dan ook niet echt meer een hulp... Legacy is waardevol en dus zeker geen ballast. 10 jaar geleden was een app van 2MB al huge, tegenwoordig is dat klein - die extra ballast kunnen we echt wel hebben hoor

In de real world worden ook elk jaar woorden geschrapt! Nederlands is geen taal waar alleen maar woorden bijkomen, er verdwijnen ook woorden. Een taal ontstaat en verandert voor en door communicatie. Om oud-Nederlandse teksten te kunnen lezen, heb je nu al specifieke kennis nodig. In computerland gaat de tijd een stuk sneller. Teksten worden sneller oud, en sneller onleesbaar, maar vaak ook sneller onnodig. Gelukkig zal de software altijd nog veel langer blijven werken. Teksten zullen echt wel gelezen worden... totdat mensen ze zelf niet meer begrijpen.

En waarom zou je dingen schrappen? Omdat het niet te onderhouden is. 2MB is misschien niet zo boeiend, maar een paar-miljoen regels voor verschillende html-versies, strict/transitional en verschillende quirks-modussen kan je niet blijven controleren. Het is op een gegeven moment beter om een bepaalde render-engine te freezen, en aan een nieuwe te beginnen waarin geen deprecated spul zit.

Dit zorgt ervoor dat over 200 jaar niet elke wrist-top telkens een gigabyte in het geheugen moet laden omdat degene die wil weten wat de file-verwachting is de komende dagen, die informatie misschien wel in HTML4 aangeleverd zou krijgen.

Bibliotheken en desktop-computers, mochten ze nog bestaan, zullen natuurlijk toegang hebben tot alle render-engines ooit gemaakt. Daarbij; de meeste informatie zal niet zijn opgeslagen in HTML. HTML is alleen leuk voor weergave. Je gaat geen database van HTML-documenten maken. Een modern front-end voor een oude database is zo gemaakt.

[crisp]

Anoniem: 69437 schreef op woensdag 25 april 2007 @ 03:06:
[...]

Extrapoleer dat eens naar 2.000 of 20.000 jaar. Sure, het zal behoorlijk wat moeite kosten om dan eens het onderscheid te maken tussen waardevolle content (zoals mijn posts hier op GoT ) en nutteloze content, maar we hebben wel te maken hier met een potentiele nieuwe "dark age" als we a) onze data niet blijvend blijken te kunnen opslaan en b) we niet in staat zijn daar blijvende regels voor te kunnen opstellen opdat het altijd op dezelfde manier geinterpreteerd kan worden.

[Anoniem: 69437]

Dan moet je denk ik toch het verschil maken tussen data en informatie. Over 20.000 jaar spreken wij geen Engels meer. Maar zolang er geen goede God is die ons verbiedt onze zieken te genezen, zal de informatie niet zomaar verloren gaan.

[Fuzzillogic]

Sowieso, om nu rekening te houden met de archeologen over 2000 jaar? Kom nou. Mocht het zover zijn, dan is er een AI die onze HTMLletjes prachtig en zeer efficient kan omzetten naar de dan gangbare vorm van communicatie.

En zoals als zovaak aangehaald is, HTML is ook door een mens nog prima te volgen. Maar de semantiek is te beperkt. HTML5 en XHTML2.0 doen daar allebei iets aan, hetgeen toe te juichen is. Alleen kan het dus m.i. beter dan wat HTML5 nu doet, door tekst en 'applicatie markup' veel verder te scheiden. Dat komt de leesbaarheid later alleen maar ten goede.

[Anoniem: 175386]

Fuzzillogic schreef op woensdag 25 april 2007 @ 23:11:
En zoals als zovaak aangehaald is, HTML is ook door een mens nog prima te volgen. Maar de semantiek is te beperkt. HTML5 en XHTML2.0 doen daar allebei iets aan, hetgeen toe te juichen is. Alleen kan het dus m.i. beter dan wat HTML5 nu doet, door tekst en 'applicatie markup' veel verder te scheiden. Dat komt de leesbaarheid later alleen maar ten goede.

Het hele punt is dat het Jan en Alleman samen met Ernst, Bobby en De Rest websites maken. Deze mensen hebben het www groot gemaakt: zonder informatie over de poes van tante Bep en de Thunderbirdsverzameling van mijn kleine neeftje was er weinig te beleven. HTML is helemaal niet bedoeld als ingewikkelde taal om zo goed mogelijk data te beschrijven: het is een middel om met relatief weinig ICT-kennis informatie te kunnen publiceren.

Ook ik zie onder de motorkap liever een www waar HTML5 het voor het zeggen heeft en <font> uitgebannen is. Maar dat is niet reël: het web is niet langer het domein van technici, maar is er voor iedereen. Tante Bep wil blijven HTML'en, en mijn VMBO-neefje van 10 heeft simpelweg niet het niveau om met CSS een leuke website te maken. Browsers dwingen alleen valide HTML5 of XHTML2 te slikken sluit deze mensen uit. En minstens zo erg, zorgt ervoor dat het huidige web in elkaar valt.

[BtM909]

Zr40 schreef op dinsdag 24 april 2007 @ 19:41:
[...]

Ik zie anders ook nergens dat class wel gebruikt kan worden voor andere zaken dan CSS.

Beter kijken

http://www.rikkertkoppes.com/thoughts/class-and-style/
http://www.rikkertkoppes.com/thoughts/reinventing-the-wheel/

[Arnold]

In plaats van elkaar proberen duidelijk te maken waarom wel/niet en discussies over 20.000 jaar later of de kennis van "normale/simpele" webbouwers (tante bep en de vmbo neef) en te vertellen hoe wij graag de HTML5 XHTML2 specs zien, waar wij uiteindelijk niets over te zeggen hebben aangezien (neem ik aan) er weinig mensen van hier in de workgroup zitten...

Is het dan niet beter om elkaar tips en tricks uit te leggen voor websites in XHTML 1.1 zodat wij allen wel een web bouwen zoals het nu bedoeld is?

Uiteindelijk wil iedereen dit hier toch? en is de reden van de discussies?

[ Voor 15% gewijzigd door Arnold op 26-04-2007 10:26 ]

[Anoniem: 175386]

GS2K1 schreef op donderdag 26 april 2007 @ 10:21:
In plaats van elkaar proberen duidelijk te maken waarom wel/niet en discussies over 20.000 jaar later of de kennis van "normale/simpele" webbouwers (tante bep en de vmbo neef) en te vertellen hoe wij graag de HTML5 XHTML2 specs zien, waar wij uiteindelijk niets over te zeggen hebben aangezien (neem ik aan) er weinig mensen van hier in de workgroup zitten...

Iedereen kan deelnemen aan de discussie op de public-html mailinglist van het W3C. Hoe de werkgroep precies werkt weet ik niet.

Om het juiste gereedschap te kiezen is het belangrijk dat je weet wat er zoal gebeurd in webdesign-land. In de werkgroep wordt beslist over hoe websites in de toekomst gebouwd worden. Het volgen van deze discussie en het schaduwdiscussiëren hier op GoT laat geïntresseerden kennismaken met de dynamiek van het web.

Is het dan niet beter om elkaar tips en tricks uit te leggen voor websites in XHTML 1.1 zodat wij allen wel een web bouwen zoals het nu bedoeld is?

Uiteindelijk wil iedereen dit hier toch? en is de reden van de discussies?

Ik wil geen XHTML 1.1. Ik wil HTML 4.01 Strict, en HTML 5. Door het volgen van discussies als deze heb ik die keuze kunnen maken. Als dit soort discussies niet hadden plaatsgevonden maakte ik nu nog websites in XHTML 1.0 Strict die ik als text/html over de lijn stuurde.

[crisp]

GS2K1 schreef op donderdag 26 april 2007 @ 10:21:
In plaats van elkaar proberen duidelijk te maken waarom wel/niet en discussies over 20.000 jaar later of de kennis van "normale/simpele" webbouwers (tante bep en de vmbo neef) en te vertellen hoe wij graag de HTML5 XHTML2 specs zien, waar wij uiteindelijk niets over te zeggen hebben aangezien (neem ik aan) er weinig mensen van hier in de workgroup zitten...

Het staat iedereen natuurlijk vrij om opmerkingen of suggesties aan de WG te doen

Is het dan niet beter om elkaar tips en tricks uit te leggen voor websites in XHTML 1.1 zodat wij allen wel een web bouwen zoals het nu bedoeld is?

Uiteindelijk wil iedereen dit hier toch? en is de reden van de discussies?

Waar maak jij uit op dat iedereen aan de XHTML wil? En waarom specifiek XHTML1.1? En is het web wel werkelijk zo bedoeld dan?

Ik kan je wel tips & tricks geven maar die zijn net zo goed toepasbaar voor HTML of eender welke opmaaktaal; good practices zijn niet voorbehouden aan een bepaalde opmaaktaal maar gaan over dingen als structurering, semantiek en het scheiden van content, opmaak en behavior.

[Arnold]

Anoniem: 175386 schreef op donderdag 26 april 2007 @ 10:40:
[...]

Ik wil geen XHTML 1.1. Ik wil HTML 4.01 Strict, en HTML 5. Door het volgen van discussies als deze heb ik die keuze kunnen maken. Als dit soort discussies niet hadden plaatsgevonden maakte ik nu nog websites in XHTML 1.0 Strict die ik als text/html over de lijn stuurde.

Maar dit topic gaat dus over HTML of XHTML gebruiken. Dat je eerst moet beslissen welke variant voor jou beste is moet nu toch duidelijk zijn (zoals je ook aangeeft).
Het is meer dat, zoals je ook zegt, dat XHTML 1.0 strict "verkeerd" wordt toegepast. Dit is meer te wijten aan het niet goed kennen van de standaard door veel mensen (waaronder ik trouwens.. ik merk dat ik zelf ook teveel moet opzoeken).

Daarom als mensen XHTML strict willen gebruiken is misschien dit topic, of een afsplitsing daarvan, te weiden aan hoe echt XHTML te maken, met tips & tricks, om de XHTML standaard duidelijk te krijgen zoals deze door het W3 bedoelt is.
En natuurlijk zijn tips en tricks ook toepasbaar op HTML, maar er zijn ook specifieke XHTML dingen te bedenken.

[Fuzzillogic]

Nee, dit topic gaat niet over hoe we nu HTML of XHTML moeten gebruiken. Het gaat om waar het heen moet met HTML, en of HTML5, zoals deze nu de meeste aanhang lijkt te krijgen, de juiste weg is en zo nee, wat je dan graag zou willen zien in plaats daarvan.

Of je nu, met de hedendaagse browsers HTML4 of XHTML1 gebruikt, maakt bar weinig uit en is voornamelijk subjectief.

[ Voor 9% gewijzigd door Fuzzillogic op 26-04-2007 12:15 ]

[Anoniem: 175386]

GS2K1 schreef op donderdag 26 april 2007 @ 12:06:
Daarom als mensen XHTML strict willen gebruiken is misschien dit topic, of een afsplitsing daarvan, te weiden aan hoe echt XHTML te maken, met tips & tricks, om de XHTML standaard duidelijk te krijgen zoals deze door het W3 bedoeld is.

XHTML is een middel, geen doel. Begin er pas aan als je er een reden voor hebt. (IE kan XHTML niet aan, dus dat vormt al een goede reden gewoon HTML te gebruiken.) De enige reden die ik op dit moment kan verzinnen om XHTML te gebruiken is het embedden van SVG of iets dergelijks in een webpagina. En er zijn maar weinig websites die überhaupt iets met SVG doen.