HTML: keep the legacy of toch naar XHTML?

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.

BtM909 wijzigde dit bericht 11-04-2007 08:19 (12%)

quote:

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

crisp wijzigde dit bericht 08-04-2007 00:50 (51%)

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

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.

quote:

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.

Nou ja, we waren nu toch al offtopic

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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?

quote:

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

quote:

Welke nieuwe features biedt XHTML1.x boven HTML?

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

Blaise wijzigde dit bericht 08-04-2007 23:30 (41%)

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.

Fuzzillogic wijzigde dit bericht 09-04-2007 00:10 (4%)

quote:

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

quote:

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

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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

quote:

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.

quote:

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

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 .

quote:

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

quote:

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

quote:

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.

quote:

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.

quote:

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?

quote:

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.

quote:

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)

quote:

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

quote:

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.

quote:

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.

quote:

[...]

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.

quote:

[...]

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.

quote:

[...]

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

quote:

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?

quote:

[...]

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.

quote:

[...]

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.

quote:

[...]

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?

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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

quote:

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?

quote:

[...]

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

quote:

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.

quote:

[...]

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.

quote:

[...]

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

quote:

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.

quote:

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

crisp wijzigde dit bericht 10-04-2007 11:05 (6%)

Afgesplitst vanuit [xHTML] rare fout in IE 7

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.

quote:

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"

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.

quote:

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

quote:

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

quote:

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

quote:

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

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

[...]

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

quote:

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?

quote:

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.

quote:

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

quote:

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

quote:

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)

quote:

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:

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

WebForms 2.0

quote:

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.

quote:

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.

Not Pingu wijzigde dit bericht 10-04-2007 23:05 (16%)