HTML: keep the legacy of toch naar XHTML?

quote:

crisp schreef op vrijdag 13 april 2007 @ 01:22:
[...]
Like I said: dat is jouw mening, maar echt overtuigende argumentatie heb ik nog niet gezien...

Maar dat is jouw mening.

quote:

De algehele concensus onder de deelnemers van de W3C HTML WG is toch dat XHTML(2) niet de juiste weg is om te bewandelen...

XHTML2 is ook niet heilig, zo is het voor webapplicatie nauwelijks beter dan wat we nu hebben. Het is wél al XML, heeft namespaces en gooit deprecated meuk overboord en voegt enkele andere niceties toe.

quote:

Ten eerste zijn browsers als IE6/7 tegen de tijd dat HTML5 mogelijk een recommendation wordt zo stoffig dat geen hond ze meer gebruikt

Dus compatibility is dan minder een issue. Browser-devvers kunnen allang en breed zich voorbereiden op de opvolger van HTML4, zodat er al snel na het verschijnen ervan implementaties kunnen komen.

quote:

Het compleet breken van compatibility door het introduceren van een compleet nieuwe technologie waarvoor browser-vendors dus weer een extra parser moeten toevoegen is imo maar beperkt nuttig als het doel (een universele markup-taal) ook bereikt kan worden op basis van wat we nu al hebben.

Extra parsers? Browsers (op IE na) hébben al een XML-parser. Terwijl er voor HTML5 dus wel aanpassingen aan de tag-soup-parsers moet komen. Ik kan niet in de broncode kijken, maar het lijkt mij makkelijk te gokken wat meer werk vergt..

Wat m.n. aangepast moet worden is de renderengine, die vanuit de DOM iets op het scherm gooit. Dat moeten ze voor HTML5 nu ook al doen.

quote:

Fuzzillogic schreef op vrijdag 13 april 2007 @ 10:07:
[...]

Maar dat is jouw mening.

Nee, dat is mijn ervaring

quote:

[...]

XHTML2 is ook niet heilig, zo is het voor webapplicatie nauwelijks beter dan wat we nu hebben. Het is wél al XML, heeft namespaces en gooit deprecated meuk overboord en voegt enkele andere niceties toe.

Deprecated meuk kan je niet overboord gooien, je moet immers legacy content ook nog kunnen renderen; het moet dus gespecificeerd blijven en anders moet er een verplichting zijn om naast een XHTML2 parser ook nog een HTML parser te implementeren, hoezo onnodig complex?

quote:

[...]

Dus compatibility is dan minder een issue. Browser-devvers kunnen allang en breed zich voorbereiden op de opvolger van HTML4, zodat er al snel na het verschijnen ervan implementaties kunnen komen.

Als ik praat over compatibility dan bedoel ik niet dat oude browsers nieuwe documenten moeten kunnen renderen maar juist dat nieuwe browsers oude documenten moeten kunnen blijven renderen; derhalve moet bestaande behavior gespecificeerd zijn en blijven.

quote:

[...]

Extra parsers? Browsers (op IE na) hébben al een XML-parser. Terwijl er voor HTML5 dus wel aanpassingen aan de tag-soup-parsers moet komen. Ik kan niet in de broncode kijken, maar het lijkt mij makkelijk te gokken wat meer werk vergt..

Een parser omvat meer dan alleen het omzetten van syntax naar een DOM-tree. Als je qua semantics al volledig breekt met de bestaande feature-set van HTML dan heb je dus wel degelijk een extra parser nodig - in ieder geval voor het renderen van de DOM-tree.

quote:

Wat m.n. aangepast moet worden is de renderengine, die vanuit de DOM iets op het scherm gooit. Dat moeten ze voor HTML5 nu ook al doen.

Juist, maar je praat niet over een aanpassing maar over een compleet andere feature-set die onderhouden moet worden naast de bestaande HTML-featureset. Wat denk je dat het toevoegen van href voor bijna alle elementen voor implicaties heeft?

Je haalt twee dingen door elkaar: specificatie en implementatie. Als er legacy-dingen uit een specificatie worden gegooid, betekent dat niet meteen dat het ook uit de browsers gegooid moet worden. Laten we er iig voor zorgen dat een nieuwe standaard gewoon goed is, zonder de zaken waarvan we nu weten dat er betere oplossingen voor zijn (<font>, bijv.) Dat browsers zelf nog een tijd vastzitten aan legacy, dat is logisch en dat is ook helemaal het punt niet.

Natuurlijk is het voor browserbouwers makkelijker als ze de bestaande codebase alleen maar hoeven uit te breiden ipv radicaal anders te maken. Maar om de luiheid(?) van browserbouwers als argument aan te voeren om dan maar een halfbakken update door te voeren, vind ik vreemd.

Webdevvers die dit werk voor hun brood doen zullen zich snel genoeg hebben aangepast aan een nieuw systeem, of dat nu HTML5 is of iets compleet anders. Maar ik gok dat het webdevvers wel uitmaakt of ze op de langere termijn meer of minder werk hebben bij het maken van webapplicaties. Zorg dan dat de standaard op langere termijn, na de 'inwerkperiode', goed geschikt is voor waar het web heengaat.

quote:

Fuzzillogic schreef op vrijdag 13 april 2007 @ 11:41:
Je haalt twee dingen door elkaar: specificatie en implementatie. Als er legacy-dingen uit een specificatie worden gegooid, betekent dat niet meteen dat het ook uit de browsers gegooid moet worden. Laten we er iig voor zorgen dat een nieuwe standaard gewoon goed is, zonder de zaken waarvan we nu weten dat er betere oplossingen voor zijn (<font>, bijv.) Dat browsers zelf nog een tijd vastzitten aan legacy, dat is logisch en dat is ook helemaal het punt niet.

Een specificatie dient compleet te zijn. Als browser-bouwer zou je gewoon de laatste (X)HTML specificatie moeten kunnen pakken, die volledig implementeren, en vervolgens zou je alle bestaande content op het web moeten kunnen weergeven. Derhalve is het belangrijk dat deprecated zaken ook benoemd en beschreven zijn en blijven in de laatste specificatie, anders is legacy-content straks verloren.
Uiteraard moet wel duidelijk zijn uit de specificatie dat dergelijke zaken niet bedoelt zijn voor nieuwe documenten. Je zou wat dat betreft net als nu kunnen praten over 'transitional conformance' en 'strict conformance' en validators zouden standaard een strict conformance check moeten doen.

quote:

Natuurlijk is het voor browserbouwers makkelijker als ze de bestaande codebase alleen maar hoeven uit te breiden ipv radicaal anders te maken. Maar om de luiheid(?) van browserbouwers als argument aan te voeren om dan maar een halfbakken update door te voeren, vind ik vreemd.

Het is geen luiheid maar realiteitszin; ik denk dat een compleet nieuwe technologie gewoon niet haalbaar is op korte/middel-lange termijn. Je praat niet alleen over browsers maar ook over authoring-tools, CMS-en, IDE's en allerhande andere legacy tools die puur ingesteld zijn op HTML-authoring. Ik denk dat zelfs door voort te bouwen op HTML het nog wel een aantal jaren kan duren voordat we daar in de praktijk profijt van zullen hebben.

quote:

Webdevvers die dit werk voor hun brood doen zullen zich snel genoeg hebben aangepast aan een nieuw systeem, of dat nu HTML5 is of iets compleet anders. Maar ik gok dat het webdevvers wel uitmaakt of ze op de langere termijn meer of minder werk hebben bij het maken van webapplicaties. Zorg dan dat de standaard op langere termijn, na de 'inwerkperiode', goed geschikt is voor waar het web heengaat.

Kennis en vaardigheden van webdevelopers is denk ik nog wel het kleinste probleem (nou ja, dat is nu al vaak een probleem - het gebrek aan dan ). HTML is nu eenmaal 1 van de fundamenten van het huidige internet, als je dat wilt omgooien praat je ineens over een geheel ander web dat niet compatible is met het huidige web. Wat doen we dan met alle legacy? Weggooien en opnieuw bouwen? Not going to happen...

quote:

crisp schreef op vrijdag 13 april 2007 @ 11:54:
[...]
Een specificatie dient compleet te zijn. Als browser-bouwer zou je gewoon de laatste (X)HTML specificatie moeten kunnen pakken, die volledig implementeren, en vervolgens zou je alle bestaande content op het web moeten kunnen weergeven. Derhalve is het belangrijk dat deprecated zaken ook benoemd en beschreven zijn en blijven in de laatste specificatie, anders is legacy-content straks verloren.

Waarom? Waar staat dat? Van wie moet dat? Browserbouwers hebben voortdurend verschillende specificaties in hun browsers geimplementeerd. XUL in Firefox bijvoorbeeld. WML in Opera. Zolang een browser OOK de HTML4/XHTML1.0 standaard ondersteunt met Javascript 1.5 en de diverse huidige DOM-specs, is er niets aan de hand en kan het prima naast elkaar.

quote:

Wat doen we dan met alle legacy? Weggooien en opnieuw bouwen? Not going to happen...

Meer dan genoeg voorbeelden van applicaties die nu opnieuw worden geimplementeerd in bijv .NET, Java. Is dat dan zo anders? Ik denk het niet.

quote:

Fuzzillogic schreef op vrijdag 13 april 2007 @ 13:37:
[...]

Waarom? Waar staat dat? Van wie moet dat? Browserbouwers hebben voortdurend verschillende specificaties in hun browsers geimplementeerd. XUL in Firefox bijvoorbeeld. WML in Opera. Zolang een browser OOK de HTML4/XHTML1.0 standaard ondersteunt met Javascript 1.5 en de diverse huidige DOM-specs, is er niets aan de hand en kan het prima naast elkaar.

Ik heb het puur over de opmaak-taal, niet over andere zaken. In de huidige situatie heb je als browser-vendor op dat gebied al te maken met verschillende specificaties: HTML enerszijds, XHTML anderszijds en XHTML2 zou weer een compleet andere specificatie worden die nog eens apart geimplementeerd moet worden. Het streven is om gewoon 1 specificatie op te stellen mbt een opmaaktaal die alles omvat.

quote:

[...]

Meer dan genoeg voorbeelden van applicaties die nu opnieuw worden geimplementeerd in bijv .NET, Java. Is dat dan zo anders? Ik denk het niet.

Applicaties zijn heel wat anders dan documenten. Documenten kunnen belangrijke data bevatten die ook voor het nageslacht bewaard dienen te worden, derhalve is het belangrijk dat hedendaagse content straks ook nog gewoon bekeken kan worden.

Je springt erg van de hak op de tak tussen de discussie omtrent opmaaktalen in het algemeen en de discussie over webapplicaties, misschien is het beter als we ons hier gewoon focussen op de eerste discussie?

crisp wijzigde dit bericht 13-04-2007 13:51 (7%)

quote:

crisp schreef op vrijdag 13 april 2007 @ 13:48:
Applicaties zijn heel wat anders dan documenten. Documenten kunnen belangrijke data bevatten die ook voor het nageslacht bewaard dienen te worden, derhalve is het belangrijk dat hedendaagse content straks ook nog gewoon bekeken kan worden.

Ik heb de discussie een beetje zitten te volgen. En ik kan mij erg sterk vinden in de argumenten van Fuzzillogic. Overigens vind ik het verstandig om enkel te richten op de documenten. Communiceren van gegevens is waar HTML in de eerste plaats voor ontworpen was, en een functie waar (X)HTML nog steeds een belangrijke functie in vervuld... en zal blijven.

Het is belangrijk dat je documenten, aangezien ze historische waarde kunnen hebben, kunt blijven lezen in de toekomst. Maar volgens mij is dit geen argument voor HTML. Ten eerste, zo ingrijpend zijn de veranderingen niet, er is niets mis met het ondersteunen van een legacy formaat naast een up to date formaat, en wat is er mis mee om te gaan werken aan een beter opslag formaat voor online informatie?

Als je door gaat met enkel toevoegen komt er op een gegeven moment een punt waar het inconsequent gaat worden. Zo vind ik het al inconsequent om een applicatie specifieke tags te introduceren in een document exchange formaat. Juist daar bied XML een oplossing om die dingen van elkaar te scheiden. Wil je applicaties specificeren in een document formaat, dan verwijs je naar een document dat jou in staat stelt beter applicaties te beschrijven. XHTML is volgens mij een poging om een basis neer te leggen voor voornamelijk documenten waar vanuit uitgebreid kan worden, terwijl met HTML5+ je volgens mij altijd dingen te kort zal komen voor specifieke applicaties. En volgens mij is het maken van een complex formaat zeer onwenselijk voor.

Zoals door anderen aangegeven: een browser kan gewoon verschillende versies ondersteunen. Volgens mij is dit ook niet complex om te ondersteunen binnen een browser. Helemaal wanneer het gaat over het ondersteunen van meerdere xml gebaseerde formaten.

Ondersteuning van een bepaalde browser is tevens een non-argument, mede omdat die browser ook nog maar het HTML5 formaat moet gaan ondersteunen op een wenselijke manier. Verder is de ondersteuning van xhtml, ookal wordt er gemiezerd hier over het niet correct doorsturen van de xhtml als text/html, gewoon goed.

Ik denk dat HTML5 weer tegen nieuwe dode eindes zal aanlopen, en dat XHTML2 b.v. gewoon kan blijven bestaan als basis waarop voortgebouwd kan worden.

De reden om nu al XHTML1 te gebruiken is voor mij de volgende: er zijn vele tools om met XML transformaties te doen, op ongeveer ieder platform. En dit maakt het veel gemakkelijker om bij te houden. XML is volgens mij een zeer goede basis voor een exchange formaat (zowel intern als extern).

En dan ten slot XHTML te moeilijk? Na, html is altijd iets geweest dat geverifieerd moest worden in een browser. Als je gewoon zorgt dat je test met een browser die controleerd of het in lijn is met de XML standaard, dan is er geen probleem. Fouten worden vaak al per teken en lijn correct aangegeven. En tja, anders, gebruiken ze toch HTML? Iedereen is vrij te kiezen. Net zoals ze er voor kunnen kiezen om het te publiceren als MS Word formaat.

quote:

:murb: schreef op zaterdag 14 april 2007 @ 11:07:
[...]


Ik heb de discussie een beetje zitten te volgen. En ik kan mij erg sterk vinden in de argumenten van Fuzzillogic. Overigens vind ik het verstandig om enkel te richten op de documenten. Communiceren van gegevens is waar HTML in de eerste plaats voor ontworpen was, en een functie waar (X)HTML nog steeds een belangrijke functie in vervuld... en zal blijven.

Inderdaad, dus het introduceren van een compleet nieuwe opmaaktaal met geheel andere semantics draagt daar niet aan bij.

quote:

Het is belangrijk dat je documenten, aangezien ze historische waarde kunnen hebben, kunt blijven lezen in de toekomst. Maar volgens mij is dit geen argument voor HTML. Ten eerste, zo ingrijpend zijn de veranderingen niet, er is niets mis met het ondersteunen van een legacy formaat naast een up to date formaat, en wat is er mis mee om te gaan werken aan een beter opslag formaat voor online informatie?

Het is op zich geen argument voor HTML als SGML-applicatie. HTML5 is dan ook een simplificatie van het SGML-formaat (geen enkele browser behandeld HTML immers echt als SGML) en kent daarbij ook een XML-serialisatie. Aan de andere kant bouwt het verder op de semantics van HTML.

quote:

Als je door gaat met enkel toevoegen komt er op een gegeven moment een punt waar het inconsequent gaat worden.

En dus maar een nieuw formaat introduceren en documenten in het oude formaat weg laten rotten is wel een verbetering? Waarom zou HTML5 inconsequent worden en zou dat niet kunnen gebeuren met bijvoorbeeld XHTML2? Blijkbaar is er behoefte aan nieuwe elementen met specifieke semantics, aan de andere kant kunnen puur presentationele elementen deprecated worden zodat je wel een goede balans overhoudt.

quote:

Zo vind ik het al inconsequent om een applicatie specifieke tags te introduceren in een document exchange formaat.

Waar doel je hier op?

quote:

Juist daar bied XML een oplossing om die dingen van elkaar te scheiden. Wil je applicaties specificeren in een document formaat, dan verwijs je naar een document dat jou in staat stelt beter applicaties te beschrijven. XHTML is volgens mij een poging om een basis neer te leggen voor voornamelijk documenten waar vanuit uitgebreid kan worden, terwijl met HTML5+ je volgens mij altijd dingen te kort zal komen voor specifieke applicaties. En volgens mij is het maken van een complex formaat zeer onwenselijk voor.

HTML5+ als XML-applicatie is gewoon te mixen met andere XML-applicaties hoor.

quote:

Zoals door anderen aangegeven: een browser kan gewoon verschillende versies ondersteunen. Volgens mij is dit ook niet complex om te ondersteunen binnen een browser. Helemaal wanneer het gaat over het ondersteunen van meerdere xml gebaseerde formaten.

Het gevaar bestaat natuurlijk dat over 20 jaar browsers dan wellicht geen HTML-parser meer inbouwen, en over 30 jaar niemand meer weet hoe je een HTML-document van vandaag nog toonbaar kan maken. Het introduceren van extra render-modes is anti-productief en maakt het wel degelijk complexer.

quote:

Ondersteuning van een bepaalde browser is tevens een non-argument, mede omdat die browser ook nog maar het HTML5 formaat moet gaan ondersteunen op een wenselijke manier.

HTML5 zal zo worden opgezet dat het overweg kan met alle hedendaagse content; in die zin hoeft een browser dus straks enkel maar HTML5 te implementeren. Simpel toch?

quote:

Verder is de ondersteuning van xhtml, ookal wordt er gemiezerd hier over het niet correct doorsturen van de xhtml als text/html, gewoon goed.

XHTML als text/html is invalid HTML (als SGML-applicatie wat HTML atm formeel nog is). Het is puur te danken aan het feit dat browsers HTML niet puur als SGML-applicatie behandelen (en door XHTML is dat ook nagenoeg onmogelijk gemaakt) en redelijk uniform aan error-correctie doen dat XHTML als text/html 'werkt'. Ik vind het woord 'ondersteuning' in die context dus ook volledig misplaatst.

quote:

Ik denk dat HTML5 weer tegen nieuwe dode eindes zal aanlopen, en dat XHTML2 b.v. gewoon kan blijven bestaan als basis waarop voortgebouwd kan worden.

En hoe dat zo dan? Note dat formeel XHTML2 puur nog een draft is waar delen van HTML5 al implementaties hebben.

quote:

De reden om nu al XHTML1 te gebruiken is voor mij de volgende: er zijn vele tools om met XML transformaties te doen, op ongeveer ieder platform. En dit maakt het veel gemakkelijker om bij te houden. XML is volgens mij een zeer goede basis voor een exchange formaat (zowel intern als extern).

XML als basis stelt nogal wat eisen aan je gehele authoring-omgeving: alles moet XML-based zijn. Ik vind XML zeker geschikt als data-interchange formaat, maar niet als basis voor een opmaaktaal...

quote:

En dan ten slot XHTML te moeilijk? Na, html is altijd iets geweest dat geverifieerd moest worden in een browser. Als je gewoon zorgt dat je test met een browser die controleerd of het in lijn is met de XML standaard, dan is er geen probleem. Fouten worden vaak al per teken en lijn correct aangegeven. En tja, anders, gebruiken ze toch HTML? Iedereen is vrij te kiezen. Net zoals ze er voor kunnen kiezen om het te publiceren als MS Word formaat.

In een opmaaktaal zou een recoverable syntax-fout niet de toegankelijkheid van je document mogen ondermijnen. Het is de taak van een browser om de content zo goed mogelijk te laten zien, niet om een parse-error aan de bezoeker te tonen. Maar validatie is zeker niet heilig; zoals al vaker is gezegd: je kan prima op een nette manier je opmaak in HTML doen en aan de andere kant tagsoup genereren in XHTML.

Overigens is het redelijk eenvoudig om parse-errors op een ander manier te ontsluiten in een browser, bijvoorbeeld via een error-console. De meeste parsers kunnen onderwater gewoon bijhouden waar ze error-correctie hebben toegepast en waarom. De parsing-rules voor HTML5 voorzien daar ook in.

quote:

crisp schreef op zaterdag 14 april 2007 @ 11:50:
[...]
Inderdaad, dus het introduceren van een compleet nieuwe opmaaktaal met geheel andere semantics draagt daar niet aan bij.

Er zitten minpunten in de huidige spec. Lijkt me prima om dat nu, bij de Grote Beurt gelijk op te lossen. (Val in herhaling, ik weet het)

quote:

En dus maar een nieuw formaat introduceren en documenten in het oude formaat weg laten rotten is wel een verbetering? Waarom zou HTML5 inconsequent worden en zou dat niet kunnen gebeuren met bijvoorbeeld XHTML2? Blijkbaar is er behoefte aan nieuwe elementen met specifieke semantics, aan de andere kant kunnen puur presentationele elementen deprecated worden zodat je wel een goede balans overhoudt.

...

HTML5+ als XML-applicatie is gewoon te mixen met andere XML-applicaties hoor.

HTML5 wordt inconsequent omdat er nog meer dingen in de HTML-namespace gegooid worden waarvan je je moet afvragen of dat wel moet. WebForms2 bijv. De XML-serialisatie van HTML5 draagt daar niets aan bij, en gebruikt dan ook niet de mogelijkheden die er zijn.

quote:

Het gevaar bestaat natuurlijk dat over 20 jaar browsers dan wellicht geen HTML-parser meer inbouwen, en over 30 jaar niemand meer weet hoe je een HTML-document van vandaag nog toonbaar kan maken. Het introduceren van extra render-modes is anti-productief en maakt het wel degelijk complexer.

Sorry maar dit is echt argumenten zoeken. Een goed HTML-document kun je zelfs als mens al prima lezen in 'source code'. En je hoeft echt niet bang te zijn dat de specificatie verdwijnt. Die blijft gewoon beschikbaar. Daarnaast, tegenwoordig lijken we op het punt te zijn gekomen dat er bijna niets meer wordt weggegooid; over 20 jaar kun je nog steeds Firefox 2.0 downloaden voor x86 in Windows XP en dat in een emulator draaien.

quote:

HTML5 zal zo worden opgezet dat het overweg kan met alle hedendaagse content; in die zin hoeft een browser dus straks enkel maar HTML5 te implementeren. Simpel toch?

Dat getuigt niet echt van toekomstgerichtheid. Het "application"-gedeelte blijft onderbelicht. Doet me denken aan IE7, een beetje bijbeunen zodat het weer lijkt alsof het weer een beetje mee kan komen met de ontwikkelingen, maar daar blijft het dan ook bij.

quote:

XHTML als text/html is invalid HTML (als SGML-applicatie wat HTML atm formeel nog is). Het is puur te danken aan het feit dat browsers HTML niet puur als SGML-applicatie behandelen (en door XHTML is dat ook nagenoeg onmogelijk gemaakt) en redelijk uniform aan error-correctie doen dat XHTML als text/html 'werkt'. Ik vind het woord 'ondersteuning' in die context dus ook volledig misplaatst.

IIRC, XHTML SHOULD be served as application/xhtml+xml, maar het MAY ook als text/html. Dat een browser met deze parser geen 'echte' SGML meer kan parsen... soit. Je kunt met SGML HTML zo schrijven dat geen mens er nog wijs uit kan komen. Hoe nuttig is dat?

Je bent hier de losheid van SGML aan het verdedigen, terwijl je de striktheid van XML afkeurt. Doe mij dan toch maar striktheid, dan weet ik waar ik aan toe ben.

quote:

En hoe dat zo dan? Note dat formeel XHTML2 puur nog een draft is waar delen van HTML5 al implementaties hebben.

Mwuh. Veel van XHTML2 kun je met XSLT naar XHTML1.0 omzetten. Eventueel met een likje javascript erbij. Ja, HTML5 ook. Dus ach, dat er van delen van HTML5 al implementaties zijn, acht ik weinig boeiend.

quote:

XML als basis stelt nogal wat eisen aan je gehele authoring-omgeving: alles moet XML-based zijn. Ik vind XML zeker geschikt als data-interchange formaat, maar niet als basis voor een opmaaktaal...

Tools die om kunnen gaan met een next-gen taal zullen dan netjes XML moeten leveren. Dat is echt niet moeilijker dan SGML/HTML, aangezien het (de opmaak) hoe dan ook een boomstructuur is.
Voorbeeldje: voor het CMS van ons bedrijf gebruiken we gewoon de IE editing component. Nou en daar komt toch RANZIGE html uit, zo je weet. Maar het lukt ons met een stukje javascript om daar perfecte valid XHTML 1.0 strict van te maken...

Gebruikers zullen minder en minder zelf HTML gaan kloppen. Ook in je browsers zie je nu al dat er meer en meer WYSIWYG en rich-text-dingen komen, waar je dus niet meer met UBB en whatever code hoeft (en kunt) werken.

Ik vind dat je dan ook veel te veel waarde hecht hieraan.

quote:

Fuzzillogic schreef op zondag 15 april 2007 @ 00:39:
[...]

Er zitten minpunten in de huidige spec. Lijkt me prima om dat nu, bij de Grote Beurt gelijk op te lossen. (Val in herhaling, ik weet het)

Ik ontken ook niet dat er minpunten zitten aan de huidige specificaties, punt is echter dat je dat moeilijk achteraf nog kan gaan wijzigen aangezien legacy content er wel van afhankelijk is.

quote:

[...]

HTML5 wordt inconsequent omdat er nog meer dingen in de HTML-namespace gegooid worden waarvan je je moet afvragen of dat wel moet. WebForms2 bijv. De XML-serialisatie van HTML5 draagt daar niets aan bij, en gebruikt dan ook niet de mogelijkheden die er zijn.

Ik denk dat je zeker kritisch moet zijn mbt zaken die je toevoegd. Algehele concensus is toch wel dat de vocabulaire van HTML4 gewoonweg te beperkt is.

quote:

[...]

Sorry maar dit is echt argumenten zoeken. Een goed HTML-document kun je zelfs als mens al prima lezen in 'source code'. En je hoeft echt niet bang te zijn dat de specificatie verdwijnt. Die blijft gewoon beschikbaar. Daarnaast, tegenwoordig lijken we op het punt te zijn gekomen dat er bijna niets meer wordt weggegooid; over 20 jaar kun je nog steeds Firefox 2.0 downloaden voor x86 in Windows XP en dat in een emulator draaien.

Ik denk dat je over 20 jaar toch goed zal moeten gaan zoeken naar Firefox 2.0, en de vraag is dan ook nog of die applicatie nog wel draait op de computers van dan.

quote:

[...]

Dat getuigt niet echt van toekomstgerichtheid. Het "application"-gedeelte blijft onderbelicht. Doet me denken aan IE7, een beetje bijbeunen zodat het weer lijkt alsof het weer een beetje mee kan komen met de ontwikkelingen, maar daar blijft het dan ook bij.

Je zal toch eerst moeten zorgen dat je weer een beetje bij de tijd bent voordat je verder kan gaan kijken. En ja, in mijn ogen heeft het ook al lang genoeg geduurt en het zal ook nog wel even duren, maar het introduceren van een compleet nieuwe markup taal waar op dit moment weinig animo voor is vanuit de browser-vendor wereld is iets dat waarschijnlijk nog vele malen langer zal duren (plus de nadelen die het met zich meebrengt mbt legacy content).

quote:

[...]

IIRC, XHTML SHOULD be served as application/xhtml+xml, maar het MAY ook als text/html. Dat een browser met deze parser geen 'echte' SGML meer kan parsen... soit. Je kunt met SGML HTML zo schrijven dat geen mens er nog wijs uit kan komen. Hoe nuttig is dat?

Niet echt nuttig, ik ondersteun dan ook de beslissing van het WHATWG om af te stappen van SGML als basis.

quote:

Je bent hier de losheid van SGML aan het verdedigen, terwijl je de striktheid van XML afkeurt. Doe mij dan toch maar striktheid, dan weet ik waar ik aan toe ben.

Ik verdedig niet zozeer SGML maar wel het feit dat SGML/HTML lenient met syntax-errors omgaat, en WA1.0/HTML5 deze error-correctie zelfs definieerd. Ik vind dat een pré (zo niet een must) voor een opmaaktaal waarbij toegankelijkheid het meest belangrijk is.

quote:

[...]

Mwuh. Veel van XHTML2 kun je met XSLT naar XHTML1.0 omzetten. Eventueel met een likje javascript erbij. Ja, HTML5 ook. Dus ach, dat er van delen van HTML5 al implementaties zijn, acht ik weinig boeiend.

Het geeft wel aan waar de prioriteiten van browser-vendors liggen, en daar werken echt wel mensen die weten waar het om gaat.

quote:

[...]

Tools die om kunnen gaan met een next-gen taal zullen dan netjes XML moeten leveren. Dat is echt niet moeilijker dan SGML/HTML, aangezien het (de opmaak) hoe dan ook een boomstructuur is.
Voorbeeldje: voor het CMS van ons bedrijf gebruiken we gewoon de IE editing component. Nou en daar komt toch RANZIGE html uit, zo je weet. Maar het lukt ons met een stukje javascript om daar perfecte valid XHTML 1.0 strict van te maken...

Wist je dat IE onderhuids niet eens een echte DOM-tree genereerd van HTML? Verder zijn er gewoonweg nog (te) weinig echte XML-based tools voor authoring en dergelijke, en dat is toch echt wel een must. Een 'stukje javascript' klinkt bij mij weer als een 'hack'.

quote:

Gebruikers zullen minder en minder zelf HTML gaan kloppen. Ook in je browsers zie je nu al dat er meer en meer WYSIWYG en rich-text-dingen komen, waar je dus niet meer met UBB en whatever code hoeft (en kunt) werken.

Ik vind dat je dan ook veel te veel waarde hecht hieraan.

Ik hecht weinig waarde aan WYSIWYG, omdat de 'S' daarin fundamenteel verkeerd is. Documenten gaan niet om opmaak maar om semantiek, WYSIWYG is dus een stap in de verkeerde richting, het zou WYMIWYS moeten zijn (What You Mean Is What You See).

quote:

crisp schreef op zondag 15 april 2007 @ 01:22:
Ik denk dat je over 20 jaar toch goed zal moeten gaan zoeken naar Firefox 2.0, en de vraag is dan ook nog of die applicatie nog wel draait op de computers van dan.

Je bedoelt... dat PC dan niet meer backwards compatible zijn omdat er iets nieuws is? Zou goed kunnen, maar de huidige PC's kunnen nog prima overweg met software van 25 jaar oud. En er is nu al emulatiesoftware voor x86 en hardware, in C (bochs) en zelfs in Java. JA dus, over 20 jaar kun je firefox draaien. Legacy wordt geemuleerd. En dat kan ook prima met HTML4 in de browsers van de toekomst, bedenk ik me net.

Over de verkrijgbaarheid: je kunt nu nog IE3 en Opera 2.12 e.d. downloaden. Ok, geen 20 jaar oud, maar al ruim op de helft

quote:

Niet echt nuttig, ik ondersteun dan ook de beslissing van het WHATWG om af te stappen van SGML als basis.

Weer een standaard erbij. Ook al is het er dan eentje die uit de huidige praktijk komt, het is er wel weer een extra. Een overbodige, imo.

quote:

Het geeft wel aan waar de prioriteiten van browser-vendors liggen, en daar werken echt wel mensen die weten waar het om gaat.

Ik heb niet zomaar blind vertrouwen in iedereen die claimt een dokter te zijn...

quote:

Wist je dat IE onderhuids niet eens een echte DOM-tree genereerd van HTML?

Ja, daar zijn we destijds ook achtergekomen. En de klotskop die dat bedacht heeft verdient m.i. een trap in de noten.

quote:

Een 'stukje javascript' klinkt bij mij weer als een 'hack'.

Mwuh. In XHTML2 kun je zowat van elk element een link maken. Met <a /> kom je een eind in XHTML1, maar soms wordt het lastig. Bovendien, je wijzigt het document niet hiermee, je vertaalt het enkel voor de browser zodat deze er visueel weer iets van kan maken. En natuurlijk is het een crapoplossing die geen enkele zot serieus moet implementeren als zijnde de oplossing. Maar als fall-back voor de huidige generatie kan het helpen.

Er zijn ook scriptjes (nee niet de mijne, die werkt anders ) die de multi-column properties van CSS3 emuleren in de huidige browser. Ook niet ideaal, en het gaat mis bij printen e.d.

quote:

Ik hecht weinig waarde aan WYSIWYG, omdat de 'S' daarin fundamenteel verkeerd is. Documenten gaan niet om opmaak maar om semantiek, WYSIWYG is dus een stap in de verkeerde richting, het zou WYMIWYS moeten zijn (What You Mean Is What You See).

Daar heb je een heel goed punt! Helaas is het voor veel mensen lastig om structuur en uiterlijk te scheiden. Ze willen een kopje, en kopjes zijn iets groter en vaak vet gedrukt. En dat is dan precies ook wat ze doen. Ik ben er ook voor om die mogelijkheden ook gewoon uit de editors te gooien. (Hoewel we ook zien dat mensen doodleuk <h3 /> gebruiken omdat dat het gewenste uiterlijk heeft op een bepaalde plaats, hoewel het niets met een kopje te maken heeft)

Wat betreft Crisp's reply op mijn eerdere bericht, ik denk dat Fuzzilogic daar goed op heeft gereageerd.

quote:

crisp schreef op zondag 15 april 2007 @ 01:22:
Ik denk dat je zeker kritisch moet zijn mbt zaken die je toevoegd. Algehele concensus is toch wel dat de vocabulaire van HTML4 gewoonweg te beperkt is.

Dus stop je van alles dat je nog nodig hebt in een opvolger van de standaard zonder na te denken of het wel thuis hoort in een hypertext taal? XML stelt je in andere specificaties toe te voegen, de meer een reden om te werken naar een opgeschoonde standaard voor hypertext.

quote:

Het geeft wel aan waar de prioriteiten van browser-vendors liggen, en daar werken echt wel mensen die weten waar het om gaat.

Ik vind HTML5 eigenlijk meer een hack van HTML4. Praktisch geeft het weer wat mogelijkheden zonder een poging te doen om een basis neer te leggen die echt schaalbaar is. Wanneer HTML5 geïmplementeerd wordt zorgt het voor meer mogelijkheden die aangeboden kunnen worden, maar het is volgens mij geen langetermijnsvisie, en vooral gericht op enkele tekortkomingen op dit moment. De praktische benadering is natuurlijk een logische benadering wanneer je een browser maker bent, maar of het de beste is...

En of dit aan zal slaan (dus of het echt een oplossing is die op de korte termijn zal werken) valt ook nog maar te bezien: MS heeft er nog niet aan meegewerkt.

Volgens mij ligt echt de toekomst in een XML benadering, vooral vanwege de flexibiliteit die XML biedt om gewenste functionaliteit uit verschillende standaarden te combineren. Door nu al als XML (XHTML) te schrijven bereidt je jezelf er op voor. En XSL b.v. is nu al erg handig.

quote:

:murb: schreef op zondag 15 april 2007 @ 14:44:
Ik vind HTML5 eigenlijk meer een hack van HTML4. Praktisch geeft het weer wat mogelijkheden zonder een poging te doen om een basis neer te leggen die echt schaalbaar is. Wanneer HTML5 geïmplementeerd wordt zorgt het voor meer mogelijkheden die aangeboden kunnen worden, maar het is volgens mij geen langetermijnsvisie, en vooral gericht op enkele tekortkomingen op dit moment. De praktische benadering is natuurlijk een logische benadering wanneer je een browser maker bent, maar of het de beste is...

En of dit aan zal slaan (dus of het echt een oplossing is die op de korte termijn zal werken) valt ook nog maar te bezien: MS heeft er nog niet aan meegewerkt.

Chris Wilson van MS is sinds een week co-chair van de HTML WG. Ik zou er stilletjes maar rekening mee gaan houden dat de benadering van browsermakers uiteindelijk doorslaggevend is. Het werkt nu eenmaal niet zo dat een browser-vendor zijn handtekening vooraf zet onder een belofte om de nieuwe spec 100% compliant te implementeren, onafhankelijk de inhoud daarvan. Browsermakers zijn de sleutel tot de hele discussie die hier gevoerd wordt. Je kunt een hoogdravende theorie ontwikkelen en die dogmatiek fantastisch speccen, zoals al jaren gebeurt met XHTML2. En er is straks geen browser-vendor die het wil implementeren. Toch zonde, jaren aan een specificatie werken die je zo de kast in kunt schuiven omdat-ie nooit IRL gebruikt zal worden.

Het ís niet zo simpel om te stellen dat als je maar een goeie specificatie maakt, dat goed is voor eenheid en syntactische en semantische kwaliteit van het internet. Je hebt namelijk pas wat aan een specificatie als die 1) veelvuldig en juist geïmplementeerd wordt en 2) geadopteerd wordt door webdevelopers. Als het bij 1 al misgaat, kom je niet aan 2 toe. Vandaar dat er nu nog niets van XHTML2 terecht is gekomen. Kortom: je gaat Microsoft nodig hebben als je een succesvolle specificatie wilt hebben, of je het nu leuk vindt of niet. Microsoft heeft een te grote userbase en er zijn daardóór teveel sites die al jaren helemaal op het buggy gedrag van IE zijn toegesneden, om revolutionaire dingen te doen niet back compat zijn. Microsoft heeft zakelijke belangen die een heel ander gewicht in de schaal leggen dan hoogdravende idealen over hoe het internet zou (hebben) moeten zijn. Dat is niet leuk, maar het is verdedigbaar en je kunt daar helaas niet omheen.

Volgens mij zijn er geruchten dat MS een nieuwe modus voor HTML5 gaat introduceren, zodat backwards-compatibility niet meer zo'n groot issue is. Best interessant!

Chris Wilson heeft glashelder aangegeven dat het voor Microsoft onacceptabel is als ze in IE niet backwards compatible kunnen zijn. Hij vindt dan ook dat ze een goede mogelijkheid moeten hebben om te onderscheiden welke versie van HTML er gebruikt wordt. Wat Microsoft in feite wil, is de huidige situatie wéér bevriezen in IE, net zoals quirks mode <> standards mode, zodat er dus inderdaad een nieuwe rendermode voor HTML5 komt.

quote: http://lists.w3.org/Archi...ic-html/2007Apr/0612.html

In short, I can guarantee you that Internet Explorer will not willingly choose to break compatibility with significant amounts of web content (and with ~80% of the browser share, half a billion users, "significant breakage" is an extremely small percent). All we do when we do that (and IE7 experience bears me out here) is tick off web developers and users. We can't afford to break what is currently working, so we will have to provide opt-ins for web authors to say "hey, I know what I'm talking about as of now, please give me standards compliant behavior," because we know from experience that all but a very small number of authors expect that in their content.

Zo'n opt-in zou dus een doctype met versienummer zijn waar IE de te gebruiken rendermethode aan kan afleiden. Dat is in strijd met het streven van de WHATWG om vanaf nu het doctype <!DOCTYPE html> te gebruiken voor álle versies vanaf HTML5.

• Backwards-compatibility *voor IE* is dan geen issue meer inderdaad: zij bevriezen de situatie zoals zij hem hadden zodra meer dan 0,5% van alle sites die spec volgt. Iets wat er vanaf dat moment zeker niet meer gebeurt, is het fixen van renderbugs. Gezien de buitengewoon trage release cycle van Internet Explorer, heb je daarna dus al gauw een jaar of vijf waarin de bugs van IE de de facto standaard worden: die rendermode blijft dan voor altijd ingebakken in IE en de websites die vertrouwen op die bugs blijven altijd goed zichtbaar... in IE.
• Interoperability is een heel ander probleem, wat dan extra pijnlijk gevoeld wordt. Alle andere browser-vendors zijn juist zeer toegewijd in het maken van een implementatie die zo goed mogelijk de specificaties volgt. Dat blijven ze doen en met korte release cycles fixen ze constant renderbugs, zodat webauteurs niet eens de kans krijgen om 'te vertrouwen' op die fouten. Het fixen van die bugs leidt er dus voor die browsers helemaal niet toe dat er content stuk gaat die vertrouwt op de bugs. (Dát is het probleem dat Microsoft wel heeft.) Zie jij al voor je wat er gebeurt als Microsoft bij elke nieuwe versie een nieuwe rendermode introduceert? De HTML5-rendermode van IE blijft voor altijd verbonden aan alle documenten met HTML5 in het doctype... *inclusief bugs*... en daarmee is die mode dus de échte standaard in plaats van de specificatie zelf. Vervolgens komt HTML6, waarmee hetzelfde gebeurt. Ieder van die nieuwe modes is niet gedocumenteerd en andere browsers komen er niet omheen om de marktleider te volgen en te proberen de renderwijze van IE te reverse-engineeren. Dan moeten zij óók een aparte mode gaan toevoegen voor die content... want met hun normale mode willen ze natuurlijk wel dat websites die volgens de standaard gemaakt zijn, ook met hun zo zwaarbevochten goede implementatie van die standaard gerenderd worden.

quote:

Fuzzillogic schreef op zondag 15 april 2007 @ 02:15:
[...]

Je bedoelt... dat PC dan niet meer backwards compatible zijn omdat er iets nieuws is? Zou goed kunnen, maar de huidige PC's kunnen nog prima overweg met software van 25 jaar oud. En er is nu al emulatiesoftware voor x86 en hardware, in C (bochs) en zelfs in Java. JA dus, over 20 jaar kun je firefox draaien. Legacy wordt geemuleerd. En dat kan ook prima met HTML4 in de browsers van de toekomst, bedenk ik me net.

Over de verkrijgbaarheid: je kunt nu nog IE3 en Opera 2.12 e.d. downloaden. Ok, geen 20 jaar oud, maar al ruim op de helft

Dat iets technisch gezien nog mogelijk is wil niet zeggen dat daarmee de toegankelijkheid ook gewaarborgd is. Wat jij beschrijft is toch behoorlijk wat moeite die je je zal moeten getroosten, en gelden die argumenten ook nog voor een langere periode, zeg geen 20 jaar maar 100 jaar?

quote:

[...]

Weer een standaard erbij. Ook al is het er dan eentje die uit de huidige praktijk komt, het is er wel weer een extra. Een overbodige, imo.

Nee, het is geen extra standaard. HTML5 is bedoelt om HTML4.x en XHTML1.x te vervangen.

quote:

[...]

Ik heb niet zomaar blind vertrouwen in iedereen die claimt een dokter te zijn...

Als je leven op het spel staat zal je wel moeten

quote:

[...]

Ja, daar zijn we destijds ook achtergekomen. En de klotskop die dat bedacht heeft verdient m.i. een trap in de noten.

Ej, we zijn het ergens over eens

quote:

[...]

Mwuh. In XHTML2 kun je zowat van elk element een link maken. Met <a /> kom je een eind in XHTML1, maar soms wordt het lastig. Bovendien, je wijzigt het document niet hiermee, je vertaalt het enkel voor de browser zodat deze er visueel weer iets van kan maken. En natuurlijk is het een crapoplossing die geen enkele zot serieus moet implementeren als zijnde de oplossing. Maar als fall-back voor de huidige generatie kan het helpen.

De klotskop die heeft bedacht dat elk element een link zou moeten kunnen zijn zouden ze ook een trap in de noten moeten geven, niet alleen maakt dat de zaken nodeloos complex, het levert ook ambiguiteiten op (wat gebeurd er als je een href specificeerd op een element dat al een default action heeft?).

quote:

Er zijn ook scriptjes (nee niet de mijne, die werkt anders ) die de multi-column properties van CSS3 emuleren in de huidige browser. Ook niet ideaal, en het gaat mis bij printen e.d.

Ik ben het ermee eens dat javascript een uitkomst biedt om beperkingen te omzeilen. Beperkingen zal je altijd houden, bijvoorbeeld onvolledige support voor bepaalde technologieën in bepaalde UA's. Het blijft echter een 'hack' (of woraround als je wil). Het geeft echter wel aan dat de ideale situatie niet bestaat en waarschijnlijk ook nooit zal bestaan en dat een zeker realisme dus ook gepast is. Long-term vision is goed, maar je moet de praktijk daarbij niet uit het oog verliezen. Zolang je niets doet op kortere termijn zal een oplossing voor de lange termijn ook gedoemd zijn te mislukken.

quote:

[...]

Daar heb je een heel goed punt! Helaas is het voor veel mensen lastig om structuur en uiterlijk te scheiden. Ze willen een kopje, en kopjes zijn iets groter en vaak vet gedrukt. En dat is dan precies ook wat ze doen. Ik ben er ook voor om die mogelijkheden ook gewoon uit de editors te gooien. (Hoewel we ook zien dat mensen doodleuk <h3 /> gebruiken omdat dat het gewenste uiterlijk heeft op een bepaalde plaats, hoewel het niets met een kopje te maken heeft)

En we zijn het hier weer eens
Mensen zijn nu eenmaal visueel ingesteld en denken vaak niet verder na over zaken als semantiek. Als ze een kopje willen in MS Word rammen ze ook op CTRL+b en vergroten ze de font-size. Als je echter vervolgens alle opmaak weglaat uit zo'n document is niet meer te zien wat nu de bedoeling was van dat stukje tekst.

Wat dat betreft zijn de achterliggende gedachten van HTML5 en XHTML2 wel enigszins vergelijkbaar; het gaat om semantiek en scheiding van content, opmaak en behavior.

quote:

:murb: schreef op zondag 15 april 2007 @ 14:44:
Wat betreft Crisp's reply op mijn eerdere bericht, ik denk dat Fuzzilogic daar goed op heeft gereageerd.

Ik kan niet ontkennen dat Fuzzilogic geen goede discussie voert Ik ben het echter nog steeds niet met al zijn standpunten eens

quote:

[...]

Dus stop je van alles dat je nog nodig hebt in een opvolger van de standaard zonder na te denken of het wel thuis hoort in een hypertext taal? XML stelt je in andere specificaties toe te voegen, de meer een reden om te werken naar een opgeschoonde standaard voor hypertext.

Het web gaat allang niet meer puur om text. Vanuit accessibility oogpunt valt er soms zelfs wel wat te zeggen voor elementen die niet puur semantisch zijn maar die bijvoorbeeld structuur of hiearchie aanduiden (zie de discussie omtrent <blockquote> en <indent> op de mailinglist).
Je hebt een punt betreffende modulariteit, maar ik ben er niet van overtuigd dat we de oplossing per-sé in XML moeten zoeken. Waarom zou dat in HTML niet kunnen, en waarom zou je een 'HTML-applicatie' niet kunnen mixen met XML-applicaties? Punt is en blijft dat je bij het zoeken naar een lange-termijn oplossing beter eerst kan kijken naar wat je nu hebt en of daar niet iets mee te doen valt. Ik en vele anderen met mij zien daar mogelijkheden toe, dus is het vrij zinloos om weg te gooien wat je al hebt en meteen met iets nieuws te beginnen zonder dat je het ueberhaupt een kans hebt gegeven.

quote:

[...]

Ik vind HTML5 eigenlijk meer een hack van HTML4. Praktisch geeft het weer wat mogelijkheden zonder een poging te doen om een basis neer te leggen die echt schaalbaar is. Wanneer HTML5 geïmplementeerd wordt zorgt het voor meer mogelijkheden die aangeboden kunnen worden, maar het is volgens mij geen langetermijnsvisie, en vooral gericht op enkele tekortkomingen op dit moment. De praktische benadering is natuurlijk een logische benadering wanneer je een browser maker bent, maar of het de beste is...

Zie mijn reply hierboven. Lange-termijn oplossingen heb je nu niets aan, en HTML5 beschuldigen van een totaal gebrek aan visie is niet echt op z'n plaats denk ik, mede temeer doordat er niet echt een alternatief is (XHTML2 staat nog steeds in de kinderschoenen en heeft nog heel wat beren op de weg) en enkel het feit dat HTML5 als doelstelling heeft de huidige situatie omtrent content op het web te formuleren en specificeren is al een behoorlijk grote stap qua toekomst-gerichtheid - iets dat bijvoorbeeld XHTML2 niet doet.

quote:

En of dit aan zal slaan (dus of het echt een oplossing is die op de korte termijn zal werken) valt ook nog maar te bezien: MS heeft er nog niet aan meegewerkt.

Zoals Superdeboer al aangeeft is Microsoft wel degelijk een speler hierin, wat in ieder geval al aangeeft dat er interesse is (hier zal ik later nog wel op ingaan verder).

quote:

Volgens mij ligt echt de toekomst in een XML benadering, vooral vanwege de flexibiliteit die XML biedt om gewenste functionaliteit uit verschillende standaarden te combineren. Door nu al als XML (XHTML) te schrijven bereidt je jezelf er op voor. En XSL b.v. is nu al erg handig.

Het weerhoudt je er niet van om nog steeds XML-based bezig te zijn, in ieder geval in de back-end. XSL is inderdaad handig, maar heeft clientside weinig waarde (XML zelf heeft geen gedefinieerde semantics). Ik ben echter van mening dat voor een doorsnee website XML voor de back-end weinig tot geen toegevoegde waarde heeft en enkel leidt tot extra complexiteit en extra restricties oplegd. Voor een markup-taal acht ik XML weinig geschikt vanwege de stricte manier van fout-afhandeling. Voor webapplicaties kan dat wel wenselijk zijn, maar het leeuwendeel van het web is nog steeds een content-verzameling.

quote:

chris schreef op zondag 15 april 2007 @ 18:12:
Volgens mij zijn er geruchten dat MS een nieuwe modus voor HTML5 gaat introduceren, zodat backwards-compatibility niet meer zo'n groot issue is. Best interessant!

Zie ook Superdeboer's reply waaruit eigenlijk wel een beetje blijkt waarom dat geen goed idee is. Je gaat namelijk bepaalde behavior per versie vastleggen (inclusief browser-bugs) wat er uiteindelijk tot zal leiden dat als je bij HTML versie 10 bent aangekomen je 5 extra rendering-modi hebt bovenop de verschillende rendering-modi die we nu al hebben (quirks, strict, XHTML). Dat maakt de boel enkel nodeloos complex en bemoeilijkt interoperability.

De doelstelling van HTML5 is te beschrijven hoe huidige browsers omgaan met *alle* content op het web en dat zo goed mogelijk te beschrijven en vast te leggen in de specificatie. Dat IE een vreemde eend in de bijt is behoeft verder geen uitleg; MS heeft zich nog nooit echt toegelegd op enige specificatie. Er zullen dus situaties zijn waarbij bepaalde behavior van IE compleet onwenselijk is, maar dat er vast wel websites of intranet-apps zijn die daar wel op gebaseerd zijn. Bij een compromis heb je uiteindelijk altijd wel te maken met uitzonderingen waarvoor de gekozen oplossing niet helemaal goed uitpakt, dus zullen er dingen 'stuk' gaan.

Chris Wilson (in naam van MS) geeft aan dat ze niet echt bereid zijn grote offers te brengen hiervoor. Ik vind die uitspraak nogal prematuur en ook weinig doordacht, daarbij zijn er genoeg voorbeelden voorhanden waarbij MS het minder strict nam met de backwards-compatibility van IE zelf (het 'afschaffen' van identificatie in URL's, activering van active content om het EOLAS-patent te omzeilen, etcetera).

Ik begrijp de beslissing van het W3C om Chris aan te stellen als Chair; immers zonder backing van MS heeft de WG geen enkele kans van slagen, maar Chris heeft wel degelijk een dubbele agenda en is bij voorbaat al bezig om zichzelf en MS in te dekken.

Ik denk zelfs dat er nog wel meer speelt, namelijk het feit dat MS op technologisch gebied nog jaren achterloopt op de concurrentie op browser-gebied. Het strict navolgen van een nieuwe HTML-specificatie brengt immers nogal wat met zich mee, ook met betrekking tot bijvoorbeeld de DOM, en Trident is daar absoluut (nog) niet geschikt voor. Ik denk dat MS uitstel aan het kopen is zodat ze de overgang in fases kunnen doen...

Mee eens crisp. Dat hier pure politiek bedreven wordt is duidelijk. Als namens Microsoft nu direct heel meegaand onderdelen uit de WA1 working draft omarmt, hebben ze geen enkel wisselgeld meer. Eerst de rem erop gooien geeft altijd nog de mogelijkheid om de teugels te laten vieren.

Het lijkt er inderdaad op alsof Wilson er vanuit gaat dat IE in zijn huidige vorm niet binnen nu en vijf á tien jaar een implementatie van HTML5 zou kunnen maken die zich met die van Opera, Apple en Mozilla zou kunnen meten. Ik heb zelfs de indruk dat hij hiermee ruimte openhoudt om zelfs geen bugfixing meer voor de HTML4 rendering te hoeven doen.

Als ik heel eerlijk ben weet ik echter ook niet goed hoe ik het streven moet beoordelen om HTML5 een neerslag te maken van 'het web in zijn huidige staat'.

quote: http://lists.w3.org/Archi...ic-html/2007Apr/0405.html

Anne van Kesteren:
On Mon, 09 Apr 2007 17:53:32 +0200, Henrik Dvergsdal
<[e-mail]> wrote:
> Lets say someone wants to create a 100% compliant browser completely
> from scratch, guided *only* by HTML5 and other standards external to
> HTML and with no prior knowledge of the functionality of current
> browsers.
>
> Should this browser then be compatible with "todays content"?

Yes.

Wilson heeft zijn bedenkingen over de haalbaarheid daarvan geuit. Hij heeft echter ook aangegeven dat het voor hem echt niet de bedoeling is dat de nieuwe HTML WG een comité is om features te bedenken en vervolgens de implementatiebugs uit IE te documenteren. Ik kan nog niet helemaal goed bedenken hoe de bovenstaande quote van Anne van Kesteren te rijmen is met de onderstaande:

quote: http://lists.w3.org/Archi...ic-html/2007Apr/0612.html

Chris Wilson:
And no, I’m not seriously claiming that IE should or must define the HTML5 standard. But I do believe IE, far more than anything else, defines the de facto “current web content” specification standard, for better or worse.

Wilson heeft daar deels gelijk in, of je het nu leuk vindt of niet. Ik vraag me af hoe je de huidige stand van het web zó kunt definiëren in een interoperabele specificatie, zonder:

1. alle bugs van IE mee te moeten documenteren (waar die content op steunt); én zonder
2. daarnaast bij het toepassen van die spec op bestaande content die content te breken.

Volgens mij is dat een tegenstelling die niet te realiseren is.

quote:

Superdeboer schreef op maandag 16 april 2007 @ 00:34:
[...]

Wilson heeft daar deels gelijk in, of je het nu leuk vindt of niet. Ik vraag me af hoe je de huidige stand van het web zó kunt definiëren in een interoperabele specificatie, zonder:

1. alle bugs van IE mee te moeten documenteren (waar die content op steunt); én zonder
2. daarnaast bij het toepassen van die spec op bestaande content die content te breken.

Volgens mij is dat een tegenstelling die niet te realiseren is.

Daar heeft Wilson in zoverre gelijk in dat als je IE als maatstaaf neemt dat het een onmogelijke taak is. Je moet je echter wel bedenken dat wat 'werkt' in IE toch veelal al broken is en was in andere UA's. Wilson gaat elke keer weer prat op het marktaandeel van IE, maar vergeet daarbij dat dat een slinkend aandeel is en dat dat ook niet zonder reden is.

Daarbij moet je niet vergeten dat in veel gevallen de soep toch echt niet zo heet gegeten dient te worden omdat tegenwoordig veel authors wel degelijk hun code forwards-compatible maken door bepaalde fixes puur te targetten op specifieke IE-versies (zie GoT).

Ik ben zelf wel voor XHTML met vele argumenten die al genoemd zijn. Wat ik echter nog steeds het grote probleem vind en wat een enorm probleem gaat worden in de toekomst is microsoft met hun IE. We zien dus nu ook met de HTML5 ontwikkeling dat alle grote browser-makers daar graag aan meewerken (zodat er een duidelijke standaard ligt die iedereen op dezelfde manier kan parser), maar dat microsoft daar niet actief aan meewerkt. Ik zie nog aankomen dat HTML5 nooit ver zal komen doordat microsoft het maar half of misschien zelfs niet gaat ondersteunen. En aangezien ~80% IE gebruikt hebben webdevelopers niet veel keus.

Wat ik zelf heb gedaan met m'n XHTML site is controleren of de gebruiker IE gebruikt en dan stuur ik gewoon de text/html content-type mee, anders netje application/xhtml+xml. Zo kunnen Opera en Firefox daar gewoon goed mee werken, terwijl IE er maar iets van probeert te maken. En wanneer netjes gebruikt gemaakt word van content-types kunnen er gewoon verschillende parsers in de browsers blijven zitten zodat HTML ook nog een hele tijd ondersteund kan blijven worden terwijl nieuwe developers in een nieuwere taal kunnen gaan werken.

Daarnaast vind ik een stricte parser (met draconische error-handling) juist heel goed, omdat het de developer verplicht om fouten op te lossen, ipv het te laten zitten "omdat de browser het toch goed weergeeft". Je moet er toch niet aan denken dat een java-compiler maar je errors zo goed mogelijk probeert te interpreteren, dan krijg je volgens mij alleen maar veel meer test-werk. En als het eenmaal goed werkt zal een gebruiker nooit zo'n parse-fout voor z'n neus mogen krijgen.

[edit] ik zie dat ik te lang heb zitten lezen en de hele tweede pagina gemist heb (50 replies/page)

Marcj wijzigde dit bericht 16-04-2007 01:35 (3%)

quote:

Marcj schreef op maandag 16 april 2007 @ 01:30:
Ik ben zelf wel voor XHTML met vele argumenten die al genoemd zijn. Wat ik echter nog steeds het grote probleem vind en wat een enorm probleem gaat worden in de toekomst is microsoft met hun IE. We zien dus nu ook met de HTML5 ontwikkeling dat alle grote browser-makers daar graag aan meewerken (zodat er een duidelijke standaard ligt die iedereen op dezelfde manier kan parser), maar dat microsoft daar niet actief aan meewerkt. Ik zie nog aankomen dat HTML5 nooit ver zal komen doordat microsoft het maar half of misschien zelfs niet gaat ondersteunen. En aangezien ~80% IE gebruikt hebben webdevelopers niet veel keus.

Wat ik zelf heb gedaan met m'n XHTML site is controleren of de gebruiker IE gebruikt en dan stuur ik gewoon de text/html content-type mee, anders netje application/xhtml+xml. Zo kunnen Opera en Firefox daar gewoon goed mee werken, terwijl IE er maar iets van probeert te maken.

Kortom, je stuurt ~80% malformed HTML. Lijkt mij nou niet echt geweldig. En waarom wil je perse XHTML versturen naar de andere browsers? Welke voordelen gebruik je dan, aangezien je die voordelen dan dus niet hebt in 80% van de andere gevallen?

quote:

En wanneer netjes gebruikt gemaakt word van content-types kunnen er gewoon verschillende parsers in de browsers blijven zitten zodat HTML ook nog een hele tijd ondersteund kan blijven worden terwijl nieuwe developers in een nieuwere taal kunnen gaan werken.

Nieuw, maar is het beter omdat het nieuw is?

quote:

Daarnaast vind ik een stricte parser (met draconische error-handling) juist heel goed, omdat het de developer verplicht om fouten op te lossen, ipv het te laten zitten "omdat de browser het toch goed weergeeft". Je moet er toch niet aan denken dat een java-compiler maar je errors zo goed mogelijk probeert te interpreteren, dan krijg je volgens mij alleen maar veel meer test-werk. En als het eenmaal goed werkt zal een gebruiker nooit zo'n parse-fout voor z'n neus mogen krijgen.

Imo hoeft een goede devver geen draconische error handling hebben om kwaliteit te produceren. Als je perse voor die kwaliteit XHTML moet gebruiken zit er iets mis in de bovenkamer wat je niet moet oplossen met een XHTML oplossing.

Daarnaast kan ik het niet verkopen aan mezelf (en klanten) dat je met HTML exact hetzelfde bereikt maar als er eens wat invalid HTML voorkomt (CMS, error, etc) dan kan je er voor kiezen dat de browser er nog iets probeert van de bakken of je knalt je bezoeker een dikke error voor. Kies ik toch echt liever voor het eerste. En natuurlijk, valid html zou uitgang moeten zijn, maar waarom risico gaan lopen, voor wat?

Even uitgegaan van het bovenstaande dat je nul gebruikt maakt van de XHTML voordelen als intergratie met andere XML tools

We Are Borg wijzigde dit bericht 16-04-2007 04:32 (14%)

Dit leest meer als een post over of we hier gekomen zijn door evolutie of door God, maar toch...

Ik vind XHTML een redelijk goede taal... in theorie. In praktijk echter zijn er teveel prutsers die er niets van kennen en toch wel iets in XML/XHTML willen zetten omdat ze dan 'mee zijn met hun tijd'.

XML is een leuke taal om iets in op te slaan en dan later universeel weer te kunnen uitlezen, echter buiten dat is het een echte hel qua restricties en andere meuk waardoor het 1) moeilijk te begrijpen is en 2) duur om in elkaar te zetten (duur als in, processortijden, programmeertijden en dataopslag) maar het is echter een buzzwoord dat iedereen ten wille en ten onwille wil gebruiken voor alle soorten programmeerwerk van datacommunicatie tem databases.

XHTML is ook zo'n buzzwoord, en het zou veel van de problemen oplossen die we hebben met HTML het enige probleem is: zelfs IE7 ondersteunt het niet. Niet tegenstaande is Microsoft SharePoint 2007 wel volledig in XHTML gebouwd, echter van zodra je vb. de master pages gaat bouwen en specifieert dat je XHTML strict wilt gebruiken (door de juiste tags te gebruiken en de namespaces te definieren) gaat zowel SharePoint Designer als IE7 de soep in. Voor de rest, XHTML wordt in SP gewoon omgezet in HTML en zo aangeboden aan de browser. Niets speciaal, het kost gewoon meer parse tijd en ipv ASP en SQL te kunnen gebruiken moet je nu volledige datastructures in XML en XPath construeren, en ik kan je zeggen, het is enorm omslachtig.

Daarom dat ik zeg, blijf gewoon bij HTML, iedereen kent het en iedereen weet hoe het te bouwen. Het enige probleem is dat bepaalde browsers (ok, IE) een eigen interpretatie heeft van HTML, wat historisch gekomen is door eigen tags om Netscape proberen uit de markt te duwen. XHTML zou dit moeten oplossen door eruit te knallen zodra er een fout gemaakt wordt, maar ik blijf veel liever bij HTML Strict (ook iets dat IE7 icm CSS niet goed ondersteunt), ipv een nieuwe taal te leren omdat er een enkel bedrijf het niet wilt ondersteunen.

quote:

Guru Evi schreef op maandag 16 april 2007 @ 04:54:
Het enige probleem is dat bepaalde browsers (ok, IE) een eigen interpretatie heeft van HTML, wat historisch gekomen is door eigen tags om Netscape proberen uit de markt te duwen. XHTML zou dit moeten oplossen door eruit te knallen zodra er een fout gemaakt wordt, maar ik blijf veel liever bij HTML Strict (ook iets dat IE7 icm CSS niet goed ondersteunt), ipv een nieuwe taal te leren omdat er een enkel bedrijf het niet wilt ondersteunen.

XHTML knalt eruit als het malformed is, maar je XHTML pagina kan net zo zijn 'eigen ding' doen als HTML in een brakke browser als IE. Daar veranderd XHTML absoluut niks aan. Render bugs in IE zijn voor XHTML en HTML vrijwel hetzelfde

quote:

We Are Borg schreef op maandag 16 april 2007 @ 04:26:
[...]
Kortom, je stuurt ~80% malformed HTML. Lijkt mij nou niet echt geweldig. En waarom wil je perse XHTML versturen naar de andere browsers? Welke voordelen gebruik je dan, aangezien je die voordelen dan dus niet hebt in 80% van de andere gevallen?

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.

quote:

[...]
Nieuw, maar is het beter omdat het nieuw is?

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

quote:

[...]
Imo hoeft een goede devver geen draconische error handling hebben om kwaliteit te produceren. Als je perse voor die kwaliteit XHTML moet gebruiken zit er iets mis in de bovenkamer wat je niet moet oplossen met een XHTML oplossing.

Daarnaast kan ik het niet verkopen aan mezelf (en klanten) dat je met HTML exact hetzelfde bereikt maar als er eens wat invalid HTML voorkomt (CMS, error, etc) dan kan je er voor kiezen dat de browser er nog iets probeert van de bakken of je knalt je bezoeker een dikke error voor. Kies ik toch echt liever voor het eerste. En natuurlijk, valid html zou uitgang moeten zijn, maar waarom risico gaan lopen, voor wat?

Even uitgegaan van het bovenstaande dat je nul gebruikt maakt van de XHTML voordelen als intergratie met andere XML tools

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.

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)? 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.

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