HTML: keep the legacy of toch naar XHTML?

[Fuzzillogic]

Afgesplitst vanuit [xHTML] rare fout in IE 7

En even mijn standaardrepliek op Crisps standaard "XHTML sucks"-riedeltje: imo is XML gewoon de enige logische keuze voor een taal als HTML; geen vage uitzonderingen, lekker duidelijk, makkelijk te leren, snel te parsen en nog een stapeltje andere voordelen. Het voegt wel wat toe: duidelijkheid.

[ Voor 12% gewijzigd door BtM909 op 11-04-2007 08:19 ]

[crisp]

Fuzzillogic schreef op zondag 08 april 2007 @ 00:22:
En even mijn standaardrepliek op Crisps standaard "XHTML sucks"-riedeltje: imo is XML gewoon de enige logische keuze voor een taal als HTML; geen vage uitzonderingen, lekker duidelijk, makkelijk te leren, snel te parsen en nog een stapeltje andere voordelen. Het voegt wel wat toe: duidelijkheid.

En mijn standaard repliek: wat blijft er over van die voordelen als je het uiteindelijk als text/html verstuurd en wat voegt dat aan nadelen toe?

Note overigens dat ik niet zeg dat 'XHTML zuigt'. XML-serialisatie van HTML kan soms nodig zijn, maar dat is slechts zo in een zeer beperkt aantal gevallen. Feit is dat het de minst begrepen smaak HTML is, en doordat het bijna altijd foutief wordt toegepast is het in de praktijk gewoon een mislukte technologie.

XML syntax is overigens ook niet altijd zaligmakend. XML-serialisatie van de DTD zorgt ervoor dat een aantal restricties die in SGML-syntax wel kunnen worden uitgedrukt voor XHTML niet kunnen worden opgelegd via de DTD (maar die volgens de specificatie wel gelden). Conformance-checking van een HTML-document tegen de DTD is daarom wel altijd exact en van een XHTML document niet altijd

HTML kent qua syntax ook niet echt vage uitzonderingen naar mijn weten, of jouw definitie van 'vaag' is anders dan de mijne. XHTML kent wel een aantal vage uitzonderingen in de praktijk in de zin van een complete appendix met HTML compatibility guidelines

[ Voor 51% gewijzigd door crisp op 08-04-2007 00:50 ]

[imp4ct]

't Jah 'k heb ook al paar keer willen wisselen van xHTML naar HTML, maar jah... 't is een beetje een vastgeroeste gewoonte geworden. De grote verschillen tussen de twee ken ik niet zo, daar zou'k me misschien eens op moeten toeleggen. Maar 'k heb wat liggen zoeken op die "float-clearing" en ben weer tot de constatatie gekomen dat ik nog ziekelijk veel CSS eigenschappen niet ken, maar goed.. al doende leert men eh !!

[Fuzzillogic]

HTML niet vaag? <p>, <td> etc die niet afgesloten hoeft te worden (maar wel mag), <meta> die niet afgesloten mag worden.. Hoe leg je dat aan een beginnende webdevver uit? In XML is het enige "uitzondering" nog de shorthand-notation. En dat DTD te beperkt is om dingen uit te drukken die je uit wilt drukken ligt dan m.n. aan DTD. Genoeg alternatieven (die wel in XML-notatie zijn, zoals je zou verwachten) waarin het vast wel kan.

Dat er veel horken zijn die XHTML 1.1/1.0 strict als text/html versturen is jammer, maar heeft waarschijnlijk heel veel met IE te maken. En het is ook geen probleem van XHTML, maar van prutsende/onwetende/beunhazende webdevvers.

Ik ben ook niet zozeer tegen de uitbreidingen van HTML5, maar dat ze alle deprecated meuk er nog gewoon inhouden is gewoon zonde. Dat je het devvers zo makkelijk mogelijk wilt maken snap ik, en vind ik als devver ook fijn. Maar best practices mogen m.i. best wat harder doorgedrukt worden. Het nut van font-elementsen is toch nihil, en voor een beginnende devver maakt het toch niet uit of hij nou <strong> leert of <b>. (hoewel.. ik denk dat de eerste makkelijker en duidelijker is).

Prutsende devvers kunnen bij HTML4 blijven, devvers die gebruik willen maken van de nieuwe features zorgen maar gewoon voor nette code. Voor oude HTML4-code die in de artikelen van CMS'en staat vallen dan ook nog wel plenty oplossingen voor te verzinnen.

Javascript heeft hetzelfde probleem. Legacy-meuk die ondersteund blijft worden. Tot op bepaalde hoogte niet zo'n ramp, maar als het te ver van de nieuwe aanpak afstaat, zoals <font> in HTML4, dan wordt het tijd om de boel eens op te ruimen.

[Patriot]

En het is ook geen probleem van XHTML, maar van prutsende/onwetende/beunhazende webdevvers.

Ja leuk, nu heb ik het weer gedaan . Ik doe mijn best om XHTML correct te gebruiken, maar als IE dat niet slikt dan moet ik het IE maar als text/html laten interpreteren, nietwaar?

Ik vind XHTML persoonlijk net iets fijner dan HTML omdat het een wat duidelijkere structuur heeft, tags niet afsluiten vind ik gewoon vreemd staan.

[crisp]

Nou ja, we waren nu toch al offtopic

Fuzzillogic schreef op zondag 08 april 2007 @ 01:24:
HTML niet vaag? <p>, <td> etc die niet afgesloten hoeft te worden (maar wel mag), <meta> die niet afgesloten mag worden.. Hoe leg je dat aan een beginnende webdevver uit? In XML is het enige "uitzondering" nog de shorthand-notation.

Zie het als taal: een taal zonder werkwoordvervoegingen is waarschijnlijk ook makkelijker om te leren, maar om je daarmee goed uit te drukken zal je je dan soms toch in rare bochten moeten gaan wringen. Ik geef toe dat het idee van optional tags en andere SGML shorthand-features hun oorsprong kennen in het beparen van bytes, maar aan de andere kant: hoe vaak gebruik jij het TBODY element in een TABLE? En waarom zou je een element dat geen content heeft en kan hebben moeten afsluiten? <br></br> is ook maar raar vind je niet? Dus waarom is <br /> dan niet raar? Dat buiten het feit dat <meta /> en <link /> gewoon invalid is in text/html (en dus error-correctie behoeft) omdat in SGML (en dus HTML) strict genomen de / al de tag afsluit (en de > dus content is)*

Overigens heeft de solidus (/) in empty elements in WA1.0 (aka HTML5 dat ws als basis zal dienen voor de eerstvolgende nieuwe HTML versie) een uitzonderingspositie verkregen en is daarmee 'gestandaardiseerd':

quote: http://www.whatwg.org/specs/web-apps/current-work/#start

Then, if the element is one of the void elements, then there may be a single U+002F SOLIDUS (/) character. This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it.

* browsers ondersteunen deze SGML feature doorgaans niet en zullen de / zelf dus eerder beschouwen als invalid attribute.

En dat DTD te beperkt is om dingen uit te drukken die je uit wilt drukken ligt dan m.n. aan DTD. Genoeg alternatieven (die wel in XML-notatie zijn, zoals je zou verwachten) waarin het vast wel kan.

Dat ligt dus aan XML dat, omdat het een versimpeling is van SGML, niet expressief genoeg is om dergelijke zaken uit te drukken:

quote: http://www.w3.org/TR/xhtml1/#h-4.9

[...] For example, the HTML 4 Strict DTD forbids the nesting of an 'a' element within another 'a' element to any descendant depth. It is not possible to spell out such prohibitions in XML.

Dat er veel horken zijn die XHTML 1.1/1.0 strict als text/html versturen is jammer, maar heeft waarschijnlijk heel veel met IE te maken. En het is ook geen probleem van XHTML, maar van prutsende/onwetende/beunhazende webdevvers.

XHTML als XML-applicatie is ook geen lolletje; draconische error-handling hoort m.i. niet thuis in een markup-language. XHTML is dan ook puur bedoelt voor die gevallen waarbij je een markup-language wilt laten samenwerken met XML-applicaties, als dat niet het geval is dan is XHTML niet de juiste keuze.

Ik ben ook niet zozeer tegen de uitbreidingen van HTML5, maar dat ze alle deprecated meuk er nog gewoon inhouden is gewoon zonde. Dat je het devvers zo makkelijk mogelijk wilt maken snap ik, en vind ik als devver ook fijn. Maar best practices mogen m.i. best wat harder doorgedrukt worden. Het nut van font-elementsen is toch nihil, en voor een beginnende devver maakt het toch niet uit of hij nou <strong> leert of <b>. (hoewel.. ik denk dat de eerste makkelijker en duidelijker is).

1 woord: backwards-compatibility. SGML en derivaten zijn ontwikkeld juist vanuit de doelstelling dat documenten over enkele tientallen jaren of misschien zelfs wel honderden of duizenden jaren gewoon
nog leesbaar moeten zijn, derhalve moet een browser die HTML versie 89.3 implementeerd ook nog steeds HTML3.2 kunnen parsen.

Prutsende devvers kunnen bij HTML4 blijven, devvers die gebruik willen maken van de nieuwe features zorgen maar gewoon voor nette code. Voor oude HTML4-code die in de artikelen van CMS'en staat vallen dan ook nog wel plenty oplossingen voor te verzinnen.

Welke nieuwe features biedt XHTML1.x boven HTML?

Javascript heeft hetzelfde probleem. Legacy-meuk die ondersteund blijft worden. Tot op bepaalde hoogte niet zo'n ramp, maar als het te ver van de nieuwe aanpak afstaat, zoals <font> in HTML4, dan wordt het tijd om de boel eens op te ruimen.

Legacy-meuk in javascript? Praat je wel over javascript of over JScript of misschien over javascript browser extensions? Ik ben zeer geinteresseerd in voorbeelden

[Blaise]

Welke nieuwe features biedt XHTML1.x boven HTML?

Draconische error handling (dat woord "draconisch" blijft wel hangen zeg)

[ Voor 41% gewijzigd door Blaise op 08-04-2007 23:30 ]

[Fuzzillogic]

Je maakt een vergelijking tussen natuurlijke taal en computertalen. Eh? Misschien dat Esperanto of Klingon nog in de buurt komt En welke dingen wil je in HTML uitdrukken die je niet in XHTML kunt uitdrukken? (Het voorbeeld dat je aanvoert is nog steeds niet een gevolg van XML, maar van een, noem het maar hiaat, in de huidige XML schematalen. En wellicht dat het een non-issue is in bijv. RelaxNG of XML Schema; ik gebruik het niet vaak genoeg om dat zo even te bevestigen of ontkennen)
Ik krijg het idee dat SGML ontwikkeld is met het idee: "zolang het zonder dubbelzinnigheid te parsen is, hoe draconisch ook, dan is het geldige code". De simplificatie die XML bracht is niet voor niets populair geworden.

Over backwards compatibiliteit: de HTML4-specs zijn al jaren af. En de code in de browsers om dat te parsen en naar een DOM om te zetten is ook wel dik in orde. Hoef je niets meer aan te doen. Moderne browsers hebben ook XML-parsers voor XHTML strict. Werkt ook, en waarom ook niet, XML-parsers zijn VEEL eenvoudiger. Dus als je nieuwe features dan voortbouwen op het oude fundament?
En oude browsers die niet meer actief ontwikkeld worden lopen tegenwoordig al zwaar tegen problemen aan, ook al zouden ze HTML4 kunnen verwerken. Laat staan dat ze WA1.0-sites nog enigszins normaal kunnen weergeven.
Ik zie echt geen reden om die compatibiliteit aan te houden.

En de "draconische errorhandling" vind ik gewoon ronduit FIJN. En ik kan nog wel iemand aanwijzen die dat ook waardeerd, ik ben dus niet alleen. Dat voorkomt rare problemen, onduidelijkheden en verschillen in interpretaties tussen de browsers. Dat geldt niet alleen voor XHTML, maar voor computertalen in het algemeen.

XHTML 1.0 is gewoon een XML versie van HTML4, dus logischerwijs voegt het niks toe. XHTML 1.1 voegt wel wat toe. Niet veel, maar dat is ook te verwachten gezien de minor version upgrade IMO het belangrijkste dat het toevoegt is duidelijkheid en eenvoud. XHTML 1.1 gooit immers het "trantitional" eruit. Opruiming dus. Da's goed.

Mijn punt met Javascript slaat op Javascript 2.0, waar ze ongetwijfeld het javascript 1.x """object model""" zullen handhaven. Ik hoop niet dat ik dat nog verder hoef uit te leggen.

Oh, imp4ct: "registratiecode" heb je aangepast zie ik, maar doe dan hetzelfde even voor "e-mailadres" en "wachtwoordcontrole" "gebruiker ID" is dan een lastige. Je zou een hyphen kunnen gebruiken.

[ Voor 4% gewijzigd door Fuzzillogic op 09-04-2007 00:10 ]

[crisp]

Fuzzillogic schreef op maandag 09 april 2007 @ 00:01:
Je maakt een vergelijking tussen natuurlijke taal en computertalen. Eh? Misschien dat Esperanto of Klingon nog in de buurt komt

Misschien, maar als je dat spreekt dan zal nog bijna niemand je begrijpen

En welke dingen wil je in HTML uitdrukken die je niet in XHTML kunt uitdrukken? (Het voorbeeld dat je aanvoert is nog steeds niet een gevolg van XML, maar van een, noem het maar hiaat, in de huidige XML schematalen. En wellicht dat het een non-issue is in bijv. RelaxNG of XML Schema; ik gebruik het niet vaak genoeg om dat zo even te bevestigen of ontkennen)

Mijn kennis gaat ook niet zo ver op dat gebied, maar het is wel een feit dat op dit moment een conformance-check van een XHTML1.x document niet 100% de specificatie 'covered'.

Ik krijg het idee dat SGML ontwikkeld is met het idee: "zolang het zonder dubbelzinnigheid te parsen is, hoe draconisch ook, dan is het geldige code". De simplificatie die XML bracht is niet voor niets populair geworden.

Ik vind dat idee achter 'zolang het niet dubbelzinnig is kunnen we het parsen' helemaal niet zo gek, zeker niet gezien de aard van de taal.

Over backwards compatibiliteit: de HTML4-specs zijn al jaren af. En de code in de browsers om dat te parsen en naar een DOM om te zetten is ook wel dik in orde. Hoef je niets meer aan te doen. Moderne browsers hebben ook XML-parsers voor XHTML strict. Werkt ook, en waarom ook niet, XML-parsers zijn VEEL eenvoudiger. Dus als je nieuwe features dan voortbouwen op het oude fundament?
En oude browsers die niet meer actief ontwikkeld worden lopen tegenwoordig al zwaar tegen problemen aan, ook al zouden ze HTML4 kunnen verwerken. Laat staan dat ze WA1.0-sites nog enigszins normaal kunnen weergeven.
Ik zie echt geen reden om die compatibiliteit aan te houden.

Ik heb het niet over oude browsers die nieuwe documenten zouden moeten kunnen parsen, maar over nieuwe browsers die altijd de oude documenten moeten kunnen blijven parsen. Om die reden kan je zaken als <font> en <b> simpelweg niet uitfaseren, hooguit als 'deprecated' markeren voor nieuwe documenten.

En de "draconische errorhandling" vind ik gewoon ronduit FIJN. En ik kan nog wel iemand aanwijzen die dat ook waardeerd, ik ben dus niet alleen. Dat voorkomt rare problemen, onduidelijkheden en verschillen in interpretaties tussen de browsers. Dat geldt niet alleen voor XHTML, maar voor computertalen in het algemeen.

Een markup-language zou m.i. nooit een document inaccessible mogen maken enkel door een syntax-fout. WA1.0 probeert zelfs regels op te stellen voor het parsen van non-conforming documents (iets wat browsers nu elk op hun eigen manier doen) en ik vind dat een noemenswaardige verbetering. Draconische errorhandling is prima in een ontwikkelomgeving maar niet in het openbaar.

XHTML 1.0 is gewoon een XML versie van HTML4, dus logischerwijs voegt het niks toe. XHTML 1.1 voegt wel wat toe. Niet veel, maar dat is ook te verwachten gezien de minor version upgrade IMO het belangrijkste dat het toevoegt is duidelijkheid en eenvoud. XHTML 1.1 gooit immers het "trantitional" eruit. Opruiming dus. Da's goed.

Maar browsers zullen 'transitional' nog steeds moeten ondersteunen. Daarbij was Strict sowieso al de norm voor nieuwe documenten, ook in HTML.

Mijn punt met Javascript slaat op Javascript 2.0, waar ze ongetwijfeld het javascript 1.x """object model""" zullen handhaven. Ik hoop niet dat ik dat nog verder hoef uit te leggen.

Er is niets mis met het prototyped-based object model in javascript...

[_Thanatos_]

Er is niets mis met het prototyped-based object model in javascript...

Dat is dan ook iets dat je alleen hoort van iemand die HTML4 evenzo mooi vindt. Waarom is HTML een openbaar iets? Dat is PDF dan dus ook, maar een syntaxfout in de source van PDF geeft evengoed een knetterharde fout, of renders helemaal scheef. Waarom? Omdat de specs daarvan net zo strak liggen als die van XHTML Strict. Om nog maar de zwijgen van OpenDocument.

Als je jezelf een devver vindt, moet je ook niet gaan piepen als iets verkeerd rendert omdat JIJ een fout in je HTML-code zet. Moet je die fout maar niet maken, en moet je maar netjes coden. Dat is wat een HTML'er doet, dat is wat een devver doet. Als een designer of een huisvrouw gaat HTML'en, dan is het een andere zaak, laat die maar aankneiteren, maar van een devver verwacht ik eerder lof dan onvrede over een stricte markup met - zoals jullie dat zo mooi noemen - draconische foutafhandeling.

[crisp]

_Thanatos_ schreef op maandag 09 april 2007 @ 03:29:
[...]

Dat is dan ook iets dat je alleen hoort van iemand die HTML4 evenzo mooi vindt. Waarom is HTML een openbaar iets? Dat is PDF dan dus ook, maar een syntaxfout in de source van PDF geeft evengoed een knetterharde fout, of renders helemaal scheef. Waarom? Omdat de specs daarvan net zo strak liggen als die van XHTML Strict. Om nog maar de zwijgen van OpenDocument.

Als je jezelf een devver vindt, moet je ook niet gaan piepen als iets verkeerd rendert omdat JIJ een fout in je HTML-code zet. Moet je die fout maar niet maken, en moet je maar netjes coden. Dat is wat een HTML'er doet, dat is wat een devver doet. Als een designer of een huisvrouw gaat HTML'en, dan is het een andere zaak, laat die maar aankneiteren, maar van een devver verwacht ik eerder lof dan onvrede over een stricte markup met - zoals jullie dat zo mooi noemen - draconische foutafhandeling.

Appels, peren en bananen. Opmaaktaal, documentformats en programmeertalen zijn niet hetzelfde.

Daarbij heb je als webprogrammeur nooit alles zelf in de hand; 3rd party content en non-XML based markup-generators zijn zaken waar je gewoon rekening mee hebt te houden.

[WormLord]

Zucht, en daar is dus alweer de zoveelste nutteloze discussie over html/xhtml .
Nutteloos omdat beide zijden de andere niet kan overtuigen, omdat beide zijden volledig overtuigd zijn van hun gelijk en alle goede argumenten al minstens honderden keren eerder zijn aangehaald in 1 van de erg vele discussies of html/xhtml die eerder zijn gevoerd .

[crisp]

WormLord schreef op maandag 09 april 2007 @ 09:26:
Zucht, en daar is dus alweer de zoveelste nutteloze discussie over html/xhtml .
Nutteloos omdat beide zijden de andere niet kan overtuigen, omdat beide zijden volledig overtuigd zijn van hun gelijk en alle goede argumenten al minstens honderden keren eerder zijn aangehaald in 1 van de erg vele discussies of html/xhtml die eerder zijn gevoerd .

True helaas... Gelukkig is het bij de meeste mensen een fase waar ze even doorheen moeten voordat ze het grote plaatje beter kunnen zien

[imp4ct]

WormLord schreef op maandag 09 april 2007 @ 09:26:
Zucht, en daar is dus alweer de zoveelste nutteloze discussie over html/xhtml .
Nutteloos omdat beide zijden de andere niet kan overtuigen, omdat beide zijden volledig overtuigd zijn van hun gelijk en alle goede argumenten al minstens honderden keren eerder zijn aangehaald in 1 van de erg vele discussies of html/xhtml die eerder zijn gevoerd .

True, volgen kan ik al niet meer misschien maar goed ook ! Hoe dan ook, HTML of xHTML gelukkig ken ik de grote verschillen, voor -en nadelen niet dus maak ik er mij ook niet druk in

[Fuzzillogic]

crisp schreef op maandag 09 april 2007 @ 00:38:
Mijn kennis gaat ook niet zo ver op dat gebied, maar het is wel een feit dat op dit moment een conformance-check van een XHTML1.x document niet 100% de specificatie 'covered'.

Ongetwijfeld is er een XML schemataal te ontwikkelen waarmee het wél kan.

Ik vind dat idee achter 'zolang het niet dubbelzinnig is kunnen we het parsen' helemaal niet zo gek, zeker niet gezien de aard van de taal.

Ik vind het wel gek. Een eenduidige, simpele syntax is makkelijker te leren voor een mens, en (VEEL) makkelijker en sneller(!) te parsen. Je hebt nog steeds geen nadeel opgenoemd.

Ik heb het niet over oude browsers die nieuwe documenten zouden moeten kunnen parsen, maar over nieuwe browsers die altijd de oude documenten moeten kunnen blijven parsen. Om die reden kan je zaken als <font> en <b> simpelweg niet uitfaseren, hooguit als 'deprecated' markeren voor nieuwe documenten.

De parsers voor HTML4 tag soup zijn er allang. Die voor XML ook. De code is ook allang in het openbaar, net als emulatoren om de machine te emuleren waarop die code kan draaien.

Of vind jij soms ook dat je portable musicplayer perse CD's moet afspelen?

Een markup-language zou m.i. nooit een document inaccessible mogen maken enkel door een syntax-fout. WA1.0 probeert zelfs regels op te stellen voor het parsen van non-conforming documents (iets wat browsers nu elk op hun eigen manier doen) en ik vind dat een noemenswaardige verbetering. Draconische errorhandling is prima in een ontwikkelomgeving maar niet in het openbaar.

Opmaaktalen en programmeertalen zijn beide gestructureerde, computer-leesbare talen. En beide worden NIET door Jan-met-de-pet ingetypt, maar door developers. Van hen mag je écht verwachten dat ze weten hoe het moet, en niet "ongeveer". Regels opstellen voor non-conforming code leidt m.n. weer tot complexe parsers. Ik zie het nut er niet van in iig.

Maar browsers zullen 'transitional' nog steeds moeten ondersteunen. Daarbij was Strict sowieso al de norm voor nieuwe documenten, ook in HTML.

Als het al de norm is sinds 1997, waarom dan TIEN jaar later nog steeds de 'deprecated' meuk meeslepen terwijl ze eindelijk de mogelijkheid hebben om dat uit de specs te flikkeren? (ik heb het over de specs, niet over de browsers)

Er is niets mis met het prototyped-based object model in javascript...

Ach kom. Het heeft de structuur van zand: chaos. Er berg aan hacks (en hacks zijn het) geven javascript 1.x "OO-achtige" mogelijkheden, zoals private en protected variabelen/methoden. Het is gewoon een zooitje, en haalt het in de verste verte niet bij iets dat nog ouder is: c++.

WormLord schreef op maandag 09 april 2007 @ 09:26:
Zucht, en daar is dus alweer de zoveelste nutteloze discussie over html/xhtml .
Nutteloos omdat beide zijden de andere niet kan overtuigen, omdat beide zijden volledig overtuigd zijn van hun gelijk en alle goede argumenten al minstens honderden keren eerder zijn aangehaald in 1 van de erg vele discussies of html/xhtml die eerder zijn gevoerd .

Zo kun je de hele politiek bagatelliseren natuurlijk. Punt is, als ik zie dat Crisp zijn "XHTML is onzin" standpunten aan het neerzetten is, dan voel ik me geroepen om daar tegenin te gaan. Heeft ook iets te maken met de kleur van zijn nickname, wellicht.

[crisp]

Fuzzillogic schreef op dinsdag 10 april 2007 @ 00:49:
[...]

Ongetwijfeld is er een XML schemataal te ontwikkelen waarmee het wél kan.

Vast wel, het is er alleen nog niet.

[...]

Ik vind het wel gek. Een eenduidige, simpele syntax is makkelijker te leren voor een mens, en (VEEL) makkelijker en sneller(!) te parsen. Je hebt nog steeds geen nadeel opgenoemd.

In hoeverre is HTML syntax niet makkelijk te leren dan? Persoonlijk vind ik de 'uitzonderingen' wel meevallen en vind ik sommige constructs in XML juist weer raar voor een opmaaktaal (<br /> bijvoorbeeld). Daarbij is een loose parser die ook error-correctie ondersteund niet noodzakelijk langzamer plus je hebt het voordeel dat die ook met fragments overweg kan en incremental rendering kan doen.

[...]

De parsers voor HTML4 tag soup zijn er allang. Die voor XML ook. De code is ook allang in het openbaar, net als emulatoren om de machine te emuleren waarop die code kan draaien.

Of vind jij soms ook dat je portable musicplayer perse CD's moet afspelen?

Gezien de aard van de taal is het wel degelijk belangrijk dat een (X)HTML89.3 parser ook nog HTML2 kan parsen.

[...]

Opmaaktalen en programmeertalen zijn beide gestructureerde, computer-leesbare talen. En beide worden NIET door Jan-met-de-pet ingetypt, maar door developers.

Oh really? I beg to differ...

Van hen mag je écht verwachten dat ze weten hoe het moet, en niet "ongeveer". Regels opstellen voor non-conforming code leidt m.n. weer tot complexe parsers. Ik zie het nut er niet van in iig.

Met die complexiteit valt het reuze mee, misschien moet je zelf eens een parser proberen te schrijven?

[...]

Als het al de norm is sinds 1997, waarom dan TIEN jaar later nog steeds de 'deprecated' meuk meeslepen terwijl ze eindelijk de mogelijkheid hebben om dat uit de specs te flikkeren? (ik heb het over de specs, niet over de browsers)

Je kan het niet uit de specs flikkeren want toekomstige browsers die versie 89.3 implementeren moeten het ook ondersteunen.

[...]

Ach kom. Het heeft de structuur van zand: chaos. Er berg aan hacks (en hacks zijn het) geven javascript 1.x "OO-achtige" mogelijkheden, zoals private en protected variabelen/methoden. Het is gewoon een zooitje, en haalt het in de verste verte niet bij iets dat nog ouder is: c++.

private/protected variabelen en methods zijn wel degelijk mogelijk in javascript.

[...]

Zo kun je de hele politiek bagatelliseren natuurlijk. Punt is, als ik zie dat Crisp zijn "XHTML is onzin" standpunten aan het neerzetten is, dan voel ik me geroepen om daar tegenin te gaan. Heeft ook iets te maken met de kleur van zijn nickname, wellicht.

Als je eens wilt discusseren met mensen die echt authoriteit op dat gebied hebben dan kan ik je wel wat namen geven hoor, een Ian Hickson bijvoorbeeld, of Anne van Kesteren. Maar geeft het feit dat XHTML2 op sterven na dood is, o.a. doordat er geen backing is van browservendors (mede vanwege het breken met backwards-compatibility) terwijl er daarnaast een WA1.0 is en de W3 HTML WG nieuw leven is ingeblazen ook niet te denken?

[Fuzzillogic]

crisp schreef op dinsdag 10 april 2007 @ 09:48:
In hoeverre is HTML syntax niet makkelijk te leren dan? Persoonlijk vind ik de 'uitzonderingen' wel meevallen en vind ik sommige constructs in XML juist weer raar voor een opmaaktaal (<br /> bijvoorbeeld).

Fuzzillogic in "[xHTML] rare fout in IE 7", eerste alinea.

Gezien de aard van de taal is het wel degelijk belangrijk dat een (X)HTML89.3 parser ook nog HTML2 kan parsen.

Het lijkt mij geen probleem om dat als losse module onder te brengen, of anderszins gescheiden te houden.

Oh really? I beg to differ...

Ik kom het iig gelukkig zelden tegen. En dan zit er vaak nog een laag tussen (UBB codes, wiki's) die de boel zelf ook zouden kunnen controleren.

Met die complexiteit valt het reuze mee, misschien moet je zelf eens een parser proberen te schrijven?

Bij het ontwerpen van de programmeertaal en compiler daarvoor tijdens mijn studie is voor mij iig bevestigd dat een eenduidige syntax voor zowel de parser als de programmeur de zaken aanzienlijk vereenvoudigt.

private/protected variabelen en methods zijn wel degelijk mogelijk in javascript.

Ik zei ook niet dat het niet kan. Ik zei dat dat middels hacks gebeurt.

Als je eens wilt discusseren met mensen die echt authoriteit op dat gebied hebben dan kan ik je wel wat namen geven hoor, een Ian Hickson bijvoorbeeld, of Anne van Kesteren. Maar geeft het feit dat XHTML2 op sterven na dood is, o.a. doordat er geen backing is van browservendors (mede vanwege het breken met backwards-compatibility) terwijl er daarnaast een WA1.0 is en de W3 HTML WG nieuw leven is ingeblazen ook niet te denken?

Ik heb nergens XHTML2 genoemd. Dat ze dat aan de kant hebben gezet vind ik overigens wel jammer, aangezien XHTML2 wél opruiming heeft gehouden en (duh) XML is. Er ontbraken wel nog wat zaken, die XHTML5 wel toevoegt.

Maar waarom zou ik mezelf als devver met wat jaartjes ervaring niet serieus mogen nemen? De voorkeur voor XHTML is niet helemaal uit de lucht komen vallen.

Slightly related: het concept van WA kan ik dan nog wel inkomen, maar waarom ze zo blijven hangen aan javascript stoort me dan weer enorm. Je ziet nu al dat er bedrijven zijn die hele kastelen bovenop javascript bouwen. Ja het kán wel, maar het is er gewoon niet voor gemaakt. IMO is javascript gewoon not the right tool for such a job.

[crisp]

Fuzzillogic schreef op dinsdag 10 april 2007 @ 10:49:
[...]

Fuzzillogic in "[xHTML] rare fout in IE 7", eerste alinea.

crisp in "[xHTML] rare fout in IE 7" :

hoe vaak gebruik jij het TBODY element in een TABLE? En waarom zou je een element dat geen content heeft en kan hebben moeten afsluiten? <br></br> is ook maar raar vind je niet? Dus waarom is <br /> dan niet raar?

[...]

Het lijkt mij geen probleem om dat als losse module onder te brengen, of anderszins gescheiden te houden.

Met de verplichting om al die modules te implementeren in een browser? En hoe weet je welke module(s) benodigd is(zijn) voor het parsen van een bepaald document? Je hebt niet altijd een versie-nummertje in je document staan, en versioning zou best wel eens helemaal kunnen gaan verdwijnen; gewoon alles <!doctype html> en klaar - da's pas simpel

Bij het ontwerpen van de programmeertaal en compiler daarvoor tijdens mijn studie is voor mij iig bevestigd dat een eenduidige syntax voor zowel de parser als de programmeur de zaken aanzienlijk vereenvoudigt.

Uiteraard vereenvoudigd het de zaken, maar imo niet in die mate dat de voordelen van een loose parser daartegen opwegen.

[...]

Ik zei ook niet dat het niet kan. Ik zei dat dat middels hacks gebeurt.

Gebruik maken van de features van een taal is geen hack.

[...]

Ik heb nergens XHTML2 genoemd. Dat ze dat aan de kant hebben gezet vind ik overigens wel jammer, aangezien XHTML2 wél opruiming heeft gehouden en (duh) XML is. Er ontbraken wel nog wat zaken, die XHTML5 wel toevoegt.

Ja, XML is heilig maar ik ben atheist

Maar waarom zou ik mezelf als devver met wat jaartjes ervaring niet serieus mogen nemen? De voorkeur voor XHTML is niet helemaal uit de lucht komen vallen.

De afkeer van XHTML ook niet, die is gebaseerd op real-world ervaringen; op het feit dat XHTML gewoonweg niet werkt in de praktijk.

Slightly related: het concept van WA kan ik dan nog wel inkomen, maar waarom ze zo blijven hangen aan javascript stoort me dan weer enorm. Je ziet nu al dat er bedrijven zijn die hele kastelen bovenop javascript bouwen. Ja het kán wel, maar het is er gewoon niet voor gemaakt. IMO is javascript gewoon not the right tool for such a job.

WA1.0 heeft op zich weinig met javascript te maken hoor
En wat zou volgens jou een beter alternatief zijn dan javascript voor het bouwen van behavioral componenten in een webpagina? Volgens mij is het toch echt de best tool for the job, maar zoals met alles geldt: je moet wel verstand van zaken hebben om het goed toe te kunnen passen...

[ Voor 6% gewijzigd door crisp op 10-04-2007 11:05 ]

[crisp]

Afgesplitst vanuit [xHTML] rare fout in IE 7

[Fuzzillogic]

Het aangeven van welke versie specs er gebruik is gemaakt bij het opstellen van een document is juist handig. Al was het maar zodat de browser zou kunnen aangeven "hey misschien moet je me eens updaten, want dit gaat me boven m'n pet". Zo kun je meteen ook de semantische/syntactische verschillen tussen de versies afvangen, en waar nodig anders verwerken. Specificaties zijn niet altijd perfect, in een latere versies worden vaker correcties of wijzigingen doorgevoerd. Met een version-tag zou een browser zich daarop kunnen instellen.

<tbody /> is optioneel. Toegegeven, het kan rare zaken opleveren als je "table > tr" als CSS selector gebruikt, maar ik heb het nooit als probleem ervaren. Dat <br /> ziet er misschien 'vreemd' uit, maar het dient een hoger doel: het houdt het simpel. Immers elke tag dient afgesloten te zijn. GEEN uitzonderingen. Bovendien lijkt het mij een kwestie van gewenning.

Door de compatibiliteit zo hoog in het vaandel te houden blijven de 'mindere zaken' uit voorgaande sites maar resources opslurpen. En waarom? Dat je met Opera 11 ook nog gewoon HTML4-pagina's wilt bekijken lijkt me niet meer dan logisch, maar er zijn andere oplossingen dan "backwards compatibility" te verzinnen om dat op te lossen. Kijk al naar de XML-parser in Opera. Die staat al volledig los van de tag-soup-parser. Meuk zoals document.write werken dan ook niet meer, omdat dat de concepten van XML ondermijnt. Ik vind dat werkelijk een goede zaak.

Enfin, ik ben ervan overtuigd dat de voordelen zwaarder wegen dan de nadelen. Dat is vaker gebleken: het scheiden van structuur en uiterlijk middels CSS is een extra gedachtestap, welke niet altijd makkelijk is voor beginnende devvers. De voordelen van CSS hoef ik niet uit te leggen.

Gebruik maken van de features van een taal is geen hack.

Een hack is het gebruiken van de mogelijkheden op andere manier dan de ontwerper voor ogen heeft gehad. Al die demo's op MSX, C64 bestaan voor een belangrijk deel uit het hacken van de videochip. Soms vonden die hacks ook hun weg naar toepassingen zoals spellen, maar gezien de beperkingen of de omslachtigheid gebeurde dat niet vaak.
Hetzelfde geldt voor het OO-model in JS: het kán wel, het is er gewoon nooit zo voor ontworpen. Het resultaat: beperkingen en omslachtigheid.

En ach, ik haalde WA1.0 eigenlijk maar aan als voorbeeld. Het is meer de algehele... beperktheid van het hedendaagse webplatform dat mij begint te vervelen. Een date-picker maken? Idealiter zou ik verwachten dat je daar een custom tag voor in je XHTML gooit, binnen je eigen namespace. <fuzzi:datepicker startdate="current" range="false" /> Je browser roept vervolgens het custom-made componentje aan dat de datepicker verder rendert (bijv. mbv SVG) en regelt. Dus eigenlijk: gewoon netjes met drop-in componenten werken.
Dat het niet zo flexibel is, daar kan ik inkomen, het is immers 10 jaar oud (HTML4, CSS). Alleen dat ze er nauwelijks iets aan verbeterd wordt, daar snap ik niets aan.

Wat ik zou willen zien: de voordelen van een gestandaardiseerde maar uitbreidbare mark-up-taal (XHTML), gecombineerd met een krachtige standaard widgets-set (bijv. Swing), programmeerbaar met een uitgebreide, volledig OO-gerichte taal (Java), maar wel met de absolute vrijheid van het 'surfen'. (dus geen WebStart-achtige zaken, hoewel ik webstart al een bijzonder goed alternatief vind voor bijv. e-mailclients.)

Pff wat een verhaal En nu is de topic-title ook weer fout. Het is niet zozeer HTML vs XHTML, maar meer "keep the legacy" vs "let's start over"

[Verwijderd]

Ik voel wel wat voor beide kanten van het verhaal maar uiteindelijk ben ik een enorme pragmatist: kies voor de techniek die de klus het beste/snelste/lekkerste klaart. Voor mij is dat negen van de tien keer gewoon HTML strict.

Fuzzillogic schreef op dinsdag 10 april 2007 @ 17:13:
Hetzelfde geldt voor het OO-model in JS: het kán wel, het is er gewoon nooit zo voor ontworpen. Het resultaat: beperkingen en omslachtigheid.

Ik heb toch het vermoeden dat je Brendan Eich licht onderschat

[crisp]

Fuzzillogic schreef op dinsdag 10 april 2007 @ 17:13:
Het aangeven van welke versie specs er gebruik is gemaakt bij het opstellen van een document is juist handig. Al was het maar zodat de browser zou kunnen aangeven "hey misschien moet je me eens updaten, want dit gaat me boven m'n pet". Zo kun je meteen ook de semantische/syntactische verschillen tussen de versies afvangen, en waar nodig anders verwerken. Specificaties zijn niet altijd perfect, in een latere versies worden vaker correcties of wijzigingen doorgevoerd. Met een version-tag zou een browser zich daarop kunnen instellen.

http://lists.w3.org/Archi...ic-html/2007Apr/0279.html
http://lists.w3.org/Archi...ic-html/2007Apr/0319.html

En probeer voor de gein maar eens rond te surfen met IE4 of zelfs IE5.0 - op het moment dat je merkt dat je browser het niet meer aankan is het wellicht gewoon tijd voor een update van je browser. Common sense heet dat en versioning zal daar weinig tot geen verbetering in brengen

<tbody /> is optioneel. Toegegeven, het kan rare zaken opleveren als je "table > tr" als CSS selector gebruikt, maar ik heb het nooit als probleem ervaren.

In XHTML is je DOM-tree ook anders als je TBODY weglaat, en zo zijn er nog veel meer zaken die toch net even anders zijn in XHTML (met XHTML mimetype) ivt HTML en waar menig 'slap-on-that-XHTML-DTD-because-it-is-newer-and-better' amateur geen weet van heeft ( XHTML is not for Beginners ) - dat is uiteindelijk ook een reden waarom XHTML nooit goed van de grond is gekomen: iedereen is HTML gewend en XHTML blijkt dan toch net te ingewikkeld te zijn (ja, niet simpeler maar juist ingewikkelder).

Dat <br /> ziet er misschien 'vreemd' uit, maar het dient een hoger doel: het houdt het simpel. Immers elke tag dient afgesloten te zijn. GEEN uitzonderingen. Bovendien lijkt het mij een kwestie van gewenning.

Ik vint dat ook wel wat ja, d of t is ook maar lastig dus doen we alles maar +t - dat went ook wel

Door de compatibiliteit zo hoog in het vaandel te houden blijven de 'mindere zaken' uit voorgaande sites maar resources opslurpen. En waarom? Dat je met Opera 11 ook nog gewoon HTML4-pagina's wilt bekijken lijkt me niet meer dan logisch, maar er zijn andere oplossingen dan "backwards compatibility" te verzinnen om dat op te lossen.

Doe een voorstel naar de HTML WG zou ik zeggen. Ik denk echter dat als je de mailinglist zo doorleest je genoeg argumenten zal vinden waarom andere oplossingen juist niet ideaal zijn.

Kijk al naar de XML-parser in Opera. Die staat al volledig los van de tag-soup-parser.

Omdat XHTML mode compleet anders is dan HTML mode ja; precies wat Hixie zelf al aangeeft (ik neem aan dat je weet wie dat is): we hebben al 4 verschillende parsing-modes, meer hoeft daar niet bij omdat dat het alleen maar nog complexer maakt.

Meuk zoals document.write werken dan ook niet meer, omdat dat de concepten van XML ondermijnt. Ik vind dat werkelijk een goede zaak.

Dat is inherent aan het feit dat XML niet echt met fragments overweg kan, en dat is echt geen goede zaak.

Enfin, ik ben ervan overtuigd dat de voordelen zwaarder wegen dan de nadelen. Dat is vaker gebleken: het scheiden van structuur en uiterlijk middels CSS is een extra gedachtestap, welke niet altijd makkelijk is voor beginnende devvers. De voordelen van CSS hoef ik niet uit te leggen.

Ik ben het met je eens dat een aantal zaken in de huidige specificaties best wel het predikaat 'deprecated' mogen krijgen (inline style en eventhandlers bijvoorbeeld), maar an sich is dat een algemene kwestie, namelijk die van good vs bad practices, en dat is niet iets dat XHTML echt afdwingt of onmogelijk is in HTML.

[...]

Een hack is het gebruiken van de mogelijkheden op andere manier dan de ontwerper voor ogen heeft gehad. Al die demo's op MSX, C64 bestaan voor een belangrijk deel uit het hacken van de videochip. Soms vonden die hacks ook hun weg naar toepassingen zoals spellen, maar gezien de beperkingen of de omslachtigheid gebeurde dat niet vaak.
Hetzelfde geldt voor het OO-model in JS: het kán wel, het is er gewoon nooit zo voor ontworpen. Het resultaat: beperkingen en omslachtigheid.

Toch knap dat jij weet dat het nooit zo ontworpen is, ik denk namelijk dat javascript juist wel ontworpen is om een flexibele en bijzonder expressieve taal te zijn. Ja, JS2 geeft je straks bijvoorbeeld 'private' en 'public' maar dat is uiteindelijk enkel syntax suiker. Ik zou zeggen: geef eens wat concrete voorbeelden van wat jij beperkend en omslachtig vindt, wellicht kan ik er dan meer over zeggen. Mijn ervarig is dat dergelijke uitspraken meestal slechts een indicatie zijn dat degene die ze doet nog niet alteveel ervaring met de taal zelf heeft

En ach, ik haalde WA1.0 eigenlijk maar aan als voorbeeld. Het is meer de algehele... beperktheid van het hedendaagse webplatform dat mij begint te vervelen. Een date-picker maken? Idealiter zou ik verwachten dat je daar een custom tag voor in je XHTML gooit, binnen je eigen namespace. <fuzzi:datepicker startdate="current" range="false" /> Je browser roept vervolgens het custom-made componentje aan dat de datepicker verder rendert (bijv. mbv SVG) en regelt. Dus eigenlijk: gewoon netjes met drop-in componenten werken.

Ik werk zelf al aardig component-based, maar dan in javascript welke ik unobtrusive koppel aan een stukje markup. Hoe is dat anders dan wat jij voor ogen hebt dan?

Dat het niet zo flexibel is, daar kan ik inkomen, het is immers 10 jaar oud (HTML4, CSS). Alleen dat ze er nauwelijks iets aan verbeterd wordt, daar snap ik niets aan.

Daarom is ook de WHATWG uiteindelijk opgezet en heeft op eigen initiatief drafts opgesteld voor een opvolger van HTML (en vergeet ook WebForms niet) en is W3 nu eindelijk ook wakker geschud. Er wordt dus wel degelijk aan gewerkt.

Wat ik zou willen zien: de voordelen van een gestandaardiseerde maar uitbreidbare mark-up-taal (XHTML), gecombineerd met een krachtige standaard widgets-set (bijv. Swing), programmeerbaar met een uitgebreide, volledig OO-gerichte taal (Java), maar wel met de absolute vrijheid van het 'surfen'. (dus geen WebStart-achtige zaken, hoewel ik webstart al een bijzonder goed alternatief vind voor bijv. e-mailclients.)

Wat wellicht iets voor jou is is misschien wel Google Web Toolkit - ideaal voor serverside programmeurs die liever niet hun vingers vies maken aan simpele clientside zaken

Pff wat een verhaal En nu is de topic-title ook weer fout. Het is niet zozeer HTML vs XHTML, maar meer "keep the legacy" vs "let's start over"

Ik zal even een betere titel verzinnen (edit: zo beter?)

[orf]

Ik werk zelf al aardig component-based, maar dan in javascript welke ik unobtrusive koppel aan een stukje markup. Hoe is dat anders dan wat jij voor ogen hebt dan?

Hoewel ik dit zelf ook doe, vind ik het vaak toch te bepekt; hoe geef je bijvoorbeeld een min- en maxvalue aan voor een inputelement? (op basis van de classname kun je leuke plus en min toetsen genereren, maar de values moet je ergens anders vandaan halen)

[crisp]

orf schreef op dinsdag 10 april 2007 @ 22:14:
[...]


Hoewel ik dit zelf ook doe, vind ik het vaak toch te bepekt; hoe geef je bijvoorbeeld een min- en maxvalue aan voor een inputelement? (op basis van de classname kun je leuke plus en min toetsen genereren, maar de values moet je ergens anders vandaan halen)

HTML:

<input type="number" min="1" max="10">

WebForms 2.0

[Not Pingu]

Fuzzillogic schreef op zondag 08 april 2007 @ 00:22:
En even mijn standaardrepliek op Crisps standaard "XHTML sucks"-riedeltje: imo is XML gewoon de enige logische keuze voor een taal als HTML; geen vage uitzonderingen, lekker duidelijk, makkelijk te leren, snel te parsen en nog een stapeltje andere voordelen. Het voegt wel wat toe: duidelijkheid.

Zoals crisp al zegt, dat voordeel wordt geheel tenietgedaan door de huidige stand van de technologie. IE ondersteunt het niet en 80% van de (X)HTML schrijvers verprutst het geheid ergens. Daardoor werkt het afdwingen van XML wellformedness niet in de praktijk, behalve in heel specifieke situaties. Misschien dat dit nog verandert op het moment dat IE de application/xhtml contenttype gaat ondersteunen, dan zal iig de acceptatie hiervan groter worden en heb je dus na verloop van tijd meer aan bijv. een webcrawler die een pagina als XML parst.

En sowieso is het grootste doel van XHTML de uitbreidbaarheid. Zolang je dat niet gebruikt mag je jezelf best afvragen waarom je XHTML dan gebruikt.

orf schreef op dinsdag 10 april 2007 @ 22:50:
[...]


Netjes opbouwen kan in zowel XHTML als HTML. Als je XHTML door IE6+7 goed weergegeven wordt, verstuur je het als text/html en juist niet als XML. Het wordt dan ook behandeld als HTML.

Idd, daarnaast is het imho een beetje een rare extra stap om tot valid HTML 4.01 te komen, als dat uberhaupt al van toepassing is.

[ Voor 16% gewijzigd door Not Pingu op 10-04-2007 23:05 ]

[orf]

crisp schreef op dinsdag 10 april 2007 @ 22:20:
[...]

HTML:

<input type="number" min="1" max="10">

WebForms 2.0

En vanaf wanneer -realistisch gezien- is dat een optie?
Het rendeert nu wel, maar dat komt omdat elk input element naar een input type="text" rendeert als er geen type -of een foutieve- gegeven wordt.

ik wil kunnen valideren

[Onbekend]

Not Pingu schreef op dinsdag 10 april 2007 @ 22:29:
En sowieso is het grootste doel van XHTML de uitbreidbaarheid. Zolang je dat niet gebruikt mag je jezelf best afvragen waarom je XHTML dan gebruikt.

Ik gebruik XHTML (strict) eigenlijk om (samen met CSS) netjes een website op te bouwen.
Nadat dit door de validator is gekomen, is het eenvoudig om te zetten naar HTML 4.01.
Meestal laat ik het dan in XHTML staan omdat hij door de meest gebruikte browsers (inclusief IE6+7) correct wordt weergegeven....

Misschien in de toekomst wat meer experimenteren met XML, AJAX e.d.....

[orf]

Ook onbekend schreef op dinsdag 10 april 2007 @ 22:43:
[...]

Ik gebruik XHTML (strict) eigenlijk om (samen met CSS) netjes een website op te bouwen.
Nadat dit door de validator is gekomen, is het eenvoudig om te zetten naar HTML 4.01.
Meestal laat ik het dan in XHTML staan omdat hij door de meest gebruikte browsers (inclusief IE6+7) correct wordt weergegeven....

Misschien in de toekomst wat meer experimenteren met XML, AJAX e.d.....

Netjes opbouwen kan in zowel XHTML als HTML. Als je XHTML door IE6+7 goed weergegeven wordt, verstuur je het als text/html en juist niet als XML. Het wordt dan ook behandeld als HTML.

Verstuur je wel als XML, dan zorgt een niet ge-escaped karakter ervoor dat er een error op het scherm getoond wordt in plaats van een error correctie.

[crisp]

orf schreef op dinsdag 10 april 2007 @ 22:35:
[...]

En vanaf wanneer -realistisch gezien- is dat een optie?

In Opera al een tijdje native, verder bestaan er javascript libraries die support bieden in overige browsers (inclusief IE).

Het rendeert nu wel, maar dat komt omdat elk input element naar een input type="text" rendeert als er geen type -of een foutieve- gegeven wordt.

Het is inderdaad backwards-compatible met oudere UA's wat dat betreft.

ik wil kunnen valideren

Validatie is niet de heilige graal

Maar WF is inderdaad nog maar draft en de implementatie in Opera is experimenteel. Let's hope dat de W3 HTML WG het overneemt zodat we op termijn meer implementaties kunnen verwachten

Voor nu zou ik zelf toch opteren voor een class, bijvoorbeeld class="numberRangeSmall" oid

[Fuzzillogic]

crisp schreef op dinsdag 10 april 2007 @ 21:48:
[...]
In XHTML is je DOM-tree ook anders als je TBODY weglaat, en zo zijn er nog veel meer zaken die toch net even anders zijn in XHTML (met XHTML mimetype) ivt HTML en waar menig 'slap-on-that-XHTML-DTD-because-it-is-newer-and-better' amateur geen weet van heeft ( XHTML is not for Beginners ) - dat is uiteindelijk ook een reden waarom XHTML nooit goed van de grond is gekomen: iedereen is HTML gewend en XHTML blijkt dan toch net te ingewikkeld te zijn (ja, niet simpeler maar juist ingewikkelder).

HTML of XHTML, beide zijn even ongeschikt voor beginners. Een gladde leercurve willen we allemaal, maar het moet niet afzakken tot het niveau van speelgoed - dat is het namelijk niet. Er mogen best eisen gesteld worden aan de gebruikers van de taal.

Ik vint dat ook wel wat ja, d of t is ook maar lastig dus doen we alles maar +t - dat went ook wel

Wat je hier doet is de boel juist weer complexer maken. Overigens maak je idd nogal wat d/t fouten. Een computer-parser zou dan denken "wat doet dat voltooid deelwoord hier??". Dat maakt het er niet makkelijker op.

Ik ben het met je eens dat een aantal zaken in de huidige specificaties best wel het predikaat 'deprecated' mogen krijgen (inline style en eventhandlers bijvoorbeeld), maar an sich is dat een algemene kwestie, namelijk die van good vs bad practices, en dat is niet iets dat XHTML echt afdwingt of onmogelijk is in HTML.

True, maar mijn punt is waarom je dan zou stoppen bij SGML. XML is niet voor niets populair geworden.

Toch knap dat jij weet dat het nooit zo ontworpen is, ik denk namelijk dat javascript juist wel ontworpen is om een flexibele en bijzonder expressieve taal te zijn.

Ja mindfuck is ook flexibel. Maar expressief? No way.

Ja, JS2 geeft je straks bijvoorbeeld 'private' en 'public' maar dat is uiteindelijk enkel syntax suiker. Ik zou zeggen: geef eens wat concrete voorbeelden van wat jij beperkend en omslachtig vindt, wellicht kan ik er dan meer over zeggen.

Weak typing, afwezigheid van string formatters (a la printf), de work-arounds die je moet maken om protected variabelen/methodes te definieren met de mogelijkheid tot overerving, de onmogelijkheid om een klasse-definitie in 1 compound statement te groeperen (kan wel, maar geeft performance issues), de combinatie van timers en objecten (weer een work-around voor), geen namespaces, geen directe mogelijkheid om andere javascriptbestanden te includen/importeren, etc etc.

Ik werk zelf al aardig component-based, maar dan in javascript welke ik unobtrusive koppel aan een stukje markup. Hoe is dat anders dan wat jij voor ogen hebt dan?

Een tijd geleden heb ik in Java een tool gemaakt a la 'curves' van Photoshop en the Gimp. Ipv een standaard jPanel gebruik je dan de jCurvePanel in de code die de GUI definieert. Iets dergelijks moet gewoon native vanuit HTML kunnen. En dat kan nu niet.

Daarom is ook de WHATWG uiteindelijk opgezet en heeft op eigen initiatief drafts opgesteld voor een opvolger van HTML (en vergeet ook WebForms niet) en is W3 nu eindelijk ook wakker geschud. Er wordt dus wel degelijk aan gewerkt.

Eraan gewerkt ja, maar de kant die het op gaat stelt mij toch teleur. Zaken als

HTML:

<input type="number" min="1" max="10">

zijn prachtig, maar zolang je niet (ook) zelf eenvoudig en gestructureerd widgets kunt toevoegen of de bestaande kunt uitbreiden blijft het in veel situaties behelpen.

Wat wellicht iets voor jou is is misschien wel Google Web Toolkit - ideaal voor serverside programmeurs die liever niet hun vingers vies maken aan simpele clientside zaken

Die GWT moet ik idd nog eens verder bestuderen. Toch zou, in het ideale geval, de vertaalslag van Java naar Javascript overbodig mogen zijn. Het online voorbeeld dat ze daar hebben staan werkt toch ook nog lang niet zoals een desktop-app, laat staan dat het uitziet als een normale desktop-app.

Microsoft's XAML met C# als client-side(!) taal komt misschien bijzonder ver in de buurt met wat ik bedoel. Thin (or thick, als je wilt) clients maken die zich gedragen en uitzien als elke andere desktop-app, in de theme van je OS/Windows manager. Maar of dat ook geschikt is als vervanging van traditionele webpagina's met informatie betwijfel ik dan weer sterk, hoewel namespaces daar een prima oplossing voor kunnen bieden.

En dan is er nog, zoals hier al aangegeven, de vraag van ALS er dan een mooie nieuwe opvolger van HTML is gekomen (in welke vorm dan ook), het zal nog zeker jaren duren voordat we daar gebruik van kunnen maken en de browsers echt op 1 lijn zitten. Alternatieven zoals Java en Flash zijn er NU al.

Overigens, wat kunstjes die met een krachtigere taal mogelijk zijn: een 360-graden viewer en een MPEG4/AAC videoplayer als Java-applet. Vanuit de browser kun je m.b.v. LiveConnect ook nog eens prima babbelen met die applets. Techniek uit wat, 1995? Waarom zien we daar niet veel meer van? Ipv daarvan zitten we nu veelvuldig te kijken naar crappy (Flash 7) video, omdat de Flash 8/9 userbase nog te klein is ofzo.

[crisp]

Fuzzillogic schreef op dinsdag 10 april 2007 @ 23:49:
[...]

HTML of XHTML, beide zijn even ongeschikt voor beginners. Een gladde leercurve willen we allemaal, maar het moet niet afzakken tot het niveau van speelgoed - dat is het namelijk niet. Er mogen best eisen gesteld worden aan de gebruikers van de taal.

De vraag is: hoe hoog stel je die eisen?

[...]

Wat je hier doet is de boel juist weer complexer maken. Overigens maak je idd nogal wat d/t fouten. Een computer-parser zou dan denken "wat doet dat voltooid deelwoord hier??". Dat maakt het er niet makkelijker op.

Nederlands was inderdaad niet mijn sterkste vak, maar moet een simpele d/t-fout dan maar afgestraft worden met een orange-screen-of-death? Volgens mij begrijpt iedereen me prima zo

[...]

True, maar mijn punt is waarom je dan zou stoppen bij SGML. XML is niet voor niets populair geworden.

Ik denk ook wel dat het tijd is om af te stappen van SGML, per slot van rekening is er ook nog geen enkele browser die wat dat betreft HTML correct als SGML-applicatie heeft geimplementeerd. XML als data-interchange format is prima, als opmaak-taal vind ik de syntax te strict en beperkend.

[...]

Ja mindfuck is ook flexibel. Maar expressief? No way.

[...]

Weak typing, afwezigheid van string formatters (a la printf), de work-arounds die je moet maken om protected variabelen/methodes te definieren met de mogelijkheid tot overerving, de onmogelijkheid om een klasse-definitie in 1 compound statement te groeperen (kan wel, maar geeft performance issues), de combinatie van timers en objecten (weer een work-around voor), geen namespaces, geen directe mogelijkheid om andere javascriptbestanden te includen/importeren, etc etc.

Nog steeds geen concreet voorbeeld maar enkel wat loze kreten, jammer. Weak typing heeft zo z'n voordelen imho, string formatting is puur suiker, en dat en de rest is op zich prima te doen in javascript maar inderdaad niet op een manier zoals je gewend bent in andere talen. Maakt dat javascript tot een minderwaardige taal? Nee, alleen anders. Het is niet gek of vreemd om je coding-style aan te passen aan wat een taal je biedt, maar je moet je er wel voor open stellen. Vasthouden aan 'ja maar in taal X kan ik dit-of-dat zo-en-zo doen' is niet echt productief, er valt vast ook wel eea op te merken aan diezelfde taal X.

[...]

Een tijd geleden heb ik in Java een tool gemaakt a la 'curves' van Photoshop en the Gimp. Ipv een standaard jPanel gebruik je dan de jCurvePanel in de code die de GUI definieert. Iets dergelijks moet gewoon native vanuit HTML kunnen. En dat kan nu niet.

Misschien komt <canvas> in de buurt?

[...]

Eraan gewerkt ja, maar de kant die het op gaat stelt mij toch teleur. Zaken als

HTML:

<input type="number" min="1" max="10">

zijn prachtig, maar zolang je niet (ook) zelf eenvoudig en gestructureerd widgets kunt toevoegen of de bestaande kunt uitbreiden blijft het in veel situaties behelpen.

Waarom zou je niet zelf 'widgets' kunnen toevoegen? Genoeg 'hooks' die je aan markup kunt toevoegen en daar je eigen behavior-sausje overheen kan gooien lijkt me...

[...]

Die GWT moet ik idd nog eens verder bestuderen. Toch zou, in het ideale geval, de vertaalslag van Java naar Javascript overbodig mogen zijn. Het online voorbeeld dat ze daar hebben staan werkt toch ook nog lang niet zoals een desktop-app, laat staan dat het uitziet als een normale desktop-app.

Is dat uiteindelijk wel het doel dan?

Microsoft's XAML met C# als client-side(!) taal komt misschien bijzonder ver in de buurt met wat ik bedoel. Thin (or thick, als je wilt) clients maken die zich gedragen en uitzien als elke andere desktop-app, in de theme van je OS/Windows manager. Maar of dat ook geschikt is als vervanging van traditionele webpagina's met informatie betwijfel ik dan weer sterk, hoewel namespaces daar een prima oplossing voor kunnen bieden.

En dan is er nog, zoals hier al aangegeven, de vraag van ALS er dan een mooie nieuwe opvolger van HTML is gekomen (in welke vorm dan ook), het zal nog zeker jaren duren voordat we daar gebruik van kunnen maken en de browsers echt op 1 lijn zitten. Alternatieven zoals Java en Flash zijn er NU al.

Overigens, wat kunstjes die met een krachtigere taal mogelijk zijn: een 360-graden viewer en een MPEG4/AAC videoplayer als Java-applet. Vanuit de browser kun je m.b.v. LiveConnect ook nog eens prima babbelen met die applets. Techniek uit wat, 1995? Waarom zien we daar niet veel meer van? Ipv daarvan zitten we nu veelvuldig te kijken naar crappy (Flash 7) video, omdat de Flash 8/9 userbase nog te klein is ofzo.

En in hoeverre praat je dan nog over markup? Je gaat hier van een content-based format ineens over op full-fledged applications. Ik zie weinig relevantie mbt deze discussie.

[NitroX infinity]

Fuzzillogic schreef op dinsdag 10 april 2007 @ 23:49:
...geen directe mogelijkheid om andere javascriptbestanden te includen/importeren,...

Excuses voor het onderbreken van jullie discussie, maar is includen/importeren niet een serverside gebeuren mbt internet-talen? Vergeten we dan niet dat JS clientside is?

[Alex)]

Javascript includen kan wel, middels de <script>-tag. Mocht je het dynamisch willen doen:

JavaScript:

function createJS(source)
{
  if(source != "")
  {
    var elmJS = document.createElement("script");
    elmJS.type = "text/javascript";
    elmJS.src = source;

    var elmHead = document.getElementsByTagName("head")[0];
    elmHead.appendChild(elmJS);
    
    return true;
  }
  else
  {
    return false;
  }
}

En dan verderop:

JavaScript:

<script type="text/javascript">
...
if( createJS("bla.js") )
{
  alert('Aanmaken geslaagd');
}
else
{
  alert('Kon object niet maken - geen bron opgegeven');
}
...
</script>

Maargoed, we dwalen af... mijn standpunt is gelijk aan dat van crisp: HTML is prima, en xHTML is - vooral voor beginners - veel lastiger dan 'plain old' HTML, zelfs strict HTML is eenvoudiger dan strict xHTML.

Over <br> vs. <br />: <br> is veel makkelijker ingetypt dan <br />, en is ook logischer imho.
Een line-break is slechts één teken wat aangeeft dat er een nieuwe regel komt terwijl een paragraaf of vette tekst een begin en een einde kent. <strong> sluit je af met </strong> omdat je anders de rest van je pagina dikgedrukt maakt, <p> sluit je af met </p> (al hoeft dat vreemdgenoeg niet) puur voor het overzicht. Maar dit:

HTML:

<p>Lorem ipsum dolor <br></br> sit amet <br></br> consectetur adisciping elit.</p>

staat voor geen meter, er is ook geen opmaak. <br /> is een vervanger voor <br></br>, dus ik schrijf dat ook gewoon voluit.

Ook die draconische () errorhandling vind ik vreselijk: je kunt niet zien hoe je website eruitziet zolang er een fout inzit, terwijl je anders misschien een heel andere fout zou hebben opgelost en de globale foutfixronde (voor kleine foutjes als een ontbrekende /) pas naderhand zou doen. Draconische errorhandling bespaart geen tijd maar kost juist tijd.

[chris]

Fuzzillogic schreef op dinsdag 10 april 2007 @ 23:49:
Weak typing, afwezigheid van string formatters (a la printf), de work-arounds die je moet maken om protected variabelen/methodes te definieren met de mogelijkheid tot overerving, de onmogelijkheid om een klasse-definitie in 1 compound statement te groeperen (kan wel, maar geeft performance issues), de combinatie van timers en objecten (weer een work-around voor), geen namespaces, geen directe mogelijkheid om andere javascriptbestanden te includen/importeren, etc etc.


[...]

Een tijd geleden heb ik in Java een tool gemaakt a la 'curves' van Photoshop en the Gimp. Ipv een standaard jPanel gebruik je dan de jCurvePanel in de code die de GUI definieert. Iets dergelijks moet gewoon native vanuit HTML kunnen. En dat kan nu niet.

Ik denk dat je nu een beetje te overtrokken reageert. Het is niet standaard, maar toch redelijk triviaal om een java-achtig systeem in javascript te bouwen. Met behulp van een aantal goede libraries kom je al een heel eind. Ik bedoel trouwens niet dingen als prototype, maar je eigen libraries. Het model van JS is anders, prototype-gebaseerd. Dat betekent imho niet dat het "slechter" is dan Java, je moet alleen wel wat werk doen om het java-like te maken. Bijna alle taal-features van java zijn na te bouwen in JS, maar in Java is het een stuk moeilijker om JS na te doen (met name dingen als first-order functions).

Heb je al eens naar JS2 gekeken? Die lost een aantal van jouw issues met Javascript op.

Ik denk niet dat de ene taal beter is dan de ander. The right tool for the right job. Ik zou het wel erg fijn vinden als er een generiek, goed geimplementeerd en open browser-assembly formaat komt, zodat iedereen z'n eigen favoriete taal kan compileren voor browser-gebruik.

[We Are Borg]

Ook onbekend schreef op dinsdag 10 april 2007 @ 22:43:
[...]

Ik gebruik XHTML (strict) eigenlijk om (samen met CSS) netjes een website op te bouwen.
Nadat dit door de validator is gekomen, is het eenvoudig om te zetten naar HTML 4.01.
Meestal laat ik het dan in XHTML staan omdat hij door de meest gebruikte browsers (inclusief IE6+7) correct wordt weergegeven....

Misschien in de toekomst wat meer experimenteren met XML, AJAX e.d.....

En waarom, als je het toch als html gaat versturen, begin je gewoon niet met HTML en CSS? Waarom XHTML gebruiken als je er toch niks mee gaat doen, lees: als HTML gaat versturen? Je kan prima met HTML 'netjes' je website bouwen, net zo netjes als met XHTML. Ik zie IE echt niet in de komende 5 jaar opeens wel correct XHTML te kunnen afhandelen. Kortom, geef eens 1 goede rede waarom je XHTML boven HTML verkiest, terwijl het andersom in jouw situatie juist veel logischer is naar mijn mening

[ Voor 72% gewijzigd door We Are Borg op 11-04-2007 05:21 ]

[Onbekend]

Gewoon experimenteren.
Eerst heb ik de basis van HTML geleerd, daarna een beetje opmaak erbij.
Vervolgens kwam ik er achter dat er een validator voor bestond. (en alle fouten en waarschuwingen dus aangepast)

Daarna heb ik hem strict proberen te krijgen i.c.m. CSS. En vervolgens in XHTML omdat je meer in je CSS moet zetten. Het leert je dan ook om gestructureerder te werken.
Sindsdien ontwikkel ik eigenlijk volgens de XHTML specs, maar voor de rest doe ik niets met XML structuur.
Ik verstuur hem daarom inderdaad als text/html en niet als xml.

[BtM909]

Ook onbekend schreef op woensdag 11 april 2007 @ 08:12:
Gewoon experimenteren.
[...]

Daarna heb ik hem strict proberen te krijgen i.c.m. CSS. En vervolgens in XHTML omdat je meer in je CSS moet zetten. Het leert je dan ook om gestructureerder te werken.
[..]

Leg mij eens uit waarom XHTML je wel gestructureerder leert werken (meer in CSS stoppen ) terwijl HTML strict dat niet kan?

[Victor]

Pff, deze discussie... De web equivalent van Windows vs Linux

Maar goed: als developer zeg ik: XHTML (application/xhtml+xml). Waarom? Omdat het moeilijker is (het vereist kennis van zaken). Het forceert kwaliteit in je code en bovendien vind ik (let op, mening!) XML prettig werken. Ik kan er met XPath en XSLT op los, ik kan namespaces gebruiken, heerlijk.

Echter, er ziijn te veel invloeden van buiten af die je code kunnen verzieken, om te kunnen werken met de strikte error handling van XML. In de praktijk is het voorlopig niet bruikbaar.

[posttoast]

King_Louie schreef op woensdag 11 april 2007 @ 09:31:
Pff, deze discussie... De web equivalent van Windows vs Linux

Maar goed: als developer zeg ik: XHTML (application/xhtml+xml). Waarom? Omdat het moeilijker is (het vereist kennis van zaken).[/knip]

Het is beter omdat het moeilijker is? Dat is nog eens een vreemd argument

[Victor]

posttoast schreef op woensdag 11 april 2007 @ 09:38:
[...]

Het is beter omdat het moeilijker is? Dat is nog eens een vreemd argument

Ik ben van de vreemde argumenten

Het voordeel is dat je op deze manier van een zekere kwaliteit verzekerd bent. De developer moet weten waar ie mee bezig is, om er goed gebruik van te maken. De code zal dus van hogere kwaliteit zijn, wat weer onderhoudbaarheid ten goede komt, etc.

Door het corrigerende gedrag van HTML (of eigenlijk de parsers daarvan), is het veel makkelijker om daar een zooitje van te maken en het toch te laten werken. Dan heb ik toch liever een nette codebase

[Fuzzillogic]

Alex) schreef op woensdag 11 april 2007 @ 00:55:
Javascript includen kan wel, middels de <script>-tag. Mocht je het dynamisch willen doen:

code:

lap code

En dan verderop:

code:

lapje code
</script>

Je slaat de spijker op zijn kop. Dit is een hack. En Javascript zit vol met dit soort gedrochten. (nofi, Alex, het gaat me om het idee)

Maargoed, we dwalen af... mijn standpunt is gelijk aan dat van crisp: HTML is prima, en xHTML is - vooral voor beginners - veel lastiger dan 'plain old' HTML, zelfs strict HTML is eenvoudiger dan strict xHTML.

[knip verhaal over <br />]

Je vindt XHTML dus prima, maar alleen <br /> val je over?

Ook die draconische () errorhandling vind ik vreselijk: je kunt niet zien hoe je website eruitziet zolang er een fout inzit, terwijl je anders misschien een heel andere fout zou hebben opgelost en de globale foutfixronde (voor kleine foutjes als een ontbrekende /) pas naderhand zou doen. Draconische errorhandling bespaart geen tijd maar kost juist tijd.

Dan moet je betere tools gebruiken. Maar zelfs als ik het met de hand type, maak ik nooit dit soort fouten, juist omdat ik gewoon alles afsluit. Gaat gewoon op de automaat.

Ach het gaat er niet eens om wat makkelijker is, HTML en XHTML liggen veel te dicht bij elkaar in de buurt om daar over te bekvechten.

Mijn punten (en ik zal ze maar eens puntgewijs neerzetten):

• XML is de logische stap voor de volgende HTML-specs
• HTML moet eindelijk eens ontdaan worden van alle deprecated zooi
• HTML voor webapps is te beperkt. Een gerichte mark-up voor webapps (XUL, XAML, you name it) zou hier uitkomst kunnen bieden. Met namespaces kun je ze door elkaar gebruiken en toch gescheiden houden.
• JavaScript is een leuk en aardig, maar niet voor de applicaties die er nu op gebouwd worden. En dat kun je niet 'fixen' door weer allerlei extra features aan de taal toe te voegen. m.i. zou het gewoon vervangen moeten worden, of een extra taal erbij. Ik zie uitbreiding met Java, middels LiveConnect-achtige zaken best wel zitten.

[Verwijderd]

Fuzzillogic schreef op woensdag 11 april 2007 @ 10:20:
Je slaat de spijker op zijn kop. Dit is een hack. En Javascript zit vol met dit soort gedrochten. (nofi, Alex, het gaat me om het idee)

nofi, maar wtf is hier een hack aan? Je gebruikt de features van een taal om een functionaliteit te realiseren.

[Fuzzillogic]

Verwijderd schreef op woensdag 11 april 2007 @ 11:07:
[...]

nofi, maar wtf is hier een hack aan? Je gebruikt de features van een taal om een functionaliteit te realiseren.

Iets basaals als een include/import dient gewoon native in de taal te zitten. Nu gebruik je een omweg via HTML/de DOM om het doel te bereiken. In mijn boekje is dat een hack.

Ik wil Javascript niet afkraken of onderuithalen, want voor veel dingen is het prima geschikt. Alleen niet voor het bouwen van volledige, grote applicaties. Dat het kán betekent niet dat het ook handig is. Met een zaag kun je ook best een schroef de muur in draaien..

[crisp]

Fuzzillogic schreef op woensdag 11 april 2007 @ 11:24:
[...]
Ik wil Javascript niet afkraken of onderuithalen, want voor veel dingen is het prima geschikt. Alleen niet voor het bouwen van volledige, grote applicaties. Dat het kán betekent niet dat het ook handig is. Met een zaag kun je ook best een schroef de muur in draaien..

Mwa, je zou je kunnen afvragen of het web an sich wel geschikt is voor grote applicaties; je zit immers nog altijd met een onderliggend stateless protocol en dat is iets wat je niet zo makkelijk oplost door voor een andere taal te kiezen.

Ik denk dat je wat dat betreft ook eea moet nuanceren en zal moeten vaststellen wanneer een bepaalde technologie wel geschikt is en wanneer niet meer (en het volgens jou dus een 'hack' wordt). Wat is in jouw ogen bijvoorbeeld een 'grote applicatie'? Als ik via javascript de mogelijkheid toevoeg op dit forum om inline je reply te editten (unobtrusive offcourse) gebruik ik dan al een verkeerde technologie volgens jou? En wat is dan op dit moment of in de nabije toekomst wel een geschikt en volwaardig alternatief?

Ik heb een beetje het idee dat jij meer kijkt naar hoe iets zou moeten zijn en daarbij voorbij gaat aan de huidige praktijksituatie. Een beetje een utopie dus, eigenlijk net zoiets als XHTML2

Overigens las ik zojuist dit interessante artikel wat ook wel een beetje mijn mening weerspiegeld: http://www.digital-web.co...nd_the_future_of_the_web/

[Fuzzillogic]

crisp schreef op woensdag 11 april 2007 @ 11:43:
Mwa, je zou je kunnen afvragen of het web an sich wel geschikt is voor grote applicaties; je zit immers nog altijd met een onderliggend stateless protocol en dat is iets wat je niet zo makkelijk oplost door voor een andere taal te kiezen.

Ik denk dat je wat dat betreft ook eea moet nuanceren en zal moeten vaststellen wanneer een bepaalde technologie wel geschikt is en wanneer niet meer (en het volgens jou dus een 'hack' wordt). Wat is in jouw ogen bijvoorbeeld een 'grote applicatie'? Als ik via javascript de mogelijkheid toevoeg op dit forum om inline je reply te editten (unobtrusive offcourse) gebruik ik dan al een verkeerde technologie volgens jou? En wat is dan op dit moment of in de nabije toekomst wel een geschikt en volwaardig alternatief?

Nee het web is helemaal niet geschikt voor grote applicaties. Bij de "online office applications" zoals Google ze aanbiedt zet ik dan ook grote vraagtekens. Maar dat zet ik ook al bij zaken als gmail. Imo is een webclient een matige vervanger voor een desktopclient. Jouw voorbeeld van inline editing is prima iets waar webtechnologie geschikt voor is. Imo moeten webapps niet krampachtig proberen om de desktopapps te evenaren. Dat is wat Google et all. wel doen. Maar inderdaad, het is subjectief.

Ik heb een beetje het idee dat jij meer kijkt naar hoe iets zou moeten zijn en daarbij voorbij gaat aan de huidige praktijksituatie. Een beetje een utopie dus, eigenlijk net zoiets als XHTML2

De praktijk is gmail. Er zijn alternatieven: een mailclients in de vorm van Java applets/WebStart. En wat is er mis met een utopie? (niets, duh). Dat we nooit daar zullen komen is logisch, maar om daarom dan alles maar bij het oude te laten?.. Ik krijg de indruk dat het vooral de browserbouwers zijn die niet willen meewerken, en hooguit aan de evolutie van de technieken willen meewerken, ipv revolutie. Developers volgen vanzelf wel, zodra nieuwe technieken goed beschikbaar zijn in de grote browsers. (een killer-app kan dan wel helpen, natuurlijk)

Overigens las ik zojuist dit interessante artikel wat ook wel een beetje mijn mening weerspiegeld: http://www.digital-web.co...nd_the_future_of_the_web/

Zal het straks eens lezen.

[Blaise]

Het internet is groot en log. Browserbouwers willen backwards compatible zijn, webmasters willen dat browsers hun sites goed weergegeven, bezoekers willen dat hun favoriete sites het doen. Dat valt niet te rijmen met revolutionaire veranderingen.

Je kan wel allemaal dingen willen en fijn dromen, maar de werkelijkheid is anders.

[Not Pingu]

King_Louie schreef op woensdag 11 april 2007 @ 09:57:
Het voordeel is dat je op deze manier van een zekere kwaliteit verzekerd bent. De developer moet weten waar ie mee bezig is, om er goed gebruik van te maken. De code zal dus van hogere kwaliteit zijn, wat weer onderhoudbaarheid ten goede komt, etc.

Dat vind ik een nogal vreemd argument. Goed werk wordt niet afgedwongen door een taal of platform. De kwaliteit van het werk is afhankelijk van de kwaliteit van de developer.
Je zou juist andersom verwachten dat een minder strikte taal (HTML/SGML) meer mensen in staat stelt om er goed mee te werken, dan een 'elitaire' taal als XHTML strict.

Het 'gevaar' van XHTML is juist dat prutsdevelopers niet ineens beter worden door het introduceren van een striktere standaard. Dus krijg je sites met nonvalide zaken waardoor de XML-wellformedness regels worden geschonden en het geen geldige XML/XHTML meer is. Dus krijgen die developers bij het bekijken van hun site een leuke parser error in beeld ipv. een site gerenderd volgens onduidelijke strategie en zullen ze binnen no time terug stappen op HTML omdat het ze daarin wel lukte. En de baas wil de nieuwe site over 2 dagen online zien, je kent dat wel.

[Fuzzillogic]

En wat nou als HTML niet meer de features biedt die nodig zijn voor de site, omdat de opvolger waarin die features zitten alleen in XML-vorm is?

Dat XHTML leidt tot betere sites betwijfel ik ook. Een pagina well-formed krijgen is niet moeilijk, maar dat voorkomt niet dat er prutsende harries zijn die er een div-soep van gaan maken en met id's en classes gaan strooien als ware het snoepgoed uit de zak van Sinterklaas...

[crisp]

Fuzzillogic schreef op woensdag 11 april 2007 @ 15:49:
En wat nou als HTML niet meer de features biedt die nodig zijn voor de site, omdat de opvolger waarin die features zitten alleen in XML-vorm is?

zo ver is het nog lang niet, als het ueberhaupt zal gaan gebeuren...

Dat XHTML leidt tot betere sites betwijfel ik ook. Een pagina well-formed krijgen is niet moeilijk

Dat is wel moeilijk, zeker als je werkt met non-XML based authoring tools en/of je te maken hebt met 3rd party content die niet gegarandeerd well-formed is.

Als je echt XML-based bezig wil zijn dan zal alles daarop ingericht moeten zijn, van content-validation tot en met markup-generation. IRL zie je dat bijna nooit en wordt er nog veel string-handling gedaan (biedt dus geen garantie), en ad-providers gebruiken zelfs meestal nog script-injection met document.write().

, maar dat voorkomt niet dat er prutsende harries zijn die er een div-soep van gaan maken en met id's en classes gaan strooien als ware het snoepgoed uit de zak van Sinterklaas...

prutsende harries zal je altijd blijven houden; elke techniek kan je op goede en op slechte manieren gebruiken.

[Victor]

Not Pingu schreef op woensdag 11 april 2007 @ 15:23:
[...]


Dat vind ik een nogal vreemd argument. Goed werk wordt niet afgedwongen door een taal of platform. De kwaliteit van het werk is afhankelijk van de kwaliteit van de developer.

Dat ben ik volledig met je eens. Maar we weten allemaal dat iedere lolbroek met Frontpage en wat copy/paste skills zichzelf tegenwoordig web developer kan noemen. Ik wens die mensen veel succes om een goede XHTML pagina neer te zetten.

Je zou juist andersom verwachten dat een minder strikte taal (HTML/SGML) meer mensen in staat stelt om er goed mee te werken, dan een 'elitaire' taal als XHTML strict.

Juist dat soepele biedt meer ruimte voor prutswerk (maar een volledig well formed, XHTML 1.1 validerende pagina kan nog steeds een bende zijn).

Het 'gevaar' van XHTML is juist dat prutsdevelopers niet ineens beter worden door het introduceren van een striktere standaard. Dus krijg je sites met nonvalide zaken waardoor de XML-wellformedness regels worden geschonden en het geen geldige XML/XHTML meer is. Dus krijgen die developers bij het bekijken van hun site een leuke parser error in beeld ipv. een site gerenderd volgens onduidelijke strategie en zullen ze binnen no time terug stappen op HTML omdat het ze daarin wel lukte. En de baas wil de nieuwe site over 2 dagen online zien, je kent dat wel.

Het is ook hoe ik het graag zou zien, ik heb nooit gezegd dat het haalbaar is

Overigens is goed XML gebruik op zich nog een utopie, want veel developers hebben er niets tot weinig van begrepen.

[ Voor 3% gewijzigd door Victor op 11-04-2007 17:50 ]

[Blaise]

Over dat prutswerk en amateurs: HTML is oorspronkelijk bedoeld om begrijpbaar te zijn voor de leek, als een makkelijke manier om tekst op te maken en te linken naar andere teksten. Dat is voor een deel ook de kracht van het internet, dat elke Harry zijn kennis en informatie op het web kan plaatsen en dat iedereen die informatie kan raadplegen.

Inmiddels heb je allerlei tools als Dreamweaver, Frontpage en Wordpress die XHTML genereren, maar dan nog vind ik dat geen reden om de lat extra hoog te leggen voor XHTML leken. Ik betwijfel ook of het web er écht beter van zou worden. Ik denk eerder dat het de nieuwe "dode links" worden: de "malformed XML pagina's".

[Victor]

Blaise schreef op woensdag 11 april 2007 @ 21:21:
Over dat prutswerk en amateurs: HTML is oorspronkelijk bedoeld om begrijpbaar te zijn voor de leek, als een makkelijke manier om tekst op te maken en te linken naar andere teksten.

HTML is uitgevonden door Tim Berners-Lee, toen hij werkzaam was bij CERN. Bij CERN werken geen leken die vakantiefoto's uit willen wisselen, daar werken wetenschappers die jawel, wetenschappelijke informatie beschikbaar willen stellen.

[orf]

Een mooie parse error is leuk in een testomgeving, maar in een live omgeving wil je gewoon error-correctie. Wat heeft je bezoeker aan een parse error? Om ervoor te zorgen dat er nooit een parse error kan ontstaan moet je verregaande maatregelen nemen, commercieel vaak niet haalbaar. Zoals Crisp al aangeeft heb je soms simpelweg geen invloed op content vanwege contentpartners.

[Blaise]

Die wetenschappers deden nucleair onderzoek, ze hadden niet per se verstand programmeren (of coden, of hoe je het wil noemen). HTML was daarom een eenvoudige opmaaktaal, begrijpbaar voor iedereen.

[Fuzzillogic]

Feit dat het web "iets" gegroeid is sinds 1992. HTML is ontwikkeld als zijnde document-opmaaktaal. Gewoon, eenzijdig informatie overbrengen, alsof het een vel papier is. Later zijn daar natuurlijk de formulieren bijgekomen die wat interactiviteit toevoegen. Voor het verschaffen van tekstuele informatie is (X)HTML prima. De rek is er m.i. wel uit. Het maken van applicaties vereist toch echt andere zaken dan <strong /> en <p />... XML kan de tekstopmaak en applicatie/formulieropmaak prachtig scheiden mbv namespaces.

Overigens, ik ken werkelijk waar geen enkele leek die zelf de HTML-code klopt. Daar zijn allemaal tools voor. En die tools kunnen echt wel gemaakt worden om netjes volgens specs te werken. Dus het argument dat het ook voor leken geschikt moet zijn lijkt me tegenwoordig niet meer opgaan.

[ Voor 14% gewijzigd door Fuzzillogic op 11-04-2007 22:33 ]

[Civil]

Fuzzillogic schreef op woensdag 11 april 2007 @ 22:31:
Overigens, ik ken werkelijk waar geen enkele leek die zelf de HTML-code klopt. Daar zijn allemaal tools voor. En die tools kunnen echt wel gemaakt worden om netjes volgens specs te werken. Dus het argument dat het ook voor leken geschikt moet zijn lijkt me tegenwoordig niet meer opgaan.

Je lijkt voorbij te gaan aan het feit dat er naast professionele webdevelopers ook mensen zijn die hun huis tuin en keuken site zelf in elkaar zetten met de hand. En die het ook leuk vinden om wat te experimenteren met nieuwe webtechnieken, maar niet de tijd hebben zich er zover in de verdiepen als de professionele webdeveloper. De kracht van het web is nu juist dat ook deze mensen er toegang toe hebben, er gebruik van maken, en hun ding doen. Een compleet gereguleerd web lijkt vanuit webdeveloper opzicht misschien prachtig, maar lijkt me vanuit de huis tuin en keuken gebruiker die het web mede zo'n prachtig medium maakt onwenselijk.

Veel webdevelopers hebben naar mijn idee hun interesse voor het web ontwikkeld omdat ze aan het knutselen geslagen zijn, veel fouten gemaakt hebben, zich ontwikkeld hebben, etc. Een 'draconische error-handling' schrikt eerder af dan dat het uitnodigd door te leren. En xhtml is echt niet makkelijker tegenover html, ook al zijn de regeltjes simpeler gesteld, de striktheid, modulariteit, namespaces maken het geheel weer ingewikkelder om door te krijgen.

Nee, ook ik zie meer in ontwikkelingen als HTML5 met een vastgelegde error correctie en die door de gebruiker losser te hanteren is.

[chris]

We voeren hier allerlei discussies door elkaar

* Is het web geschikt voor applicaties
* Is HTML beter dan XHTML
* Is HTML/XHTML geschikt voor applicaties
* Is Javascript geschikt voor applicaties

Ik denk dat ik persoonlijk een "ja" op alles behalve de derde antwoordt. De tweede is eigenlijk een nee, maar toch een ja.

HTML/CSS/JS is absoluut niet bedoeld voor wat sommige mensen er nu mee aan het bouwen zijn (rich internet applications). Toch is er op dit moment niets beters:

* Het werkt in alle browsers, zonder plugins
* Het is een set van open standaarden
* Het is redelijk compatibel (ja, er zitten veel bugs en verschillen in browsers, maar met een goede abstractielaag is dat nauwelijks een probleem)
* Het is redelijk lichtgewicht (Je hoeft geen JVM oid te starten)
* Het werkt prima voor kleinere applicaties, en zal waarschijnlijk steeds blijven groeien.

Ik gebruik zelf 90% van de tijd een desktop-applicatie, maar ik ben toch wel erg blij dat er webmail is.

Verder vind ik (om mezelf maar in de voet te schieten) dat mensen niet altijd al te veel moeten zeuren over "daar is het niet voor bedoeld". Het internet is niet voor gamen en/of porno bedoeld, toch zijn dat twee belangrijke online-dingen. Een auto is niet bedoeld om alleen maar te pimpen, toch zijn er mensen die dat leuk of nuttig vinden. HTML is niet bedoeld om een rich application in te schrijven, toch zijn er mensen die het doen, en ik ben ook erg blij dát ze het doen.

[Alex)]

Ik kom er net achter dat mijn weblog (draait nog een defaultthema op) XHTML 1.0 Strict als doctype heeft. Als ik posts plaats gooi ik er wel eens HTML in, en dan dus gewoon HTML 4.01 Strict, geen XHTML.

Ik ben toch best blij dat er geen draconische XHTML-error-handling in IE zit, dan zou ik m'n eigen blog niet eens meer kunnen bezoeken

[We Are Borg]

Alex) schreef op donderdag 12 april 2007 @ 03:20:
Ik ben toch best blij dat er geen draconische XHTML-error-handling in IE zit, dan zou ik m'n eigen blog niet eens meer kunnen bezoeken

Er zit totaal geen XHTML support in IE, kortom, nogal logisch toch?

[Alex)]

Mja, ik bedoel eigenlijk meer draconische errorhandling in het algemeen, gelukkig zit dat niet in browsers, of iig niet zo zodat ze meteen zodra ze een XHTML-doctype tegenkomen naar draconische modus overschakelen.

[We Are Borg]

Alex) schreef op donderdag 12 april 2007 @ 03:28:
Mja, ik bedoel eigenlijk meer draconische errorhandling in het algemeen, gelukkig zit dat niet in browsers, of iig niet zo zodat ze meteen zodra ze een XHTML-doctype tegenkomen naar draconische modus overschakelen.

Het heeft ook niks met het doctype te maken zolang jij XHTML als html verstuurd. Zodra jij XHTML wel correct verstuurd heb je gelijk die draconische modus waar je het over hebt, maar dat zal je voorlopig in IE toch nooit tegenkomen: dat gaat nog jaren duren voordat die ooit XHTML documenten correct kan parsen

[SuperRembo]

Voordat XHTML echt van praktisch nut zou kunnen zijn heb je toch echt ondersteuning nodig van de meest gebruikte browser(s). Dus wat zijn eigenlijk de toekomstplannen voor Internet Explorer wat betreft XHTML/HTML5 etc?

[crisp]

Alex) schreef op donderdag 12 april 2007 @ 03:28:
Mja, ik bedoel eigenlijk meer draconische errorhandling in het algemeen, gelukkig zit dat niet in browsers, of iig niet zo zodat ze meteen zodra ze een XHTML-doctype tegenkomen naar draconische modus overschakelen.

In fact: browsers doen nagenoeg niets met de DTD, enkel het bepalen van de rendermode (quirksmode of standards-compliant mode). De mimetype bepaald of de XML-parser of HTML-parser gebruikt moet worden.

Dat is uiteindelijk ook weer een argument voor het weglaten van een specifiek versie-nummer: er wordt nu ook niets mee gedaan (HTML2 wordt op dezelfde manier behandeld als HTML4) en zolang nieuwe specificaties zich enkel toespitsen op het introduceren van nieuwe features en bestaande features ongemoeid laten (bugfixes daargelaten) is dat ook geen enkel probleem en ben je verzekerd van backwards-compatibility naar de toekomst toe.

SuperRembo schreef op donderdag 12 april 2007 @ 07:59:
Voordat XHTML echt van praktisch nut zou kunnen zijn heb je toch echt ondersteuning nodig van de meest gebruikte browser(s). Dus wat zijn eigenlijk de toekomstplannen voor Internet Explorer wat betreft XHTML/HTML5 etc?

Ik geloof niet dat MS plannen heeft om op korte termijn XHTML te gaan ondersteunen. Ze zijn inmiddels wel aangeschoven bij de nieuwe W3 HTML WG (Chris Wilson is zelfs tot chair benoemd) dus dat geeft wel aan dat er op dat vlak interesse is.

Aan de andere kant heeft Chris wel de volgende uitspraak gedaan:

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

We can't, for example, change the behavior of how we support CSS floats in IE7 without requiring an opt-in, since we would change layout significantly for half the web.* When we break the web, it's our fault, even when we're breaking it to improve standards compliance.

Oftewel: MS heeft blijkbaar wel wat reserveringen om de huidige non-conformant behavior van hun eigen browser aan te passen naar de specificaties in de angst dat dat voor veel problemen gaat zorgen. Chris heeft beloofd hier binnenkort verder op in te gaan en ik ben ook wel heel benieuwd daarnaar aangezien ik het absoluut oneens ben met een dergelijk standpunt.

[ Voor 21% gewijzigd door crisp op 12-04-2007 10:05 ]

[Grijze Vos]

King_Louie schreef op woensdag 11 april 2007 @ 09:57:
[...]

Het voordeel is dat je op deze manier van een zekere kwaliteit verzekerd bent. De developer moet weten waar ie mee bezig is, om er goed gebruik van te maken. De code zal dus van hogere kwaliteit zijn, wat weer onderhoudbaarheid ten goede komt, etc.

En hoeveel lutsers zeggen tegen hun collegae "kom, we doen project X en Y in XML, want XML is nieuw en tof". Zonder verder na te denken waarom ze XML nodig hebben. En vervolgens krijg je van die configuratie bestanden in XML waar je net zo goed een ini file had kunnen gebruiken. (om maar een voorbeeld te geven dat niet web-related is. )

[Not Pingu]

crisp schreef op donderdag 12 april 2007 @ 10:01:

Ik geloof niet dat MS plannen heeft om op korte termijn XHTML te gaan ondersteunen. Ze zijn inmiddels wel aangeschoven bij de nieuwe W3 HTML WG (Chris Wilson is zelfs tot chair benoemd) dus dat geeft wel aan dat er op dat vlak interesse is.

Aan de andere kant heeft Chris wel de volgende uitspraak gedaan:

[...]

Oftewel: MS heeft blijkbaar wel wat reserveringen om de huidige non-conformant behavior van hun eigen browser aan te passen naar de specificaties in de angst dat dat voor veel problemen gaat zorgen.

Dat vind ik wel realisme vs. idealisme hoor. Feit is gewoon dat (dankzij Microsofts gebrekkige implementatie van HTML) het web voor een groot deel bestaat uit IE-only sites. Chris Wilson is zich bewust van het feit dat Microsoft daarin fouten heeft gemaakt, maar hij wil ook niet fout op fout stapelen door nu weer van het rendergedrag af te stappen waar de halve webwereld net aan gewend was geraakt.

Het is gewoon een feit dat het meerendeel van de websites niet gemaakt is met standaarden, accessibility enz. in het achterhoofd en dat kun je leuk vinden of niet, het blijft een feit.

Aan de andere kant: daarom is er ook het onderscheid tussen quirksmode en standards mode in IE en zou ik persoonlijk geen reden zien waarom XHTML sites met een valid doctype (die nu standards mode triggeren) ook niet gewoon als volledig XML behandeld kunnen worden. Want de keuze waar het over gaat is eigenlijk al gemaakt in IE6.

[crisp]

Not Pingu schreef op donderdag 12 april 2007 @ 14:14:
[...]


Dat vind ik wel realisme vs. idealisme hoor. Feit is gewoon dat (dankzij Microsofts gebrekkige implementatie van HTML) het web voor een groot deel bestaat uit IE-only sites. Chris Wilson is zich bewust van het feit dat Microsoft daarin fouten heeft gemaakt, maar hij wil ook niet fout op fout stapelen door nu weer van het rendergedrag af te stappen waar de halve webwereld net aan gewend was geraakt.

Het is gewoon een feit dat het meerendeel van de websites niet gemaakt is met standaarden, accessibility enz. in het achterhoofd en dat kun je leuk vinden of niet, het blijft een feit.

Dat een groot deel van het huidige web IE-only is valt imo nog wel mee. Dat is uiteraard ook wel te danken aan het feit dat andere browsersvendors (zeker in quirksmode rendering) zoveel en waar mogelijk het gedrag van IE imiteren. In ieder geval is het m.i. naar de toekomst toe wel belangrijk dat dergelijke zaken beschreven gaan worden in een specificatie, hierdoor vergroot je in ieder geval de toegankelijkheid van het huidige web omdat alle browservendors er dan op dezelfde manier mee om kunnen gaan.

Voor standards-compliant mode moet MS gewoon niet zeuren; ik geloof het niet dat als ze bugs op dat gebied fixen dat dat het halve web 'breekt'. Er zullen vast wel sites zijn waarbij er dan dingen ineens mis gaan, maar die websites waren dan al 'broken to begin with' - in ieder geval al in non-IE browsers.

Aan de andere kant: daarom is er ook het onderscheid tussen quirksmode en standards mode in IE en zou ik persoonlijk geen reden zien waarom XHTML sites met een valid doctype (die nu standards mode triggeren) ook niet gewoon als volledig XML behandeld kunnen worden. Want de keuze waar het over gaat is eigenlijk al gemaakt in IE6.

Als je puur op doctype gaat beslissen of een document XHTML is of niet en overeenkomstig ook zo behandeld dan kan je er in ieder geval wel zeker van zijn dat het halve web breekt

[Fuzzillogic]

crisp schreef op donderdag 12 april 2007 @ 15:16:
[...]

Als je puur op doctype gaat beslissen of een document XHTML is of niet en overeenkomstig ook zo behandeld dan kan je er in ieder geval wel zeker van zijn dat het halve web breekt

Maar die sites die dan kapot gaan waren ook al "broken to begin with"; ze hielden zich net zo min aan de standaard...

[Fuzzillogic]

Hmm, Mozilla, Opera en Appleg gooien zich in de strijd voor HTML5. De HTML design principles die daar vermeld staan stellen mij toch echt teleur. Ze zijn écht behoudend daar, terwijl ze nú de kans zouden hebben om eens een frisse wind te laten waaien. HTML5 is inderdaad de opvolger van HTML4, terwijl het web m.i. iets echt nieuws goed zou kunnen gebruiken. Ik durf zelfs te stellen dat HTML5 een laffe upgrade wordt. Na TIEN jaar zou er toch wel iets meer vooruitgang geboekt mogen worden.

Dit vooruitzicht maakt voor mij het vak 'web developer' steeds minder aantrekkelijk.

[crisp]

Fuzzillogic schreef op donderdag 12 april 2007 @ 15:59:
[...]

Maar die sites die dan kapot gaan waren ook al "broken to begin with"; ze hielden zich net zo min aan de standaard...

Tsja, het XHTML-fiasco zou je natuurlijk ook ergens anders aan kunnen toeschrijven: misschien is XML wel helemaal niet zo geschikt als basis voor een opmaaktaal

Fuzzillogic schreef op donderdag 12 april 2007 @ 19:32:
Hmm, Mozilla, Opera en Appleg gooien zich in de strijd voor HTML5. De HTML design principles die daar vermeld staan stellen mij toch echt teleur. Ze zijn écht behoudend daar, terwijl ze nú de kans zouden hebben om eens een frisse wind te laten waaien. HTML5 is inderdaad de opvolger van HTML4, terwijl het web m.i. iets echt nieuws goed zou kunnen gebruiken. Ik durf zelfs te stellen dat HTML5 een laffe upgrade wordt. Na TIEN jaar zou er toch wel iets meer vooruitgang geboekt mogen worden.

Dit vooruitzicht maakt voor mij het vak 'web developer' steeds minder aantrekkelijk.

Ik denk niet dat je dat 'laf' moet noemen, eerder realistisch...
Heb je de WA1.0 en WF2.0 specificaties ueberhaupt al eens doorgelezen?

[Fuzzillogic]

crisp schreef op donderdag 12 april 2007 @ 19:43:
[...]

Tsja, het XHTML-fiasco zou je natuurlijk ook ergens anders aan kunnen toeschrijven: misschien is XML wel helemaal niet zo geschikt als basis voor een opmaaktaal

Echt een wereld van verschil ja, XHTML 1.1 en HTML4.0 strict

Ik denk niet dat je dat 'laf' moet noemen, eerder realistisch...
Heb je de WA1.0 en WF2.0 specificaties ueberhaupt al eens doorgelezen?

Ja en zoals gezegd was ik niet echt onder de indruk. Natuurlijk worden er broodnodige zaken toegevoegd, but there's still much to be desired. Wat ik ook al zovaak gezegd heb is dat bepaalde zaken die veel voorkomen in GUI's van applicaties ontbreken. Knoppenbalken, split panes, menu's, panels, tabbladen, dialogen... Je kunt ze natuurlijk allemaal namaken, dat kan nu ook, maar het is omslachtig en werkt vaak 'net niet lekker'. En ja, dat soort zaken horen m.i. ook niet thuis in een taal die gericht is op documenten en formulieren, maar daarvoor is er juist XML met namespaces. Dus ik snap het "applications"-gedeelte van WA 1.0 niet.

Van wat ik met een half oog heb gezien doet XUL het best leuk. Firefox is notabene zelf een XUL-app, en je kunt het prima mixen met HTML. Een nadeel is nog de programmeertaal, Javascript..

[crisp]

Fuzzillogic schreef op donderdag 12 april 2007 @ 20:43:
[...]

Echt een wereld van verschil ja, XHTML 1.1 en HTML4.0 strict

Ik doelde uiteraard op de draconische error-handling van X(HT)ML...

[...]

Ja en zoals gezegd was ik niet echt onder de indruk. Natuurlijk worden er broodnodige zaken toegevoegd, but there's still much to be desired. Wat ik ook al zovaak gezegd heb is dat bepaalde zaken die veel voorkomen in GUI's van applicaties ontbreken. Knoppenbalken, split panes, menu's, panels, tabbladen, dialogen... Je kunt ze natuurlijk allemaal namaken, dat kan nu ook, maar het is omslachtig en werkt vaak 'net niet lekker'. En ja, dat soort zaken horen m.i. ook niet thuis in een taal die gericht is op documenten en formulieren, maar daarvoor is er juist XML met namespaces. Dus ik snap het "applications"-gedeelte van WA 1.0 niet.

Ik denk dat het meer een kwestie is van first-things-first. Je zal toch eerst de meer fundamentele problemen moeten oplossing voordat je ueberhaupt aan het 'applications' gedeelte kan beginnen. Wellicht dat dergelijke toevoegingen tegen die tijd best wel weer XML-based zullen zijn (de specificatie van HTML5 voorziet immers ook in XML-serialisatie), maar je moet gewoon eerst de basis goed hebben.

Van wat ik met een half oog heb gezien doet XUL het best leuk. Firefox is notabene zelf een XUL-app, en je kunt het prima mixen met HTML. Een nadeel is nog de programmeertaal, Javascript..

Wederom weinig gefundeerd deze opmerking, valt me weer tegen...

[Fuzzillogic]

First things first? Na 10 jaar? Dan kunnen we ook best nog een jaartje extra wachten. Gezien de huidige trend van webapplicaties lijkt me dat een application markup language toch best wel behoorlijk fundamenteel aan het worden is.

En mijn kritiek op de beperktheid en vaagheid van javascript was toch ook allang duidelijk dacht ik zo.

[crisp]

Fuzzillogic schreef op donderdag 12 april 2007 @ 21:14:
First things first? Na 10 jaar?

Tsja, als het W3C nou niet al die tijd en energie had gestoken in een incompatible technologie dan had het er nu misschien wel allemaal anders uitgezien (als MS in die tijd tenminste niet ook op hun gat waren blijven zitten met IE)...

Dan kunnen we ook best nog een jaartje extra wachten. Gezien de huidige trend van webapplicaties lijkt me dat een application markup language toch best wel behoorlijk fundamenteel aan het worden is.

Ik denk dat je daarom ook sneller aan de slag kan door voort te bouwen op iets wat er al is en dat op een backwards-compatible manier te doen. Ik denk dat je dan binnen een paar jaar wel support in alle main-browsers kan verwachten (vermits alle vendors ook echt meewerken), terwijl dat bij een compleet nieuwe technologie misschien nog wel 10 jaar kan duren...

En mijn kritiek op de beperktheid en vaagheid van javascript was toch ook allang duidelijk dacht ik zo.

Die kritiek was overduidelijk puur een mening die m.i. niet echt gestoelt was op echte ervaring met de taal zelf. Javascript is op veel punten afwijkend van andere talen, maar dat maakt het imo niet slecht, enkel anders, en ja - dat kost wat extra tijd om aan te wennen.
Overigens moet je een taal ook niet afrekenen op (soms brakke) implementaties en slecht doordachte interfaces (ja, dan doel ik vnl op IE's JScript). Je hebt enerszijds de taal: noem het 'Core javascript' (volgens de ECMA specificatie) en anderszijds de browserimplementaties met verschillende interfaces (DOM, XMLHttpRequest etcetera). Op beide vlakken is er al veel verbeterd maar blijven sommige browsers nogal achter qua implementatie...

Ook op dat punt zie je dus dat zelfs voortborduren op bestaande technologieën tijd kost voordat je het op grote schaal (mainstream) kan gaan toepassen. Als daar ook iets compleet anders voor in de plaats zou moeten gaan komen dan hoef ik in ieder geval niet meer bang te zijn dat ik me voor mijn pensioen nog moet laten omscholen

[Fuzzillogic]

"Anders" hoeft idd niet "slecht" te zijn, maar "anders" is in dit geval gewoon "krom". Bananen, ja die moeten krom zijn. En hoepels.

De moeite die nu in HTML5 wordt gestoken, waarin krampachtig geprobeerd wordt backwards én forwards compatible te blijven had beter ergens anders in gestoken kunnen worden.

Face it, sites die gebruik gaan maken van WA1.0 zullen gewoon niet werken in IE6/7. Niet omdat dat niet zou kunnen, maar bedenk dit: accessibility is helaas tegenwoordig al een weinig gebruikte feature van HTML4. Graceful degrading "web 2.0" websites moet je met een lampje zoeken. Ik vind het juist niet echt reeel om te veronderstellen dat men dat met HTML5 wel gaat doen.

Daarmee wil ik zeggen dat het handhaven van de compatibiliteit maar beperkt nuttig zal zijn.

[crisp]

Fuzzillogic schreef op vrijdag 13 april 2007 @ 01:04:
"Anders" hoeft idd niet "slecht" te zijn, maar "anders" is in dit geval gewoon "krom". Bananen, ja die moeten krom zijn. En hoepels.

Like I said: dat is jouw mening, maar echt overtuigende argumentatie heb ik nog niet gezien...

De moeite die nu in HTML5 wordt gestoken, waarin krampachtig geprobeerd wordt backwards én forwards compatible te blijven had beter ergens anders in gestoken kunnen worden.

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

Face it, sites die gebruik gaan maken van WA1.0 zullen gewoon niet werken in IE6/7. Niet omdat dat niet zou kunnen, maar bedenk dit: accessibility is helaas tegenwoordig al een weinig gebruikte feature van HTML4. Graceful degrading "web 2.0" websites moet je met een lampje zoeken. Ik vind het juist niet echt reeel om te veronderstellen dat men dat met HTML5 wel gaat doen.

Ten eerste zijn browsers als IE6/7 tegen de tijd dat HTML5 mogelijk een recommendation wordt zo stoffig dat geen hond ze meer gebruikt en ten tweede is juist 1 van de doelstellingen van WA1.0 om te specificeren hoe huidige browsers omgaan met de huidige content op het web. Dat laatste bevorderd interoperability en daarmee dus ook toegankelijkheid - browservendors hoeven immers IE's behavior dan niet meer te reverse-engineeren.

Daarmee wil ik zeggen dat het handhaven van de compatibiliteit maar beperkt nuttig zal zijn.

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.

[Fuzzillogic]

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.

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.

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.

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.

[crisp]

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

Maar dat is jouw mening.

Nee, dat is mijn ervaring

[...]

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?

[...]

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.

[...]

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.

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?

[Fuzzillogic]

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.

[crisp]

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.

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.

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

[Fuzzillogic]

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.

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.

[crisp]

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.

[...]

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?

[ Voor 7% gewijzigd door crisp op 13-04-2007 13:51 ]

[:murb:]

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.

[crisp]

: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.

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.

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.

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

Waar doel je hier op?

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.

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.

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?

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.

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.

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

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.

[Fuzzillogic]

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)

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.

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.

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.

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.

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.

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.

[crisp]

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.

[...]

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.

[...]

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.

[...]

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

[...]

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.

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.

[...]

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.

[...]

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'.

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

[Fuzzillogic]

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

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.

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

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.

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.

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)

[:murb:]

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

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.

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.

[Superdeboer]

: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.

[chris]

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!

[Superdeboer]

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.

[crisp]

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?

[...]

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.

[...]

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

[...]

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

[...]

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

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.

[...]

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.

[crisp]

: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

[...]

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.

[...]

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.

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

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.

[crisp]

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

[Superdeboer]

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.

[crisp]

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

[Marcj]

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)

[ Voor 3% gewijzigd door Marcj op 16-04-2007 01:35 ]

[We Are Borg]

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?

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?

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

[ Voor 14% gewijzigd door We Are Borg op 16-04-2007 04:32 ]

[Guru Evi]

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.

[We Are Borg]

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

[Marcj]

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.

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

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

[...]
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.