A HTML, XML és XHTML kapcsolatának megértése
Maciej Stachowiak közölte Understanding HTML, XML and XHTML című bejegyzését a Surfin' Safari blogban, mely a Safari böngésző alapját képező Webkit változásait is hivatott bejelenteni. Bár egy a
■ <canvas> elemet ért változás ihlette a bejegyzést, a mondanivaló minden fejlesztőt érinthet. Jól meg kell gondolni, hogy milyen környezetben szolgáljuk ki HTML vagy XHTML lapjainkat, hiszen nem biztos, hogy a szándékolt formában értelmezi őket a böngésző. A különböző problémák miatt Maciej is a legkevésbé kockázatos HTML használatát ajánlja.
ááá, nevetséges
Miért nem teszik ugyanezt a böngészők? Miért veszik a MIME típust szentnek, amikor nyilvánvaló, hogy az van tévesen megadva, és a dokumentumban a doctype-ban egyértelműen jelzi a dokumentum létrehozója, hogy milyen értelmezést szán a dokumentumának?
Röhej. A doctype a lényeg, nem a MIME. Ez teszi fájlként is hordozhatóvá a dokumentumot. Hogy jön ahhoz bármilyen automatizmus, hogy ha én gyártok egy XHTML doksit, jelölöm a fejlécben is, hogy mi az (mert annyira gagyik, hogy egyébként nem tudják észrevenni, pedig tudhatnák -- de ez már kicsit más kérdés) és ezt felülbírálva más MIME típussal küldje el? És ha el is küldi, miért olyan gagyik a böngészők, hogy nem a doctype-ban megadottak szerint cselekedjenek? ÁÁÁÁ....
IE
doctype vs mime
Kiterjesztés
Fájlnak is lehet kiterjesztése. Ha egy .txt kiterjesztésű fájlt nyitsz meg amiben mondjuk dokumentumtípus deklarációkat tárolsz felsorolva akkor a szövegszerkesztő vagy a böngésző nyissa meg?
A MIME is kb ennyit ér
Ha a böngésző kap egy txt kiterjesztésű cuccot, rögtön txt-ként értelmezze? Nem, ez nem elég. (Valami ilyesmi miatt találták ki a MIME-t: a kiterjesztés nem vált be). De a MIME sem elég. A fájl elejébe kell rakni a fejlécet természetesen, ez a normális -- nem is kellett volna másban gondolkodniuk.
A hasonlatoddal élve próbáld ki: ha egy gif-et átnevezel jpg-re, természetesen megjeleníti, és természetesen jpg-ként. Ez a normális. Meg lehet tenni, mert a fájl elején van a leírórész. A MIME is felesleges, ha úgyis van egy ugyanilyen információtípust hordozó doctype rész a fájl elején (kvázi header)
És nem csak az IE hibás, hanem minden böngésző, amelyik nem így tesz: gagyiság HTML-ként értelmezni, ha a dokumentum készítője a header részben egyértelműen jelezte, hogy XHTML. És mégvalami: talán nem a dokumentum készítőjét kéne korlátok közé szorítani, mert kavarják a MIME és doctype értelmezését.
És nevetséges, hogy a validátorosok rájöttek, hogy milyen egyszerű erre a "problémára" a megoldás, csak a böngészők nem...
(És igen, ha valaki egy txt-t küld, melynek az elején dokumentumtípus deklaráció van, akkor próbálja meg aszerint értelmezve megjeleníteni a böngésző. Ha nem ez a célod, akkor konvertáld át a txt fájlt html-be, és adj neki html doctype deklarációt, és ezt tedd fel a netre.)
Uff.
Wezz
Re
A kiterjesztés és a
Content-Typelegalább tipp szerepét, szintén nem vitathatod el. (Gondolj pl. egy olyan PHP fájlra, ami 90%-ban HTML és mondjuk 10%-ban PHP kódot tartalmaz. A .php kiterjesztés nélkül neked valószínű a böngésző nyitná meg. Vagy egy Smarty sablonfájl.)Ha nincs más típusinformáció és szöveges tartalomról van szó akkor igen.
Mármint GIF-ként értelmezve jeleníti meg, ezt jelzi is. Ez a legokosabb dolog amit tehet főleg ha pl.
IMGelemről van szó. (Amúgy ez a kettő egyértelműen csak altípusban különbözik. A HTML és az XHTML nem.)Csak sajnos nincs minden fájltípusnak fejléce. Amiknek van azoknak se egységes rendszer alapján.
Ezzel nem értek egyet. A sima szöveg olyan alaptípus amit mindig engedni kéne, attól hogy valami hasonlít a HTML-re még sima szöveg is egyben, és nem kéne automatikusan upgradelni HTML-re. Ha valaki kreál egy olyan új formátumot aminek a dokumentum elejére írt "Helo," a fejléce, akkor minden így kezdődő szöveges dokumentum ezentúl új típusba fog tartozni függetlenül attól hogy .txt vagy
text/plaintípussal van küldve?Ne adj meg semmilyen
Content-Type-ot és máris rá vagy bízva a kliens content sniffer rendszerére. :-)Hát IE máshogy nem is nagyon tudja XHTML értelmező híjján. Amúgy tényleg lehetne beállítható hogy mit kezdjen ilyen esetben, ahogy (az alapértelmezett és aktuális) karakterkódolás is átállítható az értelmezés módja is lehetne állítható.
a mostani rendszerben gondolkodsz, és nem abban, ami jobb
Tehát nézzük:
1: A fájlnév és kiterjesztésből való, vagy a MIME alapú fájltípus-detektálás abból az alpvető hibából ered, hogy bizonyos esetekben nincs a fájloknak leírórészük. Régen úgy gondolkodtak, hogy ez nem szükséges, elég a kiterjesztés. De ez hibás elgondolás, túlhaladtunk rajta, mint a 640kB-on. Nézd meg: egyre inkább szükséges, hogy a fájlok a tartalmi részhez kötődően leíró részt is tartalmazzanak, hordozzanak. Az alacsony szintű fájlok egyre inkább kikopnak. Akik nem használnak header részt, leíró részt a fájltípusukban (nevezzük RAW formátumnak), azok vagy egyedi keretrendszerben akarják csak használni, vagy előbb-utóbb problémájuk lesz vele.
2: Nem kéne egyáltalán engedni a HTML protokollban olyan fájloknak a kezelését, amelyeknek nincs headerjük. A Net tipikusan nem olyan platform, amelyet egyedi keretrendszernek vagy amiben a RAW formátumok használata előnyös lenne. Látható: a header-résszel rendelkező fájloknak (még úgy is, hogy a headerek nincsenek szabványosítva) nincs problémájuk a netes megjelenéssel.
3: Ha egy dokumentum-készítő készít egy dokumentumot, egyértelműen képesnek kell jeleznie, hogy az milyen dokumentum. Csodák csodája, ezt kitalálták a szöveges alapú dokumentum szabványoknál is, mert belátták, hogy ez egy értelmes dolog. Ott van tehát a doctype, amit a szerző egyértelműen megadhat. Nevetséges, hogy csak azért, mert egyes dokumentum szabványok nem követelnek meg fejlécet, és az emiatti zűr kiküszöbölésére hozzácsapnak egy MIME fejlécet ezekhez, a normális headeres dokumentumtípusok kezelésében essen csorba.
És most reagálok konkrétan:
A MIME csak akkor hasznos, ha nincs fejléce a dokumentumnak, egy alacsonyabb szintű azonosító mechanizmus. Nem pótolhatja a headerrészt (pl röhejes lenne, ha RAW képfájlt engedélyezne feltenni a net, aztán a webszerver próbálná kitalálni a tömörítést, színmélységet, méretet stb és így elétenne egy MIME szerű fejlécet -sőt, ha a meglévő jpg fejléc ellenére ő még odatenne egy hibás MIME fejlécet, és a böngésző aszerint értelmezne stb.) A MIME-re nem is lenne szükség. (Sőt, valójában most sincs. (De ezt most nem fejtem ki, hogy miért, hosszú))
Remélem, hogy rájönnek a protokollalkotók, hogy a MIME egy téves út, és megszűnik mihamarabb.
De elvitatom, mert eljárt felette az idő. A php hibásan fejléc nélküli formátum. Ez van. Miért nem raktak bele fejlécet? Mert úgy gondolták, hogy elég a kiterjesztés. Igazuk volt, ezzel a php egy alkalmazás-specifikus formátum lett, tiszta formában nem is szánták a netre. De máris problémákat generál: nem követhető vele a verzióinformáció például. Ragozzam még, vagy meggyőztelek?
Igen igazad van, én is ezt akartam írni, csak elírtam. (Mellesleg a modern rendszerek -jogosan és logikusan- már nem hisznek a kiterjesztésnek, ez a jövő, ebből is látszik: sem a MIME, sem a kiterjesztés nem ér semmit, ha van fejléc. Ha meg nincs fejléc, akkor a dokumentum nem a netre való!)
A gif és JPG közt nagyobb a különbség mint a html és xhtml közt. Azt, hogy altípusban különbözik, a MIME besorolásból veszed? Látható hogy ez is hibás.
A sima szöveg típus se létezzen header nélkül. Nem is létezik. Mivel felengedték a netre ezt a RAW formátumot, kénytelenek voltak elé egy MIME fejlécet tenni. Hibás elképzelés volt. (Hogy miért? Alább még részletezem)
Na ez az! Az ilyen megoldás a hibás. Pl. a szerző nem is tud megadni MIME típust! Nincs rá befolyása! Egy automatizmus dönti el, hogy milyen headerrel küldi el... Pedig a szerzőnek egyértelműen képesnek kéne lennie jelezni, hogy milyen típusú a dokumentuma... És esetünkben meg hiába jelzi, máshogy lesz feldolgozva? Áááá..
Ez már a másik kérdés: ezért csinálták meg olyanra az XHTML-t, hogy egy HTML értelmező is lásson belőle valamit. Ez egy érthető dolog. A baj nem ezzel van, hanem azzal, hogy bár mindenki tudja, hogy az XHTML tartalom is HTML MIME headerrel jön, mégsem kezelik a böngészők ezt megfelelően: ha tudja értelmezni az XHTML formátumot, nevetséges, hogy a MIME típust veszi figyelembe és nem a doctype-ot.
Alapvetően hibás elképzelés volt, hogy a fájltól független headerezéssel próbálják a dokumentumtípust, a dokumentum kezelésének módját meghatározni. Ehelyett egyszerűen ki kellett volna kényszeríteni, szabványosítani a fájl részekénti headerezést. Ez vezet ilyen problémákhoz, és látható, hogy a fejléces fájlformátumok sokkal jobban boldogulnak a neten. Ennek van jövője, a MIME kopjon ki mihamarabb. (Olyan fájlhoz már most is felesleges MIME fejlécet tenni, amelynek már eleve van egy jól meghatározott fejléce)
Wezz
Zárjuk le
Elméletről lehet vitatkozni, de most a gyakorlat van, és ezzel kell kezdeni valamit. Kitalálhatsz bármit, ha a böngészőgyártók nem valósítják meg. Lásd XHTML, CSS, SVG és egyéb szabványok. Nem nagyon van olyan böngésző, amely maradéktalanul betartaná ezeket. Van, amit pedig kénytelenek figyelmen kívül hagyni, mert a jelenlegi több milliárd weboldalból kell kiindulni - ha nem így tennének, akkor használhatatlan eszközt alkotnának.
A jelen helyzet nem véletlenül alakult így. Sok-sok év van mögöttünk, sok-sok ok, hogy valami miért pont úgy, miért ebben a formában áll végül a rendelkezésünkre az aktuális technológia. Naivitás azt hinni, hogy egy élő piacra rá lehet erőszakolni egy technológiát. Még ha jobb, akkor is évek kérdése lehet - nagyon kevés hely van, ahol azonnal lehet cserélni.
Azt is lehet persze játszani, hogy elkezdünk arról vitatkozni, hogy mi lenne, ha holnap jelenne meg az első PC, és gyorsan le kéne tenni az internet alapjait is. Ekkor nyilván egy önleíró fájl lenne a legegyszerűbb, aminek az elején ott van a típusa is. Lám, a MacOSX fájlrendszere egész hasonló.
Nincs tökélesség azonban, nagyon sok szempont van, és ezek között kell ellavírozni. Lehet küzdeni a rendszer ellen, de meg kell tanulni legalább részben elfogadni azt. A fejlesztőknek a jelenlegi rendszerből kell megtanulniuk kihozni a maximumot. Ezt teszik, ezt tették ezzel a lépéssel is. Hogy eléggé gányolás szaga van? Netán nevetséges? Igen. De működik. Ma, most, azonnal. Nem három év múlva. Nyilván a jelenlegi megoldások megtalálása mellett érdemes elgondolkodni azon, hogy mit hoz a jövő, és a megoldások keresése közben a jövővel is kompatibiliseket választani. A MIME kikopik? Megnézem majd, de ha igen, akkor is: a fenti megoldás jövő kompatibilis tud lenni ebből a szempontból is. Sajnos nagyon sok múlt a Microsofton is, hogy idáig jutott a böngészőpiac, az egykor modernnek számító böngésző az évek során tökéletesen elavult lett, és nagyon sok megoládst rákényszerített a piacra. Hamarosan jön a következő, de a múlttal együtt kell élnünk még így is. Ez van.
Kérlek titeket, hogy ezzel zárjuk is le ezt a meddő vitát.
Igazad van
Wezz
Röviden
Én ott arról írtam hogy a MIME típusok (mint egységes besorolások) mindenképp jók ha vannak függetlenül attól hogy mi alapján találod ki hogy melyikbe tartozik.
Írtam egy példát amikor hasznos a kiterjesztés, még lehetne sok hasonlót, nem írtál rá jelenleg használható, jobb megoldást. (Abból a tényből kiindulva hogy sokmindennek nincs headerje.)
Dehogynem. Meg tudod határozni milyen
Content-Typefejléccel teszed közzé a dokumentumot vagy anélkül is küldheted. Gyors teszt alapján:Content-Typefejléc nélkül küldve XHTML 1.0-t, XML deklarációval az elején: IE nem ismeri a típust, de HTML-ként megjeleníti, FF, Opera is megjeleníti és a tagsoup helyett az XML értelmezőt használják. Ezt akartad, nem?Ott vannak a kompatibilitási okok is, ha XML-ként dolgozná fel akkor vannak dolgok amik máshogy működnek.
úgy tűnik mégsem sikerült abbahagyni :-(
A cikk szerint a MIME típus és a doctype deklaráció közt különbség van, ez okozza a gondot. A validátorok helyesen a doctype-ot veszik figyelembe, a rosszul működő rendszerek a MIME-t. Ez alapján gondoltam, hogy ez esetben a MIME felesleges is. Szerinted mindenképp jók ha vannak. (?)
Na jó, tehát még egyszer: Ha nincs header, az nem jó, ez rendben van, ugye? Ezért kell elé tenni egy headert. Ez vagy automatikusan kerül elé (pl a webszerver kiterjesztés, vagy valamilyen fájlvizsgálat alapján eldönti hogy mi legyen), vagy egy egy másik fájlt gyártasz aminek az elejébe beleteszed a MIME headert (vagy egy ini-ben bekonfigolod). Az automatizmus szerver oldalon kvázi felesleges, mert akár a kliens is elvégezhetné ezt a műveletet. Ha a headert magad teszed elé, akkor ott tartunk, amit javasoltam: headeres fájlt publikálsz valójában. Ergó a MIME felesleges.
Nem írok példát a kiterjesztés helyettesítésére (ha feltételezzük, hogy nem lehet header) mert szerintem a header az, ami helyettesítheti. Igazad van, a kiterjesztés hasznos ilyen esetben, de elvitatom, hogy jó megoldás lenne hosszú távon. Valójában a kiterjesztés jobban hasonlít a headerre, mint a MIME: a fájlal együtt adja meg a dokumentum szerzője.
Nincs rá befolyásom. A Content-Type fejléc nem része az XHTML szabványnak. Ha felteszek a netre egy XHTML doksit, nem tudom megadni, hogy milyen MIME típussal menjen ki. Ha beteszed egy php fájlba, és ráteszel egy Content-Type fejléc bejegyzést, akkor már nem XHTML-ről beszélünk, hanem egy webszerver, vagy php értelmező (mint alkalmazás) specifikus állományról.
De nem is járnék jól, ha megadnám a MIME típust: ha megadnám, hogy XML, sok böngésző nem értelmezné; de a cikk szerint a text/HTML fejléc sem jó, mert így meg html-ként értelmezik. Végülis logikus, hogy miért nem engedik, hogy megadjam :-)
De ez érdekes, amit írsz: ha direkt letiltjuk a MIME headert, akkor minden jó lesz? Ez tutijó! Akkor miért nem ez az általános? (Végülis ez is azt mutatja, hogy a MIME felesleges, nem?) (Nem az történik ilyenkor, hogy a webszerver detektálja az agent-et, és tudja, hogy az IE-nek text/html-t, a mozillának xml headert kell küldeni, és mégiscsak küld MIME-t?)
Ejnye, de hisz én épp azt szeretném, ha XML/XHTML-ként dolgozná fel. Nem értem, mire utalsz ezzel. (?)
tényleg nem :)
A logikád kb. ott bukik el, hogy a validátor egy kifejezetten web dokumentumot vár, és ezen a kategórián belül dönt a doctype alapján, míg a böngésző nem.
Felhő
Teszt
Jó, de ha így van ez csak a te saját rendszered korlátja, a lehetőség adott rá, a logikus lépés hogy állítsd be helyesen vagy cseréld le a rendszered.
Bocs, de ha XHTML-t használsz akkor igazából nem kéne meglepőnek lennie, hogy a kliensben ami nem képes ezt kezelni, abban nem fog működni. Tehát küldj HTML-t és nincs semmi gond. Vagy az átmeneti XHTML 1.0-t HTML kompatibilis mód szerint ahhoz tagsoup feldolgozó és
text/htmljár.Nem, egy sor gond lenne vele. (Keresők, HEAD kérés, pár kliensnek nem tetszik jogosan pl. Links, Dillo, validator, stb.)
Nem, elvileg az történik ami itt van leírva:
http://developer.mozilla.org/en/docs/How_Mozilla_determines_MIME_Types
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp
Tesztoldalak:
http://changelog.hu/teszt/xhtml-nincs-content-type.xhtml
http://changelog.hu/teszt/xhtml-nincs-content-type
(számít a kiterjesztés, FF-ban a 2. csak
text/xml, nemapplication/xhtml+xml,METAelem csak IE-nek, a karakterkódolás felismeréséhez van benne)A Mozilla meg pont nem szeretné a megkülönböztetést. Ami érthető is mert az XML alapú feldolgozás miatt egy kósza & jel és máris nem jól formázott a dokumentum, hirtelen lenne egy rakás oldal ami csak IE-ben megy, FF meg hibaoldalt adna.
Csak mint érdekesség, itt a
Content-Typemellett dönt pl.:http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fchangelog.hu%2Fteszt%2Fxhtml-nincs-content-type.xhtml
a HTML working group szerint sem helyes a doctype-ra
ez a tema mar tobbszor at lett beszelve:
hixie
anne
7 év
'99-ben még én is csak úgy dobáltam össze a cuccokat és nem érdekelt, hogy valid (azt se tudtam akkor, hogy mi az), csak vigye az IE. Nem is tudtam, hogy vannak verziói a HTML-nek, a Frontpage meg a Dreamweaver nem hangsúlyozta, hogy van jelentősége.
Mert sokan nem úgy indulnak el ezen a "pályán", hogy "na most akkor w3c.org és átrágom magam a specifikáción", hanem inkább Start menü -> HTML Editor és uccuneki öszetákolni valami jót.
Sokan el se jutnak arra a szintre, hogy elkezdje érdekelni őket, hogy mi van a háttérben, hogy működik, mi mit csinál. De ezt nem is várhatjuk sajnos el.
Az internet mindenkié. És ez így van jól. Csak akkor szem előtt kéne tartani, hogy mit hogy engednek a szerkesztők és a böngészők.
A HTML 3, 4, 4.01 legyen olyan tákolmány, amilyennek tetszik, sokat tenni ellene nem lehet, erre van a Transitional megoldás, és lényegében a quirks mode is ha jól tudom, ami meg próbálja javítani a kódot és kitalálni, mit akart a szerkesztője (tudomásom szerint).
Da ha egy XML fájlt elrontasz, azonnal szól a böngésző.
XHTML 1.1+ esetén is ezt kéne. Ha engedjük a hibát a fejlesztés során (és itt nem a workaroud trükkökről van szó), akkor nem csoda, hogy sokan a kényelmesebb utat választják, aminek az eredménye a quirks mode, és akkor a böngészők persze, hogy tojnak a doctype-ra, a content-type-ra stb.
Tehát szerintem az kéne (de ez már a kutyát nem érdekli, és biztos nem én vagyok az első, aki felveti), hogy ha XHTML 1.1+ mellett döntünk, akkor az csak strict lehessen, minden hiba nélkül, mind a szerkesztés, mind pedig a renderelés oldalon és akkor nem lenne baj. Ha valakinek ez nem fekszik/nem ért hozzá stb., gond nélkül választhatja a korábbi HTML verziók valamelyikét, vagy az XHTML 1.0-t.
Bár lehet, hogy hülyeséget írtam most, de nekem ez a pillanatnyi meglátásom.
--