[html/alg] XHTML als text/html, wat is het? *

[Verwijderd]

oikoyama schreef op zondag 17 april 2005 @ 14:00:

Praktijkproblemen: http://www.hixie.ch/advocacy/xhtml
(hoewel ik hierbij de kanttekening moet maken dat je met de juiste kennis wel veel (aldan niet alle) problemen kunt voorkomen, maar in veel gevallen gebeurt dit niet...)

Dat is dus een van de problemen. Ian Hickson maakt problemen waar ze niet zijn.

Uiteraard, je bent vrij in je keuze en je mag doen en laten wat je niet wilt. Maar de grote vraag van "die mensen die over SGML parsers beginnen" is waarom je iets maakt wat helemaal niet zo gebruikt wordt? Gebruik je eigenlijk wel XHTML functies? Wat is jouw grote reden om XHTML boven HTML te verkiezen terwijl je documenten nog steeds als HTML behandeld worden? Vind je jezelf niet een beetje onnodig moeilijk doen? (ik zie net in de tijd dat ik mijn bericht aan het tikken ben, dat We Are Borg het zelfde denkt )

Wat versta jij onder XHTML functies?

Ik gebruik het onder meer om de zeer duidelijke syntax die je voor jezelf afdwingt. Bij XHTML 1.0 haal je sneller problemen uit je code dan bij HTML 4.01. Als er ergens een <td> staat zonder bijbehorende </td> is er bijvoorbeeld iets mis in de achterliggende logica van een server-side script. Er zijn geen enorme voordelen, maar ook geen enorme nadelen.

En nee, ik doe niet onnodig moeilijk, want het kost me niet meer tijd of moeite om een site XHTML 1.0 Strict compliant te maken dan om een site HTML 4.01 Strict compliant te maken.

Verder is er denk ik nog een ander probleem: mensen die met XHTML werken willen wel eens denken dat ze hiermee een goede bijdrage aan het web geven, omdat ze netjes via een standaard werken.
Nou, eerlijk gezegd vind ik malformed HTML versturen eerder het tegenovergestelde!

Wat jij vind kan mij weinig schelen. Ik heb meer bijgedragen aan de vooruitgang van de kennis op dit forum dan jij. Dus wat probeer je nu te bereiken (behalve mensen op de kast jagen)?

[Erkens]

crisp schreef op zondag 17 april 2005 @ 13:57:

[...]

Nee, <br></br> is in HTML hardstikke fout:

[...]

Versus:

[...]

maar het ging hier om XHTML

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

Empty elements must either have an end tag or the start tag must end with />. For instance, <br/> or <hr></hr>.

Uiteraard is het niet aan te raden (en nodig) om dit voor <br> te doen, maar het ging hier om de <script>-tag, waarbij ik dus <br> als voorbeeld aanhaal, dat het wel mag.

[crisp]

Erkens schreef op zondag 17 april 2005 @ 14:33:
[...]
maar het ging hier om XHTML
[...]
Uiteraard is het niet aan te raden (en nodig) om dit voor <br> te doen, maar het ging hier om de <script>-tag, waarbij ik dus <br> als voorbeeld aanhaal, dat het wel mag.

Dat kwam niet helemaal naar voren in je eerdere post
En uiteindelijk demonstreer je hier weer een bekende pitfall; mensen zouden kunnen denken dat <br></br> acceptabel is in XHTML (wat ook zo is) en gaan zich vervolgens afvragen waarom IE het als 2 linebreaks rendered (omdat ze niet doorhebben dat door het sturen als text/html het geen XHTML meer is maar gewoon plain HTML*).

* en dat brengt ons weer op het oorspronkelijke discussiepunt

[Not Pingu]

Verwijderd schreef op zondag 17 april 2005 @ 14:20:

Wat versta jij onder XHTML functies?

Ik gebruik het onder meer om de zeer duidelijke syntax die je voor jezelf afdwingt. Bij XHTML 1.0 haal je sneller problemen uit je code dan bij HTML 4.01. Als er ergens een <td> staat zonder bijbehorende </td> is er bijvoorbeeld iets mis in de achterliggende logica van een server-side script. Er zijn geen enorme voordelen, maar ook geen enorme nadelen.

Waar denk je dat de X voor staat? Veel mensen zien over het hoofd dat XHTML is geintroduceerd met als doel mensen zelf uitbreidingen te laten maken om bijv. custom DHTML controls makkelijker toegankelijk te maken. Dat is waar je XHTML voor moet gebruiken, niet om het afdwingen van stijloefeningen die je met een beetje goede wil en een goeie syntax-highlighter ook gewoon mbv. HTML 4 kunt doen.

[eamelink]

Gunp01nt schreef op zondag 17 april 2005 @ 15:03:
Waar denk je dat de X voor staat? Veel mensen zien over het hoofd dat XHTML is geintroduceerd met als doel mensen zelf uitbreidingen te laten maken om bijv. custom DHTML controls makkelijker toegankelijk te maken.

Die X staat misschien voor eXtended, maar dat betekent zeker niet dat XHTML slechts is ontwikkeld om html te kunnen uitbreiden.

De oorspronkelijke reden was een herformulatie van html 4.01 volgens xml syntax. Niet om html uit te breiden.

Dat is waar je XHTML voor moet gebruiken, niet om het afdwingen van stijloefeningen die je met een beetje goede wil en een goeie syntax-highlighter ook gewoon mbv. HTML 4 kunt doen.

xhtml erft allerlei voordelen van de xml syntax. Het is gemakkelijker te parsen, het is gemakkelijker te transformeren naar andere documenten, en het is wel degelijk zoals Cheatah zegt gemakkelijker om fouten te vinden.

Waarom zou je er géén gebruik van maken? "HTML doet het nog prima" zeg jij, en dat klopt, maar gemak dient de mens toch? Als Cheatah (net als ik), heeft besloten dat voor zijn doelen het gebruik van xhtml voordelen oplevert boven html, waarom zou je dat niet gebruiken?

Wat betreft de mimetypes : volgens het W3c mág je xhtml documenten die als text/html verzenden. Dat sommige browsers het dan niet als xhtml verwerken, tsja, dat is wellicht jammer, maar in de praktijk werkt het wel gewoon.

Dus je voldoet aan de standaarden, het werkt, en je hebt een aantal xml voordelen. Wat wil je nog meer? Ik niets

[Verwijderd]

HTML5 (alsmede de extensie voor XHTML die met deze specificatie gemoeit gaat onder de http://www.w3.org/1999/xhtml) zal uiteindelijk door het W3C erkend worden verwacht ik. Momenteel is Web Forms 2 bij het W3C terechtgekomen ( http://annevankesteren.nl/archives/2005/04/web-forms-2 ) en op de WHATWG mailing lijst was Dean Jackson redelijk positief over verdere samenwerking.

Web Forms 2 is een extensie op HTML4 forms en zal ook onderdeel worden van HTML5. Het zit tevens in XHTML onder de hierboven genoemde namespace. Mozilla is momenteel bezig met een implementatie en ik geloof dat Opera intern ook versies heeft draaien met ondersteuning voor Web Forms 2.

HTML5 is nog niet af, maar uiteindelijk zal daarmee iets soortgelijks gebeuren. Het is IMHO tien keer beter als XHTML2 wat betreft semantics en ook qua specificatie en daarnaast backwards compatible als je de HTML variant gebruikt. (Er zijn wel meer mogelijkheden voor de XHTML variant uiteraard, momenteel XHTML5 genoemd, wat nogal verwarrend klinkt.)

Zoals ik al zei stapt de specificatie af van het idee dat HTML een vorm van SGML is en gaan alle SGML features er ook uit. Waarschijnlijk zal ook wel ergens staan dat <br>, <br/> en <br /> gewoon op dezelfde manier geparst moeten worden in text/html context. Wellicht vereist de specificatie ook lower-case van auteurs en "case-insensitive handling" van elementen door browsers. (text/html error handling.)

Zoals het er nu voor staat zullen iig Mozilla, Opera en Safari het implementeren.

(Wellicht handig om hier een apart topic voor te hebben, kan ik gelijk even een iets duidelijker verhaal neerzetten...)

[Verwijderd]

Waar denk je dat de X voor staat? Veel mensen zien over het hoofd dat XHTML is geintroduceerd met als doel mensen zelf uitbreidingen te laten maken om bijv. custom DHTML controls makkelijker toegankelijk te maken. Dat is waar je XHTML voor moet gebruiken, niet om het afdwingen van stijloefeningen die je met een beetje goede wil en een goeie syntax-highlighter ook gewoon mbv. HTML 4 kunt doen.

XHTML is daarvoor niet echt bedoeld. Dat Alistapart daar leuke artikeltjes over schrijft, ok, maar dat impliciteert niet gelijk bovenstaand verhaal.

Daarnaast heeft het helemaal geen zin. XHTML bestaat om HTML met XML tools te kunnen bewerken en om HTML te kunnen "mixen" met andere XML varianten, zoals MathML of XForms. (SVG zou ook kunnen, maar dat is niet echt een goed voorbeeld vanwege het gebrek aan semantiek.)

Heb je dat allemaal niet nodig kun je net zo goed HTML gebruiken. In HTML kun je ook custom elementjes/attributen toevoegen. (Zie Web Forms 2, dat is grotendeels implementeerbaar met een script voor IE.)

[Verwijderd]

En ik ben van mening dat een XHTML document altijd XHTML blijft ook al serveer je met het verkeerde mime-type. Feit is dan wel dat je dom bezig bent omdat je de verkeerde mime-type gebruilkt. Je geeft iemand toch geen koffie met de boodschap "chocolademelk".

Als je iemand koffie geeft met die boodschap kan de ander nog wel uitvogelen dat het geen koffie is. Met MIME types en documenten zit dat toch wel ietsje complexer in elkaar, anders waren MIME types overbodig geweest.

[Verwijderd]

Ik gebruik het onder meer om de zeer duidelijke syntax die je voor jezelf afdwingt. Bij XHTML 1.0 haal je sneller problemen uit je code dan bij HTML 4.01. Als er ergens een <td> staat zonder bijbehorende </td> is er bijvoorbeeld iets mis in de achterliggende logica van een server-side script. Er zijn geen enorme voordelen, maar ook geen enorme nadelen.

Sinds wanneer is het missen van een optionele end tag een probleem? (Los van het feit dat je XHTML moet genereren met XML tools, niet met strings plakken en knippen.)

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 15:50:

Als je iemand koffie geeft met die boodschap kan de ander nog wel uitvogelen dat het geen koffie is. Met MIME types en documenten zit dat toch wel ietsje complexer in elkaar, anders waren MIME types overbodig geweest.

Om dit even aan te vullen:

Als je een document moet gaan analyseren, en dat moet een user agent, en het document is verzonden met het Content-Type text/html, dan betekent dat dat het document weleens HTML4.01 of iets anders kan zijn, iets wat niet met een XML parser verwerkt kan worden.
Krijg je echter application/xhtml+xml voorgeschoteld, dan ga je er van uit dat het een XML document is, en gebruik je een XML parser.

Zo kost het het minste tijd als het inderdaad om een XML document gaat, dat scheelt het erbij halen van een stukje testherkenning om de document type declaration op te zoeken, en uit een of andere tabel opzoeken of dat document dan wel of geen XML is.

Kortom, die MIME type is belangrijk voor het selecteren van de juiste verwerkingsmethode voor het document.

Dat maakt het ook erg handig om in de Content-Type header de character encoding te vermelden als die afwijkt van de "standaard" encoding. Als dat uit de XML declaration of een meta element gehaald moet worden, ben je eigenlijk al te laat om dat gegarandeerd goed vast te kunnen stellen.

[Verwijderd]

Plus natuurlijk het feit dat het volgende:

code:

<html></html>

... zowel met 'text/html', 'application/xml' als 'text/plain' iets zou kunnen voorstellen en in elk geval een ander type document teruggeeft. Bij 'text/plain' krijg je gewoon letterlijk de string. In 'application/xml' krijg je een XMLDOM met als rootnode 'html' en in 'text/html' krijg je een HTMLDOM met als rootnode 'HTML' en waarschijnlijk twee childnodes: 'HEAD' en 'BODY'.

[ Voor 18% gewijzigd door Verwijderd op 17-04-2005 16:08 ]

[Verwijderd]

omdat ze niet doorhebben dat door het sturen als text/html het geen XHTML meer is maar gewoon plain HTML

Ik leg het nog een keer uit

stel jij hebt op jouw server een map /www. In die map zie je een bestandje 'pagina.wml' of 'pagina.xhtml'. Je opent het bestandje. Je ziet een xhtml doctype. Het bestand is valid xhtml.

Wat is dat bestandje op dat moment volgens jou? Volgens jou is het niets, volgens mij is het 'een xhtml bestand'.

Nu gaan we dat bestand serveren. Iemand vraagt onze webserver op dit bestandje, en aangezien die iemand IE gebruikt, serveren we het met mime-type 'text/html' - wij willen immers geen kansloze purist zijn van wie de website nog maar door 10% van de bezoekers te lezen is. Nu is deze persoon een nogal eigenaardig typje (zijn IE gebruikers meestal) en purist. Hij wil de pagina dus niet in IE bekijken, en surft louter met notepad. Zo kan hij precies zien wat er op die pagina staat. Nadat hij het bestand heeft opgehaald met IE, heeft hij op zijn locale filesystem een bestandje 'pagina.xml' of 'pagina.xhtml' staan. Als hij het opent met notepad, ziet hij een XHTML doctype en een valid XHTML inhoud.

Volgens jou is het nu een HTML bestand. Volgens mij is het nog steeds een XHTML bestand.

Er zijn mensen die beweren dat dit bestandje bij de overdracht vanaf server naar client, indien het mimetype text/html gebruikt wordt, kenmerken kwijt is geraakt. Dit is nonsense. Zodra diegene die het bestandje op die manier gedownload heeft, het op z'n eigen webserver zet, en serveert met het voor XHTML bedoelde mimetype, is alles ineens weer goed. Zouden er kenmerken verloren zijn gegaan bij de overdracht als html, dan zou dat inhouden dat deze 2e server kenmerken heeft toegevoegd. Dat dit niet zo is, zal iedereen beamen. Het bestandje bevatte dus nog steeds alle kenmerken.

Moraal: het is en blijft gedurende de hele overdracht gewoon een .xhtml. Waarom zien we het dan toch niet goed? Omdat de browser het leest als HTML, met een HTML parser. Waarom doet de browser dit? NIET omdat de webserver hem GEDWONGEN heeft dit te doen. Louter omdat de webserver hem vertelde dat het een .html was, en er lokaal de instelling is gemaakt dat .html met een .html parser geopend moet worden.

De browser leest dus het bestand verkeerd. Dat neemt niet weg dat het gewoon nog steeds een xhtml bestand is.

Toch maar weer een analogie er tegenaan gooien. Stel ik ben programmeur. Stel ik programmeer in Delphi. Stel ik heb een applicatie gemaakt, en wil die aan jou versturen. Nu was ik zo blij dat ik klaar was, dat ik mij een stuk in m'n kraag gezopen had, en abusievelijk tegen jou zeg dat ik de applicatie in c# geschreven heb. Ik verstuur dus een .pas aan jou met als mimetype c#.

Wat is het bestand nu als het eenmaal op jouw computer aangekomen is? Volgens jou is het dan een c# bestand. Volgens mij niet. Volgens je c# IDE ook niet. Volgens mij is het nog immer een .pas. Als ik mijn vergissing inzie, en jou vertel dat het geen c# bestand is, maar een delphi/pascal bestand en jij opent het met Delphi, werkt alles ineens weer.

Waarom? Omdat het bestand zelf tijdens de overdracht nooit gewijzigd is, het is nog steeds hetzelfde bestand, met dezelfde kenmerken. Als jij C# gebruikt om het te openen, open jij het verkeerd, maar is het nog steeds een pascal bestand.

Het is echt nonsense te beweren dat het bestand na overdracht ineens c# is (of HTML, om terug te keren naar de normale discussie).

De juiste uitspraak is:

XHTML verstuurd met mimetype text/html is nog steeds XHTML, echter het wordt gelezen als HTML.

[ Voor 5% gewijzigd door Verwijderd op 17-04-2005 16:31 ]

[bgever]

Verwijderd schreef op zondag 17 april 2005 @ 14:20:
[...]
Wat versta jij onder XHTML functies?

Ik denk dat Anne het zo wel aardig heeft verwoord:

Daarnaast heeft het helemaal geen zin. XHTML bestaat om HTML met XML tools te kunnen bewerken en om HTML te kunnen "mixen" met andere XML varianten, zoals MathML of XForms. (SVG zou ook kunnen, maar dat is niet echt een goed voorbeeld vanwege het gebrek aan semantiek.)

Doe jij dat dus ook? Of is de XML syntax de enige reden om XHTML te gebruiken?

Cheatah schreef op zondag 17 april 2005 @ 14:20[/message]:
[...]
Ik gebruik het onder meer om de zeer duidelijke syntax die je voor jezelf afdwingt. Bij XHTML 1.0 haal je sneller problemen uit je code dan bij HTML 4.01. Als er ergens een <td> staat zonder bijbehorende </td> is er bijvoorbeeld iets mis in de achterliggende logica van een server-side script. Er zijn geen enorme voordelen, maar ook geen enorme nadelen.

Of je daar persé een standaard voor nodig hebt vind ik discutabel, maar ik moet je daar wel gelijk in geven als je bijvoorbeeld gebruik gaat maken van validatie tools.

En nee, ik doe niet onnodig moeilijk, want het kost me niet meer tijd of moeite om een site XHTML 1.0 Strict compliant te maken dan om een site HTML 4.01 Strict compliant te maken.

Ik ga even uit van alle XHTML developers, en dan lijkt het mij toch voor hun meer moeite om de problemen die Ian Hickson aangeeft op te lossen. Geluk voor jou dat jij daar niet zo lang over doet.

Wat jij vind kan mij weinig schelen. Ik heb meer bijgedragen aan de vooruitgang van de kennis op dit forum dan jij. Dus wat probeer je nu te bereiken (behalve mensen op de kast jagen)?

Lees mijn opmerking nog eens, en je zult merken dat dit helemaal geen persoonlijke aanval is, zoals jij dit blijkbaar opvat. En even eerlijk: status is hierbij niet van belang.

Wat ik probeer te bereiken: dat XHTML ontwikkelaars onder ogen durven te zien dat ze malformed HTML over het net verspreiden (hierbij geld wel dat de XHTML dus als text/html wordt geserveerd). Bovendien vind ik het "als XHTML ontwikkelaar verbeter ik het web" labeltje dat wel vaker aan XHTML ontwikkelaars wordt gekoppeld dus niet altijd terecht... Dat ik hiermee mensen op de kast jaag is niet een reden om het te gaan ontkennen...

[Verwijderd]

oikoyama schreef op zondag 17 april 2005 @ 16:29:
Wat ik probeer te bereiken: dat XHTML ontwikkelaars onder ogen durven te zien dat ze malformed HTML over het net verspreiden (hierbij geld wel dat de XHTML dus als text/html wordt geserveerd).

Dit is dus niet zo. Ze verspreiden XHTML met het verkeerde mime-type.

Stel dat ID7 het XHTML mimetype wel goed pakt. Dan is de developer klaar met louter het aanpassen van het mime-type. Daarna kan hij direct, zonder verdere aanpassingen, gaan proviteren van de voordelen die XHTML/XML te bieden hebben.

Nu XHTML devven doe je dus niet om dat het nu beter is, maar omdat het in de toekomst voordelen biedt.

[Verwijderd]

hezik, voor jou is het wellicht XHTML. Aangezien jij weet wat je probeerde te maken. Een computer (en daar gaat het hier over) zal daar echter nooit achter komen waardoor jou bestandje vanwege het MIME type herkend gaat worden als HTML. Op het moment dat er dingen aangepast worden zal dat dan ook gebeuren aan de hand van de HTMLDOM en niet aan de hand van de XMLDOM waardoor de uiteindelijk output best wel eens ill-formed XHTML, maar correcte HTML zou kunnen zijn ondanks dat jij onder al je goede bedoelingen het zo netjes well-formed XHTML had gemaakt.

Het MIME type bepaald wel degelijk de inhoud en hoe de inhoud behandeld zal worden en wat er uiteindelijk van de inhoud terecht zal komen na bewerkingen.

Als je het hebt over een simpel los tekst bestandje heb je een punt, maar dat lijkt me niet iets om je druk over te maken. (Daarnaast wordt het andere argument: "XHTML als text/html is HTML," vooral gebruikt om aan te geven hoe browsers (computers, whatever) erover denken.)

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 16:46:
hezik, voor jou is het wellicht XHTML. Aangezien jij weet wat je probeerde te maken. Een computer (en daar gaat het hier over) zal daar echter nooit achter komen

Dit is niet waar. Als ik mozilla als standaard browser gebruik, en ik dubbelklik op het 'pagina.xhtml' bestandje op mijn bureaublad, zal mozilla hem correct parsen.

Wat is een XHTML volgens jou als hij niet geserveerd wordt? Een zip bestand bestaat dus ook niet, tenzij hij als zip geserveerd wordt? Een .doc is geen word bestand, totdat een webserver 'm als zodanig aanbiedt?

Voor praktisch alle bestandstypen geldt dat de inhoud en de extentie bepalen wat voor bestand het is. Waarom is dat voor XHTML ineens anders?

[ Voor 31% gewijzigd door Verwijderd op 17-04-2005 16:49 ]

[bgever]

Verwijderd schreef op zondag 17 april 2005 @ 16:27:
[...]
XHTML verstuurd met mimetype text/html is nog steeds XHTML, echter het wordt gelezen als HTML.

Klopt als een bus. Voor jou, de anderen en ik als mensen.

Maar blijkbaar snap je niet wat er met het browser perspectief wordt bedoeld. Dat is namelijk wat de parser leest, en uiteindelijk op het scherm toont. Wat jij op het scherm ziet met text/html ís HTML, en geen XHTML. Er gaat weldegelijk iets verloren bij text/html, niet in het bestand, maar wel in het geheugen van de browser en dus uiteindelijk ook op het scherm. De HTML parser zal namelijk alle XML functies negeren, en hiervan kun je dus ook geen gebruik maken in de browser.
Hierdoor kunnen er dus veranderingen ontstaan in de weergave, en deze fouten zie je ook terug in de visuele pagina. Wat jij dus dan visueel ziet is HTML, en géén XHTML. Dus wat ís het dan voor de browser?

Hopelijk snap je nu ook dat je nog steeds appels met peren aan het vergelijken bent. Op het menselijk perspectief heb jij gelijk, en op het browser perspectief ik. Het is dus maar net hoe je het bekijkt. Maar je moet deze twee niet door elkaar halen...

Maar ik zal me er maar bij neerleggen dat op code niveau XHTML verzonden als text/html wel XHTML is. Op visualisatie niveau is dit een ander verhaal, maar ik denk dat dit eigenlijk buiten deze discussie staat, omdat dit browser specifiek is.

[Verwijderd]

Stel dat ID7 het XHTML mimetype wel goed pakt. Dan is de developer klaar met louter het aanpassen van het mime-type.

Onzin. Hoogstwaarschijnlijk zijn er vele fouten ingeslopen. Uit een onderzoek onder honderd sites van "web standards people" bleek dat 89% niet valideerde en 99% het verkeerde MIME type gebruikte. ( http://annevankesteren.nl/archives/2004/08/xhtml ). (En dat waren niet alle subpagina's.)

Verder is het zo dat op het moment dat je bij die 11% hoort die wel valideert nog steeds duizenden problemen tegen gaat komen. CSS werkt anders, javascript werkt anders en je wilt waarschijnlijk nog steeds een text/html versie hebben die blijft werken wat het allemaal niet vereenvoudigt.

Ik denk dat je de zaken teveel simpliceert zonder echt te weten wat de gevolgen zijn van het switchen van een MIME type. Zeker als je praat over enorme sites die niet door middel van XSLT gegeneerd worden. Het is dan gewoon niet slim om XHTML te gaan gebruiken.

Nu XHTML devven doe je dus niet om dat het nu beter is, maar omdat het in de toekomst voordelen biedt.

Niet echt dus.

[Verwijderd]

Dit is niet waar. Als ik mozilla als standaard browser gebruik, en ik dubbelklik op het 'pagina.xhtml' bestandje op mijn bureaublad, zal mozilla hem correct parsen.

Windows verbindt een bepaalde logica aan extenties zover ik weet. (Uiteraard heeft Mozilla ook wat extentie logica.) Er zijn ook OSsen waar de file-metadata los staat van het bestand zelf.

Maar je quote maar een specifiek stukje uit m'n reactie en dan ook nog eens een deel wat niet superrelevant was.

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 16:51:
Onzin. Hoogstwaarschijnlijk zijn er vele fouten ingeslopen. Uit een onderzoek onder honderd sites van "web standards people" bleek dat 89% niet valideerde en 99% het verkeerde MIME type gebruikte. ( http://annevankesteren.nl/archives/2004/08/xhtml ). (En dat waren niet alle subpagina's.)

Dus? Dit zegt niets over of het al dan niet kan. De discussie hier ging niet over het serveren van malformed XHTML als HTML.

Verder is het zo dat op het moment dat je bij die 11% hoort die wel valideert nog steeds duizenden problemen tegen gaat komen. CSS werkt anders, javascript werkt anders en je wilt waarschijnlijk nog steeds een text/html versie hebben die blijft werken wat het allemaal niet vereenvoudigt.

Kul. Als ik mijn valide XHTML document met het juiste mimetype aanbiedt aan firefox, ziet hij er goed uit. Als ik 'm als html aanbiedt aan IE, ziet hij er goed uit. Zodra IE xhtml gaat ondersteunen, ben ik klaar met het corrigeren van het mimetype, en kan ik direct hele specifieke XML/XHTML zaken gaan toevoegen. Desgewenst kan ik de bestaande pagina nog serveren als html aan oudere IE's.

Niet echt dus.

Zo lust ik er nog wel een paar. Zo kan ik ook zeggen dat het niet goed is om je pagina in HTML te devven, omdat 90% van de HTML op het web niet well-formed is. Dat is een drogreden.

Mits de developer juist developed, is mijn uitspraak gewoon geheel waar. Dat er veel developers zijn die er een zooitje van maken, maakt de uitspraak niet minder waar.

Maar je quote maar een specifiek stukje uit m'n reactie en dan ook nog eens een deel wat niet superrelevant was.

Ik quote juist het meest relevante gedeelte. Jouw hele stelling is gebaseerd op de aanname dat een computer niet weet wat voor bestand iets is, tenzij hij het mimetype erbij krijgt. Ik toon aan dat dat niet waar is.

[ Voor 11% gewijzigd door Verwijderd op 17-04-2005 16:59 ]

[bgever]

Verwijderd schreef op zondag 17 april 2005 @ 16:46:
[...]
Nu XHTML devven doe je dus niet om dat het nu beter is, maar omdat het in de toekomst voordelen biedt.

Hmm, dat is dus wat ik bedoel met die slechte bijdrage aan het web. Laat ik deze mentaliteit eens zo omschrijven:

Laten we vandaag een deel van de mensen op de wereld afmaken, zodat we in de toekomst genoeg te eten hebben!

We nemen nu dus maar de negatieve gevolgen voor lief, zodat we het in de toekomst wel gemakkelijk hebben. Wie zegt dat er in de toekomst niet een nieuw voedsel wordt ontdekt (of dat IE helemaal nooit XHTML zal ondersteunen)? Heb je wel allemaal die mensen afgemaakt, en heb je ook nog een boel getraumatiseerde mensen. Is het dat risico wel waard?

[ Voor 18% gewijzigd door bgever op 17-04-2005 17:04 ]

[Verwijderd]

oikoyama schreef op zondag 17 april 2005 @ 17:02:
We nemen nu dus maar de negatieve gevolgen voor lief, zodat we het in de toekomst wel gemakkelijk hebben.

Ik mag toch hopen dat je zelf ook inziet dat deze analogie totaal ridicuul is? Wat zijn volgens jou dan precies die negatieve gevolgen? Ik zie alleen gekwestie puristen die het niet kunnen hebben dat mensen XHTML met een html mimetype serveren. De pagina's zelf werken prima. Het internet werkt prima. Welke negatieve gevolgen?

Om dat nou te gaan vergelijken met het afmaken van mensen voor eten.. komop zeg.

[Erkens]

idd, het gaat er toch om dat de uiteindelijke bezoeker van de site die site gewoon kan zien en gebruiken?
Wat is nu echt het werkelijke nadeel wat deze bezoekers hebben als ik mijn XHTML pagina's als text/html aanbied? niks, idd.

[crisp]

Verwijderd schreef op zondag 17 april 2005 @ 16:27:
[...]


Ik leg het nog een keer uit

stel jij hebt op jouw server een map /www. In die map zie je een bestandje 'pagina.wml' of 'pagina.xhtml'. Je opent het bestandje. Je ziet een xhtml doctype. Het bestand is valid xhtml.

Wat is dat bestandje op dat moment volgens jou? Volgens jou is het niets, volgens mij is het 'een xhtml bestand'.

Op dat moment is het niets meer dan platte tekst.

Nu gaan we dat bestand serveren. Iemand vraagt onze webserver op dit bestandje, en aangezien die iemand IE gebruikt, serveren we het met mime-type 'text/html' - wij willen immers geen kansloze purist zijn van wie de website nog maar door 10% van de bezoekers te lezen is. Nu is deze persoon een nogal eigenaardig typje (zijn IE gebruikers meestal) en purist. Hij wil de pagina dus niet in IE bekijken, en surft louter met notepad. Zo kan hij precies zien wat er op die pagina staat. Nadat hij het bestand heeft opgehaald met IE, heeft hij op zijn locale filesystem een bestandje 'pagina.xml' of 'pagina.xhtml' staan. Als hij het opent met notepad, ziet hij een XHTML doctype en een valid XHTML inhoud.

Volgens jou is het nu een HTML bestand. Volgens mij is het nog steeds een XHTML bestand.

Volgens mij is het dan wederom platte tekst; een representatie van wat misschien wel eens XHTML zou kunnen zijn, maar aangezien we het niet in de juiste omgeving bestuderen weten we dat niet zeker.

Er zijn mensen die beweren dat dit bestandje bij de overdracht vanaf server naar client, indien het mimetype text/html gebruikt wordt, kenmerken kwijt is geraakt. Dit is nonsense. Zodra diegene die het bestandje op die manier gedownload heeft, het op z'n eigen webserver zet, en serveert met het voor XHTML bedoelde mimetype, is alles ineens weer goed. Zouden er kenmerken verloren zijn gegaan bij de overdracht als html, dan zou dat inhouden dat deze 2e server kenmerken heeft toegevoegd. Dat dit niet zo is, zal iedereen beamen. Het bestandje bevatte dus nog steeds alle kenmerken.

En als ik nu eens besluit om het bijvoorbeeld met een XML-mimetype te gaan serveren, dan is het ineens XML geworden; goh wat raar nou

Moraal: het is en blijft gedurende de hele overdracht gewoon een .xhtml. Waarom zien we het dan toch niet goed? Omdat de browser het leest als HTML, met een HTML parser. Waarom doet de browser dit? NIET omdat de webserver hem GEDWONGEN heeft dit te doen. Louter omdat de webserver hem vertelde dat het een .html was, en er lokaal de instelling is gemaakt dat .html met een .html parser geopend moet worden.

De browser leest dus het bestand verkeerd. Dat neemt niet weg dat het gewoon nog steeds een xhtml bestand is.

Als ik dubbelklik op een .php wat heb ik dan in mijn text-editor staan? Als ik diezelfde .php oproep in mijn browser, wat is het dan? De textuele representatie van iets maakt het nog niet wat je denkt dat het is; alleen wanneer je het bestudeert in de omgeving waarvoor het bedoelt is kan je met zekerheid uitspraken doen.

Een leeuw zal in een kooitje heel ander gedrag vertonen dan in het wild; aan de hand van de gedragingen in gevangenschap kan je nog geen uitspraken doen over leeuwen in het algemeen, daarvoor zal je op safari moeten gaan.

[BtM909]

Heren, wat is voor jullie het voordeel om XHTML code te gebruiken in pagina's?

En liever geen argument alszijnde: jah, want het is nieuwe techniek

[crisp]

Verwijderd schreef op zondag 17 april 2005 @ 18:02:
[...]


Ik mag toch hopen dat je zelf ook inziet dat deze analogie totaal ridicuul is? Wat zijn volgens jou dan precies die negatieve gevolgen? Ik zie alleen gekwestie puristen die het niet kunnen hebben dat mensen XHTML met een html mimetype serveren. De pagina's zelf werken prima. Het internet werkt prima. Welke negatieve gevolgen?

Om dat nou te gaan vergelijken met het afmaken van mensen voor eten.. komop zeg.

Erkens schreef op zondag 17 april 2005 @ 18:06:
idd, het gaat er toch om dat de uiteindelijke bezoeker van de site die site gewoon kan zien en gebruiken?
Wat is nu echt het werkelijke nadeel wat deze bezoekers hebben als ik mijn XHTML pagina's als text/html aanbied? niks, idd.

En hier ging de hele discussie dus niet over. Als je mijn mening wilt weten: ja, ik vind XHTML als text/html harmfull omdat het uiteindelijk gewoon mallformed HTML is.
En aan de andere kant: ook al kan je geen nadelen ontdekken, leg mij dan maar eens uit wat de voordelen zijn?

[Verwijderd]

crisp schreef op zondag 17 april 2005 @ 18:33:
Op dat moment is het niets meer dan platte tekst.

Dus als ik een zip bestand open in notepad, is het volgens jou platte tekst? Volgens mij is het dan nog immer een zip bestand.

En als ik nu eens besluit om het bijvoorbeeld met een XML-mimetype te gaan serveren, dan is het ineens XML geworden; goh wat raar nou

Nee dan is het nog immer XHTML, echter wordt het gelezen als XML

BtM909 schreef op zondag 17 april 2005 @ 18:34:
Heren, wat is voor jullie het voordeel om XHTML code te gebruiken in pagina's?

En liever geen argument alszijnde: jah, want het is nieuwe techniek

1) het is een nieuwe techniek ( )
2) een eventuele latere overstap naar full-fledged XML wordt makkelijker gemaakt.

En hier ging de hele discussie dus niet over. Als je mijn mening wilt weten: ja, ik vind XHTML als text/html harmfull omdat het uiteindelijk gewoon mallformed HTML is.

En wat is daar precies harmfull aan? Ziet de eindgebruiker de site niet goed? Werkt de site niet?

Ik durf rustig te zeggen dat zeker meer dan 50% van de 'gewone' HTML's al niet wellformed zijn.

En het is dus uiteindelijk geen malformet HTML, het is uiteindelijk nog steeds XHTML die echter als HTML gelezen wordt.

Als ik een niet frans sprekende rus een frans boek geeft, en 'm dat laat voorlezen, welke taal is dat boek dan in gesteld? Volgens mij nog steeds in het frans, en niet in het russisch.

Jullie verwarren hoe een bestand gelezen wordt met wat het bestand echt is. Hoe het gelezen wordt, bepaald NIET wat het is.

[ Voor 63% gewijzigd door Verwijderd op 17-04-2005 19:05 ]

[JHS]

Verwijderd schreef op zondag 17 april 2005 @ 18:59:
2) een eventuele latere overstap naar full-fledged XML wordt makkelijker gemaakt.

Omdat de syntax een beetje anders is? Dat is met intilligent gebruik van regexp en replacing zo op te lossen als je later wil overstappen...

[Verwijderd]

BtM909 schreef op zondag 17 april 2005 @ 18:34:
Heren, wat is voor jullie het voordeel om XHTML code te gebruiken in pagina's?

En liever geen argument alszijnde: jah, want het is nieuwe techniek

ik gebruik xhtml op de server en gooi daar een hele arsenaal aan xml tools overheen. In het geval van mijn stage verslag wordt de inhoud mbv xsl toegevoegd, ook de index werd zo gedaan. Verder zijn er via de dom afkortingen toegevoegd (had ook via een html dom gekund) en wordt de boel opgesplitst in losse hoofdstukken als daar om gevraagd wordt. Ook het versie beheer zal ik hiermee gaan bijhouden (ins en del met een datum in de class).

Browsers die het ondersteunen krijgen xhtml, anders maak ik er voor ik het verzend nog ff html van (door wat replaces uit te voeren op oa. <br /> <img /> <hr /> <link /> en <img />)

verder gebruik ik ook nog mathml, maar dat wordt later dmv javascript in de dom ingevoerd (vertaald vanuit TeX, zodat voor non mathml browsers de TeX code leesbaar blijft). Die js is dus zo geschreven dat ie met zowel een html als xml dom om kan gaan, want IE met mathplayer krijgt html van mij

[Verwijderd]

JHS schreef op zondag 17 april 2005 @ 19:04:
Omdat de syntax een beetje anders is? Dat is met intilligent gebruik van regexp en replacing zo op te lossen als je later wil overstappen...

Het voordeel van XHTML nu is dus dat je later niet intelligent met regexp en replacing aan het klooien hoeft.

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 19:06:
[...]


Het voordeel van XHTML nu is dus dat je later niet intelligent met regexp en replacing aan het klooien hoeft.

zo'n scriptje is in 5 min geschreven of ge-c/p'ed, dus waarom zou je dat er nu niet achter hangen? dan stuur je html naar non xhtml browsers en xhtml naar de rest. Hoef je "later" alleen maar dat scriptje weg te kieperen

[ Voor 9% gewijzigd door Verwijderd op 17-04-2005 19:13 ]

[Osiris]

Ben ik de enige die vind dat die MIME-type-header en een doctype dubbelop is? Of snap ik 't nu niet?

Overigens vind ik XHTML gewoon fijner dan "normale" HTML, omdat het logischer is op bepaalde punten. Geen losse tags zoals <br>, maar alles afsluiten, al dan niet in dezelfde tag. 't Werkt gewoon logischer en voor de wat "autistischere" nerds is dat ongetwijfeld fijner. Enige feit is dat ik 't vaak verstuur als text/html is omdat er zo'n incompetente browser bestaat die 't correcte niet snapt en ik niet graag "terug" wil stappen op "onlogische" code.

Overigens is de pagina/site in mijn "Homepage"-link wel 100% valid, alleen hebben IE-users daar dus niets aan

[ Voor 88% gewijzigd door Osiris op 17-04-2005 19:17 ]

[Verwijderd]

da's niet dubbelop, alle html versies verstuur je als text/html, alle xhtml versies (in principe) als application/xhtml+xml, je hebt dus nog een hoop versies waar het doctype het verschil maakt. Verder hebben css en js files bv ook geen doctype, wel een mime type (en die is nuttig ook, zijn hier al genoeg topics geweest van verkeerd geserveerde css files die niet werkten)

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 18:59:

Jullie verwarren hoe een bestand gelezen wordt met wat het bestand echt is. Hoe het gelezen wordt, bepaald NIET wat het is.

Dat idee heb ik dus ook.

Een XHTML document verstuurt als text/html is nog steeds een XHTML document. Alleen om praktische redenen (performance, compatibility) mag het worden gelezen met een HTML parser, welke dat toch wel goed gaat doen vanwege de foutcorrectie die in praktijk deze manier van serveren toestond. De document type declaration is nog steeds geldig.

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 19:12:
zo'n scriptje is in 5 min geschreven of ge-c/p'ed, dus waarom zou je dat er nu niet achter hangen? dan stuur je html naar non xhtml browsers en xhtml naar de rest. Hoef je "later" alleen maar dat scriptje weg te kieperen

Ik weet niet hoe lang jij in de IT rondloopt, maar zodra een sysadmin/devver/it-er tegen jou zegt dat hij een scriptje wel even in 5 minuten zal schrijven om iets te doen, dat je dan de komende 48 uur je server/services kwijt bent.

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 19:25:
[...]


Ik weet niet hoe lang jij in de IT rondloopt, maar zodra een sysadmin/devver/it-er tegen jou zegt dat hij een scriptje wel even in 5 minuten zal schrijven om iets te doen, dat je dan de komende 48 uur je server/services kwijt bent.

da's natuurlijk geen argument (je was net beter bezig ) Maar ok, ik maak er 1 minuut van:

PHP:

function make_html($xml) {
    $xml = preg_replace('/<\?xml.*?>\s*/','',$xml); //remove prolog and whitespaces following it;
    $xml = preg_replace('/<!DOCTYPE.*?>\s*/','<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">'."\n",$xml); //replace DTD
    $xml = preg_replace('/<html.*?>/','<html lang="en">',$xml); //strip html tag
    $xml = preg_replace('/\/>/','>',$xml);
    return $xml;
}

_{ey niet gaan zeuren om de variabelenamen he op welk punt moet ik dan $html gebruiken ipv $xml}

[ Voor 18% gewijzigd door Verwijderd op 17-04-2005 19:34 ]

[JHS]

mophor: je hebt maakt van je xml html, en je returnt xml?

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 19:22:
[...]

Dat idee heb ik dus ook.

Een XHTML document verstuurt als text/html is nog steeds een XHTML document. Alleen om praktische redenen (performance, compatibility) mag het worden gelezen met een HTML parser, welke dat toch wel goed gaat doen vanwege de foutcorrectie die in praktijk deze manier van serveren toestond. De document type declaration is nog steeds geldig.

Ik snap een ding niet aan deze hele discussie. Je hebt twee kampen bij de vraag: XHTML document verstuurt als text/html is...

1.) XHTML
2.) Mallformed HTML

Het een sluit het ander niet uit. Het ligt er maar net aan vanuit welk referentiekader je het bekijkt. Beide kampen kijken vanuit twee verschillende referentiekaders, waardoor dit een zinloze discussie is. Beide partijen hebben gelijk vanuit hun eigen referentiekader, waarom dan nog door blijven hameren?

Vanuit browser perspectief gezien is het Mallformed HTML; de browser verwacht namelijk HTML en krijgt iets voor zijn kiezen dat geen HTML is. Voor de browser is het dus mallformed HTML dat m.b.v. error correctie tot nog iets leuks wordt weergegeven.

Vanuit document perspectief gezien is en blijft het XHTML; het document is immers niet gewijzigd.

Deze discussie voortzetten slaat compleet nergens op aangezien iedereen vanuit zijn eigen referentiekader gelijk heeft. Niemand heeft ongelijk. Dus proberen de ander te overtuigen is nogal verspilling van je tijd.

[ Voor 24% gewijzigd door Verwijderd op 17-04-2005 19:37 ]

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 19:33:

Ik snap een ding niet aan deze hele discussie. Je hebt twee kampen bij de vraag: XHTML document verstuurt als text/html is...

1.) XHTML
2.) Mallformed HTML

Ik probeer dus te vertellen dat het geen HTML is. Het is alleen zo dat het parsen met een HTML parser wel goed gaat, als je een beetje rekening houdt met de compatibility guidelines.

Het een sluit het ander niet uit. Het ligt er maar net aan vanuit welk referentiekader je het bekijkt. Beide kampen kijken vanuit twee verschillende referentiekaders, waardoor dit een zinloze discussie is. Beide partijen hebben gelijk vanuit hun eigen referentiekader, waarom dan nog door blijven hameren?

Ik heb eerder al gezegd dat iedereen het voor zichzelf moet bepalen, in plaats van blind achter anderen (inclusief ik) aan te gaan.

Vervolgens gaan mensen door met Hixie sprookjes en onwaarheden verkondigen. Dat probeer ik recht te zetten, ik probeer mensen iets bij te leren, en dat is waarom ik erop door ging.

[Verwijderd]

Dit was geen aanval richting jou; die quote. Maar volgens mij moet iedereen het met me eens zijn dat voortdiscussieren nogal zinloos is. Iedereen weet gewoon hoe de vork in de steel zit en mensen nu nog aftroeven op punt-komma gevalletjes slaat nergens op.

Als niet beide partijen vanuit hetzelfde referentiekader een probleem bekijken, dan heeft discussieren nogal weinig zin aangezien het ene kader zijn eigen (aangenomen) waarheid heeft, die niet noodzakelijk de waarheid hoeft te zijn in het andere kader.

[crisp]

Ik zie XHTML niet als een document met een bepaalde syntax, ik zie het als een techniek die in toegepaste vorm bepaalde eigenschappen heeft...

[JHS]

Bovendien is het helemaal niet relevant of het nu XHTML, HTML, malformed HTML, malformed HTML, platte tekst, pindakaas of erwtensoep is. Het gaat erom dat het voor de gebruiker en de developer goed werkt. En dus, wat Cheetah al de hele tijd zegt, is het belangrijk dat je kennis van zaken hebt, zelf onderzoek doet, en 's een hoop leest.

En iedereen heeft een mening over wat nu het makkelijkst en het best is, maar dat is inderdaad vanuit een bepaald referentiekader, en zeker een bepaalde smaak. Ik gebruik persoonlijk HTML omdat dat me de problemen bespaart, die ik hopelijk wel op kan lossen, van XHTML als text/html, en aangezien ik geen XML functies gebruik héb ik er ook niks aan. En met de syntax van HTML kan ik best omgaan. Die ene <br> die je niet afsluit maakt je code er imo niet onduidelijker op...

Maargoed, dat is dus mijn mening, mijn smaak, mijn manier van werken. En iedereen heeft weer een andere. En zolang je het maar goed doet (vanuit de gebruiker, het web, de klant, jezelf gezien), doet het er helemaal nul toe wat die manier precies is...

edit:

crisp schreef op zondag 17 april 2005 @ 20:02:
Ik zie XHTML niet als een document met een bepaalde syntax, ik zie het als een techniek die in toegepaste vorm bepaalde eigenschappen heeft...

Dat bedoel ik, het is zelfs de vraag wát je aan het benoemen bent... Overigens vind ik die manier wel de duidelijkste, en de meest relevante, want zo komt het bij de gebruiker op zijn scherm. Maar dat is vervolgens toch weer redelijk irrelevant...

[ Voor 20% gewijzigd door JHS op 17-04-2005 20:08 ]

[Verwijderd]

Kul. Als ik mijn valide XHTML document met het juiste mimetype aanbiedt aan firefox, ziet hij er goed uit. Als ik 'm als html aanbiedt aan IE, ziet hij er goed uit.

Sla het volgende op als XHTML en bekijk het in IE als text/html en in Firefox als application/xml en vertel me of het er hetzelfde uitziet:

code:

<html xmlns="http://www.w3.org/1999/xhtml">
 <style>body{background:lime}</style>
</html>

... wellicht een beetje flauw, probeer anders deze is:

code:

<html xmlns="http://www.w3.org/1999/xhtml">
 <style>body{background:lime}</style>
 <body>
  <p>Alleen deze tekst behoort een groene achtergrond te krijgen...</p>
 </body>
</html>

Verder heb je natuurlijk javascript, waar je snel overheen leek te lezen. Rekening houden met namespaces e.d. maakt het er wel lastiger op en vaak wordt het vergeten (maar dat vind jij geen argument, want je bent van mening dat iedereen het vanzelf goed doet en iedereen die dat niet doet een prutser is...).

Zodra IE xhtml gaat ondersteunen,

Dat waren ze niet van plan: http://annevankesteren.nl/archives/2004/06/updateless-ie

(Uiteraard zijn er nu wat geruchten nu IE7 deze zomer uit gaat komen, maar dat is voornamelijk patchwerk.)

Ik quote juist het meest relevante gedeelte. Jouw hele stelling is gebaseerd op de aanname dat een computer niet weet wat voor bestand iets is, tenzij hij het mimetype erbij krijgt. Ik toon aan dat dat niet waar is.

Onzin, jij geeft de computer een bestandsextentie en omdat er interne mapping bestaat weet de browser het alsnog. Dat er twee wegen zijn, maakt het nog niet onwaar dat de computer een gegeven nodig heeft voor het bepalen van het type bestand.

[Verwijderd]

Ey anne, da's geen valid xhtml he, in xhtml zijn de head en body tags niet optioneel

(ben overigens wel nieuwschierig of er een voorbeeld te vinden is die en valid xhtml is en voldoet aan de compatibility guidelines en toch discrepanties vertoont, afgezien van script dingen (andere dom)

overigens: aan een extensie kan je idd prima afschatten wat voor bestand het is, maar dat gaat de mist in met gebruik van php of een andere server side scripttaal. En natuurlijk werken niet alle ossen met extensies

[ Voor 89% gewijzigd door Verwijderd op 17-04-2005 20:47 ]

[Verwijderd]

Ey anne, da's geen valid xhtml he, in xhtml zijn de head en body tags niet optioneel

In dit geval maakt dat niet uit. (Hoewel wel een klein beetje voor het eerste voorbeeld, maar daarom heb ik ook die andere gegeven.)

(ben overigens wel nieuwschierig of er een voorbeeld te vinden is die en valid xhtml is en voldoet aan de compatibility guidelines en toch discrepanties vertoont, afgezien van script dingen (andere dom)

Ja, zie boven. Zet er een DOCTYPE boven, voeg een HEAD element en een TITLE toe en je bent klaar.

overigens: aan een extensie kan je idd prima afschatten wat voor bestand het is, maar dat gaat de mist in met gebruik van php of een andere server side scripttaal. En natuurlijk werken niet alle ossen met extensies

Nee, sommige OSsen werken met metadata voor bestanden. Dan wordt er een bepaald MIME type + character encoding gekoppeld aan een bestand. Wat uiteraard veel handiger is dan werken met extenties. (Is het nou extensie of extentie?)

[blizt]

offtopic:
extensie

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 20:29:
Sla het volgende op als XHTML en bekijk het in IE als text/html en in Firefox als application/xml en vertel me of het er hetzelfde uitziet

Totaal irrelevant. Ik zei het idd verkeerd. Wat ik bedoelde is; het is perfect mogelijk een valide XHTML te maken die zowel geserveerd als XHTML aan firefox als geserveerd als html aan IE, er goed uit ziet. Zolang je dat doet, is er domweg geen probleem, hooguit de gekrenkte puristenziel.

Verder heb je natuurlijk javascript, waar je snel overheen leek te lezen. Rekening houden met namespaces e.d. maakt het er wel lastiger op en vaak wordt het vergeten (maar dat vind jij geen argument, want je bent van mening dat iedereen het vanzelf goed doet en iedereen die dat niet doet een prutser is...).

Nee dat is niet (geheel) wat ik vind. Mijn punt is dat fouten gemaakt zullen worden, ongeacht of je je pagina nu schrijft in .txt, .doc, .html, .xhtml, .xml of wat dan ook. Er zullen altijd devvers zijn die fouten maken, al dan niet opzettelijk. Dat is geen argument om te zeggen dat je een bepaalde techniek dan maar niet moet gebruiken. Het is net zo makelijk een .html te vernaggelen als om een .xhtml te vernaggelen. Zeggen 'ja maar als men het fout doet, is het fout' (wat hier nogal veel gebeurde) is dan ook gewoon een drogreden.

Onzin, jij geeft de computer een bestandsextentie en omdat er interne mapping bestaat weet de browser het alsnog. Dat er twee wegen zijn, maakt het nog niet onwaar dat de computer een gegeven nodig heeft voor het bepalen van het type bestand.

Punt is dat het niet de computer is die bepaald wat het type is van een bestand. Als ik in IE mijn mimetypes omgooi zodanig dat .jpg als .html gezien wordt, is het niet zo dat de .html die bij me binnenkomt ook daadwerkelijk een .html is, het is nog steeds een .jpg. Dat is ook de reden dat hij in zo'n geval niet correct zou worden weergegeven, immers de browser ziet 'm verkeerd.

Het is de inhoud en ook alleen de inhoud van het bestand wat bepaald wat het type is. Niet een van de tig stikkertjes die wij (of webservers) er op kunnen plakken om het voor elkaar te krijgen dat de juiste lezer geselecteerd wordt. De mensen die het hier met mij oneens zijn snappen imo niet dat een bestandsextentie en een mimetype niet meer dan labels op de verpakking zijn, bedoeld om de verdere verwerking van de inhoud van die verpakking goed te laten verlopen.

Het is volstrekt mogelijk om met niet-bestaande en ongeldige mime-types toch een goede 'internet-ervaring' te maken, mits het vernaggelen van de mime-types aan beide kanten (client/server) maar op de zelfde manier gebeurd. Ik kan bv. rustig mijn webserver een .html laten aanbieden met als mimetype 'text/gelulinderuimte', mits ik de browser maar vertel dat hij dat mimetype met een HTML parser moet openen. Die mogelijkheid toont gewoon bikkelhard het ongelijk aan van de mensen die beweren dat een XHTML met mimetype html is. Immers het mimetype is in dit voorbeeld 'gelulinderuimte' en DUS is het volgens hen onmogelijk dat de browser het juist parsed. Toch doet hij het. Wondere wereld.

[Verwijderd]

Ik kan bv. rustig mijn webserver een .html laten aanbieden met als mimetype 'text/gelulinderuimte', mits ik de browser maar vertel dat hij dat mimetype met een HTML parser moet openen. Die mogelijkheid toont gewoon bikkelhard het ongelijk aan van de mensen die beweren dat een XHTML met mimetype html is. Immers het mimetype is in dit voorbeeld 'gelulinderuimte' en DUS is het volgens hen onmogelijk dat de browser het juist parsed. Toch doet hij het. Wondere wereld.

Je verhaal toont helemaal niks aan. Als jij aan de browser duidelijk zou weten te maken dat text/gelulinderuimte bij de HTML parser hoort (hoe wou je dat eigenlijk gaan doen?), dan is vanaf dat moment text/gelulinderuimte gelijk aan text/html (ze worden immers gelijk behandeld).

Verder heb ik geen enkele "purist" in dit topic horen zeggen dat XHTML met een text/html mime-type verkeerd gerenderd wordt. Het is geen 100% valid XHTML, maar daar ben je een purist voor Maar de reden dat het goed gerenderd wordt, is niet omdat de browser herkent dat het XHTML is, maar omdat de HTML parser van de meeste browsers redelijk fout-tolerant is. Dat is het hele punt, niet dat het niet zou werken, maar dat je een fout HTML-bestand stuurt (dat eruit ziet als een XHTML bestand), dat genoeg op een gewoon HTML-bestand lijkt. Daarom werkt het!

offtopic:
Als je het nu nog niet begrijpt, ga ik RFC's quoten

[Verwijderd]

Totaal irrelevant. Ik zei het idd verkeerd. Wat ik bedoelde is; het is perfect mogelijk een valide XHTML te maken die zowel geserveerd als XHTML aan firefox als geserveerd als html aan IE, er goed uit ziet. Zolang je dat doet, is er domweg geen probleem, hooguit de gekrenkte puristenziel.

Weer onzin, want je zei dat er geen migratieproblemn zouden onstaan bij het switchen naar XML rendering.

Nee dat is niet (geheel) wat ik vind. Mijn punt is dat fouten gemaakt zullen worden, ongeacht of je je pagina nu schrijft in .txt, .doc, .html, .xhtml, .xml of wat dan ook. Er zullen altijd devvers zijn die fouten maken, al dan niet opzettelijk. Dat is geen argument om te zeggen dat je een bepaalde techniek dan maar niet moet gebruiken.

Dat is een argument om een bepaalde techniek boven een andere aan te raden. Gezien het feit dat de error-handling van de ene techniek niet gericht is op de eind gebruiker, maar de andere wel.

Als ik in IE mijn mimetypes omgooi zodanig dat .jpg als .html gezien wordt, is het niet zo dat de .html die bij me binnenkomt ook daadwerkelijk een .html is, het is nog steeds een .jpg.

Als een .html binnenkomt lijkt me dat die nog steeds als HTML behandeld wordt. Als het een .jpg is wordt hij ook als HTML behandeld... Of mis je daar een stukje tekst?

Dat is ook de reden dat hij in zo'n geval niet correct zou worden weergegeven, immers de browser ziet 'm verkeerd.

De browser krijgt de foutieve metadata over het bestand waardoor het bestand anders is dan de browser denkt dat het is.

Maar volgens mij praten we nogal langs elkaar heen... De punten die je maakt in de rest van het stukje kloppen wel, maar het gaat alleen maar om een uitspraak waar jij het niet mee eens bent dat op internet XHTML als text/html niet echt XHTML is. Het is uiteraard interessant om dat vanuit "lezertjes" e.d. te gaan bekijken maar dat is helemaal niet het punt van de discussie. Het gaat erom dat XHTML als text/html fout is, door browsers niet als XML behandeld zal worden, forward compat problemen creeert (en niet oplost), etc.

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 22:10:
Weer onzin, want je zei dat er geen migratieproblemn zouden onstaan bij het switchen naar XML rendering.

Nope. Jij claimde dat deze problemen moesten onstaan, gebruikte dat als argument. Ik zeg dat het niet hoeft. Bij elke migratie kun je problemen krijgen. Ook bij deze. Als je als developer er bij het ontwikkelen op de juiste manier rekening mee houdt dat een dergelijke switch in de toekomst uitgevoerd kan worden, ontstaan er geen problemen.

Dat is een argument om een bepaalde techniek boven een andere aan te raden. Gezien het feit dat de error-handling van de ene techniek niet gericht is op de eind gebruiker, maar de andere wel.

De pagina die jij aan de eindgebruiker servereert, moet gewoon foutvrij zijn. Foutvrij in de zin van; de gebruiker moet de pagina zien zoals bedoeld, en hij moet werken zoals bedoeld. Niet meer en niet minder. Debuggen is niet het werk van de eindgebruiker, maar van de devver.

Als een .html binnenkomt lijkt me dat die nog steeds als HTML behandeld wordt. Als het een .jpg is wordt hij ook als HTML behandeld... Of mis je daar een stukje tekst?

Je mist de point. Ik bedoel dit.. die .jpg komt als html binnen en wordt inderdaad als zodanig behandelt. Toch is het geen HTML, wat ook al blijkt uit de fouten die je krijgt. Immers, het bestand is nog steeds een .jpg en derhalve niet als HTML te gebruiken.

De browser krijgt de foutieve metadata over het bestand waardoor het bestand anders is dan de browser denkt dat het is.

Neeeeeee. Het bestand is nog steeds hetzelfde. De juiste zin is:

De browser krijgt de foutieve metadata over het bestand waardoor het bestand door de browser verkeerd gelezen wordt.

[André]

En hoe lang gaan we nog door met het herhalen van dezelfde punten? Elk punt is al een aantal keer genoemd alleen sommigen gaan toch weer opnieuw vanuit een andere hoek het punt benaderen. Zo langzamerhand hebben we alles wel gehoord....

[crisp]

Verwijderd schreef op zondag 17 april 2005 @ 21:50:
[...]
Het is de inhoud en ook alleen de inhoud van het bestand wat bepaald wat het type is. Niet een van de tig stikkertjes die wij (of webservers) er op kunnen plakken om het voor elkaar te krijgen dat de juiste lezer geselecteerd wordt. De mensen die het hier met mij oneens zijn snappen imo niet dat een bestandsextentie en een mimetype niet meer dan labels op de verpakking zijn, bedoeld om de verdere verwerking van de inhoud van die verpakking goed te laten verlopen.

[rml]crisp in "[ html/alg] XHTML als text/html, wat is h..."[/rml]

In sommige gevallen is meta-data wel degelijk belangrijk en het is ook gewoon onderdeel van de data. Soms heb je gewoon een label nodig om te kunnen zeggen wat iets is, en een computer heeft dat dan zeker nodig.

Maar nogmaals, en dat is volgens mij het hele punt van deze discussie en waar we volgens mij langs elkaar heenpraten ( ), ik bezie XHTML als een techniek, en beoordeel het dan ook in z'n toegepaste vorm - dat is immers waar het uiteindelijk om gaat. Als jouw mooie XHTML document in toegepaste vorm enkel HTML-kenmerken heeft dan zeg ik dat het HTML is (dat wil niet zeggen dat het wel XHTML kan zijn, maar niet op dat moment).

Als ik het volgende stukje PHP door een javascript engine heengooi is het op dat moment dan nog wel PHP?

code:

$a = 10;
$b = 20;
$c = $a + $b;

[crisp]

André schreef op zondag 17 april 2005 @ 22:33:
En hoe lang gaan we nog door met het herhalen van dezelfde punten? Elk punt is al een aantal keer genoemd alleen sommigen gaan toch weer opnieuw vanuit een andere hoek het punt benaderen. Zo langzamerhand hebben we alles wel gehoord....

Zolang we nog niet met modder naar elkaar gaan gooien zie ik daar geen bezwaar tegen

Daarbij is het zo dat juist door het meermalen belichten van de materie vanuit diverse standpunten je gaandeweg beter in staat bent om je eigen standpunt onder woorden te brengen; ik denk dat we wat dat betreft nu al meer bereiken dan in het begin toen we het nog over erwten en erwtensoep hadden

Als je zelf moe wordt van de discussie raad ik je aan gewoon even verder te klikken en de mensen die graag verder willen discuseren hun gang te laten gaan.

Overigens kan ik me hezik's standpunt toch ook wel een beetje voorstellen hoor (je moet je ook kunnen inleven in andermans standpunten wil je daar voor jezelf een oordeel over kunnen vellen), alleen vind ik mijn eigen benadering juister. Dat daar een verschil van mening over blijft kan en mag best, daar heb ik best vrede mee en dan wil ik o.a. hezik best bedanken voor het uiteenzetten van zijn standpunten en meningen. We zijn het dan misschien niet met elkaar eens, maar hebben wel beide op een andere manier over dingen nagedacht en ook nog eens wat discussie-vaardigheden opgedaan

[bgever]

Verwijderd schreef op zondag 17 april 2005 @ 18:59:
[...]
Ik durf rustig te zeggen dat zeker meer dan 50% van de 'gewone' HTML's al niet wellformed zijn.

Correct. En het was júist de bedoeling om met XHTML dit tegen te gaan. Met een meer afdwingende standaard (immers, de XML parser zou zijn nek moeten breken over fouten).
Allemaal prachig, maar XHTML heeft wel een hele lelijke "feature" waardoor er nóg ranzigere dingen zijn toegestaan als júist malformed HTML over het net versprijden! Iets deed daar bij mij een belletje rinkelen...

Wat ik jammer vind, is dat XHTML zich conflicteert met de HTML standaard door zichzelf voor te doen als HTML maar dit niet helemaal goed doet, en dit gedag goedkeurt doordat het door de implementaties van de standaard toevallig geaccepteerd wordt... XHTML zou zich gewoon niet met de HTML standaard moeten bemoeien!

Het argument "maar het werkt toch?" vind ik niet bepaald mooi. Ik kan ook met een te brede auto op de weg gaan rijden, want het werkt toch? Iedereen vliegt de berm in voor mij! Totdat iemand het een keer niet doet...

---

Jullie verwarren hoe een bestand gelezen wordt met wat het bestand echt is. Hoe het gelezen wordt, bepaald NIET wat het is.

Nee, jij wilt maar niet de twee perspectieven uit elkaar halen, en wakkert maar de hele tijd een onnodige discussie aan. Ik heb al een aantal keren aangegeven dat er twee perspectieven zijn. En dat jij in het ene wel gelijk hebt, maar het ander niet. En dat je appels met peren aan het vergelijken bent. Kun je daar dan nu echt a.u.b. een keer mee ophouden, want ik wordt er een beetje moe van...
En mocht je er dan niet mee eens zijn, probeer dat browser perspectief dan maar aan te vechten met goede argumenten, want tot dusver doe je dit helemaal niet, en maak je een probleem van iets wat helemaal niet bestaat.

Om nog maar eens een uitspraak te quoten:

Verwijderd schreef op zondag 17 april 2005 @ 19:33:
[...]
Het een sluit het ander niet uit. Het ligt er maar net aan vanuit welk referentiekader je het bekijkt. Beide kampen kijken vanuit twee verschillende referentiekaders, waardoor dit een zinloze discussie is. Beide partijen hebben gelijk vanuit hun eigen referentiekader, waarom dan nog door blijven hameren?
[...]
Deze discussie voortzetten slaat compleet nergens op aangezien iedereen vanuit zijn eigen referentiekader gelijk heeft. Niemand heeft ongelijk. Dus proberen de ander te overtuigen is nogal verspilling van je tijd.

---

Verwijderd schreef op zondag 17 april 2005 @ 19:42:
[...]
Ik heb eerder al gezegd dat iedereen het voor zichzelf moet bepalen, in plaats van blind achter anderen (inclusief ik) aan te gaan.

Dat vind ik wel een gewaagde uitspraak, en wel een zeer zwak argument om de discussie maar af te wimpelen, want zo kun je elk meningsverschil wel oplossen.
Om iets te kunnen geloven zul je toch echt iets van iemand anders moeten aannemen... Of dat nu van een bron is hier op het forum, of een website, zolang je de kwaliteit maar kan controleren...

Vervolgens gaan mensen door met Hixie sprookjes en onwaarheden verkondigen. Dat probeer ik recht te zetten, ik probeer mensen iets bij te leren, en dat is waarom ik erop door ging.

Sprookjes? Onwaarheden? Verklaar je nader...

[Verwijderd]

oikoyama schreef op zondag 17 april 2005 @ 23:04:
Het argument "maar het werkt toch?" vind ik niet bepaald mooi. Ik kan ook met een te brede auto op de weg gaan rijden, want het werkt toch? Iedereen vliegt de berm in voor mij! Totdat iemand het een keer niet doet...

Een verkeerde vergelijking, immers er heeft niemand last van als ik aan IE een xhtml serveer als HTML. Mits ik er voor zorg dat die XHTML er in die representatie ook goed uitziet, is er NIEMAND die er last van heeft. Dat is heel iets anders dan 'iedereen vliegt de berm in voor mij'.

Nee, jij wilt maar niet de twee perspectieven uit elkaar halen, en wakkert maar de hele tijd een onnodige discussie aan.

Heb je de topictitel wel eens goed bekeken? Zo nee, voor alle zekerheid:

XHTML als text/html, wat is het?

die hele 'onnodige discussie' is dus het onderwerp van dit topic. Als je daar moe van wordt, moet je naar een ander topic gaan omzien imo, nofi.

Ik heb al een aantal keren aangegeven dat er twee perspectieven zijn. En dat jij in het ene wel gelijk hebt, maar het ander niet.

Er zijn geen twee perspectieven. Er is er maar eentje. Een bestand is iets, of het is het niet.

crisp schreef op zondag 17 april 2005 @ 22:38:
Als ik het volgende stukje PHP door een javascript engine heengooi is het op dat moment dan nog wel PHP?

code:

$a = 10;
$b = 20;
$c = $a + $b;

We hebben het hier niet over het serveren van halve pagina's toch?

Dus.. als jij deze .php (bestandsnaam crisps.php):

code:

<?php
$a = 10;
$b = 20;
$c = $a + $b;
?>

door een java parser heengooit, is het inderdaad nog steeds PHP

Maar goed, ik had me al een tijdje stilgehouden, en zal dat nu weer gaan doen.. de standpunten zijn inderdaad wel duidelijk, en we gaan het op sommige punten gewoon never nooit niet eens worden

[ Voor 24% gewijzigd door Verwijderd op 17-04-2005 23:13 ]

[JHS]

Verwijderd schreef op zondag 17 april 2005 @ 23:10:
Er zijn geen twee perspectieven. Er is er maar eentje. Een bestand is iets, of het is het niet.

Natuurlijk zijn er wel twee perspectieven. Je bepaald aan de hand van bepaalde eigenschappen wat iets is. Dat kan de intentie van de auteur zijn, het mime-type, het doctype, de extentie, de syntax, of het XML eigenschappen heeft (zie posts van crisp en Anne) en nog een hele hoop zaken. Er is geen objectieve maatstaf voor. Net zoals we een mens onder de mensen scharen omdat die een bepaalde set eigenschappen heeft. Als jij alleen maar in staat bent om naar een bepaald deel van die eigenschappen te kijken, of alleen maar geïnterresseerd bent in een deel van die eigenschappen (mens / browser verschil), kan het voorkomen dat je iets ander benoemt dan een ander.

edit:

Verwijderd schreef op zondag 17 april 2005 @ 23:10:
Maar goed, ik had me al een tijdje stilgehouden, en zal dat nu weer gaan doen.. de standpunten zijn inderdaad wel duidelijk, en we gaan het op sommige punten gewoon never nooit niet eens worden

Als jij ((semi)nieuwe) argumenten aandraagt, en ik reageer daar op een ((semi)nieuwe) manier op, hoop ik toch wel dat je reageert, zeker nu deze discussie al zo lang bezig is, en nu toch in enige mate lijkt te vorderen. Iniedergeval zijn de standpunten nu weer wat verder uitgekristaliseert.

[ Voor 26% gewijzigd door JHS op 17-04-2005 23:18 ]

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 23:10:
[...]

Er zijn geen twee perspectieven. Er is er maar eentje. Een bestand is iets, of het is het niet.

Als je mijn reply hebt gelezen en het niet met me eens bent, dan vind ik dat je een enorme plaat voor je kop hebt. Wanneer je namelijk vanuit browser perspectief bekijkt, dan is het wel mall formed html. De browser verwacht html vanwege het content-type: text/html, maar krijgt dat niet. Dan zegt hij: eey, dit is mall formed html. huh? ow, ik kan er nog iets van maken. Doen we dat toch...

Ik vind het nogal vreemd dat je er vanuit gaat dat je deze vraag maar vanuit een richting kan benaderen, je kan een probleem altijd op minimaal twee manieren benaderen. Iets is kort, of iets is niet lang. Iets is hoog of iets is niet laag. etc. Voor de browser is de data die hij toegestuurd krijgt mall formed html aangezien hij HTML verwacht en het niet krijgt. Is dit zo moeilijk te bevatten?

[ Voor 25% gewijzigd door Verwijderd op 17-04-2005 23:27 ]

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 23:24:
[...]


Als je mijn reply hebt gelezen en het niet met me eens bent, dan vind ik dat je een enorme plaat voor je kop hebt. Wanneer je namelijk vanuit browser perspectief bekijkt, dan is het wel mall formed html. De browser verwacht html vanwege het content-type: text/html, maar krijgt dat niet. Dan zegt hij: eey, dit is mall formed html. huh? ow, ik kan er nog iets van maken. Doen we dat toch...

dan nog kan een browser zien aan de doctype hoe hij die file moet behandelen, doet hij dat niet, dan is dat zijn eigen probleem en moet hij er maar wat van maken. een XHTML file is en blijft valid XHTML ook al geef je hem aan als text/html, dat sommige browsers dat niet begrijpen is hun probleem, zolang ze hem maar goed weergeven (wat imo ook altijd gebeurd)

[Verwijderd]

Erkens schreef op zondag 17 april 2005 @ 23:29:
[...]

dan nog kan een browser zien aan de doctype hoe hij die file moet behandelen, doet hij dat niet, dan is dat zijn eigen probleem en moet hij er maar wat van maken. een XHTML file is en blijft valid XHTML ook al geef je hem aan als text/html, dat sommige browsers dat niet begrijpen is hun probleem, zolang ze hem maar goed weergeven (wat imo ook altijd gebeurd)

De data is inderdaad nog XHTML... maar niet voor de browser... die ziet het als verkeerde HTML. en doctype vertelt volgens mij niet wat het document *is*. Maar dat weet Anne vast beter.

/me gooit er nog een voedsel analogie tegenaan
Als ik jou een boterham met pindakaas geef en zeg; alsjeblieft een boterham met jam. Dan vind jij het toch ook niet raar dat je vreemd opkijkt als je een hap neemt? Voordat jij die hap neemt heb jij gewoon een boterham met jam in je hand, je weet immers niet beter. Dat dat toevallig gelogen is en niet de waarheid is maakt niet uit. Jou waarheid is: ik heb een boterham met jam.
De browsers waarheid is dat hij verkeerde html voor zich heeft, omdat hij gewoon niet weet dat het stiekem xhtml is. Jij had ook kunnen kijken of die boterham toevallig niet iets anders bevatte, maar dat deed je niet. Kortom, voor jou is het nog steeds een boterham met jam, terwijl de waarheid is dat het een boterham met pindakaas is. Zelfde voor de browser.

[ Voor 40% gewijzigd door Verwijderd op 17-04-2005 23:36 ]

[crisp]

Verwijderd schreef op zondag 17 april 2005 @ 23:10:
[...]
Een verkeerde vergelijking, immers er heeft niemand last van als ik aan IE een xhtml serveer als HTML. Mits ik er voor zorg dat die XHTML er in die representatie ook goed uitziet, is er NIEMAND die er last van heeft. Dat is heel iets anders dan 'iedereen vliegt de berm in voor mij'.

Het verplicht andere browserbouwers wel om dezelfde mate van error-correctie als IE gebruikt in te bouwen in hun eigen browsers. Als het om stricte interpretaties gaat is IE natuurlijk niet het juiste meetinstrument, maar helaas wel het meest gebruikte instrument. Dat niemand er last van heeft is dus puur omdat er rekening mee gehouden wordt in browserengines, maar dat maakt het nog niet 'goed' (maar dat is dan weer een puristisch standpunt )

Er zijn geen twee perspectieven. Er is er maar eentje. Een bestand is iets, of het is het niet.

Ik denk dat er wel degelijk 2 perspectieven zijn; bekeken vanuit hoe jij iets bedoelt hebt, en bekeken vanuit hoe het toegepast wordt. Je zegt zelf dat labels niet uitmaken, dus een doctype doet dat ook niet (dus heb ik die in mijn voorbeeld bewust weggelaten). Een mimetype is echter meer dan enkel een label; het zegt ook hoe er mee omgegaan moet worden, daar zijn gewoon afspraken over gemaakt. Een DTD zegt enkel iets over de syntax en de elementen en attributen die toegestaan zijn en in welke context - handig voor validatie, maar verder weinig tot geen toegepaste waarde.

[...]
We hebben het hier niet over het serveren van halve pagina's toch?

Dus.. als jij deze .php (bestandsnaam crisps.php):

code:

<?php
$a = 10;
$b = 20;
$c = $a + $b;
?>

door een java parser heengooit, is het inderdaad nog steeds PHP

Wie zegt dat ik dat bestand opgeslagen heb met een .php extensie? Laten we zeggen dat het bestand crisp.foo heet en ik helemaal niet hebt gezegd dat het PHP zou moeten zijn. Jij haalt het door een PHP parser en het werkt, dus jij zegt 'het is PHP'. Iemand anders haalt dat bestand door een javascript parser (valid java is het niet ) en dat werkt ook, dus die iemand zegt 'het is javascript'. Tsja, ze hebben beiden gelijk... had ik maar duidelijker moeten zijn, misschien door een mimetype mee te geven...

Maar goed, ik had me al een tijdje stilgehouden, en zal dat nu weer gaan doen.. de standpunten zijn inderdaad wel duidelijk, en we gaan het op sommige punten gewoon never nooit niet eens worden

Zolang je maar niet met modder gaat gooien

Ik merk wel bij mensen hier in deze discussie dat het soms wat persoonlijker wordt, probeer jezelf op dat vlak aub wat in te houden; het is nergens voor nodig en verzwakt je eigen argumenten.

[bgever]

Verwijderd schreef op zondag 17 april 2005 @ 23:10:
[...]
Heb je de topictitel wel eens goed bekeken? Zo nee, voor alle zekerheid:

Jazeker, en het grote probleem van deze topictitel is dat er niet bij staat voor wie dit geldt! Ik ga er van uit dat dit voor de browser geldt, omdat "als text/html" een verwerkingsproces aangeeft. Het mens perspectief heeft eigenlijk geen MIME-type verwerkingsproces, een mens ziet namelijk alleen iets. Maar het browser perspectief wel, omdat deze een response van een webserver verwerkt. Tijdens dit verwerkingsproces gebeurt er iets met dit document, en daar gaat deze duscussie over.

die hele 'onnodige discussie' is dus het onderwerp van dit topic. Als je daar moe van wordt, moet je naar een ander topic gaan omzien imo, nofi.

Ik wordt er moe van dat jij niet wilt inzien dat er twee perspectieven zijn. Er is al een aantal keren aangegeven door diverse mensen dat dit dus wel zo is. Maar zolang we het hier niet over eens kunnen worden, vind ik het een onnodige discussie.

Er zijn geen twee perspectieven. Er is er maar eentje. Een bestand is iets, of het is het niet.

Dan interpreteer jij de titel dus anders dan ik...

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 23:31:
[...]


De data is inderdaad nog XHTML... maar niet voor de browser... die ziet het als verkeerde HTML. en doctype vertelt volgens mij niet wat het document *is*. Maar dat weet Anne vast beter.

wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype )

[Verwijderd]

oikoyama schreef op zondag 17 april 2005 @ 23:37:

[...]

Dan interpreteer jij de titel dus anders dan ik...

Om hier verder op in te gaan...

Als de vraag komt: "XHTML als text/html, wat is het?" Dan vraag ik me meteen af. Wacht eens, deze vraag is niet compleet. Vanuit wiens oogpunt? Browsers perspectief of document perspectief?

[Verwijderd]

Erkens schreef op zondag 17 april 2005 @ 23:40:
[...]

wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype )

Wat fijn dat jij wel de waarheid in pacht hebt en dat jij zomaar kan zeggen dat ik iets verkondig zonder te weten waar ik het over heb. Dank je... Ik zal mijn mond wel houden. Jongens, waarom discussieren we nog? Erkens heeft gelijk... \o/

[bgever]

Erkens schreef op zondag 17 april 2005 @ 23:40:
[...]
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig

Een doctype is niet bedoelt om te beschrijven wat het is. Het is een verwerkings instructie voor de SGML parser. Deze is bedoelt om het document te controleren op geldigheid. Net als een XML Schema (XSD) dat doet. Dat je het toevallig kunt gebruiken om te controleren wat het is, maakt nog niet dat het hiervoor gemaakt is.
Het is namelijk toegestaan om een DTD uit een HTML document te laten...

[Erkens]

crisp schreef op zondag 17 april 2005 @ 23:36:
Wie zegt dat ik dat bestand opgeslagen heb met een .php extensie? Laten we zeggen dat het bestand crisp.foo heet en ik helemaal niet hebt gezegd dat het PHP zou moeten zijn. Jij haalt het door een PHP parser en het werkt, dus jij zegt 'het is PHP'. Iemand anders haalt dat bestand door een javascript parser (valid java is het niet ) en dat werkt ook, dus die iemand zegt 'het is javascript'. Tsja, ze hebben beiden gelijk... had ik maar duidelijker moeten zijn, misschien door een mimetype mee te geven...

maar het uitendelijke doel is hetzelfde, je krijgt je uitkomst van je som.
overigens, als het PHP was geweest dan had je je file begonnen met <?php waarover een javascript parser als het goed is moet struikelen, hetzelfde geld natuurlijk ook andersom.

als we dit terugkoppelen naar het XHTML verhaal, stel een browser krijgt XHTML als text/html en die denkt serieus dat het HTML4 is.
Dan zijn er een paar verschillen (http://www.w3.org/TR/xhtml1/#diffs)
"Documents must be well-formed"
in HTML4 moet je document ook well-formed zijn, ook al maakt het sommige browsers niks uit, maw een browser zal hier geen probleem mee hebben.

"Element and attribute names must be in lower case"
ook hierover zal een browser niet struikelen.

"For non-empty elements, end tags are required"
zal niks uitmaken, een browser zou hier juist blij mee moeten zijn, duidelijkheid waar iets begint en eindigd.

"Attribute values must always be quoted"
juist extra handig, maakt de browser dus ook niks uit, moet hij mee overweg kunnen.

"Attribute Minimization"
ook hier zal een browser geen last van hebben

"Empty Elements"
dit is wellicht een puntje, maar de huidige browsers (die ik ken) maken hiervan geen probleem (standaard doe ik altijd al een spatie voor de sluit slash, bij XHTML maakt dat niet uit)

etc etc
het gaat om het resultaat

terug op de titel van dit topic: het is nogsteeds XHTML, echter als de browser neit weet wat XHTML is, dan zal hij het gewoon als HTML4 _kunnen_ behandelen

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 23:42:
[...]


Wat fijn dat jij wel de waarheid in pacht hebt en dat jij zomaar kan zeggen dat ik iets verkondig zonder te weten waar ik het over heb. Dank je... Ik zal mijn mond wel houden. Jongens, waarom discussieren we nog? Erkens heeft gelijk... \o/

ik zeg niet dat ik gelijk heb, maar jij weet het niet zeker, maakt niks uit, maar zoek het dan even op ipv het te verkondingen en dan iemand anders er maar bij roepen als "argument"

oikoyama schreef op zondag 17 april 2005 @ 23:48:
Het is namelijk toegestaan om een DTD uit een HTML document te laten...

hmm, bron?
afaik is die HTML file dan niet valid.

[Verwijderd]

aan een dtd zou je prima kunnen aflezen wat voor document het is, punt is dat IE gewoon geen xhtml parser heeft en er dus gewoon niks anders mee kan dan parsen als html.

Dat maakt het dus voor ontwikkelaars mogelijk om invalid xhtml te bouwen (dat dus never door een xhtml parser zou komen) en dat maakt het voor andere browsers noodzakelijk om dat ook na te leven, omdat er op een bepaald moment gewoon zulke documenten zijn

dit maakt het vervolgens voor ontwikkelaars weer mogelijk om (nu valid) xhtml als text/html te versturen en het voor w3c dus noodzakelijk dit toe te laten en hier compatibilityguidelines over te schrijven.

[ Voor 6% gewijzigd door Verwijderd op 17-04-2005 23:59 ]

[Verwijderd]

Erkens schreef op zondag 17 april 2005 @ 23:40:
[...]

wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype )

Een DOCTYPE is slechts bedoelt om tussen versies te kiezen, nadat al is vastgesteld om wat voor document het gaat. Bij text/html, verwacht de browser een HTML document. Vervolgens bepaalt de DOCTYPE slechts nog om welke versie van HTML het gaat. Het zou natuurlijk kul zijn om aan de hand van de content te bepalen om wat voor content het gaat. In dat geval zou een content-type meesturen helemaal niet nodig zijn.

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 23:58:
aan een dtd zou je prima kunnen aflezen wat voor document het is, punt is dat IE gewoon geen xhtml parser heeft en er dus gewoon niks anders mee kan dan parsen als html.

dat is dus een probleem voor IE, en gelukkig voor de ontwikkelaar is om de meeste zaken eenvoudig heen te werken (http://www.w3.org/TR/xhtml1/#guidelines)

Dat maakt het dus voor ontwikkelaars mogelijk om invalid xhtml te bouwen (dat dus never door een xhtml parser zou komen) en dat maakt het voor andere browsers noodzakelijk om dat ook na te leven

het maakt het mogelijk, maar in dat geval is de kennis van die ontwikkelaar gewoon niet goed en is het _zijn_ schuld, niet de schuld van een content-type. Daarnaast is text/html, gewoon toegestaan voor XHTML (oa http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/)

dit maakt het vervolgens voor ontwikkelaars weer mogelijk om (nu valid) xhtml als text/html te versturen en het voor w3c dus noodzakelijk dit toe te laten en hier compatibilityguidelines over te schrijven.

opzich, true, echter een slimme browser had even naar de DTD kunnen kijken om zich wat moeite te besparen. Maar teruggaand naar het topic, het doet geen afbreuk op het feit dat die file nogsteeds XHTML is.

[Verwijderd]

IE rendert pagina bijna niet

kijk, dat bedoel ik nu, daarom moeten mensen zich niet zomaar aan xhtml overgeven

@Erkens: een andere browser kan dan wel zeggen up yours met al die malformed xhtml documenten, maar daar krijgen ze geen marktaandeel mee, ze zijn dus min of meer gedwongen mee te gaan, je wilt dus xhtml als text/html niet parsen als xhtml omdat dat het web overhoop helpt.

[ Voor 53% gewijzigd door Verwijderd op 18-04-2005 00:07 ]

[crisp]

Erkens schreef op zondag 17 april 2005 @ 23:40:
[...]

wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype )

Nee, een DTD beschrijft waar de syntax van een document aan moet voldoen, en biedt browsers de mogelijkheid aan de hand van de URI in de DTD om de preciese specificaties daarvan te downloaden en het document daaraan te toetsen. Dat is echter niet verplicht en de meestgebruikte browsers doen dat ook niet. Het zegt verder helemaal niets over hoe het document behandeld dient te worden (XHTML mag immers als HTML behandeld worden, punt is dat het op dat moment praktisch gezien ook gewoon HTML is).

Ik was vorig jaar op safari met Ian Hickson (niet te verwarren met de browser safari aangezien Ian voor Opera werkt, maar ik heb niet zoveel met dikke zingende dames ) en daar hebben we leeuwen bestudeerd in hun natuurlijke omgeving. Ian zei toen tegen mij: 'kijk, dat is nou XHTML'.
Nu was ik vorige week in Artis met hezik, en die wees mij toen op een leeuw in een kooi, en zei toen ook tegen mij: 'kijk, dat is nou XHTML'. Ik antwoorde toen: 'Nou, het lijkt meer op onze huiskat' (die overigens Bonk heet).

XHTML is dus meer dan alleen hoe het eruit ziet in textuele representatie. Meer dan enkel een XML-like syntax sausje en een hippe DTD. Ik kijk naar alle eigenschappen van XHTML in een XHTML omgeving en beoordeel dan of het echt XHTML is. Als de toegepaste vorm echter alle eigenschappen van HTML heeft, en de specifieke eigenschappen van XHTML mist dan zeg ik dat het gewoon HTML is.
Natuurlijk kan je XHTML toepassen zonder specifieke XHTML eigenschappen te gebruiken. In dat geval is het ook nog eens volledig identiek aan HTML, of kan het in ieder geval doorgaan daarvoor (dankzij error-correction etcetera), en is enkel de DTD nog maar een leidraad, maar die doet dus niet terzake Eenmaal toegepast blijft het HTML, en je kan me wel blijven wijsmaken dat de leeuw in het kooitje een wild dier is, ik merk er echter weinig van...

[Erkens]

Verwijderd schreef op maandag 18 april 2005 @ 00:03:
Het zou natuurlijk kul zijn om aan de hand van de content te bepalen om wat voor content het gaat. In dat geval zou een content-type meesturen helemaal niet nodig zijn.

niks kul, computers doen niks anders dan kijken naar de content (header van een file*) om te bepalen wat ze ermee kunnen. van te voren aangeven wat ze ermee kunnen is gewoon een handige tool voor de browser, en ze zullen dom zijn om die te negeren.


* Waarom denk je anders dat bijna elke file een identificatie heeft van wat hij is? Linuxexecutables (ELF), Windows/DOS executables (MZ), ZIP Files (PK), PNG files (PNG), PDF files (PDF) etc etc, nog nooit opgevallen?

[bgever]

Erkens schreef op zondag 17 april 2005 @ 23:52:
[...]
hmm, bron?
afaik is die HTML file dan niet valid.

Hmm, ik kan inderdaad niet vinden dat het optioneel is. HEAD en BODY elementen tags zijn wel optioneel. Zonder DTD is een document dus malformed HTML, maar wordt wel door de browsers geaccepteerd. Ik had het dus bij het foute eind, mijn excuses.

[ Voor 2% gewijzigd door bgever op 18-04-2005 00:21 . Reden: haal tags en elementen nog steeds door elkaar... ]

[Verwijderd]

elementen niet, alleen de tags de elementen zal je wel in de dom terug vinden (zelfde geldt voor tbody bv)

...authors must include one of the following document type declarations in their documents.

moet dus gewoon

[ Voor 41% gewijzigd door Verwijderd op 18-04-2005 00:20 ]

[crisp]

Erkens schreef op maandag 18 april 2005 @ 00:09:
[...]

niks kul, computers doen niks anders dan kijken naar de content (header van een file*) om te bepalen wat ze ermee kunnen. van te voren aangeven wat ze ermee kunnen is gewoon een handige tool voor de browser, en ze zullen dom zijn om die te negeren.


* Waarom denk je anders dat bijna elke file een identificatie heeft van wat hij is? Linuxexecutables (ELF), Windows/DOS executables (MZ), ZIP Files (PK), PNG files (PNG), PDF files (PDF) etc etc, nog nooit opgevallen?

Dat geldt niet voor alle bestanden. Er zijn verschillende manieren waarop een OS besluit hoe met een bestand om te gaan. mimetype en file-extensie zijn andere voorbeelden (en dat laatste heeft in windows nogal eens voor problemen gezorgd). In Linux zal je verder een bestand ook expliciet als executable moeten aanduiden voordat je het kan uitvoeren. Mac doet (meen ik) helemaal niets met extensies. Het zijn allemaal truukjes, maar op het moment dat een bestand qua inhoud voor zowel XHTML als voor HTML kan doorgaan is de mimetype toch wel leading om te bepalen wat het nou eigenlijk is (want DTD wordt dus niet naar gekeken) browser-perspective, toegepaste omgeving jada-jada.

[ Voor 6% gewijzigd door crisp op 18-04-2005 00:28 ]

[JHS]

Het verschil is dat hezik en Erkens niet erkennen dat een bestand meer eigenschappen heeft dan alleen de "content" en de syntax. Als je alleen op grond daarvan baseert wat een bestand is hebben ze gelijk. Als je echter ook andere eigenschappen zoals mime-type, maar ook hoe het om kan gaan met andere XML varianten, hoe je scripting toe moet passen, etcetera, meeneemt dan kan het best iets anders zijn.

Waaraan bepaal je of iets een boterham met jam is? Aan de smaak, kleur, structuur, etcetera. Maar misschien is het vanuit een ander perspectief helemaal geen jam. Misschien is het wel synthetisch gemaakt van gelatine, en kan je vinden dat het dus geen jam is, maar bewerkte gelatine. Er is geen objectief absoluut meetmiddel om te bepalen wat het is. Je kijkt naar bepaalde eigenschappen, kijkt wat je het belangrijkst vind, en bepaald dan wat je kiest.

En aangezien bovenstaande volgens mij een onoverbrugbaar meningsverschil is tussen hezik / Erkens / ea? en de rest, gaat er volgens mij nóóit een antwoord op komen. De ene vind het andere eigenschappen verhaal een acceptabel perspectief, de ander niet.

Maar wat veel belangrijker is, is wat Cheetah en anderen al zeiden. Het gaat erom dat het werkt. En daarvoor is kennis benodigd. Het gaat er dus om dat mensen die kennis opdoen, en dat ze hun dingen kunnen laten werken.

[Erkens]

JHS schreef op maandag 18 april 2005 @ 08:10:
Het verschil is dat hezik en Erkens niet erkennen dat een bestand meer eigenschappen heeft dan alleen de "content" en de syntax. Als je alleen op grond daarvan baseert wat een bestand is hebben ze gelijk. Als je echter ook andere eigenschappen zoals mime-type, maar ook hoe het om kan gaan met andere XML varianten, hoe je scripting toe moet passen, etcetera, meeneemt dan kan het best iets anders zijn.

waar lees jij dat ik dat niet erken?

Waaraan bepaal je of iets een boterham met jam is? Aan de smaak, kleur, structuur, etcetera. Maar misschien is het vanuit een ander perspectief helemaal geen jam. Misschien is het wel synthetisch gemaakt van gelatine, en kan je vinden dat het dus geen jam is, maar bewerkte gelatine. Er is geen objectief absoluut meetmiddel om te bepalen wat het is. Je kijkt naar bepaalde eigenschappen, kijkt wat je het belangrijkst vind, en bepaald dan wat je kiest.

slecht voorbeeld, het maakt niet uit hoe het is gemaakt, maar dat het die eigenschappen heeft.

Maar wat veel belangrijker is, is wat Cheetah en anderen al zeiden. Het gaat erom dat het werkt. En daarvoor is kennis benodigd. Het gaat er dus om dat mensen die kennis opdoen, en dat ze hun dingen kunnen laten werken.

en dat is ook precies wat ik probeer te vertellen

[JHS]

Erkens schreef op maandag 18 april 2005 @ 08:39:
waar lees jij dat ik dat niet erken?

Geen idee, maar zo kwam het zeker op me over .

slecht voorbeeld, het maakt niet uit hoe het is gemaakt, maar dat het die eigenschappen heeft.

Natuurlijk maakt het wel uit. Op chemisch niveau heeft gelatine toch echt andere eigenschappen . Bovendien vind hezik dat het wel uitmaakt: "het is gemaakt als gelatine, dus is het gelatine". Ok, wat betreft dat laatste had ik misschien wel een beter voorbeeld kunnen kiezen, maar ik kom niet zo snel op iets anders...

en dat is ook precies wat ik probeer te vertellen

Mooi . Zo kwam het echter eerlijkgezegd niet op me over .

[ Voor 23% gewijzigd door JHS op 18-04-2005 08:48 ]

[Verwijderd]

dan nog kan een browser zien aan de doctype hoe hij die file moet behandelen, doet hij dat niet, dan is dat zijn eigen probleem en moet hij er maar wat van maken.

De HTML WG heeft tegen Mozilla gezegd dat XHTML als text/html HTML is en niet als XHTML behandeld dient te worden.

http://lists.w3.org/Archives/Public/www-html/2000Sep/0024

Eerlijk gezegd dacht ik dat iedereen hier inmiddels wel bekend mee was aangezien ik het in voorgaande discussies meerdere malen heb gepost, maar ok.

een XHTML file is en blijft valid XHTML ook al geef je hem aan als text/html, dat sommige browsers dat niet begrijpen is hun probleem, zolang ze hem maar goed weergeven (wat imo ook altijd gebeurd)

Niet echt. CSS2 zegt bijvoorbeeld dat 'background' op het BODY element op de canvas gezet zou moeten worden in HTML documenten, maar niet in XHTML documenten. Drie keer raden wat browsers doen in een text/html omgeving. Precies, ze volgen de guidelines van het W3C dat XHTML als text/html gewoon HTML is...

[Verwijderd]

die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig

Een DOCTYPE is een overblijfsel uit de SGML wereld en heeft een aantal voordelen. In text/html documenten kun je er "quirks mode", "almost standards mode" en "standards mode" mee triggeren in browsers. In XML documenten kun je met sommige XHTML doctypes bepaalde entities gebruiken in browsers omdat browsers interne mappers hebben voor bepaalde doctypes.

http://lxr.mozilla.org/se...src/nsExpatDriver.cpp#205

Doctypes dienen verder geen enkel nut aangezien browsers geen "validating parsers" hebben zoals dat in de SGML tijd nog bestond.

Merk ook op dat in XML het niet uitmaakt of je <b><h2>foo</h2></b> doet. De DOM blijft er zo uitzien en je krijgt geen raar HTML DOM waar <b> wellicht in de H2 beland ofzo.

[Verwijderd]

het maakt het mogelijk, maar in dat geval is de kennis van die ontwikkelaar gewoon niet goed en is het _zijn_ schuld, niet de schuld van een content-type. Daarnaast is text/html, gewoon toegestaan voor XHTML (oa http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/)

Heb je ook een normatieve bron?

http://annevankesteren.nl/archives/2004/08/xhtml-media-types

[Verwijderd]

Hmm, ik kan inderdaad niet vinden dat het optioneel is. HEAD en BODY elementen tags zijn wel optioneel. Zonder DTD is een document dus malformed HTML, maar wordt wel door de browsers geaccepteerd. Ik had het dus bij het foute eind, mijn excuses.

Als er al zoiets bestond als malformed HTML zou het nog best "formed HTML" kunnen zijn. Alleen niet valid. Daarnaast is een document zonder DOCTYPE onbetrouwbaar in text/html met de huidige browsers.

[curry684]

Erkens schreef op maandag 18 april 2005 @ 00:09:
[...]

niks kul, computers doen niks anders dan kijken naar de content (header van een file*) om te bepalen wat ze ermee kunnen. van te voren aangeven wat ze ermee kunnen is gewoon een handige tool voor de browser, en ze zullen dom zijn om die te negeren.

* Waarom denk je anders dat bijna elke file een identificatie heeft van wat hij is? Linuxexecutables (ELF), Windows/DOS executables (MZ), ZIP Files (PK), PNG files (PNG), PDF files (PDF) etc etc, nog nooit opgevallen?

Dit is pertinent onzin. De header van een file dient enkel ter metadata over de verdere content van een file nadat het type reeds uniek is gedetermineerd. Windows, Linux of wat voor programma ook zal nooit bij een file zonder extensie of andere metadata de content gaan sniffen om het type van de data te bepalen. Dat kan ook niet, want als ik 10 miljard willekeurige files genereer heb je best kans dat ik daar een paar keer toevallig een file bij heb zitten die toevallig de goede identifiers bevat voor een exe, png of jpeg. De BITMAPFILEHEADER struct van een bmp bevat toevallig wel ergens de 2 lettertjes BM ter bevestiging dat het een valide BMP is, maar dat is reeds nadat het OS/browser op basis van content-type of extensie een BMP-parser uit de kast heeft getrokken.

Op eenzelfde manier functioneert het doctype van een (X)HTML file: het is een bevestiging en verdere specificatie (metadata!) van de content nadat reeds bekend is dat het (X)HTML is. Indien de file als text/plain of application/octet-stream verstuurd is of een .txt extensie heeft mag en zal er nooit naar een doctype gezocht of gekeken worden. Op eenzelfde manier moet een text/html document geparsed worden met een HTML parser die er een HTML DOM van maakt, en moet application/xhtml+xml geparsed worden met een XML parser die er een XHTML DOM van bakt. Je gaat toch ook geen .ico file als BMP parsen?

Het hele probleem van deze discussie is dat een aantal mensen vergeet mee te nemen dat XHTML enkel met een hoop stomme patches en error correction door een HTML-parser heen komt. Als ik hier een topic zou openen "Goh ik verstuur een JPEG-file als image/png, waarom toont ie niets" word ik voor idioot uitgemaakt, maar er is geen enkel verschil met dit topic behalve dat een PNG-parser echt geen ruk bakt van een JPEG, en een HTML-parser met wat moeite nog wel iets begrijpelijks van een XHTML-document kan bakken. Maar het blijft exact dezelfde fout.

[ Voor 13% gewijzigd door curry684 op 18-04-2005 11:15 ]

[bgever]

Verwijderd schreef op maandag 18 april 2005 @ 09:32:
[...]
Als er al zoiets bestond als malformed HTML zou het nog best "formed HTML" kunnen zijn. Alleen niet valid. Daarnaast is een document zonder DOCTYPE onbetrouwbaar in text/html met de huidige browsers.

De standaard vereist dat er boven een HTML document een HTML DTD moet staan. Immers in de standaard staat:

A valid HTML document declares what version of HTML is used in the document. The document type declaration names the document type definition (DTD) in use for the document (see [ISO8879]).
[...]
HTML 4.01 specifies three DTDs, so authors must include one of the following document type declarations in their documents.

Zonder HTML DTD is het verloop dus geen geldige HTML volgens de standaard, want om als HTML document betiteld te worden moet je een DTD hebben.
Gezien de browsers het wel slikken, kun je zeggen dat ze "malformed HTML" accepteren... Malformed zegt namelijk niet enkel dat de elementen slecht geformuleerd zijn het zegt gewoon dat het "slecht geformuleerd" is. Hier weer de vraag, wát is er slecht geformuleerd? HTML, dus de tekst volgens de HTML standaard...

[ Voor 13% gewijzigd door bgever op 18-04-2005 12:34 ]

[Verwijderd]

Verwijderd schreef op maandag 18 april 2005 @ 09:21:

De HTML WG heeft tegen Mozilla gezegd dat XHTML als text/html HTML is en niet als XHTML behandeld dient te worden.

http://lists.w3.org/Archives/Public/www-html/2000Sep/0024

Er staat helemaal nergens dat een XHTML document dat met text/html is verstuurd een HTML document is. Er staat wel dat het als een HTML document behandelt moet worden, en dat er geen verdere controle moet plaatsvinden.

Eerlijk gezegd dacht ik dat iedereen hier inmiddels wel bekend mee was aangezien ik het in voorgaande discussies meerdere malen heb gepost, maar ok.
[...]
Niet echt. CSS2 zegt bijvoorbeeld dat 'background' op het BODY element op de canvas gezet zou moeten worden in HTML documenten, maar niet in XHTML documenten. Drie keer raden wat browsers doen in een text/html omgeving. Precies, ze volgen de guidelines van het W3C dat XHTML als text/html gewoon HTML is...

Nee, het moet worden behandeld als HTML. Dat is een subtiel verschil.

Stel je hebt een doos appels, en een doos peren. Alleen staat er op beide dozen dat er appels in zitten. De peren kunnen net zoals appels worden geschild, in partjes gesneden en geserveerd, maar dan zijn het nog steeds peren. Er hoeven geen nieuwe machines te worden aangeschaft om peren te kunnen verwerken. Dat was het voordeel van overstappen op peren, en niet op sinaasappels. De wereld was nog niet klaar voor sinaasappels.

En die machine blijft gewoon blokjes maken en in potjes doen met daarop een sticker "appels". Zie wat eruit komt als de DOM tree.

[Erkens]

curry684 schreef op maandag 18 april 2005 @ 11:03:
Dit is pertinent onzin. De header van een file dient enkel ter metadata over de verdere content van een file nadat het type reeds uniek is gedetermineerd. Windows, Linux of wat voor programma ook zal nooit bij een file zonder extensie of andere metadata de content gaan sniffen om het type van de data te bepalen. Dat kan ook niet, want als ik 10 miljard willekeurige files genereer heb je best kans dat ik daar een paar keer toevallig een file bij heb zitten die toevallig de goede identifiers bevat voor een exe, png of jpeg. De BITMAPFILEHEADER struct van een bmp bevat toevallig wel ergens de 2 lettertjes BM ter bevestiging dat het een valide BMP is, maar dat is reeds nadat het OS/browser op basis van content-type of extensie een BMP-parser uit de kast heeft getrokken.

dus als ik een zip file ter download aanbied met als content-type application/octet-stream, dan kan jij er niks mee want het is gewoon een grote bende met bytes

[Verwijderd]

Erkens schreef op maandag 18 april 2005 @ 14:03:
[...]

dus als ik een zip file ter download aanbied met als content-type application/octet-stream, dan kan jij er niks mee want het is gewoon een grote bende met bytes

De browser kan er niks mee, want in die context is het inderdaad een zooi bytes. Je krijgt dus een download-schermpje. Als het op je harde schijf staat kan je er waarschijnlijk wel wat mee, want een OS gebruikt over het algemeen geen mime-types, maar een ander mechanisme om de inhoud te bepalen

[Erkens]

Verwijderd schreef op maandag 18 april 2005 @ 15:01:
[...]


De browser kan er niks mee, want in die context is het inderdaad een zooi bytes. Je krijgt dus een download-schermpje. Als het op je harde schijf staat kan je er waarschijnlijk wel wat mee, want een OS gebruikt over het algemeen geen mime-types, maar een ander mechanisme om de inhoud te bepalen

precies, en dan komen we terug bij dit topic, ik download een XHTML file welke met text/html wordt verstuurd, jij saved hem op je HD, de file blijft gewoon XHTML

[bgever]

Verwijderd schreef op maandag 18 april 2005 @ 13:12:
[...]
De wereld was nog niet klaar voor sinaasappels.

De wereld is ook niet klaar voor je peren... Ik zou het toch wel een vervelende bijsmaak vinden als ik appelflappen krijg met peren er in!
Dat XHTML als text/html wordt geserveerd is niet goed te praten. Dat het toevallig wel werkt, is een ander verhaal...
Peren horen peren te zijn, en appels horen appels te zijn en te blijven. En anders ben je eigenlijk gewoon niet goed bezig...

[Erkens]

oikoyama schreef op maandag 18 april 2005 @ 16:53:
Dat XHTML als text/html wordt geserveerd is niet goed te praten. Dat het toevallig wel werkt, is een ander verhaal...

voor de laatste keer, voor compatibility met oudere browsers mag je gewoon text/html gebruiken, het doet geen afbreuk op het feit dat het XHTML is. Uiteraard dien je er wel van op de hoogte te zijn dat niet elke browser het dan ook als XML gaat parsen, maar dat is het "risico"

overigens zijn al die vergelijkingen met voedsel gewoon bullshit en kan je gewoon niet op het XHTML verhaal toepassen.

[Glashelder]

Erkens schreef op maandag 18 april 2005 @ 15:06:
[...]

precies, en dan komen we terug bij dit topic, ik download een XHTML file welke met text/html wordt verstuurd, jij saved hem op je HD, de file blijft gewoon XHTML

Na het lezen van deze discussie irriteer ik me aan 2 dingen

• Jouw eeuwige smilie;
• Het feit dat deze discussie allang afgelopen is, maar van voren...en naar achteren herhaalt wordt.

[curry684]

Erkens schreef op maandag 18 april 2005 @ 14:03:
[...]

dus als ik een zip file ter download aanbied met als content-type application/octet-stream, dan kan jij er niks mee want het is gewoon een grote bende met bytes

Zolang je er geen Content-Disposition veld bij levert met een .zip extensie zal het inderdaad enkel gedownload en gesaved worden met de filename waaronder de browser hem opgevraagd heeft, heb je helemaal gelijk in

[curry684]

Erkens schreef op maandag 18 april 2005 @ 17:10:
[...]

voor de laatste keer, voor compatibility met oudere browsers mag je gewoon text/html gebruiken, het doet geen afbreuk op het feit dat het XHTML is. Uiteraard dien je er wel van op de hoogte te zijn dat niet elke browser het dan ook als XML gaat parsen, maar dat is het "risico"

Nee geen enkele browser zal 'm als XML parsen, tis namelijk text/html en gaat dus de tagsoupprocessor in, dat was geloof ik het hele punt

[Erkens]

Glashelder schreef op maandag 18 april 2005 @ 17:21:
[...]

Na het lezen van deze discussie irriteer ik me aan 2 dingen

• Jouw eeuwige smilie;
• Het feit dat deze discussie allang afgelopen is, maar van voren...en naar achteren herhaalt wordt.

als ik een smilie wil gebruiken dan doe ik dat of had je liever gezien

deze discussie is volgens mij nooit afgelopen, er zijn gewoon 2 fronten, en ja ik irriteer me ook aan het feit dat steeds die appels en peren terug komen, maar dat is niet mijn schuld

curry684 schreef op maandag 18 april 2005 @ 17:28:
Nee geen enkele browser zal 'm als XML parsen, tis namelijk text/html en gaat dus de tagsoupprocessor in, dat was geloof ik het hele punt

dat die browsers dat niet kunnen is hun probleem, niet die van mij, ik hou daar gewoon rekening mee, want volgens mij iedereen (moet) doen die bezig houdt met (X)HTML, rekening houden met de diversiteit aan browsers.
Maar het punt was juist dat een XHTML file niet meer XHTML zou zijn als je een ander content-type mee geeft. Beetje hetzelfde als die zip file. Als ik die XHTML file ter download aanbied met application/octet-stream en ik geef aan dat het een .xhtml (is dat de extensie? ik gebruik die doorgaands nooit ivm serverside scripts, hmm, zoek ik even op, maar even als voorbeeld ) is dan blijft het gewoon XHTML.

[Verwijderd]

curry684 schreef op maandag 18 april 2005 @ 17:28:
[...]

Nee geen enkele browser zal 'm als XML parsen, tis namelijk text/html en gaat dus de tagsoupprocessor in, dat was geloof ik het hele punt

Hij *mag* zelfs niet de XML parser ingaan volgens de standaard. Degene die text/html er doorheen heeft gedrukt is imho een imbiciel. text/html had nooit in de specs opgenomen moeten worden. Dat geeft inderdaad wat mierenneuk voedsel voor een aantal mensen.

Is het voor niets dat de opvolgers van XHTML 1.0 op dit besluit zijn terug gekomen?

[Glashelder]

Maar het punt was juist dat een XHTML file niet meer XHTML zou zijn als je een ander content-type mee geeft.

• Voor de browser is het geen XHTML
• De inhoud blijft XHTML

Einde discussie?

Quist: dat bedoel ik.

[ Voor 6% gewijzigd door Glashelder op 18-04-2005 17:46 ]

[Verwijderd]

Glashelder schreef op maandag 18 april 2005 @ 17:43:
[...]

• Voor de browser is het geen XHTML
• De inhoud blijft XHTML

Einde discussie?

Glashelder, tot die conclusie zijn ik en heel veel andere mensen al lang gekomen. Volgens mij is dit gewoon een techpost boost topic aan het worden...

[bgever]

Erkens schreef op maandag 18 april 2005 @ 17:10:
[...]
voor de laatste keer, voor compatibility met oudere browsers mag je gewoon text/html gebruiken, het doet geen afbreuk op het feit dat het XHTML is. Uiteraard dien je er wel van op de hoogte te zijn dat niet elke browser het dan ook als XML gaat parsen, maar dat is het "risico"

Het zal wel aan mij liggen, dat ik het gewoon niet logisch vind dat XHTML als text/html verstuurd mag worden, maar ik heb het dan maar ff voor de duidelijkheid opgezocht zodat we er eens en voor altijd uit zijn.

RFC: The 'text/html' Media Type

Published specification:
The text/html media type is now defined by W3C Recommendations;
the latest published version is [HTML401]. In addition, [XHTML1]
defines a profile of use of XHTML which is compatible with HTML
4.01 and which may also be labeled as text/html.

Hierin staat overigens ook een interessant stukje over herkenning van XHTML/HTML...

Weer wat geleerd. Maar ik blijf achter mijn standpunt staan dat het eigenlijk niet zo mooi is dat XHTML als text/html verstuurd mag worden. Maar dat is mijn mening waar niemand zich druk over hoeft te maken.

[Verwijderd]

oikoyama, tuuluuk telt jou mening. Ik wil er wel naar luisteren hoor, ook al heb je geen 10k posts
Ik ben het zelfs met je eens. Ja het staat in de standaard. Maar iedereen kan op z'n vingers natellen dat het een ridicule beslissing was.