HTML: keep the legacy of toch naar XHTML?

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.

quote:

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

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

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

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

DOT wijzigde dit bericht 25-04-2007 02:02 (8%)

quote:

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

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

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

quote:

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

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

quote:

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

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

quote:

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

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

quote:

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

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

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

quote:

[...]

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

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

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

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

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

quote:

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

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

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

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

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

quote:

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

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

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

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.

Beter kijken

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

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

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

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

GS2K1 wijzigde dit bericht 26-04-2007 10:26 (15%)

quote:

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

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

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

quote:

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

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

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

quote:

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

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

quote:

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

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

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

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

quote:

Weird Hobbes schreef op donderdag 26 april 2007 @ 10:40:
[...]

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

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

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

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

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

Fuzzillogic wijzigde dit bericht 26-04-2007 12:15 (9%)

quote:

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

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