HTML: keep the legacy of toch naar XHTML?

quote:

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

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

dat is ongeveer mijn punt..

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

quote:

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

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

quote:

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

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

quote:

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

helaas denken ze er bij MS alleen wat anders over

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

quote:

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

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

Hoe weet je dat het volgende over fruit gaat?
HTML:

1 2 3 4 5

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

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

1 2 3 4 5 6 7 8 9 10

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

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

quote:

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

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

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

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


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

Michali wijzigde dit bericht 24-04-2007 14:39 (20%)

quote:

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

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

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

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

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

quote:

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


Hoe weet je dat het volgende over fruit gaat?

HTML:

1 2 3 4 5

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

quote:

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

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

quote:

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

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

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

quote:

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


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

daar ben ik het idd helemaal mee eens

quote:

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

1 2 3 4 5

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

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

quote:

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


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

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

quote:

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


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

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

quote:

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

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

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

quote:

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

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

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

quote:

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

Nee, dataverwerkende applicaties zijn geen user agents.

quote:

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

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

Lees voor de gein ook eens A Touch of Class

quote:

Nee, dataverwerkende applicaties zijn geen user agents.

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

Victor wijzigde dit bericht 24-04-2007 19:11 (10%)

quote:

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

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

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

quote:

Lees voor de gein ook eens A Touch of Class

Dat geeft toevallig precies aan wat ik bedoel.

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

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

quote:

[...]

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

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

quote:

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

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

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

For general purpose processing by user agents

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

quote:

Dat geeft toevallig precies aan wat ik bedoel.

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

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

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

Om maar even een voorbeeld uit dat artikel te gebruiken:
HTML:

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

XML:

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

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

quote:

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

Niet valide HTML documenten valideren ook niet hoor..?

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

quote:

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

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

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

in xhtml gebruik je net zo goed
HTML:

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

dus wat voegt xhtml toe aan html op dat vlak?

quote:

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

Wat is XHTML dan wel volgens jou?

quote:

in xhtml gebruik je net zo goed
HTML:

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

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

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

Victor wijzigde dit bericht 24-04-2007 21:05 (6%)

quote:

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

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

quote:

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

Om maar even een voorbeeld uit dat artikel te gebruiken:
HTML:

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

XML:

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

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

[...]

Niet valide HTML documenten valideren ook niet hoor..?

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

quote:

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

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

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

quote:

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

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

quote:

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

in xhtml gebruik je net zo goed
HTML:

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

dus wat voegt xhtml toe aan html op dat vlak?

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

quote:

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

Elementen zijn data.

Nee, elementen bevatten en omschrijven data.

quote:

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

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

quote:

Oftewel, in HTML is de opmaak data.

Nee dus.

quote:

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

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

quote:

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

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

quote:

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

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

quote:

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

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

quote:

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

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

quote:

[...]

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

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

quote:

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

Mooi zo.

quote:

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

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

quote:

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

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

quote:

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

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

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

quote:

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

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

quote:

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

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

quote:

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

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

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

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

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

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

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

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

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

quote:

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

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

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

quote:

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

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

quote:

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

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

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

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

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

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

quote:

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

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

quote:

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

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

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

quote:

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

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

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

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