HTML: keep the legacy of toch naar XHTML?

@superdeboer: misschien is internet groot geworden door gepruts en jatwerk, maar ik ben van mening dat dat allang niet meer opgaat. Tante Bep gebruikt nu Word op een """webpagina""" te maken. En het is dan de taak van Word om er fatsoenlijke HTML van te brouwen.

Het veel gebruikte argument hier dat ook tante Bep een pagina voor de poes moet kunnen maken vind ik prima, maar tante Bep gaat tegenwoordig echt niet meer zelf in de HTML lopen rommelen. Daar geloof ik echt helemaal niets van.

quote:

Alex) schreef op vrijdag 20 april 2007 @ 01:20:
Wat is er mis met de huidige HTML-namespace uitbreiden? Waarom zou je een compleet nieuwe standaard moeten maken voor iets wat al een goede basis heeft?

Met HTML kun je prima dingen vormgeven, alleen zijn er wat hiaten ja. Maar waarom zou je die niet wegwerken met een nieuwe versie met een compleet andere syntax?

Precies. XML is al een bestaande techniek die zich ruimschoots bewezen heeft, compleet met namespaces en al. Kant-en-klaar. Kun je zo gebruiken.

Maar goed, afgezien van XML, zelfs het concept namespaces willen ze blijkbaar niet gebruiken in HTML5. En ze vergeten dus gemakshalve maar even een Application Markup Language. En dan noemen ze het het WebApplications 1.0 platform?

quote:

Fuzzillogic schreef op vrijdag 20 april 2007 @ 00:58:
[...]

Ik zou C ook liever vergeten ja, maar helaas. Toch hindert mij dat niet met bijv. Java.

toch jammer voor jou dan dat de wereld niet enkel en puur java is

quote:

[...]

Nee, want bijv. IE maakt er doodleuk dit van:
code:

P
    TABLE
        TBODY
            TR
                TD
                    #text

IE is dan ook een slecht voorbeeld want niet standards-compliant op dit punt (ook een reden waarom HTML5 <table> binnen <p> wel wil toestaan - teveel content die daar vanuit gaat)

quote:

[...]

Oh? In dat geval zou er geen probleem zijn geweest. Maar dat was er toch. Rara.

Hmmz, IE lijkt het wel te ondersteunen zonder puntkomma, rare jongens daar bij MS

quote:

[...]

Dat soort dingen kun je prima oplossen met een nieuwe specificatie die geen last heeft van dergelijke legacy-meuk.

En legacy-meuk dan maar laten wegrotten omdat nieuwe browsers met een nieuwe implementatie van de spec het niet meer ondersteunen? (ja, ik blijf dit punt aanhalen)

quote:

[...]

Ze hebben het tag/boom-principe van SGML genomen en van de rest gedacht: ok deze meuk is niet te handhaven en maakt het nodeloos complex. WEG ERMEE. As I said before: er is een reden dat XML populair is geworden ten koste van SGML. De eenduidige en eenvoudige structuur maakt dat software eenvoudig kan blijven, dat maakt dat er veel software voor is.

XML is ook prima als data-formaat, hoewel het in sommige gevallen wel erg verbose is.

quote:

Het zou me dan ook niet verbazen als de huidige complexiteit die een browser moet bezitten om ueberhaupt een HTML webpagina weer te geven dan ook de reden is dat er eigenlijk maar een handje vol browsers zijn. Ik kan meer operating systems van belang opnoemen dan browsers. Teken aan de wand? Ik denk het wel.

Ik kom op het volgende rijtje (en dan kijk ik alleen naar render-engines):

- Trident (IE)
- Gecko (Mozilla, Firefox)
- WebKit (Safari)
- KHTML (Konqueror)
- Merlin (Opera)

Qua operating systems die echt van belang zijn kom ik niet echt verder dan dit aantal hoor...

quote:

[...]

Thin line in dit geval. colspan=2 is een syntax error, maar met een wat meer vergevingsgezinde parser opeens enkel nog een conformance error.

uhm, HTML behoeft geen quotes om dergelijke attribute-values en verder is colspan een valid attribute - helemaal geen error dus...

quote:

[...]

Ach weet je, het zou nog niet eens zo'n probleem zijn om bijv XHTML 1.1 met wat uitbreidingen op te nemen als namespace voor text-documents. Wat mij met name stoort is het totale gebrek aan specifieke support voor webapplicaties, qua GUI, in HTML5. En dat ze uitbreidingen aan de forms ook weer allemaal in de HTML-namespace flikkeren.

Qua GUI-mogelijkheden moet je toch echt support hebben van browser-vendors. Overigens biedt XHTML2 ook niets extra's op dat gebied. Namespace-sharing-fobie is ook weer zo'n XML-trekje - wanneer is dat wel geoorloofd en wanneer niet? Mijn zoon is geadopteerd maar deelt wel mijn namespace - mag dat?

quote:

Ook Rome is niet in 1 dag gebouwd. Maar als de browser support bieden voor een next-gen iets, dan komen de content providers wel heel snel met toepassingen. Kijk maar al eens naar de enorme verscheidenheid van extensies voor Firefox/Thunderbird (XUL), en dat is dan nog maar een relatief klein platform.

Rome is ook niet in 1 dag platgebrand...

Ik zie echt het nut niet van XML voor de GUI van een webapplicatie. Voor mij is XML puur een data-uitwisselingsformaat, niet een opmaakformaat. Daarvoor is HTML meer bedoeld, vind ik.

XML = data (en zou dus eigenlijk XDL of DEF ofzo moeten heten) en HTML = opmaak. En je kunt ze allebei prima uitbreiden, maar ga ze alsjeblieft niet mengen. Dat levert zo'n zooi op voor webbrowsermakers: ze moeten meer ondersteunen (XHTML <> HTML) wat vanzelf tot inconsistenties leidt.

Een parse error in een opmaaktaal is vervelend (teveel dikgedrukte tekst) maar het is niet anders. Kan gebeuren. Met een parse-error in een datataal zit het anders: daar kan dan de juistheid van de data niet worden gecontroleerd, dus dan is draconic error-handling wél belangrijk. Maar in een opmaaktaal? Alsjeblieft zeg...

quote:

Fuzzillogic schreef op vrijdag 20 april 2007 @ 01:34:
@superdeboer: misschien is internet groot geworden door gepruts en jatwerk, maar ik ben van mening dat dat allang niet meer opgaat.

Ik denk toch dat dat nog steeds opgaat: het leeuwendeel van de 'professionele' webdevelopers zijn nog steeds copy/paste cowboys zonder enige clue ...

quote:

Tante Bep gebruikt nu Word op een """webpagina""" te maken. En het is dan de taak van Word om er fatsoenlijke HTML van te brouwen.

O really?

quote:

Het veel gebruikte argument hier dat ook tante Bep een pagina voor de poes moet kunnen maken vind ik prima, maar tante Bep gaat tegenwoordig echt niet meer zelf in de HTML lopen rommelen. Daar geloof ik echt helemaal niets van.

Waarschijnijk doet ze dat niet nee, tenzij ze zichzelf er wat verder in verdiept en tot de ontdekking komt dat authoring-tools heden ten dage niet zaligmakend zijn...

quote:

[...]

Precies. XML is al een bestaande techniek die zich ruimschoots bewezen heeft, compleet met namespaces en al. Kant-en-klaar. Kun je zo gebruiken.

Bewezen grotendeels incompatible te zijn met het huidige internet ja; tegenwoordig zijn er zelfs RSS-feedreaders die maar error-correction toepassen...

quote:

Maar goed, afgezien van XML, zelfs het concept namespaces willen ze blijkbaar niet gebruiken in HTML5. En ze vergeten dus gemakshalve maar even een Application Markup Language. En dan noemen ze het het WebApplications 1.0 platform?

Tsja, jij hebt blijkbaar betere ideeën, dus snap ik niet waarom je hier op het forum blijft rondhangen
mailing-list

quote:

Superdeboer schreef op vrijdag 20 april 2007 @ 01:19:
[...]

Juist, en de doodsteek voor XHTML als application/xml+xhtml is die verrekte draconische foutafhandeling. Daar is hier in dit topic al erg veel over gezegd, maar ik wil er graag mijn visie aan toevoegen.

[...]

En ik kan niets anders zeggen dan dat dit volledig aansluit op mijn visie: het internet is openbaar en dient dus zo toegankelijk mogelijk te blijven, nu en in de toekomst...

Met het risico om allemaal dingen te zeggen die al verteld zijn, ik zou het prettig vinden als er in de toekomstige browserwereld wat meer browser-gerenderde (en dus user-themable!) GUI-elementen zouden kunnen komen voor webapps. Ik mis sliders, tabs, menu's, toolbars, frames, tabellen. Ik denk eigenlijk ook dat die widgets beter kunnen worden gecreëerd met javascript, omdat je in webapps toch meestal al met javascript bezig bent voor de afhandeling van events van diezelfde widgets. Vervolgens kan je XML, of wat voor structuur je maar wilt gebruiken voor data-uitwisseling.

Voor simpelere sites zoals we ze nu kennen met gewoon content+links kan dan HTML4.02 worden gebruikt, waarin alle verbeteringen zitten voor HTML die niets te maken hebben met dingen die nodig zijn voor "het web als applicatie-platform". Ik weet niet wat ze nog zouden willen verbeteren aan HTML als hypertext document-taal.

Als er een duidelijke scheiding komt tussen "Web1.5"-sites zoals we ze nu kennen, en een full-blown applicatie-taal gebaseerd op javascript met user-themable widgets, dan krijg je "echte" applicaties. Die applicaties integreren dan ook in ieders desktop-omgeving, of het nu Ubuntu, OSX, of Windows is.

Misschien nog een sterkere speculatie: wat als die webapps ook rootless kunnen gaan draaien! Dan krijg je heel simpel te bouwen server/client-software.

DOT wijzigde dit bericht 20-04-2007 03:27 (20%)

Wat zijn eigenlijk (realistisch) de te verwachten ontwikkelingen als je kijkt naar user agents?
Opera 9 ondersteund Event Streaming en ik verwacht eigenlijk redelijk gelijke implementaties van andere vendors.

Zijn er meer initiatieven op redelijke korte termijn te verwachten?

quote:

orf schreef op vrijdag 20 april 2007 @ 08:19:
Wat zijn eigenlijk (realistisch) de te verwachten ontwikkelingen als je kijkt naar user agents?
Opera 9 ondersteund Event Streaming en ik verwacht eigenlijk redelijk gelijke implementaties van andere vendors.

Zijn er meer initiatieven op redelijke korte termijn te verwachten?

Sommige initiatieven hoef je niet op te wachten hoor, Firefox ondersteund nu al bijvoorbeeld Javascript 1.7 en voor versie 3 staat Javascript 2.0 op de planning.
Opera ondersteund tegenwoordig ook WebForms 2.0 en verschillende vendors hebben al delen van WA 1.0 geimplementeerd w.o. <canvas>

Ik ben overigens behoorlijk sceptisch geworden omtrent de gang van zaken in de HTML WG. Er is wel behoorlijk wat support voor het adopteren van WA 1.0 als uitgangspunt, maar Chris Wilson (in naam van Microsoft) zit al behoorlijk dwars. Ik begin me ook af te vragen in hoeverre deze WG eigenlijk deels bestaat uit 'gesponserde deelnemers'.

Het gevaar bestaat dat MS straks via deze WG alsnog de 'browser-wars' voor zich probeert te winnen door het de competitie nagenoeg onmogelijk te maken de specificatie op dezelfde manier te implementeren als MS dat wil gaan doen...

quote:

crisp schreef op dinsdag 24 april 2007 @ 00:44:
Ik ben overigens behoorlijk sceptisch geworden omtrent de gang van zaken in de HTML WG. Er is wel behoorlijk wat support voor het adopteren van WA 1.0 als uitgangspunt, maar Chris Wilson (in naam van Microsoft) zit al behoorlijk dwars. Ik begin me ook af te vragen in hoeverre deze WG eigenlijk deels bestaat uit 'gesponserde deelnemers'.

Het gevaar bestaat dat MS straks via deze WG alsnog de 'browser-wars' voor zich probeert te winnen door het de competitie nagenoeg onmogelijk te maken de specificatie op dezelfde manier te implementeren als MS dat wil gaan doen...

Chris Wilson zorgt er op deze manier ook voor dat HTML 5 toch wel verder naar achteren geschoven wordt.
Microsoft moet vanaf scratch beginnen eigenlijk. Gewoon IE.next de legacy breken met een compleet nieuwe complient engine, want wat ik begrijp is het toch "het breken van het verleden" waar ze bij MS te bang voor zijn toch?

quote:

Alex) schreef op vrijdag 20 april 2007 @ 01:40:
Ik zie echt het nut niet van XML voor de GUI van een webapplicatie. Voor mij is XML puur een data-uitwisselingsformaat, niet een opmaakformaat. Daarvoor is HTML meer bedoeld, vind ik.

Er zijn heel veel potentiele voordelen voor het gebruiken van een XML-gebaseerde taal voor het definieren van een GUI. Een GUI is vaak een hierarchische structuur van variaties op standaard UI-componenten. XML is met z'n tags en attributes wat mij betreft ideaal om zo'n structuur te definieren. Het is niet voor niets dat Backbase, Adobe, Mozilla en Microsoft allemaal die richting op zijn gegaan.

quote:

Alex) schreef op vrijdag 20 april 2007 @ 01:40:
Ik zie echt het nut niet van XML voor de GUI van een webapplicatie. Voor mij is XML puur een data-uitwisselingsformaat, niet een opmaakformaat. Daarvoor is HTML meer bedoeld, vind ik.

Je kunt met XML dan ook geen GUI voor een webapplicatie maken. Je kunt wellicht gebruik maken van een formaat dat gebouwd is op XML om GUI's mee voor te geven. XUL bijvoorbeeld.

HTML is overigens ook geen taal op GUI's mee te bouwen, HTML is een specificatie gebaseerd op SGML, wederom om data mee op te maken.

quote:

XML = data

XML is een opmaaktaal. Wat je er mee opmaakt is geheel aan jou.

quote:

En je kunt ze allebei prima uitbreiden, maar ga ze alsjeblieft niet mengen.

XHTML is XML... Dat is geen kwestie van mengen, je zit al in XML te werken.

quote:

Een parse error in een opmaaktaal is vervelend (teveel dikgedrukte tekst) maar het is niet anders. Kan gebeuren. Met een parse-error in een datataal zit het anders: daar kan dan de juistheid van de data niet worden gecontroleerd, dus dan is draconic error-handling wél belangrijk. Maar in een opmaaktaal? Alsjeblieft zeg...

HTML is een datataal. Semantiek enzo? Je omschrijft je data.

quote:

crisp schreef op vrijdag 20 april 2007 @ 01:36:
En legacy-meuk dan maar laten wegrotten omdat nieuwe browsers met een nieuwe implementatie van de spec het niet meer ondersteunen? (ja, ik blijf dit punt aanhalen)

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

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

Zr40 wijzigde dit bericht 24-04-2007 12:45 (0%)
Reden: [url] verwijderd - React maakt er http:// van

quote:

King_Louie schreef op dinsdag 24 april 2007 @ 11:46:
XML is een opmaaktaal. Wat je er mee opmaakt is geheel aan jou.
[...]
HTML is een datataal. Semantiek enzo? Je omschrijft je data.

Helaas, je hebt het verkeerd om.

XML beschrijft data, die je eventueel met XSLT kan opmaken.
HTML beschrijft al opgemaakte data. Wil je daar toch data uit halen, moet je (er van uit gaande dat de opmaak niet verandert) weten wat er op welke manier opgemaakt is.

Zr40 wijzigde dit bericht 24-04-2007 12:49 (13%)

quote:

GS2K1 schreef op dinsdag 24 april 2007 @ 09:33:
[...]
Microsoft moet vanaf scratch beginnen eigenlijk. Gewoon IE.next de legacy breken met een compleet nieuwe complient engine, want wat ik begrijp is het toch "het breken van het verleden" waar ze bij MS te bang voor zijn toch?

Microsoft zou gewoon Opera ofzo moeten kopen. Hebben ze een goede standard compliant, razendsnelle engine. En Trident laat je ouwe HTML meuk renderen. De engine van Opera is vrij klein, dus volgens mij zou het prima moeten kunnen.

quote:

PolarBear schreef op dinsdag 24 april 2007 @ 12:45:
[...]


Microsoft zou gewoon Opera ofzo moeten kopen. Hebben ze een goede standard compliant, razendsnelle engine. En Trident laat je ouwe HTML meuk renderen. De engine van Opera is vrij klein, dus volgens mij zou het prima moeten kunnen.

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.

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.

HTML:

1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Dit geeft toch duidelijk aan dat 'HTML 4.01 Strict' gebruikt is

quote:

Zr40 schreef op dinsdag 24 april 2007 @ 13:03:
[...]
HTML:

1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Dit geeft toch duidelijk aan dat 'HTML 4.01 Strict' gebruikt is

ja dus?
dit wil niet zeggen dat alle websites die dit niet hebben maar direct met de oude engine gerenderd moeten worden.

Sterker nog, ik ken websites met een super foutieve inhoud waar dat doctype boven staat. Deze zien er soms in IE zelfs prachtig uit.
Als je die renderd met een nieuwe engine (bijv opera engine, zoals jij voorstelde) dan zien ze er echt niet uit hoor.

andersom ook, je krijgt dan mensen die (net als nu) een website bouwen die het alleen voor IE doet, omdat ze geen doctype er boven zetten, en daardoor IE met zijn oude engine de site foutief renderd.

Als mensen willen dat een site werkt in zowel IE als complient browsers, dan krijgen ze dit nu echt wel voor elkaar. Echter is het probleem dat ze voor IE een berg hax moeten toepassen (of functionaltieit missen etc.)

Wanneer je IE 2 engines geeft, en ik wil lekker mijn site bouwen in html transitional, en IE besluit vervolgens dit met de oude engine te renderen schiet ik toch geen klap op?
Transitional is wat vrijer html, maar is nog steeds gebonden aan afspraken.

Als IE al van tevoren zegt 'ow transitional doe ik met oude engine' wat eigenlijk inhoud 'hey transitinal verkloot ik' . Wat is dan het grote nut van die hele standaard?

---

even om het probleem duidelijk te maken (en ja dit gaat dan idd niet meer over xhtml vs html)

probleem:
een groot deel van de sites die op het moment op internet staan voldoen niet aan welke standaard dan ook, maar zien er goed uit in IE.
IE weigerd standaarden te gebruiken, waardoor niemand deze sites in orde maakt. Dit geeft weer fouten in complient browsers

oplossing:
IE zijn engine laten updaten, zodat deze aan afspraken voldoet, zodat de webmasters gedwongen worden zich aan dezelfde standaarden te houden


IE voorzien van 2 engines lost niets op, omdat de oude websites dan hun code niet hoeven te wijzigen, en de complient browsers dus nog steeds foutieve code moeten zitten parsen. (wat uiteraard wel eens mis gaat)

quote:

King_Louie schreef op dinsdag 24 april 2007 @ 11:46:
...HTML is een specificatie gebaseerd op SGML....

xml ook

BasieP wijzigde dit bericht 24-04-2007 13:19 (22%)

Tja, transitional is deprecated meuk. Dat kan je dan het beste renderen met de deprecated render-engine. Strict is dan gewoon de simpelste manier om je site perfect cross-browser te laten werken. Strict is ook altijd de "huidige" html. Het is de html waarin je nieuwe documenten schrijft. Transitional is voor de transitie van deprecated naar nieuw.

En ik snap echt niet waarom transitional zoveel makkelijker zou moeten zijn dan strict. In veel gevallen komt het neer op <center> versus style="text-align:center".

---

Hoewel... transitional is nog altijd gestandaardiseerde deprecated meuk. Deze standaard-regels kunnen goed gerenderd worden door alle compliant render-engines.

Maar zodra de browser in 'quirks-mode' gaat, kan de oude render-engine gebruikt worden, aangezien die engine die sites 'goed' zal renderen.

DOT wijzigde dit bericht 24-04-2007 13:24 (23%)

quote:

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

ja dus?
dit wil niet zeggen dat alle websites die dit niet hebben maar direct met de oude engine gerenderd moeten worden.

Sterker nog, ik ken websites met een super foutieve inhoud waar dat doctype boven staat. Deze zien er soms in IE zelfs prachtig uit.
Als je die renderd met een nieuwe engine (bijv opera engine, zoals jij voorstelde) dan zien ze er echt niet uit hoor.

Een verkeerde (of geen) doctype gebruiken is ook vragen om problemen. Nu was dat bij HTML niet zo'n ramp, omdat het allemaal backwards compatible is, maar dit is wel belangrijk nu er andere (en in de toekomst wellicht incompatible) versies zijn.

Ik kan aannemen dat alle HTML die momenteel geschreven wordt een doctype bevat. Is dat niet het geval, dan is de ontwikkelaar in kwestie dom bezig, of is zijn documentatie verouderd. Als verder alle nieuwe documenten doctypes bevatten, is het veilig om aan te nemen dat de doctype-loze documenten 'oud' zijn.

Overigens stelde PolarBear de engine van Opera voor. Ik heb hem slechts gequoted

Als er een doctype boven staat, dan geef je al aan dat je wat meer verstand van zaken hebt (hopelijk). Als je beweert dan je site volgens een bepaald document type is opgebouwd, dan mag IE van mij wel trachten zo veel mogelijk volgens de standaarden te renderen, aangezien je met dat document type ook aangeeft volgens een standaard te werken. Dit gebeurt nu overigens ook al bij het switchen tussen strict en quirks mode in IE.

Overigens kun je met transitional HTML er ook gewoon een doctype boven zetten. Dus ook daarmee kun je dan kiezen tussen de nieuwe en oude meuk, als je het op deze manier oplost.

quote:

Michali schreef op dinsdag 24 april 2007 @ 13:24:
Als er een doctype boven staat, dan geef je al aan dat je wat meer verstand van zaken hebt (hopelijk). Als je beweert dan je site volgens een bepaald document type is opgebouwd, dan mag IE van mij wel trachten zo veel mogelijk volgens de standaarden te renderen, aangezien je met dat document type ook aangeeft volgens een standaard te werken. Dit gebeurt nu overigens ook al bij het switchen tussen strict en quirks mode in IE.

Overigens kun je met transitional HTML er ook gewoon een doctype boven zetten. Dus ook daarmee kun je dan kiezen tussen de nieuwe en oude meuk, als je het op deze manier oplost.

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

dat is ongeveer mijn punt..

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?

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.

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

BasieP wijzigde dit bericht 24-04-2007 13:42 (17%)

quote:

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

Helaas, je hebt het verkeerd om.

XML beschrijft data, die je eventueel met XSLT kan opmaken.

Nee, met XSLT kun je het in een ander jasje gieten.

quote:

HTML beschrijft al opgemaakte data. Wil je daar toch data uit halen, moet je (er van uit gaande dat de opmaak niet verandert) weten wat er op welke manier opgemaakt is.

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.

quote:

BasieP schreef op dinsdag 24 april 2007 @ 13:11:
xml ook

Joh? Ik vond ze al op elkaar lijken! Met die < en >...

Er moet in mijn ogen iets gebeuren, waardoor het internet langzaam die tagsoep-websites kwijtraakt. Want op deze manier blijven die ranzige pagina's bestaan, en nog veel erger: komen er elke dag nieuwe gedrochten bij.

Ongeacht of er nu voor HTML5 gekozen wordt, of toch voor een XHTML, dat maakt me nog niet eens zo ontzettend veel uit. Wat ik belangrijker vind, is dat er een spec komt die door elke browser precies het zelfde gerenderd wordt.

Ik vind dat als er een DocType boven een document staat, je er van uit mag gaan dat de inhoud ook volgens die spec gemaakt is. En dus vind ik dat een website gemaakt in HTML4 Trans. met een HTML5 DocType "stuk" mag gaan in de nieuwe browsers.

Een probleem is wel hoe een browser moet omgaan met fouten in de opmaak. Ik zou het liefst willen dat een pagina niet werkt als er een fout in zit; puur om zo eindelijk eens "goede" websites te krijgen, helaas is dit totaal niet rëeel.

quote:

OkkE schreef op dinsdag 24 april 2007 @ 14:03:
Ik vind dat als er een DocType boven een document staat, je er van uit mag gaan dat de inhoud ook volgens die spec gemaakt is. En dus vind ik dat een website gemaakt in HTML4 Trans. met een HTML5 DocType "stuk" mag gaan in de nieuwe browsers.

*kuch* backwards compatibility *kuch*