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

[Verwijderd]

Modbreak:

Dit topic is afgesplitst van php chatbox zonder refreshen wil niet met internet explorer.

crisp schreef op donderdag 14 april 2005 @ 17:47:
Sloop dan minimaal de doctype uit je document, want je claimt nu te voldoen aan een richtlijn waar je absoluut niet aan voldoet Daarbij stuur je het waarschijnlijk met een text/html mimetype en is het dus mallformed HTML.

Nee. XHTML is XHTML ongeacht het MIME type. Het doctype kan gewoon blijven staan, er is geen technische reden het weg te halen. Ik zie overigens dat Gathering ook niet valid is, daar ook maar het doctype uithalen?

Overigens valideert bovenstaande wel, hoewel het natuurlijk niet valid is.

Bovendien hoor je dit soort dingen in je HTTP headers te regelen en niet via META-tags. Dat IE er soms niet naar luistert komt gewoon doordat het een antieke brakke browser is...

Erg leuk, maar ik de praktijk gebruikt 90% van je bezoekers IE. DUS moet je het via META tags regelen, want dat werkt.

[ Voor 4% gewijzigd door NMe op 15-04-2005 21:14 ]

[crisp]

Verwijderd schreef op donderdag 14 april 2005 @ 18:45:
[...]


Nee. XHTML is XHTML ongeacht het MIME type. Het doctype kan gewoon blijven staan, er is geen technische reden het weg te halen.

Nee, mimetype zegt juist wel wat je stuurt, en als je mimetype text/html is wordt dat dus gewoon als HTML behandeld en niet als XHTML. Read up!

Ik zie overigens dat Gathering ook niet valid is, daar ook maar het doctype uithalen?

GoT is qua templates 100% HTML 4.01 Strict compliant, enkel de RML-parser is dat nog niet helemaal maar daar word nog aan gewerkt...

Overigens valideert bovenstaande wel, hoewel het natuurlijk niet valid is.

Een head-element in een body valideert natuurlijk voor geen meter...

Erg leuk, maar ik de praktijk gebruikt 90% van je bezoekers IE. DUS moet je het via META tags regelen, want dat werkt.

Vziw is dat niet nodig als je maar gewoon de juiste headers gebruikt. Dat IE andere headers nodig heeft is alleen irritant.

[ Voor 3% gewijzigd door crisp op 15-04-2005 00:22 ]

[bgever]

crisp schreef op donderdag 14 april 2005 @ 17:47:
[...]
Bovendien hoor je dit soort dingen in je HTTP headers te regelen en niet via META-tags. Dat IE er soms niet naar luistert komt gewoon doordat het een antieke brakke browser is...

In dat geval vind ik altijd de IE-only feature Conditional Comments een "mooie" oplossing. Omdat deze feature enkel voor IE is, is deze ook net zo geschikt voor de IE-only bugs of fixes.

Als je dus alle ranzige zooi tussen Conditional Comments zet, zal IE deze netjes uitvoeren, en andere browsers zullen het gewoon zien als commentaar.

Ik gebruik ze zelf altijd graag op plekken waar ik extra IE-only CSS wil laden, of JavaScript oplossingen implementeren als IE weer eens niet de CSS wil ondersteunen...

Maar dit is natuurlijk geen excuus voor zo'n zooi als een HEAD element in je BODY element zetten.

[Verwijderd]

crisp schreef op vrijdag 15 april 2005 @ 00:20:
Nee, mimetype zegt juist wel wat je stuurt, en als je mimetype text/html is wordt dat dus gewoon als HTML behandeld en niet als XHTML. Read up!

Nofi maar dit soort gelul hoor ik hier wel vaker. Een .xhtml is een .xhtml ongeacht het mimetype. Daar heeft 'readup' niets mee te maken. Als ik jou een bak koffie geef en ik zeg tegen je 'hier heb je een colaatje', wat heb ik je dan gegeven, koffie of cola?

GoT is qua templates 100% HTML 4.01 Strict compliant, enkel de RML-parser is dat nog niet helemaal maar daar word nog aan gewerkt...

Feit is dat het niet valideert. Helemaal geen ramp, want het werkt wel. Mijn punt was ook niet zozeer om te zeggen of GoT al dan niet goed was, maar meer dat iets van 90% van het web niet valideert. Toch staan overal doctypes. Het is kul om te zeggen dat je het doctype weg moet halen, omdat je in een hele pagina één smerig truukje uithaalt om iets goed te laten werken.

Een head-element in een body valideert natuurlijk voor geen meter...

Dat hangt van je definitie van valideren af denk ik. Strikt genomen heb je natuurlijk gelijk. De W3C validator pikt het echter (althans de laatste keer dat ik het probeerde, wel).

Vziw is dat niet nodig als je maar gewoon de juiste headers gebruikt. Dat IE andere headers nodig heeft is alleen irritant.

Vziw refreshed de pagina niet op IE met de headers die jij hier opgaf.

Laat een ding duidelijk zijn.. een head tag in je body is natuurlijk smerig, dat zei ik er ook direct bij. Maar het werkt wel.

[ Voor 5% gewijzigd door Verwijderd op 15-04-2005 04:43 ]

[bgever]

Verwijderd schreef op vrijdag 15 april 2005 @ 04:42:
[...]

Nofi maar dit soort gelul hoor ik hier wel vaker. Een .xhtml is een .xhtml ongeacht het mimetype. Daar heeft 'readup' niets mee te maken. Als ik jou een bak koffie geef en ik zeg tegen je 'hier heb je een colaatje', wat heb ik je dan gegeven, koffie of cola?

Fout voorbeeld! Laat ik het eens anders proberen:
Ik geef jou een bord met erwtensoep, maar zeg tegen jou dat het erwten zijn. Jij ziet dat het soep is, en weet dat je het lekker kunt opslurpen met een lepel. Echter doordat de ober dacht dat het erwten zijn, heeft hij jou een vork gegeven. Dwz, jij kunt de soep alleen als erwten behandelen.

En dat is dus ook wat er met de browser aan de hand is. Je geeft iets anders dan wat je voordoet, en daardoor zal de browser het ook gewoon inlezen als hoe je hebt aangegeven. Doordat XHTML "backward compatible" is, kan de browser het inlezen. Maar in feite behandelt ie het als brakke HTML, omdat het niet aan deze eisen voldoet; hij kent bijv. geen <br/>... Maar gezien de browser er gelukkig nog met wat moeite doorheen komt, lijkt het toch te werken. En dat "lijkt te werken" zie jij als een XHTML document dat als dusdanig behandeld is.
Neem anders de proef op de som: gebruik eens XML in je XHTML document, want dat ís XHTML. En kijk wat de browser doet. Als hij het niet begrijpt, dan betekent dus dat hij het niet als XHTML ziet, hoewel het document wel middels de XHTML syntax is beschreven.
De vraag is dus wat je onder "is XHTML" verstaat. Is het volgens de syntax XHTML, of is het volgens de browser XHTML? Ik vind het persoonlijk pas XHTML als de user-agent het ook als dat behandelt; want nu behandelt ie het als doodnormale HTML.

Dus zo'n gelul is dat van crisp niet. Eerder die onzin van jou. Tip: lees eens helemaal de XHTML specificatie op www.w3.org.

[crisp]

Verwijderd schreef op vrijdag 15 april 2005 @ 04:42:
Nofi maar dit soort gelul hoor ik hier wel vaker. Een .xhtml is een .xhtml ongeacht het mimetype. Daar heeft 'readup' niets mee te maken. Als ik jou een bak koffie geef en ik zeg tegen je 'hier heb je een colaatje', wat heb ik je dan gegeven, koffie of cola?

Vertaald naar mimetypes: cola met een koffiesmaak, maar aangezien ik mijn koffiesmaak papil niet geactiveerd heb zal ik niet beter weten dan dat het gewoon cola is met een vreemd bijsmaakje

Feit is dat het niet valideert.

Wat is het? De index valideerd prima, net als 95% van de andere acties. Enkel list_message(s) en aanverwanten zijn nog een zorgenkindje omdat de RML nog niet up-to-date is. Laten we zeggen dat wij tenminste de intentie hebben om te voldoen aan de richtlijn, dus die DTD heeft toch wel zeker enige waarde hier.

Dat hangt van je definitie van valideren af denk ik. Strikt genomen heb je natuurlijk gelijk. De W3C validator pikt het echter (althans de laatste keer dat ik het probeerde, wel).

Ik probeerde het gisteravond nog, en krijg toch mooi de melding 'element head is not allowed in this context' (of zoiets). (de validator heeft inderdaad wel eens wat tekortkomingen, maar wordt regelmatig bijgewerkt).

Vziw refreshed de pagina niet op IE met de headers die jij hier opgaf.

Volgens mij zijn er headers waar IE wel goed op reageert, ik zal zo eens even in mijn oude doos zoeken.

Laat een ding duidelijk zijn.. een head tag in je body is natuurlijk smerig, dat zei ik er ook direct bij. Maar het werkt wel.

Gebruik dan in ieder geval conditional comments zoals oikoyama al aangaf; dan blijft het smerig, maar enkel voor IE

[Verwijderd]

oikoyama schreef op vrijdag 15 april 2005 @ 09:06:
Fout voorbeeld! Laat ik het eens anders proberen:
Ik geef jou een bord met erwtensoep, maar zeg tegen jou dat het erwten zijn. Jij ziet dat het soep is, en weet dat je het lekker kunt opslurpen met een lepel. Echter doordat de ober dacht dat het erwten zijn, heeft hij jou een vork gegeven. Dwz, jij kunt de soep alleen als erwten behandelen.

Welke webserver geeft een browser er gereedschap bij dan? Jouw voorbeeld is juist fout, en het mijne klopt. Ik serveer een glas koffie (=xhtml) en zeg er bij dat het cola is (=html). In jouw voorbeeld serveer jij ertensoep en een vork. Je ziet dat jouw voorbeeld niet klopt, en het mijne wel

Jouw voorbeeld juist weergegeven is dat jij op de tafel een sloot gereedschap hebt liggen. Vorken, messen, lepels, enzovoort. De ober komt er aan en zegt tegen jou dat hij je erten geeft, maar geeft je erwtensoep. Op dat moment mag jij gaan kijken wat je met je erwtensoep gaat doen, of je hem met een vork gaat eten of met een lepel, is aan jou. NIET aan de webserver. Feit blijft nog steeds dat er in je bord/kom erwtensoep zit, en geen erten zoals de webserver (=ober) aangaf.

XHTML is XHTML zodra er XHTML op staat. Als het bestand eindigt op .xhtml, en het is valide xhtml, dan is het xhtml. Ongeacht of de webserver het aanbiedt als html of niet. Jouw webserver levert de parser erbij (=de vork). Ik moet de eerste webserver nog zien die de parser erbij levert.

Dus zo'n gelul is dat van crisp niet. Eerder die onzin van jou. Tip: lees eens helemaal de XHTML specificatie op www.w3.org.

Wat is dat toch? Zowel jij en crisp komen met opmerkingen als 'lezen'. Ik persoonlijk vind dat ERG onbeschoft. Dat ik het niet met je eens ben, wil niet zeggen dat ik niet weet waar ik het over heb hoor.

[ Voor 22% gewijzigd door Verwijderd op 15-04-2005 09:57 ]

[crisp]

Verwijderd schreef op vrijdag 15 april 2005 @ 09:54:
[...]
Welke webserver geeft een browser er gereedschap bij dan? Jouw voorbeeld is juist fout, en het mijne klopt. Ik serveer een glas koffie (=xhtml) en zeg er bij dat het cola is (=html). In jouw voorbeeld serveer jij ertensoep en een vork. Je ziet dat jouw voorbeeld niet klopt, en het mijne wel

Het is eerder zo dat jij erwtensoep serveert en tegen de browser zegt dat 'ie het met een vork moet eten. En wie is de browser om niet te gehoorzamen; hij zal rustig de vork pakken (tagsoup parser) en de erwtensoep gaan eten. Aangezien de tagsoup parserr alles lust zal hij het waarschijnlijk nog lekker vinden ook.
Als je 'm achteraf vraagt wat 'ie nou eigenlijk gegeten heeft zal hij zeggen: 'tsja, het leek wel een beetje op erwtensoep'.
Browsers doen niet zo heel veel met de DTD; het enige wat ze aan de hand daarvan besluiten is om in quirks of standardsmode te renderen. De mimetype zegt ze echter of het HTML of XHTML is, en als je er al zoveel van weet dan moet je ook weten dat er veel verschillen zijn hoe een browser omgaat met een document met HTML mimetype of XHTML mimetype.

Overigens heeft een extensie van je bestand er natuurlijk helemaal niets mee te maken; ik kan mijn webserver zo inrichten dat hij bestanden met een .xxx extentie als jpeg opstuurt. De browser zal het dan gewoon als plaatje accepteren (mits de inhoud ook als jpeg geparsed kan worden).

Kortom: de mimetype zegt wel degelijk wat het is, of in ieder geval wat het zou moeten zijn. Als de inhoud voldoet aan hetgeen jij zegt dat het is dan hoor je de browser niet klagen. Een XHTML bestand verstuurt als text/html wordt dus gewoon als HTML gezien en behandelt, en dat gaat over het algemeen ook prima ook al is het mallformed HTML maar dat lost de errorcorrectie van de HTML parser wel op.

[bgever]

crisp schreef op vrijdag 15 april 2005 @ 10:25:
[...]

Het is eerder zo dat jij erwtensoep serveert en tegen de browser zegt dat 'ie het met een vork moet eten. En wie is de browser om niet te gehoorzamen; hij zal rustig de vork pakken (tagsoup parser) en de erwtensoep gaan eten. Aangezien de tagsoup parserr alles lust zal hij het waarschijnlijk nog lekker vinden ook.

Kijk jij snapt het. (ik geef toe, mijn erwtensoep verhaal kan wel verwarrend overkomen)

Om te bepalen wat iets is, gaat het er om vanuit welk standpunt je kijkt. De auteur zal het in zijn editor zien zoals hij het gemaakt heeft: XHTML. De browser zal het zien, zoals het hem verteld wordt: text/html = HTML. (als hij te horen kreeg dat het application/xml+xhtml was, dan was het overigens wél XHTML geweest)
Gezien een (X)HTML bestand voor het publiek bedoeld is, gaat het dus om hoe de verwerkers (browsers) het zien. En deze zien het dus gewoon als HTML. Daarom zeg ik: het ís HTML.
Haal dus niet deze twee perspectieven door elkaar...

[Verwijderd]

crisp schreef op vrijdag 15 april 2005 @ 10:25:
Het is eerder zo dat jij erwtensoep serveert en tegen de browser zegt dat 'ie het met een vork moet eten.

Dit is domweg niet waar. Het mimetype vertelt de browser NIET welke parser hij moet gebruiken. Het mimetype zegt alleen maar wat voor type bestand dat is. De browser zoekt dan zelf uit welke parser hij bij dat mimetype moet gebruiken, of hoe hij dat mimetype moet parsen.

Volgens jullie vertel ik de klant welk bestek hij moet gebruiken. Het bestek is in deze analoog aan de parser. Dat is domweg niet waar. Ik vertel de klant alleen welk type eten hij krijgt.

De enige juiste analogie is de ober die erwtensoep serveert en erbij zegt dat het erwten zijn. Niet meer en niet minder. Hij doet geen uitspraken over welk bestek de klant moet gebruiken, immers een browser bepaald zelf wat hij met een mime-type moet doen.

Analoog hieraan kan ik ook tegen een browser zeggen dat hij een .jpg moet openen als .html. Als ik dat koppel aan Crisps webservert die alle .html's als .jpg's serveert, kan ik browsen zonder te merken dat er geen fuck van de mimetypes klopt.

Je ziet, jullie verhaaltje loopt spaak.

[ Voor 28% gewijzigd door Verwijderd op 15-04-2005 15:24 ]

[crisp]

Verwijderd schreef op vrijdag 15 april 2005 @ 15:21:
Dit is domweg niet waar. Het mimetype vertelt de browser NIET welke parser hij moet gebruiken. Het mimetype zegt alleen maar wat voor type bestand dat is. De browser zoekt dan zelf uit welke parser hij bij dat mimetype moet gebruiken, of hoe hij dat mimetype moet parsen.

Volgens mij spreek je jezelf nu tegen?

[Verwijderd]

Waar dan precies? De browser zegt 'hier is je bord, en het bevat erwten'. De browser maakt hierop zelf de beslissing om een vork te pakken. De server zegt neit dat hij een vork moet pakken.

In een mimetype staat bv. niet 'gebruik msxml om dit bestand te parsen'. Daar staat alleen maar 'dit bestand is xml'.

Ik spreek mezelf trouwens helemaal niet tegen in het door jou gequote gedeelte? Kun je aanwijzen waar ik mezelf volgens jou tegenspreek?

[crisp]

Vergelijk

Het mimetype vertelt de browser NIET welke parser hij moet gebruiken.

met

De browser zoekt dan zelf uit welke parser hij bij dat mimetype moet gebruiken

oftewel: je zegt eerst dat mimetype niets uitmaakt, en vervolgens dat de browser aan de hand van de mimetype juist wel gaat bepalen hoe het geparsed moet worden. Je eerste bewering klopt dus niet aangezien je 2e wel klopt.
Een browser gaat anders om met een text/html bestand dan met een application/xhtml+xml bestand. De eerste zal als HTML geparsed worden, de 2e als XHTML.

De grote vraag hier is: kan dat 1e bestand dan stiekum toch XHTML zijn? Mijn antwoord: nee; het wordt gezien als HTML, is (dankzij SGML NET features) compatible met HTML en heeft daardoor ook alle karakteristieken van HTML. Er zit alleen een verkeerd labeltje op (DTD), maar de verpakking zegt dat het HTML is, en dat is waar de browser naar kijkt.

[Verwijderd]

crisp schreef op vrijdag 15 april 2005 @ 16:15:
Vergelijk
oftewel: je zegt eerst dat mimetype niets uitmaakt, en vervolgens dat de browser aan de hand van de mimetype juist wel gaat bepalen hoe het geparsed moet worden.

Nee.. je leest niet goed, of ik leg het onduidelijk uit. Het mimetype wat de server opgeeft is niets meer dan een bewering over het type van het bestand. Analoog met de ober die zegt 'dit is cola' of 'dit is koffie' of 'dit is erwtensoep'. Volgens jullie zegt de ober er nog bij 'en dit moet je met een vork eten'. Dat is niet waar.

Wat de ontvangende browser doet is kijken naar wat de ober zegt. Die zegt 'het zijn erwten', dus pakt de browser een vork. Het verschil is dat dat een beslissing van de browser zelf is, niet van de webserver of ober.

Feit blijft nog steeds dat onafhankelijk van hoe die browser z'n erwtensoep gaat opeten, en wat voor uitspraken de server er ook over gedaan heeft, het nog steeds erwtensoep is. En geen erwten, zoals jullie beweren. Volgens jullie redenatie is erwtensoep getransformeerd naar erwten omdat de ober er abuisievelijk bij zei dat het erwten waren. Dat is onzin.

Je eerste bewering klopt dus niet aangezien je 2e wel klopt.

Beide beweringen kloppen precies. Is gewoon Nederlands hoor. Je moet in dit geval 'vertellen' zien als gebiedende wijs. Laat ik het anders zeggen: het mime type verplicht de browser niet tot het gebruiken van een bepaalde parser. Het is de koppeling tussen mime types en parsers die de browser ZELF maakt (en dus niet de server die het mime type opgeeft) die dit bepaald.

De grote vraag hier is: kan dat 1e bestand dan stiekum toch XHTML zijn? Mijn antwoord: nee; het wordt gezien als HTML, is (dankzij SGML NET features) compatible met HTML en heeft daardoor ook alle karakteristieken van HTML. Er zit alleen een verkeerd labeltje op (DTD), maar de verpakking zegt dat het HTML is, en dat is waar de browser naar kijkt.

En hierover worden we het nooit eens. Wat jij zegt is namelijk gewoon onzin in mijn ogen. Als ik in de supermarkt een blik erwtensoep koop, het etiket er afweek en er het etiket van appelmoes opplak, zit er volgens jou vanaf dat moment appelmoes in dat blik. Immers dat is wat er op staat en dat is dus ook wat de klant ziet als hij het koopt.

Dit is echter niet waar. Er zit nog steeds erwtensoep in het blik, ondanks het feit dat het verkeerd gelabeled is.

Laat ik het zo uitleggen.. volgens jullie ziet een mime type er zo uit:

.xml -->msxml

en volgens mij gewoon zo:

.xml

De browser heeft in mijn voorbeeld zelf een tabelletje, waar in staat:
.xml ->msxml

Ik hoop dat je nu het nuanceverschil ziet, en ook ziet waarom de vergelijking die jullie maken domweg niet klopt. De webserver bepaald niet welke parser de browser moet gebruiken. Het mime type bepaald niet welke parser de browser moet gebruiken. Het enige wat dit bepaald is de koppeltabel tussen parsers en mime types, en dat is volledig te bepalen door de browser.

De ober zegt dus helemaal niet 'gebruik een vork'. De ober zegt alleen maar 'dit zijn erwten'. Mijn cola voorbeeld is domweg 100% correct.

[ Voor 28% gewijzigd door Verwijderd op 15-04-2005 16:33 ]

[crisp]

Het grote verschil met alle analogieen hier is dat XHTML gewoon door kan gaan als HTML qua syntax. XHTML is echter pas XHTML in mijn ogen als het ook alle specifieke karakteristieken heeft van XHTML, en dat heeft het niet op het moment dat het door de browser gewoon als HTML behandeld wordt.

En misschien begrijp je nog niet helemaal wat een mimetype precies inhoud, want je komt nu weer met bestandsextensies aanzetten, en daar kijkt een browser al helemaal niet naar (hoewel IE als uitzondering wel eens een gok doet op basis van bestandsextensie, maar alleen als het op basis van mimetype en/of inhoud van het bestand niet kan bepalen wat het nu eigenlijk is - dezelfde IE die de XHTML mimetype niet kent cq ondersteund - maar daar gaat het hier niet over).

En nogmaals: XHTML verstuurt als HTML (je beweerd dus dat het HTML is) wordt door een browser ook gewoon als HTML behandeld. Daar heb je a) om gevraagd en b) de browser weet niet beter want de HTML parser weet er wel raad mee. Aangezien het dus als HTML geparsed wordt mist het echter de karakteristieken van XHTML, maar heeft het wel alle karakteristieken van HTML. Wat is het dan?

En hoe een browser omgaat met een mimetype is wat ik zou moeten mogen verwachten. Als ik zeg 'dit is erwtensoep' verwacht ik dat de browser een lepel pakt; als ik zeg 'dit zijn erwten' dan verwacht ik dat hij een vork ter hand neemt. Jij stuurt erwten, maar zegt erbij dat het soep is, en dan vind je het raar als de browser een lepel pakt

[ Voor 37% gewijzigd door crisp op 15-04-2005 18:15 ]

[Verwijderd]

crisp schreef op vrijdag 15 april 2005 @ 18:05:
En misschien begrijp je nog niet helemaal wat een mimetype precies inhoud, want je komt nu weer met bestandsextensies aanzetten

Misschien moet je eens ophouden een ander er van te beschuldigen niet te weten wat iets is, omdat hij/zij het niet met je eens is? Ik gebruik extenties om duidelijk te maken wat ik bedoel.

En nogmaals: XHTML verstuurt als HTML (je beweerd dus dat het HTML is) wordt door een browser ook gewoon als HTML behandeld. Daar heb je a) om gevraagd en b) de browser weet niet beter want de HTML parser weet er wel raad mee. Aangezien het dus als HTML geparsed wordt mist het echter de karakteristieken van XHTML, maar heeft het wel alle karakteristieken van HTML. Wat is het dan?

Als ik jou erwtensoep serveer, maar erbij zeg dat het erwten zijn, en jij eet het (wonder boven wonder) ook op als erwten (dus met een vork, met goede erwtensoep kan dat wel), wat heb jij dan gegeten?

Volgens jou erwten, volgens mij nog steeds erwtensoep.

En hoe een browser omgaat met een mimetype is wat ik zou moeten mogen verwachten. Als ik zeg 'dit is erwtensoep' verwacht ik dat de browser een lepel pakt; als ik zeg 'dit zijn erwten' dan verwacht ik dat hij een vork ter hand neemt. Jij stuurt erwten, maar zegt erbij dat het soep is, en dan vind je het raar als de browser een lepel pakt

Dat heb ik nergens gezegd. Je spreekt hier jezelf overigens ook al tegen. Volgens jullie was het zo dat de browser ERBIJ VERTELT welk bestek je moet gebruiken. Dat was (en is) volgens mij niet zo, en hierboven geef je me daar gelijk in. Immers je spreekt over 'verwachten', waarmee je zelf al aangeeft dat de browser zelf bepaald wat hij er daadwerkelijk mee gaat doen, en niet de webserver of het mimetype. De browser gebruikt het mimetype wel bij het bepalen, maar that's it. Het is gewoon pertinent niet waar dat de server aan de browser vertelt hoe hij het bestand moet parsen. De server zegt alleen wat voor type bestand het is. Niets meer en niets minder.

[ Voor 37% gewijzigd door Verwijderd op 15-04-2005 18:20 ]

[Soultaker]

offtopic:
Die voedselanalogie maakt de discussie er absoluut niet helderder op.
(Bovendien krijg ik er trek van.)

[crisp]

Verwijderd schreef op vrijdag 15 april 2005 @ 18:17:
[...]


Misschien moet je eens ophouden een ander er van te beschuldigen niet te weten wat iets is, omdat hij/zij het niet met je eens is? Ik gebruik extenties om duidelijk te maken wat ik bedoel.

Het zal mij worst zijn welke naam een browserfabrikant aan z'n parser geeft. All I care about is dat een bestand wordt geparsed volgens bepaalde karakteristieken die overeen komen met het mimetype dat ik aan dat bestand meegeef. Als dat HTML is, dan verwacht ik dat een HTML parser wordt gebruikt, als dat XHTML is dan verwacht ik ook dat het als XHTML geparsed wordt (Dus ook een dikke parsererror als het bestand niet voldoet aan de requirements voor XHTML).
Dat is ook precies wat er gebeurd, dus ik bepaal op die manier wel degelijk hoe mijn bestand geparsed wordt.

[...]
Als ik jou erwtensoep serveer, maar erbij zeg dat het erwten zijn, en jij eet het (wonder boven wonder) ook op als erwten (dus met een vork, met goede erwtensoep kan dat wel), wat heb jij dan gegeten?

Volgens jou erwten, volgens mij nog steeds erwtensoep.

Het ziet er bijna hetzelfde uit als erwten, smaakt bijna hetzelfde en is eetbaar met een vork; wie ben ik om te denken dat het geen erwten zijn? Misschien een ander merk, maar ik vind het prima erwten. Ik mis dan wel de rookworst, maar dan had je maar moeten zeggen dat het erwtensoep was...

[...]
Dat heb ik nergens gezegd. Je spreekt hier jezelf overigens ook al tegen. Volgens jullie was het zo dat de browser ERBIJ VERTELT welk bestek je moet gebruiken. Dat was (en is) volgens mij niet zo, en hierboven geef je me daar gelijk in. Immers je spreekt over 'verwachten', waarmee je zelf al aangeeft dat de browser zelf bepaald wat hij er daadwerkelijk mee gaat doen, en niet de webserver of het mimetype. De browser gebruikt het mimetype wel bij het bepalen, maar that's it. Het is gewoon pertinent niet waar dat de server aan de browser vertelt hoe hij het bestand moet parsen. De server zegt alleen wat voor type bestand het is. Niets meer en niets minder.

Das gewoon het probleem met analogieen, maar impliciet geeft een mimetype wel degelijk aan hoe het 'gegeten' moet worden; als je daar al niet meer vanuit kan gaan dan zou het een dolle boel worden...

[bgever]

Verwijderd schreef op vrijdag 15 april 2005 @ 18:17:
[...]
Misschien moet je eens ophouden een ander er van te beschuldigen niet te weten wat iets is, omdat hij/zij het niet met je eens is? Ik gebruik extenties om duidelijk te maken wat ik bedoel.

Als wij het over appels hebben (mime-types) en jij begint met een vergelijking met peren (extensies) moet je niet gek opkijken van zo'n opmerking...

Als ik jou erwtensoep serveer, maar erbij zeg dat het erwten zijn, en jij eet het (wonder boven wonder) ook op als erwten (dus met een vork, met goede erwtensoep kan dat wel), wat heb jij dan gegeten?

Volgens jou erwten, volgens mij nog steeds erwtensoep.

Nope erwten. Waarom?
1) Jij weet niet beter dan dat het erwten zijn, omdat je het verteld is.
2) Jij kunt niet achterhalen of het erwtensoep is, en daar controleer je ook niet op omdat het erwten zijn.

Het enige wat jij denkt: hey, wat is er met die erwten gebeurt? Ze zijn geplet. Hmm, het smaakt nog wel naar erwt. Ach, dan zullen het wel erwten zijn...

Volgens jullie was het zo dat de browser ERBIJ VERTELT welk bestek je moet gebruiken.

Euh, kun je dan ff zeggen waar ik dit beweer?
Ik zeg alleen: omdat hij weet wat het is (volgens de ober), pakt hij uit gewoonte dat bestek. Omdat dit nu eenmaal hoort bij die vorm van eten...

[Verwijderd]

oikoyama schreef op vrijdag 15 april 2005 @ 18:45:
Nope erwten. Waarom?
1) Jij weet niet beter dan dat het erwten zijn, omdat je het verteld is.
2) Jij kunt niet achterhalen of het erwtensoep is, en daar controleer je ook niet op omdat het erwten zijn.

Nofi, maar onzin. Het is nog steeds erwtensoep, ook al behandelen zowel jij als de ober het als erwten.

Euh, kun je dan ff zeggen waar ik dit beweer?

Ja hoor.. hier:

crisp schreef op vrijdag 15 april 2005 @ 10:25:
Het is eerder zo dat jij erwtensoep serveert en tegen de browser zegt dat 'ie het met een vork moet eten.

Daar reageer jij op met:

oikoyama schreef op vrijdag 15 april 2005 @ 13:35:
Kijk jij snapt het. (ik geef toe, mijn erwtensoep verhaal kan wel verwarrend overkomen)

[crisp]

code:

<html>
  <head>
    <title>blaat</title>
  </head>
  <body>
    <p>Wat is dit?</p>
  </body>
</html>

HTML? XHTML? XML? who can tell?

[NMe]

Modbreak:

Topic afgesplitst van php chatbox zonder refreshen wil niet met internet explorer. Gelieve in W&G verder te gaan.

PW>>WG

[Room42]

Verwijderd schreef op vrijdag 15 april 2005 @ 19:07:
Nofi, maar onzin. Het is nog steeds erwtensoep, ook al behandelen zowel jij als de ober het als erwten.

En daar geef je dus PRECIES aan waarom het zo belangrijk is om de JUISTE mimetype mee te geven! En dat is precies wat crisp en oikoyama je proberen te vertellen.

Mooi! We zijn eruit

[BtM909]

offtopic:
OMG, tag- vs. erwtensoepsoup

Deze discussie heeft denk ik niet zoveel zin meer. hezik, het is geen persoonlijke aanval op jou, maar haal er desnoods geen analogien bij, want de rest van de posters heeft wel degelijk gelijk.

Als je nog argumenten hebt, post ze (desnoods zonder toelichting) hier, dan kunnen wij daarop reageren.

[We Are Borg]

Verwijderd schreef op vrijdag 15 april 2005 @ 18:17:
[...]


Misschien moet je eens ophouden een ander er van te beschuldigen niet te weten wat iets is, omdat hij/zij het niet met je eens is? Ik gebruik extenties om duidelijk te maken wat ik bedoel.

No offence, maar jij komt ook behoorlijk over a;s "IK heb GELIJK(punt)". Kan geen kwaad om een beetje open te staan en niet gelijk jouw mening over dit onderwerp als 'de waarheid' te beschouwen. Gewoon een idee

Nu heb ik er niet veel kaas van gegeten, maar om even te stoppen met hele erwten verhaal (wat dat loopt toch nergens op uit).

Ik heb een bestand met een XHTML doctype erboven. Vervolgens geeft ik aan de browser aan dat de content text/html is (mime). Vervolgens kijkt (als ik jouw verhaal goed gelezen hebt) de browser dan naar welke parser die gaat gebruiken, maar in alle gevallen die ik ken betekent dat dat de browser een parser pakt die ook wordt gepakt bij een HTML doctype. Kortom, dan parst hij het zooitje(expres die woord, geen xtml of html) toch als HTML, omdat de browser een html afhandeling gebruikt ? Vertel graag wat hier niet overeen komt met jouw gedachte, maar laat please de erwtensoep achterwege

[ Voor 9% gewijzigd door We Are Borg op 15-04-2005 21:52 ]

[Verwijderd]

We Are Borg schreef op vrijdag 15 april 2005 @ 21:50:
No offence, maar jij komt ook behoorlijk over a;s "IK heb GELIJK(punt)". Kan geen kwaad om een beetje open te staan en niet gelijk jouw mening over dit onderwerp als 'de waarheid' te beschouwen. Gewoon een idee

eh ? dat doen beide partijen hoor. Verschil is dat ik 'de anderen' niet de hele tijd loop te vertellen dat ze maar een boek moeten kopen.

ik denk toch echt dat je beter moet lezen. ik geef de hele tijd duidleijk aan dat het om volgens mij uitspraken gaat. Crisp en Oikoyama zijn juist diegenen die zeggen dat ik maar boeken moet gaan lezen.

Deze discussie heeft denk ik niet zoveel zin meer. hezik, het is geen persoonlijke aanval op jou, maar haal er desnoods geen analogien bij, want de rest van de posters heeft wel degelijk gelijk.

Als je nog argumenten hebt, post ze (desnoods zonder toelichting) hier, dan kunnen wij daarop reageren.

Wat zijn jouw argumenten dan?

En daar geef je dus PRECIES aan waarom het zo belangrijk is om de JUISTE mimetype mee te geven! En dat is precies wat crisp en oikoyama je proberen te vertellen.

Mooi! We zijn eruit

Jij begrijpt duidelijk de discussie niet. De vraag was niet of je perse het juiste mimetype moet meegeeven maar of het mimetype bepaald wat voor bestand iets is. en dat doet het niet. dat doet de inhoud van het bestand zelf.

Een ander voorbeeld dan. Als ik een jpegje ga versturen met als mimetype html. Dan zal de browser het niet correct weergeven. Waarom niet? Omdat het geen HTML is, maar een jpeg.

Ik weet niet hoe ik duidelijker kan aantonen dat het mimetype niet bepaald wat voor bestand iets is.

Daarnaast, om meer richting het topic te gaan wat hieraan gegeven is.. als jij in XHTML ontwikkeld ben je gek als je daar een XHTML mimetype aan koppelt. Je sluit dan vanwege een miereneukerige preciesheid even 90% van je gebruikers uit. Ja theoretisch gesproken is het het mooist om alles correct te doen. Praktisch gesproken kan dat niet altijd.

[ Voor 63% gewijzigd door Verwijderd op 15-04-2005 22:23 ]

[Verwijderd]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:15:
[...]

Jij begrijpt duidelijk de discussie niet. De vraag was niet of je perse het juiste mimetype moet meegeeven maar of het mimetype bepaald wat voor bestand iets is. en dat doet het niet. dat doet de inhoud van het bestand zelf.

Na alles gelezen te hebben ben ik het er inderdaad mee eens dat hezik niet star is. Hij dringt z'n mening niet op, in deze discussie doen beide partijen uitspraken alleen is hezik in z'n eentje waardoor het lijkt dat hij fout zit en niet bereid is te luisteren naar de rest.
Het is evengoed mogelijk dat de rest fout is en hezik niet.

Om even op bovenstaande quote terug te komen. Hezik: jij zegt dat de inhoud bepaald wat iets is. Daar ben ik het helemaal mee eens. bedenk echter wel dat XHTML ook HTML is. Wanneer jij dus een mime type meestuurt text/html. Dan is het gewoon HTML. Het had evengoed XHTML kunnen zijn, maar zo heb je het niet benoemd. Sterker nog, het zowel HTML als XHTML, het wordt echter verschillend geinterpreteerd.

Sorry jongens, toch nog even de erwtensoep analogie. Je hebt een blik met erwtensoep en plakt er een etiket op: hier zitten erwten in. Dan is dat waar. Plak je er het etiket op: hier zit erwtensoep in, dan is dat *ook* waar.
Hoe je het eet ligt er maar net aan hoe je het ziet. In het ene geval zie je het als erwten en eet je het met een vork. In het andere geval zie je het als soep en eet je het met een lepel.

Hoe je het ziet hangt af van het mime-type in dit geval aangezien het zowel XHTML is als HTML

[ Voor 6% gewijzigd door Verwijderd op 15-04-2005 22:28 ]

[We Are Borg]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:15:
Daarnaast, om meer richting het topic te gaan wat hieraan gegeven is.. als jij in XHTML ontwikkeld ben je gek als je daar een XHTML mimetype aan koppelt. Je sluit dan vanwege een miereneukerige preciesheid even 90% van je gebruikers uit. Ja theoretisch gesproken is het het mooist om alles correct te doen. Praktisch gesproken kan dat niet altijd.

Hier ben ik het helemaal met je eens, maar dan niet puur om die 90% die je buitensluit (daar zijn oplossingen voor). Als je geen gebruikt maakt van xml zut bij het xhtml bestand, waarom zou je dan ooit zo gek zijn om het als XHTML te versturen, of zelfs XHTML te gebruiken? Ik kan het niet verkopen aan een bedrijf dat als er 1 foutje wordt gemaakt, heel de pagina niet werkt. Oh, maar als je dan gewoon HTML gebruikt (wat hetzelfde doet, je website tonen) dan heb je dat probleem niet? Keuze makkelijk gemaakt denk ik zo .

Reageer je express niet op het 2de deel van mijn vorige post ? Ben wel benieuwd namelijk naar je mening daarover.

[JHS]

In de analogie. Je hebt erwtensoep, wat eigenlijk met een lepel moet worden gegeten. Je vertelt de browser dat het erwten zijn. Die pakt dus een vork, en prikt alleen de erwten eruit, wat heeft hij nu gegeten? Juist, erwten. Met het veranderen van het bestek/parser van de klant/browser verander je wat hij eet/krijgt. Zodra de browser het bestand als HTML behandeld in plaats van XHTML, omdat hij de X zogezegd helemaal niet binnen kan krijgen omdat de door het mimetype gekozen parser niet correct was, heeft hij ook daadwerkelijk HTML gegeten. Dus, de webserver beweert dat het HTML is, de browser behandelt het als HTML en krijgt ook daadwerkelijk alleen maar HTML binnen. Alleen terwijl de auteur het dus als XHTML schrijft is het XHTML.

Volgens mij is de anologie nu eindelijk kloppend gemaakt .

edit:

Misschien een andere variant, naar aanleiding van wat Quist zij. Je hebt een tomaten&groente soep. Je plakt er een tomatensoep etiket op. Je eet dan inderdaad tomatensoep, alleen zit er wat groente bij. Je plakt er een tomaten&groentesoep etiket op. Ook waar, maar nu geniet je misschien meer van de groente, omdat je je ervan bewust bent .

edit:

Beide varianten kloppen overigens volgens mij, en zijn beide waar .

[ Voor 24% gewijzigd door JHS op 18-04-2005 19:56 ]

[Verwijderd]

Eensch is! Nu klopt de analogie. Dit komt overeen met mijn verhaal dat het zowel HTML is als XHTML. Hoe je het ziet hangt er vanaf hoe je het benoemd hebt.

[KneoK]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:15:


[...]


Een ander voorbeeld dan. Als ik een jpegje ga versturen met als mimetype html. Dan zal de browser het niet correct weergeven. Waarom niet? Omdat het geen HTML is, maar een jpeg.

Dit geeft dus precies aan waarom het mimetype WEL gevolgd wordt. Weet je waarom de browser het niet weer wil geven ? Omdat de browser de "HTML parser" heeft gepakt aan de hand van het mimetype wat je in de jpg hebt gezet.
De browser ziet de .jpg extensie, hij zou volgens jouw theorie aan de hand van de code ook moeten zien dat het een jpg is maar toch geeft 'ie het verkeerd weer.
Als de browser alleen aan de hand van de inhoud had bepaald dat het bestand stiekem (ondanks mimetype) toch een jpg is dan had die wel automatisch overgesprongen op de JPG parser, dat is immers wat je ons de hele tijd vertelt.

[ Voor 38% gewijzigd door KneoK op 15-04-2005 22:46 ]

[Verwijderd]

/me ziet door de soep de erwten niet meer,

xhtml verstuurd als text/html wordt gezien als html en geparsed als html, punt uit, feit

xhtml verstuurd als application/xhtml+xml wordt behandeld als xhtml, en door IE niet geslikt (IE kan niet omgaan met xhtml, hij heeft er simpelweg geen parser voor)

html met xhtml-like dingen (lees xhtml verstuurd als text/html), like <br /> is vaak incorrecte html, <br /> zou volgens de SGML NET Shorttag gerenderd moeten worden als <br>> (met een extra >), omdat <br/ een afkorting is voor <br>. Probeer maar eens <script src="iets" /> in je xhtml verstuurd als html te doen, gaat fout omdat de html parser het ziet als <script>> en dus wordt het element niet afgesloten en draait je document de soep in.

[Verwijderd]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:43:
/me ziet door de soep de erwten niet meer,

xhtml verstuurd als text/html wordt gezien als html en geparsed als html, punt uit, feit

xhtml verstuurd als application/xhtml+xml wordt behandeld als xhtml, en door IE niet geslikt (IE kan niet omgaan met xhtml, hij heeft er simpelweg geen parser voor)

Niet helemaal waar. Ik ben het grotendeels met je eens, behalve het punt dat xhtml verstuurd als text/html geparsed wordt als html. Immers zou het strikt als html geparsed worden, dan zou het niet goed gerendert worden, zoals je zelf hieronder al aangeeft.

html met xhtml-like dingen (lees xhtml verstuurd als text/html), like <br /> is vaak incorrecte html, <br /> zou volgens de SGML NET Shorttag gerenderd moeten worden als <br>> (met een extra >), omdat <br/ een afkorting is voor <br>. Probeer maar eens <script src="iets" /> in je xhtml verstuurd als html te doen, gaat fout omdat de html parser het ziet als <script>> en dus wordt het element niet afgesloten en draait je document de soep in.

Helemaal waar. Ik denk dat mensen niet begrijpen wat ik bedoel. Laatste poging, duidelijker dan dit kan ik het niet maken:

xhtml verstuurd als text/html wordt gezien als html en geparsed als html, punt uit, feit

... maar het is nog steeds XHTML.

[ Voor 24% gewijzigd door Verwijderd op 15-04-2005 22:46 ]

[Verwijderd]

Hezik, kijk nog eens naar mijn post. Het is *en* html, *en* xhtml. Jullie hebben gewoon allemaal gelijk...

[Verwijderd]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:46:
Hezik, kijk nog eens naar mijn post. Het is *en* html, *en* xhtml. Jullie hebben gewoon allemaal gelijk...

Ik had je post gezien hoor, maar ben het gewoon niet met je eens. Om de erwtensoep er dan toch maar weer bij te halen.. als ik een blik erwtensoep label met 'appelmoes' zit er nog immer erwtensoep in het blik en geen appelmoes

Maar goed.. ik denk dat we hier niet uit gaan komen, het is gewoon een verschil van mening. Agree to disagree lijkt mij een goede optie.

[Verwijderd]

dat laatste maakt me helemaal niks uit, maakt mij niks uit hoe je het noemt, ik denk dat het het duidelijkst is als je het xhtml noemt ja, maar weet wel dat de browser denkt dat het html is.

en het wordt echt wel geparsed als html, gooi namelijk maar eens een malformed xhtml document de deur uit als text/html, bijv met die script tag of een andere niet afgesloten tag, dit wordt gewoon geslikt.

Of doe eens alert(document.body.nodeName); krijg je "BODY" terug, terwijl een xhtml parser "body" terug zou moeten gaven (want xhtml is case sensitive)

@Quist: het is niet en en, een browser kan niet halfhalf renderen (ok, een xml dataisland (mathml ofzo) in xhtml wel, maar da's wat anders)

overigens heb je gelijk dat er niet overal > verschijnen, maar dat ligt aan een html parser die geet NET shorttag ondersteund, of eigenlijk beter gezegd, hier een foutcorrectie op doet

[ Voor 28% gewijzigd door Verwijderd op 15-04-2005 22:52 ]

[BtM909]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:15:

Wat zijn jouw argumenten dan?

Alle argumenten inclusief beargumentatie zijn al de revue gepasseerd Vandaar m'n vraag of je er nog meer hebt.

Een ander voorbeeld dan. Als ik een jpegje ga versturen met als mimetype html. Dan zal de browser het niet correct weergeven. Waarom niet? Omdat het geen HTML is, maar een jpeg.

Waarom wordt die niet correct weergegeven? JUIST, omdat de browser er vanuit (moet gaan) gaat dat het een HTML bestand moet zijn.

Ik weet niet hoe ik duidelijker kan aantonen dat het mimetype niet bepaald wat voor bestand iets is.

Je kan het nog verder trekken, lees voor de gein dit artikel eens, en probeer de strekking verder te strekken

edit:

Sorry, kan het artikel even niet vinden

[JHS]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:46:
Hezik, kijk nog eens naar mijn post. Het is *en* html, *en* xhtml. Jullie hebben gewoon allemaal gelijk...

Of juist geen van beiden. Het gaat voor een deel over een hoe-het-te-benoemen, wat je niet echt verder brengt.. Maar volgens mij is inmiddels toch wel duidelijk wát het nu is, zelfs in die analogie. Maar belangrijker, duidelijker is wat je wel / niet en waarom moet doen. En dáár gaat het om, niet om of je het nu HTML, XHTML of groentesoep noemt . Ja, ik vind oeverloos discussieren over dit soort dingen ook leuk, maar op een gegeven moment is het wel duidelijk...

[Verwijderd]

ok, testcase:

HTML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script type="text/javascript">
onload = function() {alert(document.body.nodeName)}
</script>
</head>
<body>
<p>niet afgesloten paragraaf
<p>nog een
</body>
</html>

gooi die code in http://www.rikkertkoppes.com/thoughts/test-suite
en serveer met verschillende mimetypes en observeer in verschillende browsers

iedereen is het er wel mee eens dat dit brakke xhtml is en dus een error op moet leveren, serveer het als text/html en zie dat het als html gezien wordt (die p's zijn ok en de alert is uppercase)

serveer als application/xhtml+xml en zie dat IE het niet pikt, en ff een keurige error geeft

[Glashelder]

Verwijderd schreef op vrijdag 15 april 2005 @ 22:45:
Niet helemaal waar. Ik ben het grotendeels met je eens, behalve het punt dat xhtml verstuurd als text/html geparsed wordt als html. Immers zou het strikt als html geparsed worden, dan zou het niet goed gerendert worden, zoals je zelf hieronder al aangeeft.

Parser ziet dat het niet klopt en gaat in quirksmode.

[Verwijderd]

niet helemaal waar, IE gaat idd in quirksmode, maar dat komt omdat er iets voor het doctype staat. Haal je dat weg dan zit IE in standards mode. FF doet sowieso standards mode. (doe maar eens een boxmodel test erbij)

Wat er gebeurd is dat de browser verteld wordt dat het html is en hij dus z'n html parser te voorschijn tovert en niet z'n xhtml parser (IE kan dit laatste niet eens, want hij heeft er geen, dus die biedt aan het (onbekende) bestand te downloaden)

[ Voor 16% gewijzigd door Verwijderd op 15-04-2005 23:35 ]

[crisp]

Andersom: een DTD zegt zero squad over het document vanuit een browser-perspective. Een browser gebruikt het hooguit om te kijken of hij in standards-compliant mode of in quirksmode moet renderen, voor de rest doet een browser daar helemaal niets mee. Je kan dus een HTML DTD boven een document zetten en serveren als XHTML, en andersom ook (ik ga hier even voorbij aan het opgeven van een default namespace voor XHTML).

Een XHTML DTD boven een document plakken en serveren als text/html maakt het dus geen XHTML. Het is gewoon HTML die toevallig wellformed is (mag je hopen) en daarmee eventueel ook als X(HT)ML geserveerd zou kunnen worden (of die DTD dan ook appropriate is is weer een andere discussie). XHTML als text/html heeft alle kenmerken van HTML en mist bepaalde kenmerken van XHTML, en is dus geen XHTML meer. punt. uit.

[ Voor 4% gewijzigd door crisp op 15-04-2005 23:52 ]

[Verwijderd]

crisp schreef op vrijdag 15 april 2005 @ 23:47:
Een XHTML DTD boven een document plakken en serveren als text/html maakt het dus geen XHTML. Het is gewoon HTML die toevallig wellformed is (mag je hopen) en daarmee eventueel ook als X(HT)ML geserveerd zou kunnen worden (of die DTD dan ook appropriate is is weer een andere discussie).

vergelijk dit met:

Een XHTML DTD boven een valid XHTML document plakken maakt het een XHTML document. Als je het juist doet, is deze XHTML ook als HTML te serveren. Of die DTD dan ook appropriate is, is weer een andere discussie

XHTML als text/html heeft alle kenmerken van HTML en mist bepaalde kenmerken van XHTML, en is dus geen XHTML meer. punt. uit.

XHTML als text/html mist helemaal geen kenmerken van XHTML. Het wordt alleen verkeerd gelezen. Dat wil niet zeggen dat het bestand wat uiteindelijk verzonden en ontvangen wordt, niet de features bevat, sterker nog, het is inhoudelijk nog steeds hetzelfde bestand. Zou ik het text/html bestand wat ik ontvangen heb weer gaan serveren als XHTML, heeft het de kenmerken wel degelijk. Dit geeft aan dat de kenmerken bewaard zijn gebleven, ondanks het doorgeven als text/html. Het mime type heeft geen invloed op het bestand zelf, het verandert geen kenmerken van een bestand.

Ik heb een object (een bestand/erwtensoep). Die gooi ik door een distrubutieproces (serveren). In dat distributieproces geef ik steeds een andere typeomschrijving (xhtml vs html/erwten vs erwtensoep) aan het object, maar verander de inhoud niet. Waarmee eindig ik dan? Volgens mij nog steeds met hetzelfde object, met dezelfde kenmerken etc.

Vergelijk het met casten bij programmeren. Je cast je XHTML als HTML.

[ Voor 6% gewijzigd door Verwijderd op 16-04-2005 00:50 ]

[curry684]

Wat een verhaal.... ik zeg er maar 1 ding over: stel dat je de volgende XHTML als text/html naar een browser stuurt:

code:

<br />

Een correct volgens de regel der wet SGML parsende browser toont dit als volgt:

code:

/>

Ergo het mime-type is wel altijd leading en vitaal dat het correct meegestuurd wordt, omdat het voor de browser aangeeft hoe hij het document moet pakken: een SGML parser bij text/html, een XML parser bij application/*xml*, een JPEG parser bij image/jpg etc. Pas zodra hij op basis van mimetype een SGML of XML parser uit de kast heeft getrokken mag en kan hij beoordelen of er een geldig doctype staat en wat hij vervolgens met dat doctype aanmoet. Want anders heb je een kip en ei probleem: de doctype parsen voordat het uberhaupt besloten is dat het document van een type is dat een doctype bevat

[curry684]

Verwijderd schreef op zaterdag 16 april 2005 @ 00:47:
Vergelijk het met casten bij programmeren. Je cast je XHTML als HTML.

Het is echter een reinterpret_cast die je niet op unrelated objects mag doen omdat de vtables dan niet meer kloppen en tot crashes of foute resultaten kunnen leiden

Overigens is dit wel een mooiere analogie dan de erwtensoep Zoals ik zeg mag je alleen related types casten, en jouw foute aanname is dat je denkt dat dit de class tree is:

code:

MarkupLanguage
+-- SGML
  +-- HTML
    +-- XHTML

Oftewel dat XHTML enkel een superset is van HTML die ook als "de baseclass" te beschouwen is. Dat klopt dus pertinent niet, want de correcte class tree is als volgt:

code:

MarkupLanguage
+-- SGML
| +-- HTML
+-- XML
| +-- XHTML

XML en SGML zijn beide markup languages ja, maar voor geen meter compatible. Een uiterlijk vergelijkbare notatiestijl hebben ze wel, maar verder houdt het snel op zodra je PCDATA, CDATA, custom defined entities en namespaces opentrekt (not to mention wellformedness). En in deze classtree mag je ook expliciet XHTML niet naar HTML casten nee, in geen enkele taal

[ Voor 56% gewijzigd door curry684 op 16-04-2005 01:06 ]

[crisp]

Verwijderd schreef op zaterdag 16 april 2005 @ 00:47:
[...]
XHTML als text/html mist helemaal geen kenmerken van XHTML. Het wordt alleen verkeerd gelezen.

Namespaces? Integratie met andere XML modules (MathML)? Niet mogelijk als je text/html gebruikt...
Andersom kan ik in een 'XHTML' document geserveert als text/html mbv document.write() in javascript content toevoegen. Het document dat jij dan krijgt en opnieuw serveert als echte XHTML (dus met XHTML mimetype) is dan toch echt anders. XHTML is echt wel iets meer dan enkel HTML in een XML-jasje hoor...

Vergelijk het met casten bij programmeren. Je cast je XHTML als HTML.

Casten door er enkel een ander label op te plakken? Waar een browser zich ook nog eens niets van aantrekt?
XHTML syntax in een HTML omgeving is gewoon mallformed HTML...

[ Voor 18% gewijzigd door crisp op 16-04-2005 01:09 ]

[Verwijderd]

curry684 schreef op zaterdag 16 april 2005 @ 00:55:
Wat een verhaal.... ik zeg er maar 1 ding over: stel dat je de volgende XHTML als text/html naar een browser stuurt:
Een correct volgens de regel der wet SGML parsende browser toont dit als volgt:

code:

<br />

Even kijken.. IE, wat, 90% van de markt? Firefox tweede? Beide tonen jouw <br /> gewoon als linebreak. Dit neemt niet weg dat je volledig gelijk hebt

Ergo het mime-type is wel altijd leading en vitaal dat het correct meegestuurd wordt

Als je wilt dat een correct volgens de regel der wet SGML parsende browser het juist rendert/interpreteert.. ja.

Dit alles spreekt nog steeds niet tegen dat nog immer hetzelfde (XHTML) bestand verstuurd wordt, zonder modificaties. Een bestand is imo niet pas een XHTML als het als zodanig verstuurd wordt.

[Verwijderd]

Browsers als firefox kijken wel ezker naar de dtd en mimetype. Die schiet in standaardenmodus als je hem application/xhtml+xml serveert in plaats van text/html. Het is jammer dat niet iedere browser dat ondersteund.

Een oplossing die ik zelf gebruik is met behulp van een stukje php kijken of de browser application/xhtml+xml ondersteund, zoja, geef je de pagina als application/xhtml+xml door en anders als text/html.

Werkt prima.

Het is overigens een uitstekend middel om mee te 'debuggen', ik wil nog wel eens vergeten om & als & neer te zetten en firefox gaat dan direct op zn bek en komt met een error message als je de pagina als application/xhtml+xml serveert.

Edit: Zag niet dat er nog een tweede pagina was , dus paar dingetjes die ik zei waren beetje dubbelop

[ Voor 9% gewijzigd door Verwijderd op 16-04-2005 01:12 . Reden: Zag niet dat er nog een tweede pagina was |:( ]

[crisp]

Verwijderd schreef op zaterdag 16 april 2005 @ 01:05:
[...]
Even kijken.. IE, wat, 90% van de markt? Firefox tweede? Beide tonen jouw
gewoon als linebreak. Dit neemt niet weg dat je volledig gelijk hebt

Wie heeft het over browser implementaties? Dat heet gewoon error-correction; het voordeel van HTML...

[...]
Een bestand is imo niet pas een XHTML als het als zodanig verstuurd wordt.

Wat bepaalt dat dan wel? De DTD zeker? Dan kan een Fiat ook een Ferrari zijn als ik er een Ferrari-embleem opplak...

[curry684]

Verwijderd schreef op zaterdag 16 april 2005 @ 01:05:
[...]

Even kijken.. IE, wat, 90% van de markt? Firefox tweede? Beide tonen jouw <br /> gewoon als linebreak. Dit neemt niet weg dat je volledig gelijk hebt

Blijft het punt staan dat als IE7 morgen als critical update voor WinXP/2k uitkomt met wel strikte SGML, HTML en XHTML implementaties over een maand 50% van de markt overal vreemde /> meuk in jouw websites aantreft als je je XHTML als text/html serveert, en als je het daar nu eens mee eens bent dat je het daarom niet moet doen zijn we het geloof ik allemaal eens

[bgever]

OK. Ik wordt er helemaal gek van, want we halen echt alles door elkaar (ik niet uitgezonderd ).

Even voor de duidelijkheid, zodat we allemaal elkaar goed begrijpen:

---

Twee perspectieven

1. Mens (hezik): De mens ziet tekst. Tekst in zijn editor, tekst die verstuurd wordt, tekst die de browser probeert te parsen. Tekst is in XHTML syntax. Blijft XHTML syntax geen bitjes of bytejes gaan verloren, dus het is XHTML.
2. Browser (ik en anderen): De browser ziet bytes (karakterset waarden) met metadata (headers). Metadata = gegevens over gegevens. Een gegeven is dat de bytestream, text/html is. Voor de browser is het dus HTML. Wát die bytestream bevat is niet relevant, maar het is dus HTML, en de browser zal het ook zo proberen te behandelen.

---

Ok, nu we deze twee feiten overzichtelijk kunnen zien, kunnen we verder. Als je wilt bepalen wat het is, dan moet je wel weten vanuit welk perspectief je het bekijkt. Omdat je anders appels met peren gaat vergelijken, en er zo'n belachtelijk langdradige discussie over erwten en erwtensoep ontstaat. (Was ik er maar nooit over begonnen! )

Ik moet hezik dus 100% gelijk geven vanuit perspectief 1.

Echter vanuit perspectief 2 niet.
Het ís dus HTML voor de browser. De browser zal dit dus ook als HTML willen verwerken, en zal hiervoor een SGML parser pakken. De IE SGML parser heeft echter wat fixjes en tweakjes waardoor deze met wat kleine hobbels door XHTML tekst kan worstelen - mede doordat XHTML zo ontworpen is dat een HTML parser het als malformed HTML zal zien - en met wat oplapwerk er output van kan maken die deze naar de renderer kan sturen.

Hopelijk is dit wat duidelijker dan mijn erwtensoep verhaal...

[ Voor 4% gewijzigd door bgever op 16-04-2005 02:19 ]

[coubertin119]

Verwijderd schreef op zaterdag 16 april 2005 @ 00:47:
[...]


vergelijk dit met:

[...]


[...]


XHTML als text/html mist helemaal geen kenmerken van XHTML. Het wordt alleen verkeerd gelezen. Dat wil niet zeggen dat het bestand wat uiteindelijk verzonden en ontvangen wordt, niet de features bevat, sterker nog, het is inhoudelijk nog steeds hetzelfde bestand. Zou ik het text/html bestand wat ik ontvangen heb weer gaan serveren als XHTML, heeft het de kenmerken wel degelijk. Dit geeft aan dat de kenmerken bewaard zijn gebleven, ondanks het doorgeven als text/html. Het mime type heeft geen invloed op het bestand zelf, het verandert geen kenmerken van een bestand.

Ik heb een object (een bestand/erwtensoep). Die gooi ik door een distrubutieproces (serveren). In dat distributieproces geef ik steeds een andere typeomschrijving (xhtml vs html/erwten vs erwtensoep) aan het object, maar verander de inhoud niet. Waarmee eindig ik dan? Volgens mij nog steeds met hetzelfde object, met dezelfde kenmerken etc.

Vergelijk het met casten bij programmeren. Je cast je XHTML als HTML.

Een document met een XHTML DTD en als text/html verzonden mist wel kenmerken van XHTML. In HTML (en dus ook documenten met een XHTML DTD verzonden als text/html) is zijn BODY en HTML speciale elementen met bepaalde limieten wat betreft styling dmv CSS. In een document met een XHTML DTD dat verzonden is met application/xhtml+xml als mime-type zijn die 2 elementen niet meer dan 2 te stylen block-level elementen.

De afhandeling van Javascript is anders. De afhandeling van CSS is anders. De uitbreiding die in XML (en dus in een document met XHTML DTD én application/xhtml+xml) mogelijk is doormiddel van namespaces en andere XML-verwanten (slechte benaming maar je hebt m'n punt wel, dingen als MathML, SVG enzoverder dus) is onbestaande. Hoe wil je blijven volhouden dat een document mét XHTML DTD maar zonder het mime-type toch hetzelfde is als een document mét XHTML DTD én ook het juiste mime-type?

[Verwijderd]

curry684 schreef op zaterdag 16 april 2005 @ 00:55:
Wat een verhaal.... ik zeg er maar 1 ding over: stel dat je de volgende XHTML als text/html naar een browser stuurt:

code:

<br />

Een correct volgens de regel der wet SGML parsende browser toont dit als volgt:

code:

/>

ff corrigeren hoor, <br/ is kort voor <br>, dus <br/> wordt <br>> (geen slash te zien

amaya doet dit bijvoorbeeld "goed" (edit - dacht ik, ff testen en er wordt blijkbaar toch gecorrigeerd), andere browsers hebben idd foutcorrectie, wat mijns inziens een feature is,

uitleg hierover heb ik al eens geschreven: http://www.rikkertkoppes.com/thoughts/net-shorttag

zie ook: http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.7

en het zijn idd gewoon 2 standpunten, ik zou persoonlijk een xhtml textbestand die verstuurd is als text/html ook gewoon xhtml noemen, vanwege de gebruikte syntax. Maar da's denk ik persoonlijke smaak, voor mijn part noem je het een broodje pindakaas (nee niet doorgaan met analogieen en zeggen dat de browser het als pinda's behandeld ), feit is dat het voor de browser op dat moment behandeld wordt als html. Als je het bestand saved en served als xhtml, dan is het weer xhtml ja

is er wat aan het bestand veranderd - nee, alleen de manier van serveren is anders, vandaar dat ik het er mee eens ben dat je het xhtml blijft noemen, alleen is het op het moment dat de browser er wat mee doet niks meer dan (eventueel malformed) html (waar je mee weg komt vanwege de foutcorrectie over het algemeen)

Dat laatste gaat dus al niet meer op met een constructie als <script /> (in IE, die struikelt daar gegarandeerd over omdat het script element dus niet wordt afgesloten)

edit: toevoeging: voor zover ik heb kunnen testen ondersteunt alleen lynx (IE, FF, moz, opera, amaya niet) de NET shorttag, maar ook lynx laat geen extra > zien (bij het valideren met de w3c validator komt ie wel boven water (zet de parse tree aan)

[ Voor 73% gewijzigd door Verwijderd op 16-04-2005 11:35 ]

[Genoil]

Ik heb het helemaal doorgelezen, gelachen om de leuke metaforen, me verbaasd over de ijver die sommigen ten toon spreiden om hun punt te maken, en respect voor hezik omdat hij zo dapper z'n kont in de krib gooit tegen een legertje puristen, prachtig!

Maar ik zat zo'n beetje te denken aan een titlechange en dan kan hij in principe gelijk op slot, want de onvolledige vraagstelling is de bron van de discussie. Als je het beter formuleert als "XHTML geserveerd als text/html, wat is het?" dan is het antwoord: "XHTML geserveerd als text/html". Klaar.

[Erkens]

coubertin119 schreef op zaterdag 16 april 2005 @ 09:16:
Hoe wil je blijven volhouden dat een document mét XHTML DTD maar zonder het mime-type toch hetzelfde is als een document mét XHTML DTD én ook het juiste mime-type?

dus als jij dat XHTML bestand (wat gewoon een ascii tekst file is) op je PC hebt staan en lokaal opent is het plotseling geen XHTML meer omdat er geen juist mime-type bij zit
of als je een dergelijk bestand via een ftp server in je browser bekijkt is het ook ineens iets anders?

[crisp]

De 'human perspective' is hier van ondergeschikt belang, en daarbij zou je vanuit dat perspectief hooguit kunnen zeggen 'het zou XHTML kunnen zijn' op basis van de DTD en de syntax. XHTML behelst echter wel meer dan alleen dat, en dat openbaart zich alleen in het perspectief waarvoor (X)HTML gemaakt is: een browseromgeving

Erkens schreef op zaterdag 16 april 2005 @ 13:44:
[...]

dus als jij dat XHTML bestand (wat gewoon een ascii tekst file is) op je PC hebt staan en lokaal opent is het plotseling geen XHTML meer omdat er geen juist mime-type bij zit

Ja, je browser kan daar anders mee omgaan

[ Voor 35% gewijzigd door crisp op 16-04-2005 13:48 ]

[curry684]

Erkens schreef op zaterdag 16 april 2005 @ 13:44:
[...]

dus als jij dat XHTML bestand (wat gewoon een ascii tekst file is) op je PC hebt staan en lokaal opent is het plotseling geen XHTML meer omdat er geen juist mime-type bij zit

Je operating system doet bij gebrek aan mimetypes of anderszins bekende fileinformatie op basis van de extension beoordelen wat het is, en de browser doet dat ook als je lokaal files opent. Als jij jouw XHTML met de extensie .html of .htm lokaal opent heb je dus alsnog 99% kans dat het als HTML-tagsoup geparsed wordt op basis van het dan afgeleide type

[samo]

oikoyama schreef op zaterdag 16 april 2005 @ 02:15:
OK. Ik wordt er helemaal gek van, want we halen echt alles door elkaar (ik niet uitgezonderd ).

Even voor de duidelijkheid, zodat we allemaal elkaar goed begrijpen:

---

Twee perspectieven

• Mens (hezik): De mens ziet tekst. Tekst in zijn editor, tekst die verstuurd wordt, tekst die de browser probeert te parsen. Tekst is in XHTML syntax. Blijft XHTML syntax geen bitjes of bytejes gaan verloren, dus het is XHTML.
• Browser (ik en anderen): De browser ziet bytes (karakterset waarden) met metadata (headers). Metadata = gegevens over gegevens. Een gegeven is dat de bytestream, text/html is. Voor de browser is het dus HTML. Wát die bytestream bevat is niet relevant, maar het is dus HTML, en de browser zal het ook zo proberen te behandelen.

---

[...]

En een 3de perspectief:

• Bezoeker: De bezoeker ziet de geparste text zoals deze zich wordt voorgeschoteld. De bezoeker vertrouwt dus helemaal op de output van de browser. De bezoeker is ook bij machte zelf de afweging te maken welk type het is, aan de hand van de output. Je kan er van uit gaan dat de bezoeker niet in de broncode zal gaan kijken. De bezoeker zal in het algemeen van de browser overnemen welk type het is.

Mocht bijvoorbeeld door incompatibiliteit de in XHTML geschreven code niet correct worden weergegeven in HTML door de browser, zal de bezoeker dat als eerste opmerken als incorrect HTML. Als het document uiteindelijk in XHTML geschreven blijkt te zijn, maar nergens correct wordt weergegeven, is het volgens de bezoeker toch een fout van de maker/programmeur, aangezien deze er voor zorgt dat de browser de inhoud niet correct weergeeft. Ongeacht dat het document in XHTML is opgesteld, het wordt weergegeven als HTML, en het document word door beide de browser en de gebruiker geinterpreteerd als HTML.

[Verwijderd]

HTML5 ( http://whatwg.org/specs/web-apps/current-work/ ) gaat hoogstwaarschijnlijk error handling definieren voor text/html. En stapt ook van de SGML basis af. (Net zoals HTML 1 geen SGML basis had.) Er staat een klein beetje informatie hier: http://whatwg.org/specs/web-apps/current-work/#parsing

Het meeste is echter nog niet geschreven. (Het heet momenteel ook nog Web Applications 1.0 en geen HTML5.)

[curry684]

Verwijderd schreef op zaterdag 16 april 2005 @ 14:43:
Het meeste is echter nog niet geschreven. (Het heet momenteel ook nog Web Applications 1.0 en geen HTML5.)

Is het officieel dat HTML5 naast XHTML2 een aparte branche gaat blijven vormen?

[Genoil]

@3e perspectief bezoeker:

Ik denk niet dat de gemiddelde bezoeker ook maar 1 moment de afweging maakt of het XHTML dan wel HTML is. Een heel klein groepje doet "View source" om te kijken naar de markup en het doctype, en van dat groepje zijn er nog maar een paar die bij een XHTML doctype even "Page info" checken of het wel met het correcte doctype geserveerd is. Dat geeft het praktisch nut van deze discussie ook wel een beetje aan. Argumenten als "nou stel dat bepaalde browsers zich ineens wel aan de regels houden, dan staat er ineens overal > in je pagina's" zijn misschien wel waar, maar puur hypothetisch. Dat gaat namelijk niet gebeuren, daar wordt wel omheen gewerkt. Het web is wat dat betreft een gemuteerd gedrocht dat aan elkaar hangt van fouten.

Zelf vind ik de "human perspective" best interessant, en zeer zeker niet "van ondergeschikt belang". Het hele "probleem" is immers juist van dit perspectief ontstaan. Als XML en XHTML niet van die buzzwords waren geweest, zat iedereen nu nog braaf aan de HTML4 en werd alles correct geserveerd. Veel ontwikkelaars stellen het gebruik van semantisch correcte markup icm stylesheets gelijk aan het gebruik van XHTML. Het klinkt ook gewoon hip, zo'n X voor je HTML. Een XHTML doctype is ook gewoon veel stoerder dan zo'n ouderwetse HTML4. Ik begrijp dat dat er bij de standards-mensen slecht in gaat en natuurlijk hebben jullie gelijk dat het eigenlijk allemaal niet klopt. En het is ook heel goed dat jullie als voorlopers op plekken als deze jullie evangelie prediken, maar door de massa gaan jullie nooit worden ingehaald, en oude rommel blijft sowieso tot het einde van internet erop staan.

[bgever]

Genoil schreef op zaterdag 16 april 2005 @ 16:00:
[...]
Zelf vind ik de "human perspective" best interessant, en zeer zeker niet "van ondergeschikt belang". Het hele "probleem" is immers juist van dit perspectief ontstaan. Als XML en XHTML niet van die buzzwords waren geweest, zat iedereen nu nog braaf aan de HTML4 en werd alles correct geserveerd. Veel ontwikkelaars stellen het gebruik van semantisch correcte markup icm stylesheets gelijk aan het gebruik van XHTML. Het klinkt ook gewoon hip, zo'n X voor je HTML. Een XHTML doctype is ook gewoon veel stoerder dan zo'n ouderwetse HTML4. Ik begrijp dat dat er bij de standards-mensen slecht in gaat en natuurlijk hebben jullie gelijk dat het eigenlijk allemaal niet klopt. En het is ook heel goed dat jullie als voorlopers op plekken als deze jullie evangelie prediken, maar door de massa gaan jullie nooit worden ingehaald, en oude rommel blijft sowieso tot het einde van internet erop staan.

Wat zijn ''standards-mensen"? Vat je mij daar ook onder? Ik doe dit wel, omdat ik ook gebruik maak van standaarden, maar ik pas niet echt bij de beschrijvind die jij er van geeft... Want ik werk wél in HTML4, maar maak óók gebruik van de HTML4.01 Strict standaard. Ik neem aan dat je eerder doelt op: webontwikkelaars die gebruik maken van de XHTML standaard?

De reden waarom ik zelf zo driftig op dit onderwep in ga, is doordat de meeste browsers alle aangeleverde pagina's nog steeds als HTML verwerken. Als je dit weet, dan kun je je dus ook gaan afvragen wat nu het hele nut van XHTML is? Ik ben dan ook van mening, dat XHTML puur een hype is, en dat het eigenlijk iets voor de toekomst is: als de meeste bezoekers middels hun browsers ook gebruik kunnen maken van XHTML (lees: XML functionlaliteit).
Vandaar dat ik zelf ook weer lekker werk in HTML. Daar kun je net zo goed semantiek in toepassen, een duidelijke structuur maken, enkel CSS in losse bestanden gebruiken, en meer van dat soort dingen die soms onterecht aan XHTML gekoppeld worden.
Het is maar een taal, en waarom zou je een andere taal gaan spreken, als de basis net zo verstaanbaar is voor de ander, maar de rest problemen geeft?
Niet dat ik nu iemand verwijt "slecht" te zijn als je XHTML gebruikt, maar het is helaas wel zo dat veel webontwikkelaars XHTML gebruiken terwijl ze hiervover onvoldoende geinformeerd zijn. Helaas behoorde ik daar ook toe...

Verder vind ik dat 3e perspectief "bezoeker" niet echt relevant. Het is namelijk een afgeleide van perspectief 1: "mens".

[ Voor 3% gewijzigd door bgever op 16-04-2005 17:33 ]

[We Are Borg]

curry684 schreef op zaterdag 16 april 2005 @ 14:55:
[...]

Is het officieel dat HTML5 naast XHTML2 een aparte branche gaat blijven vormen?

Idd, ik heb vaak gelezen dat HTML5 niet meer zou komen en dat we het het zouden houden bij 4.01 Dus is dit officieel?

[coubertin119]

We Are Borg schreef op zaterdag 16 april 2005 @ 22:00:
[...]

Idd, ik heb vaak gelezen dat HTML5 niet meer zou komen en dat we het het zouden houden bij 4.01 Dus is dit officieel?

HTML5 wordt niet ontwikkeld door het W3C. Zij zijn op de XML-tour gegaan en ontwikkelen enkel nog verder aan XHTML. XHTML2 is druk bezig met ontstaan. Maar HTML5 (of Web Applications 1.0 zoals het nu nog heet) wordt ontwikkeld door WHATWG, een "organisatie" die volledig losstaat van het W3C. Maar je moet bij Anne van Kesteren zijn om hier meer informatie over te krijgen, hij kent er een hoop meer van .

[Verwijderd]

Hartstikke interresant deze topic. Echter het welles nietes vind ik een beetje jammer.Die tijd hebben we denk ik allemaal achter ons gelaten, toch?! Het draagt niet echt bij aan deze topic. The truth is out there

<praktijk>

Ik ben ff iets in de praktijk gaan checken. Ik heb ben een websitje voor mezelf bezig. Deze heeft xhtml1.1 DTD (geen xml declaratie ervoor). Onder Firefox en IE6 worden de floated divs goed gepositioneerd mbv. text/html. Echter IE5.5 gaat de mist in een div treed buiten zijn “oevers”, is een bekend probleem (CSS hacks uitvoeren, heb nog niet een werkende gevonden).

Wanneer ik de application/xml+xhtml in meta-tag gooi ziet Firefox en IE6 nog steeds ok uit EN IE5.5 gaat nu wel goed met de desbetreffende div om, echter de CSS property margin: 0 auto; werkt niet meer ok. De "wrapper" div staat niet meer gecentreerd.

IE5.5 gaat al anders om met application/xml+xhtml dan text/html.

</praktijk>

De eerder genoemde “uitsluiting van 90% van de gebruikers” lijkt dus voor mijn testje niet op te gaan.

[ Voor 3% gewijzigd door Verwijderd op 17-04-2005 00:22 ]

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 00:21:
Wanneer ik de application/xml+xhtml in meta-tag gooi ziet Firefox en IE6 nog steeds ok uit EN IE5.5 gaat nu wel goed met de desbetreffende div om.......

de laatste keer dat ik die content-type meegaf aan IE(6) wilde hij de file downloaden want hij kon er niks mee, nogal logisch want IE is een oud ding wat zich niks aan wil trekken van "nieuwe" technieken uit 2000.
Dus of jij hebt een of andere plugin geinstalleerd, of mijn schone install van IE6 klopt niet

edit:
meta tag

overigens zie ik bij mijn sites (xhtml) geen verschil in Firefox, welk content-type ik ook gebruik

[ Voor 14% gewijzigd door Erkens op 17-04-2005 00:35 ]

[crisp]

Verwijderd schreef op zondag 17 april 2005 @ 00:21:
[...]

Content-type hoort in je HTTP headers, en niet in een meta-tag. Een browser dient vooraf te weten om wat voor bestand het gaat, achteraf dmv een meta-tag is dus ook compleet zinloos en vziw doet een browser daar niets mee.
IE5.5 kent zelfs geen standards-compliant mode, dus doctype switching zal je ook niet helpen...

Verder: zolang je je content als text/html blijft sturen maakt het niet eens uit wat voor DTD er boven staat; het wordt immers toch als HTML behandeld.

[ Voor 16% gewijzigd door crisp op 17-04-2005 00:35 ]

[Not Pingu]

Verwijderd schreef op zondag 17 april 2005 @ 00:21:
De eerder genoemde “uitsluiting van 90% van de gebruikers” lijkt dus voor mijn testje niet op te gaan.

Totdat je je XHTML file op een webserver zet, en door die webserver laat serveren als application/xml+xhtml. Dan gaat het wel fout in IE.

Ik meng me verder niet in deze discussie, omdat het zoals altijd uitloopt in een welles-nietes festijn tussen standaarden-fundamentalisten en pragmatische webdesigners.

[crisp]

Gunp01nt schreef op zondag 17 april 2005 @ 00:35:
[...]
Ik meng me verder niet in deze discussie, omdat het zoals altijd uitloopt in een welles-nietes festijn tussen standaarden-fundamentalisten en pragmatische webdesigners.

Deze discussie gaat helemaal niet over standaarden-fundamentalisme of pragmatiek. In feite ben ik namelijk beide (ik zal altijd voor een standaard kiezen die het beste bij de praktijk aansluit, voor een webinterface zal dat HTML zijn)

[ Voor 14% gewijzigd door crisp op 17-04-2005 00:41 ]

[Verwijderd]

Gunp01nt schreef op zondag 17 april 2005 @ 00:35:

Totdat je je XHTML file op een webserver zet, en door die webserver laat serveren als application/xml+xhtml. Dan gaat het wel fout in IE.
.

Klopt dan gebeurd er met IE helemaal niets meer, einde oefening.
Ok, ik heb dus in een html-extensie <discussie>xhtml elementen</discussie> gepropt. Ik vind het vreemd dat het div grootte probleem van IE5.5 weg is met xhtml1.1 DTD en application/xml+xhtml mime-type, dus. Er komen wel CSS fouten voor terug, maar toch.

Er wordt hier gezegd dat de juiste procedure is dat HTTP-header de mime-type aangeeft. Waarom staat er uberhaupt in de metadata om wat voor een soort document het gaat? Is het dan een soort controlle?

Hier wordt opgedoeld dat 90% van de browsers (IE) alleen text/html HTTP-headers versturen. Of heb ik het nou bij het foute eind? En ja, ik vind het ook gewoon geil om een xhtml-doctype in mijn document te knallen.

samengevat; men kan net zo goed html4.01 gebruiken, IE snapt toch niets anders.

[ Voor 35% gewijzigd door Verwijderd op 17-04-2005 10:33 ]

[Verwijderd]

buiten het feit dat je xhtml 1.1 niet eens als text/html mag versturen

- met de mathplayer plugin geinstalleerd slikt IE wel application/xhtml+xml, echter het wordt nog steeds door de html parser geduwd
- Als je een xml prolog boven je xhtml documenten zet, springt IE in quirksmode, wat boxmodel problemen oplevert, laat je deze weg, dan rendert IE in standards mode

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 10:28:
buiten het feit dat je xhtml 1.1 niet eens als text/html mag versturen

o?
bewijs?

[blizt]

Als we naar deze tabel over (X)HTML-mediatypes kijken, zien we dat je XHTML 1.1 in principe nog wel mág verzenden als text/html, hoewel het wel heel sterk wordt afgeraden.

[Verwijderd]

http://www.w3.org/TR/2002...a-types-20020801/#summary

"should not"

edit: spuit 11

ok, mag was iets te krachtig, vervang door "niet zou moeten"

[ Voor 50% gewijzigd door Verwijderd op 17-04-2005 10:41 ]

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 10:38:
http://www.w3.org/TR/2002...a-types-20020801/#summary

should is iets anders dan must

[blizt]

quote: RFC 2119

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

Dus het mág, maar je moet rekening houden met de consequenties. M.a.w. is het gewoon niet aan te raden, maar als je het per sé wilt (IE-compatible blijven ofzo) dan kan je het doen ... Vraag is alleen of het dan nog nut heeft, maar dat is 'n andere discussie geloof ik

[Verwijderd]

Uit die tabel blijkt alleen maar wat overal keer op keer herhaald wordt. Je mag gerust XHTML 1.0 versturen met text/html content-type. Dat sommige parsers in theorie hun nek kunnen breken over afgekorte elementen is heel leuk, maar het blijft een beetje bij theorie aangezien het in praktijk wel best gaat. Dat is uberhaupt een deel van de reden waarom XHTML 1.0 een soort overbrugging is tussen HTML en het echte XHTML (als XML aangeboden dus)..

Overal zul je vinden dat XHTML redelijk backward compatible is met HTML 4.01, in praktijk gaat er niet zoveel mis als je het met text/html content-type verstuurt.

Kortom, ik gebruik zelf lekker XHTML 1.0 Strict, verstuur dat met text/html content-type, en dan doe je niet iets wat expliciet wordt afgeraden. Ja, wel door mensen die over SGML parsers blijven beginnen, maar goed, ik kan zelf wel beslissen waar ik voor kies als ik wat rondlees op w3.org, en dat zou iedereen moeten doen.

En nee, ik heb er nog nooit een probleem mee gehad.

[Verwijderd]

Vraagje: Er wordt hier gezegd dat de juiste procedure is dat HTTP-header de mime-type meestuurt. Waarom staat er uberhaupt in de metadata om wat voor een soort document het gaat? Is het dan een controlle?

Hier wordt opgedoeld dat 90% van de browsers (IE) alleen text/html HTTP-headers versturen. Of heb ik het nou bij het foute eind? En ja, ik vind het ook gewoon geil om een xhtml-doctype en syntax in mijn document te knallen.

samengevat; men kan net zo goed html4 strict DTD gebruiken, IE snapt toch niets anders dan html.

[Verwijderd]

@cheatah: ik raad het af omdat het problemen kan opleveren in scripts en idd in een enkele keer met afgekorte elementen. Dit heet niks met de SGML shorttag te maken, maar gewoon met het feit dat elementen niet worden afgesloten.

met <br />, <hr /> en <img /> is dat geen probleem, echter wel met bijvoorbeeld <script /> (als je alleen maar naar een js file refereert). IE gaat hier geheid van op z'n bek omdat het script element nu niet afgesloten wordt.

Verder kun je problemen krijgen met je scripts op het moment van switchen, denk bijvoorbeeld aan case sensitivity en innerHTML / document.write issues.

Als je van al deze dingen op de hoogte bent: ga je gang, maar ik heb hier genoeg topics voorbij zien komen met mensen die hier problemen mee kregen: tegen die mensen zou ik willen zeggen: lees je goed in in de materie (dit topic is nu een mooie om naar te verwijzen), of gebruik gewoon geen xhtml.

Door te adviseren om geen xhtml te gebruiken tenzij je het echt nodig hebt, voorkom je imho een hoop problemen

@hierboven: browsers versturen geen mime type, servers doen dat, IE kan idd alleen maar met HTML omgaan, en beschouwd xhtml ook als html (en dat gaat in het algemeen redelijk goed, afgezien van de punten hierboven). Met een mimetype in de metadata wordt iha niks gedaan, behale geloof ik als er helemaal geen mimetype wordt meegestuurd. Verder kunnen sommige editors en jijzelf er wel profijt van hebben, je ziet dan iig waar je in bezig bent.

Mijn documenten verstuur ik als xhtml (+mathml) naar browsers die dat ondersteunen. Browsers die geen application/xhtml+xml in de accept headers hebben staan krijgen html 4.01 (met 5regels php en wat string replaces heb je van xhtml zo weer html gemaakt). In mijn scripts hou ik hier ook rekening mee. (dus als je in het tabelletje kijkt ben ik mathml met html als text/html aan het versturen, da's natuurlijk ook niet best practice, maar wel datgene wat imho het beste werkt; ik had ook xhtml+mathml als text/html kunnen doen, maar het wordt toch geparsed als html, dus vind ik het als html netter, kwestie van smaak denk ik)

[ Voor 41% gewijzigd door Verwijderd op 17-04-2005 11:12 ]

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 11:05:

met <br />, <hr /> en <img /> is dat geen probleem, echter wel met bijvoorbeeld <script /> (als je alleen maar naar een js file refereert). IE gaat hier geheid van op z'n bek omdat het script element nu niet afgesloten wordt.

Daarom moet je ook geen elementen gaan afkorten die standaard niet empty zijn. Dat staat keurig vermeld in de compatibility guidelines.

Verder kun je problemen krijgen met je scripts op het moment van switchen, denk bijvoorbeeld aan case sensitivity en innerHTML / document.write issues.

Als je niet alles eerst naar lower- dan wel uppercase cast wel ja. Het is echt een kleine moeite om scripts compatible te maken.

Als je van al deze dingen op de hoogte bent: ga je gang, maar ik heb hier genoeg topics voorbij zien komen met mensen die hier problemen mee kregen: tegen die mensen zou ik willen zeggen: lees je goed in in de materie (dit topic is nu een mooie om naar te verwijzen), of gebruik gewoon geen xhtml.

Daar kan ik het mee eens zijn. Het belangrijkste is: loop niet blind achter iemand anders aan en trek zélf je conclusies.

Door te adviseren om geen xhtml te gebruiken tenzij je het echt nodig hebt, voorkom je imho een hoop problemen

Je stelt het alleen maar uit. Vroeg of laat kom je het vanzelf tegen. Stel je voor dat je een bestaande site moet opknappen, en dat je de kennis mist om bepaalde probleempjes op te lossen. Zou je dan die site om gaan zetten naar HTML 4.01?

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 11:05:
<script /> (als je alleen maar naar een js file refereert). IE gaat hier geheid van op z'n bek omdat het script element nu niet afgesloten wordt.

je bent niet verplicht om het zo te sluiten, je mag best <script></script> doen of zelfs <br></br>
Maar omdat we (bijna) altijd te maken hebben met een brakke browser (IE) moet je gewoon wat extra backwards compatible zaken toevoegen, zoals dus die </script>

Verder kun je problemen krijgen met je scripts op het moment van switchen, denk bijvoorbeeld aan case sensitivity en innerHTML / document.write issues.

case sensitivity is bullshit, alles kleine letters, klaar.
scripting _kan_ problemen geven idd, maar als webdeveloper dien je daar rekening mee te houden, scripts van derden moet je ook niet zomaar gaan toevoegen. Wil je dat wel dan moet je wat truckjes toepassen om die (oude) scripts te gebruiken, maar beter is om ook die gewoon compatible te houden, document.write etc is bijna nooit nodig

Als je van al deze dingen op de hoogte bent: ga je gang, maar ik heb hier genoeg topics voorbij zien komen met mensen die hier problemen mee kregen: tegen die mensen zou ik willen zeggen: lees je goed in in de materie (dit topic is nu een mooie om naar te verwijzen), of gebruik gewoon geen xhtml.

dat zijn ook de mensen die gewoon 1337 willen doen, maar gewoon geen kennis hebben en XHTML alleen maar leuk vinden staan. Als je je werk serieus neemt, dan is er geen enkele reden om niet XHTML te gebruiken. Uiteraard zijn er uitzonderingen als je met server software zit die gewoon (nog) niet weet hoe hij valid (X)HTML moet afleveren (bijvoorbeeld React )

[Verwijderd]

als je casesensitivity bullshit vind, moet je juist alles in hoofdletters doen. nodeNames geven in HTML uppercase terug en in XML (XHTML) zoals je ze hebt gemaakt (case sensitive).

Als je de kennis niet hebt om probleempjes op te lossen moet je het ook niet doen vind ik, vraag dan een collega die dit topic wel gelezen heeft

de 2 posters hierboven geven zelf ook al aan: als je met xhtml bezig gaat, moet je wel bv de compatibility quidelines ff gelezen hebben, anders kan je tegen onverwachte problemen aanlopen

[ Voor 23% gewijzigd door Verwijderd op 17-04-2005 11:22 ]

[Verwijderd]

Verwijderd schreef op zondag 17 april 2005 @ 11:17:

Als je de kennis niet hebt om probleempjes op te lossen moet je het ook niet doen vind ik, vraag dan een collega die dit topic wel gelezen heeft

Dan komen we terug op een heel eenvoudige stelling, en die is als volgt:

Houd je niet bezig met zaken waar je geen verstand van hebt.

Je kunt je natuurlijk altijd inlezen in de materie, dat is wat ik tenminste heb gedaan, om de benodigde kennis te krijgen. Maar maak niet de fout om zomaar achter iemand in dit topic, achter blogs, of achter wat dan ook aan te gaan.

Als iemand xhtml met text/html gaat versturen omdat pietje heeft gezegd dat het prima kan, dan gaat er nog steeds iets niet helemaal goed. Doe gewoon voldoende kennis op om zelf die beslissingen te kunnen maken. Dat is wat ik wil zeggen

[Verwijderd]

/me is eensch

en ik heb het natuurlijk ook niet bij het juiste eind, maar daarom zijn fora als deze wel handig, waar bijvoorbeeld een Erkens zegt "bewijs!!!1111oneoneeleven"

en dan werd ik weer even eraan herinnerd dat xhtml1.1 als text/html heel eventueel toch nog wel mag

but the full implications should be understood and the case carefully weighed
before implementing any behavior described with this label

[ Voor 115% gewijzigd door Verwijderd op 17-04-2005 11:26 ]

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 11:23:
/me is eensch

en ik heb het natuurlijk ook niet bij het juiste eind, maar daarom zijn fora als deze wel handig, waar bijvoorbeeld een Erkens zegt "bewijs!!!1111oneoneeleven"

offtopic:
ten eerste ben ik niet "een Erkens", gewoon Erkens
daarnaast heb ik niet gezegt "bewijs!!!1111oneoneeleven" je moet mensen geen woorden in de mond leggen die ze niet gezegt hebben

[Verwijderd]

moet ik nog expliciter "dank je wel" zeggen?

@hieronder, dat was niet de bedoeling, excuses.

edit: dit wordt een beetje offtopic, Erkens, ik heb je ff een mailtje gestuurd, laten we de thread schoonhouden iig

[ Voor 100% gewijzigd door Verwijderd op 17-04-2005 12:00 . Reden: typo ]

[Erkens]

Verwijderd schreef op zondag 17 april 2005 @ 11:42:
moet ik nog expliciter "dank je wel" zeggen?

dus iemand belachelijk maken heet bij jou "dank je wel" zeggen

[blizt]

Erkens, zal dan wel aan mij liggen, maar ik zag ook wel dat mophor je bedankte.. Ok, misschien niet zoals je het gewend bent; maar het is toch duidelijk wat hij wil zeggen?

[We Are Borg]

Verwijderd schreef op zondag 17 april 2005 @ 10:53:
Kortom, ik gebruik zelf lekker XHTML 1.0 Strict, verstuur dat met text/html content-type, en dan doe je niet iets wat expliciet wordt afgeraden. Ja, wel door mensen die over SGML parsers blijven beginnen, maar goed, ik kan zelf wel beslissen waar ik voor kies als ik wat rondlees op w3.org, en dat zou iedereen moeten doen.

Even benieuwd naar verdere gedachtes: waarom stuur je het niet met een application/xhtml+xml mime naar de browsers die dat wel aankunnen en een text/html naar de browsers die het niet begrijpen ? Wat voor motivatie zit daar achter ?

[Verwijderd]

deze denk ik
http://www.mozilla.org/docs/web-developer/faq.html#accept

misschien is deze ook wel een aardige read-up:
http://www.w3.org/International/articles/serving-xhtml/

[ Voor 43% gewijzigd door Verwijderd op 17-04-2005 12:15 ]

[crisp]

Erkens schreef op zondag 17 april 2005 @ 11:13:
[...]

je bent niet verplicht om het zo te sluiten, je mag best <script></script> doen of zelfs <br></br>
Maar omdat we (bijna) altijd te maken hebben met een brakke browser (IE) moet je gewoon wat extra backwards compatible zaken toevoegen, zoals dus die </script>

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

quote: http://www.w3.org/TR/html401/struct/text.html#h-9.3.2.1

Start tag: required, End tag: forbidden

Versus:

quote: http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1

Start tag: required, End tag: required

[bgever]

Verwijderd schreef op zondag 17 april 2005 @ 10:53:
Overal zul je vinden dat XHTML redelijk backward compatible is met HTML 4.01, in praktijk gaat er niet zoveel mis als je het met text/html content-type verstuurt.

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

Kortom, ik gebruik zelf lekker XHTML 1.0 Strict, verstuur dat met text/html content-type, en dan doe je niet iets wat expliciet wordt afgeraden. Ja, wel door mensen die over SGML parsers blijven beginnen, maar goed, ik kan zelf wel beslissen waar ik voor kies als ik wat rondlees op w3.org, en dat zou iedereen moeten doen.

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 )

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!

[André]

Leuke discussie, hij was al 2 maand niet meer geweest natuurlijk

* André zorgt gewoon dat zijn sites overal werken en er hetzelfde uitzien met semantisch verantwoorde documenten.

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

[ Voor 54% gewijzigd door André op 17-04-2005 14:06 ]

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