Jak funguje HTML
2006-03-10 14:12 napsal Lukáš Havrlant
Pošlete-li stránku jako text/html můžete se spolehnout na
to, že prohlížeč bude dodržovat jistá pravidla, kdy si bude domýšlet
různé značky. Vámi napsaný zdrojový kód stránky ještě nutně nemusí
být konečný kód pro prohlížeč. Specifikace HTML totiž obsahuje několik
značek, které jsou „optional“ (neboli jsou nepovinné) a které se
tedy uvádět nemusí, protože prohlížeč snadno pozná, kdy je doplnit.
Jedná se především o ukončovací značky jako například
</li>. Neboli v praxi – máte li nějaký seznam
a neukončujete jednotlivé položky značkou </li>, jak
prohlížeč pozná, kdy má danou značku ukončit? Ukončí ji ve chvíli,
kdy narazí na element, který není v odrážce povolen. Tedy
nejčastěji další odrážka. Ve chvíli, kdy prohlížeč narazí na druhou
značku <li>, automaticky doplní i potřebnou značku
</li>. I HTML musí být správně formátované tedy
žádné neukončené značky, pouze pokud se o to nepostará přímo
webdesigner, dodělá to prohlížeč. Takže vezměme si takovýto
příklad:
<ul>
<li>hrušky
<li>jablka
<li><span>švestka</span>
</ul>A jak to nakonec uvidí prohlížeč? Vykreslí první odrážku
(hrušky), kouká kouká, další element <li> –
odrážka nemůže být obsažena sama v sobě – proto okamžitě
odrážku ukončí </li> a začne vykreslovat druhou
odrážku. Opět narazí na třetí odrážku a ukončí druhou odrážku.
Vykresluje třetí odrážku, <span> je povolený obsah
elementu <li> tudíž se nic ukončovat nebude a teprve až
narazí na konec seznamu, doplní i poslední </li>
(končí-li seznam, tak s největší pravděpodobností také končí
odrážka, že ano). Takže prohlížeč nakonec vykresluje tento kód:
<ul>
<li>hrušky</li>
<li>jablka</li>
<li><span>švestka</span></li>
</ul>Nejčastěji bývají nepovinné značky ukončovány samy sebou (to byl
třeba ten příklad s </li>), ale mohou být ukončeny
jakýmkoliv elementem, který tam nemá co dělat. Jako příklad mohou
posloužit odstavce, které také mají nepovinnou ukončovací značku.
Element <p> je sice blokový, ale sám blokové elementy
obsahovat nemůže. Tudíž prohlížeč ukončí odstavec ve chvíli, kdy
v jeho obsahu
nalezne kupříkladu nějaký blokový element. Takže když se do jednoho
odstavce pokusíte zanořit další, nepovede se vám to, prohlížeč nejprve
první odstavec uzavře a vytvoří druhý. Stejně tak uzavře odstavec, pokud
se do něj pokusíte vnořit třeba <div>. Takže opět
příklad:
<p>První odstavec
<p><strong>Druhý</strong> odstavec
<div id="footer">
Copyright 2006
</div>Takže jak to uvidí prohlížeč? Začne vykreslovat první odstavec,
narazí na další značku <p> a tak okamžitě chytře
ukončí první odstavec a začne poté vykreslovat druhý.
<strong> normálně vykreslí, jedná se o povolený
obsah odstavce, ale až narazí na <div>, který také
v odstavci nemá co dělat, ukončí druhý odstavec a začne vykreslovat
patičku. Na konci tedy prohlížeč vidí takovýto kód:
<p>První odstavec</p>
<p><strong>Druhý</strong> odstavec</p>
<div id="footer">
Copyright 2006
</div>Elementy, které mají nepovinnou ukončovací značku jsou tyto:
colgroup, dd, dt, li,
option, p, td, tfoot,
th, thead a tr. Pokud se tedy
v těchto elementech vyskytne nějaký další prvek, který tam nemá co
dělat, prohlížeč si automaticky domyslí ukončovací značku a to
i proti vaší vůli – pokud byste chtěli například zanořit
nadpis do odstavce, neuspějete, protože v odstavci nadpis být
nemůže.
<p>
<h1>nadpis</h1>
</p>Protože nadpis je blokový element, prohlížeč automaticky doplní před
nadpis ukončovací značku odstavce </p> a nadpis bude
brán sám o sobě, „druhá“ značka </p>
je tam tedy zbytečná. Prohlížeč by tento kód tedy viděl takto:
<p></p>
<h1>nadpis</h1>
</p>Zde bych ještě udělal drobnou vsuvku a zmínil se krátce o XHTML.
V XHTML dokumentech se žádné značky nedomýšlejí, protože
o to, aby byl dokument správně formátovaný se musí postarat již
webdesigner. Proto budou i výstupy validátory jiné. Zvalidujeme-li ten
kód s nadpisem vloženým do odstavce, HTML validátor
vyhodí chybu právě na tu druhou ukončovací značku, která je tam
navíc („end tag for element "P“ which is not open").
Ovšem na stejný kód pod hlavičkou XHTML vyhodí
validátor jinou chybu – jelikož XHTML si žádné ukončovací
značky nedomýšlí, nedomyslí si ani </p> před nadpisem
a skutečně nyní vnímá daný kód jako nadpis v odstavci. Ovšem
odstavec pořád nemá ve svém povoleném obsahu nadpis, proto validátor
oznámí, že nadpis nemá v odstavci co dělat („document type
does not allow element "h1“ here"). Zpět k HTML.
Je důležité si uvědomit, že prohlížeč si domýšlí ukončovací
značky pouze u těch elementů, které ji mají definovanou jako
nepovinnou. Neplatí, že si domyslí ukončovací značku u každého
řádkového prvku, když do něj vložíte blokový prvek (poznámka:
ona to tak trochu není pravda, co jsem teď napsal, ale je to na delší
povídání, v příštím článku nevalidní zanoření blokového
elementu do řádkového rozeberu podrobněji. Prozatím předpokládejme, že
se prostě neukončí). Takže můžete s klidným svědomím
neukončovat odrážky v seznamu, ale pokud chcete mít (pouze) jednu
odrážku zvýrazněnou, musíte element <strong> také
ukončit:
<ul>
<li>první položka
<li><strong>druhá položka
<li>třetí položka
<li>čtvrtá položka
</ul>Element <strong> nemá volitelnou ukončovací značku, tudíž si ji tam
prohlížeč nedomyslí a zvýrazněná bude i ta třetí a čtvrtá
položka. Správně by ten kód měl pochopitelně vypadat takto:
<ul>
<li>první položka
<li><strong>druhá položka</strong>
<li>třetí položka
<li>čtvrtá položka
</ul>Prozatím jsem se zmiňval o elementech, které mají volitelnou
ukončovací značku. Ale existují i elementy, které mají volitelnou
počáteční značku. Jedná se o elementy
<html>, <head>, <body>
a <tbody>. Volitelná počáteční značka v praxi
znamená, že i když do kódu tyto značky nenapíšete, prohlížeč si
je tam sám domyslí, obdobně jako ukončovací značky
</li>. V každém HTML dokumentu musí být elementy
<html>, <head> a
<body> přítomny, stejně tak element
<tbody> musí být obsažen je
obsažen v každé běžné tabulce. Mimochodem
s tím souvisí i to, že pokud tyto elementy do kódu nenapíšu,
stejně je mohu normálně stylovat (viz třeba kaskádová hádanka, kde
styluji element <body>, aniž bych ho psal do kódu).
Jelikož <html> je kořenový element , musí obalovat
celou stránku. Pokud tedy tuto značku do dokumentu nevložíte, ve chvíli,
kdy prohlížeč narazí na první element či přímo znak, domyslí si tuto
značku a pokračuje dále ve vykreslování. Každý dokument musí obsahovat
element <title>. Pokud neuvedete ani značku
<head>, ve chvíli, kdy prohlížeč narazí na element
<title> (nebo na jiný element, který se běžně vyskytuje
v hlavičce), domyslí si značku <head> a pokračuje ve
vykreslování. Jakmile narazí na element, který se může vyskytnout pouze
v elementu <body> nebo na prostý text, domyslí si
značku <body> (a zároveň uzavře havičku) a pokračuje
ve vykreslování. Na konci dokumentu potom již v klidu uzavře
</body> a </html>. Mějme tedy
následující kód:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<title>jednoduchá stránka</title>
to koukáteZápis je pochopitelně validní. Prohlížeč si všechny elementy domyslí sám, takže nakonec vidí takovýto kód:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>jednoduchá stránka</title>
</head>
<body>
to koukáte
</body>
</html>Že to funguje i v praxi se můžete přesvědčit na tomto webu, všechny tři značky jsem z kódu vyhodil a přece to funguje. Přitom se nespoléháte na nějaké milosrdenství prohlížeče, že ty značky domýšlí, prohlížeč je musí domýšlet, není to jeho „chyba“, je to spíš jeho „princip“. A o tom, jak prohlížeče vidí některé pestrobarevné části kódu zase někdy příště.
Komentáře
Způsob jak prohlížeč domýšlí html kód se dá i zobrazit, třeba bookmarkletem který zobrazí innerHTML dokumentu. Ve FF je tato funkce již připravena, stačí označit kus textu a v kontextovém menu zvolit „View selection source.“
dgx
Asi tam mělo být napsané každá běžná tabulka. Najdou se i případy, kdy tam nebude – třeba tento nebo tenhle.
Mimochodem – díky Ti (již poněkolikáté :-)) za odkaz ;-).
Výtečný souhrn toho, co občas útržkovitě zmiňuji na diskusi JPW. Pro příště vím, kam odkázat :-)
Z hlediska SGML mají nepovinnou ukončovací značku ještě prázdné elementy. U nich je dokonce zakázána.
Reaguji na dgx:
Jistě. Musí být a také je v naprosto každé HTML 4 validní tabulce. Alespoň podle W3C doporučení.
Chamurappi
Výtečný souhrn toho, co občas útržkovitě zmiňuji na diskusi JPW. Pro příště vím, kam odkázat :-)
Jojo, z těch všech útržků se toho nakonec dalo hodně pochopit a a když už jsem něco nevěděl, pomohl Hixie.
Pokud vim – jsem ted lini se tam koukat – tak tbody je v HTML 4 sice povinne, ale pocatecni i koncovy tag jsou nepovinne. Leo
Leo
No, ano. Stejně jako třeba body nebo head. Akorát nevidím rozpor s článkem…
Jeste poznamku – mozna by chtelo upresnit co to znamena, ze prohlizec vidi kod tak a tak – jedna vec je jak to dopadne pri stylovani pres CSS, trochu jina vec je jak dopadne strom dokumentu (DOM) vytvoreny JavaScriptem a trosku neco jineho je kod ulozene stranky (Soubor/Ulozit…) Leo
Nemůžu se zbavit pocitu, že tohle je totální úlet :) Opravdu ti, Lukáši, připadá lepší naučit se komplikovaná pravidla, podle kterých prohlížeče renderují HTML kód, a spoléhat se na ně, než prostě psát podle pravidel XHTML? Upřímně řečeno jsem se zděsil, když jsem viděl zdrojový kód této stránky – možná je to validní, možná se to vykreslí správně, ale připadá mi to hrozné :)
Borek
Nemusíš je znát, i v HTML můžeš psát „hezky“. Nikdo tě v HTML nenutí neuzavírat li apod. Nehledě na to, že všechny tyto pravidla mi přijdou více než jasná. Každý druhý začátečník ví, že neuzavřené li prohlížeči nevadí, tady jsem pouze vysvětlil, proč to nevadí.
Naopak tobě nepřijdou pravidla XHTML komplikovaná? Nejdřív se musíš naučit základní rozdíly poté se musíš naučit to, co už se do DTD nevešlo poté musíš znát „nekompatibilní“ směrnici kompatibility, protože IE application/xhtml+xml nezná, tudíž už kvůli němu musíš psát podle těchto pravidel. Musíš vědět, že při použití XML deklarace shodíš IE do quirku, musíš vědět, že pokud nepíšeš v UTF, neměl bys vynechat XML deklaraci (nebo určit kódování přes http tuším). Musíš vědět, jak vypadá striktně shodný dokument. Měl bys znát pojem well-formed, měl bys vědět, k čemu slouží jmenné prostory. Potom by jsi měl znát základní rozdíly mezi MIME-typy text/html a application/xhtml+xml tj. jak se chovají prohlížeče – všechny se při obdržení tohoto MIME-typu chovají jinak. A tak dále :-)
Reaguji na Borka:
Píšeš-li syntaxí XHTML a užíváš-li MIME typ „text/html“, tak stejně pořád platí tato dle tebe „komplikovaná“ pravidla. Odstavec nebo nadpis do jiného odstavce nenacpeš a tabulky stejně vždy [tbody] obsahují. Můžeš se na to spoléhat. Nemusíš. Můžeš psát volitelné značky. Nemusíš. Pokud se ti vynechávání zbytečných značek nelíbí, piš si je. Máš větší volnost a máš právo ji využít, nikoliv povinnost. To ti připadá hrozné? Proč tedy čím dál více lidí přechází na HTML?
Borek
Detaily stranou; když se podíváš na zdrojový kód této stránky, připadá ti to v pořádku?
Naprosto. A když už se mi tady něco nelíbí, tak to budou asi jiné věci, než které se nelíbí tobě :-).
2 Chamurappi: Prosím nepřekrucovat, že možnost volby je hrozná říkáš ty, ne já. Jen jsem si položil otázku, k čemu je vlastně problematika probíraná v článku dobrá. Kdybych děti na škole učil HTML, tak jim prostě řeknu, ať všechny tagy uzavírají a používají elementy tak, jak jsou myšleny. Lukáš by jim vysvětlil, že si mohou zapamatovat X elementů, které není nutno uzavírat, a Y elementů, které dokonce není nutno psát vůbec.
První přístup vysvětlím za pár sekund a nebude dělat problémy, zatímco o druhém budu dlouho povídat (nebo psát článek).
Ačkoliv tedy souhlasím, že je tento článek „skvěle napsaný“, osobně bych podobný přístup nikomu nedoporučil.
Borek:
Je diskutabilní, jak brzo s tíhmle úplného začátečníka seznámit, ale docela určitě tohle každý jenom trošičku zkušenější webdesigner pochopí (a je už na něm, jestli to využije). Vlastně na tom není nic k nepochopení, celé mi to přijde nanejvýš logické a pochybuji, že jsem někoho vyloženě překvapil s tím, že když neuzavřu li, že to prohlížeč stejně vykreslí správně.
Sorry, ale jsi blázen… Psát tunu textu o něcem, co je samozřejmé… Rozhodně tě nechci urazit, ale jsi to trochu přehnal…
BTW: Podle HTML 4.01 a nižších je přímo povoleno křížit tagy, takže stačilo napsat TAGY se mohou KŘÍŽIT a prohlížeč se postará. To že se postará i u XHTML (Ano! Zkuste si code a v něm pre v Mozille) je jasné.
Fakt se omluvám ale tohle asi přesně spadá do kolonky Atd… stačí napsat odstavec a pak jen Atd… resp atd…
No ohledně těch barviček. No to už jsme spolu diskutovali (v rámci komprese webu) že lze prakticky vypustit html head a body. Protože elementy v nich vnořené si přímo vynucují mít jako předka html a body resp. head viz třeba meta, ten nikde jinde být nemůže. (Nepeskuj mě, pokud se pletu)
PS: Diky za pomoc s webem plesu UTB Zlin :-)
MiSHAK
Podle HTML 4.01 a nižších je přímo povoleno křížit tagy, takže stačilo napsat TAGY se mohou KŘÍŽIT a prohlížeč se postará.
Ne, není.
Nikto zatiaľ nespomenul to, že vynechanie nepovinných tagov môže do značnej miery ovplyvniť zložitosť alebo rýchlosť algoritmu pri generovaní HTML skriptom. Napríklad rekurzívne generovanie stromu pomocou zoznamu – tam mi možnosť vynechania ukončovacieho elementu môže ušetriť prácu alebo odľahčiť databáze. Nezanedbateľný je aj podstatne menší prenesený objem dát a teda rýchlosť načítavania stránky. Rozhodne je dobré o možnosti vynechania ukončovacích značiek vedieť.
MiSHAK
Sorry, ale jsi blázen… Psát tunu textu o něcem, co je samozřejmé… Rozhodně tě nechci urazit, ale jsi to trochu přehnal…
Já zase nechci urazit Tebe, ale na aktivní české webdesignerské scéně znám sotva pět, nejvýš deset lidí, kteří by tento článek dokázali napsat s podobným nadhledem a zkušenostmi, jaké má Timy.
Onu tu teorii do detailů a přímo od zdroje zná dokonce i překvapivě málo jinak opravdu dobrých a zkušených webdesignerů. Jsem zcela přesvědčen o tom, že jen s málokým bych si do detailu naživo popovídal o teorii značkovacích jazyků a kaskádových stylů – většina takzvaných expertů na tyto technologie je totiž bez vyhledávače ztracená, když na tu teorii přijde.
Já neříkám, že to je špatně, profík se pozná podle vykonané práce, jen konstatuji.
pa3k
…tam mi možnosť vynechania ukončovacieho elementu môže ušetriť prácu alebo odľahčiť databáze
Právě pro automatizované zpracování je XHTML značně vhodnější než HTML. V případě HTML si musíme uchovávat tabulku blokových, řádkových a prázdných elementů, abychom poznali, do které skupiny patří. Dále implementovat automatické doplňování značek, opět pomocí tabulky výjimek. Naproti tomu XHTML zpracuji i bez znalosti významu jednotlivých značek.
Ono to neznamená, že zpracování validního HTML je pomalejší (možná zanedbatelně), ale algoritmus je rozhodně komplikovanější, než u validního XHTML.
To Dero: CSS Znám nazpamět a (x)html z 95% Praxi v oboru mám delší…
K tomu renderování. Jediná věc, kterou zatím znám je uvedení počtu buněk u tabulky, to dopředu prohlížeči řekne, kolik buněk a vykreslí se trochu rychleji…
To DGX: 1.) Jo právě proto dělám v XHTML většinou, ale ne pro „automaty“ ale pro sebe. Líp se čte a daleko lépe se člověk drží normy… No bezesporu se lépe parsuje (viz. parsing v 3WE ;-)
2.) Našel jsem menší chybku v Texy! ;-)
Toto: XHTML 1.*0
Zdroj: 2×[hvězdička] 0 2×[hvězdička]
BTW: Pane správný, co takhle odsazovat odstavce v komentářích.
To umí každej takže tady s tím tak nemusíš čachrovat co třeba sem dát nějaký html na okpčení html obrázků druhů písma kdybys sem dal navíc nějaký html na ukázku něco co budou v každým případě potřebovat na webu něco s textama atd ale jestly se toho chcete naučit najděte si nějakou dobrou stránku na který se toho naučíte mnohem víc třeba např:
MiSHAK
CSS Znám nazpamět a (x)html z 95% Praxi v oboru mám delší…
V tom případě ten nesmyslný výrok o povoleném křížení tagů v HTML patří nejspíše do těch pěti procent ;-).
Pane správný, co takhle odsazovat odstavce v komentářích.
Bylo-li to na mě, tak odsazení je zrušené, páč se mi to v komentářích nelíbilo. Toť vše.
Adéla
Tenhle web ale není „učebnice HTML“. Ale jakpsatweb.cz také doporučuji, když už jsme u toho :-).
MiSHAK
CSS Znám nazpamět a (x)html z 95% Praxi v oboru mám delší…
Tak, padla kosa na kámen, já tvrdím, že to není pravda.
Pokud si za tímto výrokem stojíš, připravím Ti osobně test čistě z teorie (X)HTML a CSS – 50 otázek. Pokud jej uděláš alespoň na 90% (45 správných odpovědí), omluvím se Ti a uznám, že patříš mezi těch pár vyvolených odborníků.
Souhlasíš? Já si s tím tu práci dám a dokážu Ti, že se jen namyšleně chvástáš.
gdx: Dík za reakciu. Keď som nedávno robil generovanie zoznamu s neznámym počtom úrovní z db tabuľky (id, meno, id_predka) tak mi to vynechanie uzatváracieho úplne bodlo. Mal som totiž menší problém s tvorbou algoritmu, no vďaka tomu som úplne náhodou prišiel na to, že vynechanie je úplne korektné a validné :-}
Takže: Borek považuje ta pravidla za příliš komplikovaná pro začátečníky, MiSHAK předvádějíce vlastní neznalost za samozřejmá a dle začátečnice Adély to umí každý. Zajímavé.
Reaguji na dgx a pa3ka:
Zdá se mi, že každý hovoříte o něčem jiném. Dgx vnímá XHTML jako ideální vstupní formát pro strojové zpracování, zatímco pa3k vidí v HTML ideální generovaný výstup.
Reaguji na MiSHAKa:
daleko lépe se člověk drží normy
Naopak. Při MIME typu „text/html“, který soudě podle předcházejícího příspěvku užíváš, se od normy odkláníš.
Reaguji na dgx:
Naproti tomu XHTML zpracuji i bez znalosti významu jednotlivých značek.
Neplatí obecně. Řádkové elementy mohou potutelně obsahovat část slova a pokud je při zpracování nerozlišíš od blokových, ztratíš informaci o možné hranici mezi slovy. Uznávám, že jde o detail.
Ono to neznamená, že zpracování validního HTML je pomalejší (možná zanedbatelně), ale algoritmus je rozhodně komplikovanější, než u validního XHTML.
Neřekl bych. Nesmíme porovnávat jablka s hruškami. Vhodně navržený HTML kód nemusí počítat s automatickým domýšlením značek a naopak nevhodně navržený XHTML kód může obsahovat interní podsadu DTD s vlastními entitami, parametrickými entitami atd. – obecný XHTML parser to vše musí podporovat. Stejně tak obecný HTML parser musí podporovat domýšlení volitelných značek. V obou případech může jít o validní dokumenty. Pokud se donutíme nepoužívat ty náročnější konstrukce, budou oba algoritmy na zpracování jednoduché přibližně stejně. Tudíž proti sobě nestojí HTML a XHTML, ale silná sebekázeň a určitý specifický druh lenosti. A jelikož webovou stránku nepotřebuji rozebírat téměř nikdy, sebekázeň prohrává.
Timy, pěkný článek, opravdu pěkný. Myslím, že ti, co ho kritizují (záporně) mu ani kapku nerozumí a je to pro ně pouze nějaký „text“.
MiSHAK
az na to ze v rámci zpětné kompatibility je možno XHTML 1.0 posílat jako text/html…
Hmm, proč tedy tu směrnici kompatibility nedodržuješ?
Čvachta
Děkuji :-).
2 Čvachta:
Myslím, že ti, co ho kritizují (záporně) mu ani kapku nerozumí a je to pro ně pouze nějaký „text“.
V tom případě si zase já myslím, že jsi záporné komentáře vůbec nečetl.
Abych to shrnul, článek je technicky bezvadný – pro začátečníky pěkně shrnuje problematiku a právě oni jsou patrně cílovou skupinou, protože každý trochu zkušenější webdesigner samozřejmě ví, jak se to v HTML s domýšlením značek má.
Problémem tohoto článku je jeho použitelnost. Jsem-li začátečník a pustím-li se do čtení, vyzní mi tak, že bych se měl spoléhat na domýšlení značek, že je to ta správná cesta – koneckonců, sám autor domýšlení značek v kódu tohoto webu používá. Vím, že článek je čistě popisný a nic nedoporučuje, nicméně pro začátečníky (cílovou skupinu) nejsou uvedeny výhody a nevýhody tohoto přístupu ani jeho alternativy. Pro začátečníka tedy článek vyzní normativně, nikoliv deskriptivně. To je to jediné, co se mi na článku nelíbí.
Výborný a velmi užitečný článek. Už nejednou jsem se divil nad tím, proč mi prohlížeč špatně vykresluje odstavec vložený v odstavci :-).
Jen bych měl ještě jednu otázku: Nezpomalí se rychlost vykreslování stránky, když si prohlížeč musí domýšlet různé tagy? Není to něco podobného, jako když u tagu IMG neudáte rozměry?
2 ObiSkyWalker: Neuvedení rozměrů u IMG způsobí horší vykreslování, protože prohlížeč neví dopředu, kolik místa má pro obrázek alokovat. Výsledkem bude „poskakující“ stránka, která bude jinak vypadat po 1 sekundě načítání, dvou sekundách načítání atd.
Naproti tomu je neuvedení HTML tagů věc, která zatěžuje pouze procesor, a to zcela minimálně. Odpověď tedy zní: vykreslování stránky se nezpomalí (znatelně).
Borek: Jsem-li začátečník a pustím-li se do čtení, vyzní mi tak, že bych se měl spoléhat na domýšlení značek, že je to ta správná cesta…
Vždyť je to správná cesta. Plně v souladu s HTML 4.01.
ObiSkyWalker: Nezpomalí se rychlost vykreslování stránky, když si prohlížeč musí domýšlet různé tagy?
Tady je vidět, že pojem „domýšlení značek“ je trošku zavádějící. Ono se ve skutečnosti nic „nedomýšlí“ – tedy není třeba žádné myšlení. Nemůže nastat situace, kdy by se prohlížeč rozhodoval – naopak! Vše je se strojovou přesností dáno, o tom koneckonců je celý článek je.
Borek
v článku měly být zmíněny výhody, nevýhody a alternativy.
Výhody a nevýhody jsou čistě subjektivní (někdo má rád všechny značky ukončené, někdo nerad píše zbytečný kód) a alternativa? Promiň, ale tenhle článek je právě ta alternativa.
MiSHAK
Kde ji nedodržuji?
C7 minimálně.
Ok dík! Upravím to až v nové verzi stejně. Ale to je ještě moc práce…
Doufám, že si to nebereš zas až tak moc osobně.
BTW: O těch jménech(name resp. xml:name) jsme (spolu) mluvili (je to už dávno)…
Borek
Dokument napsaný podle pravidel HTML je velmi snadné převést do XHTML a zpět, jde o ekvivalenty. Pak se veškeré rozdíly ztrácejí.
Parsování XHTML je jednodušší, ale jen zdánlivě :-( Chamurappi správně připomněl, že parser XHTML musí umět parsovat i DTD, což je zápis používající téměř opačná pravidla než má XHTML, respektive nemá s ním nic společného s výjimkou ostrých závorek. Setkáváme se s tím minimálně v případě DOCTYPE. Otázka zní: zvládne tohle (alespoň ignorovat) váš parser?
Jo to je dobre… pouvazuju a pridam to do 3WE no kod mi nenabobtná o 100kB ale jen o jeden Copy():-) Podle me je jeste horsi parsing XHTML 1.1 s jejich .mod soubory architekturou… Jsem si to zkusil a vím o čem mluvím. Můj parser zvládá soko vse az na MATH 2.0 a XHTML 1.1 a vyžší…
Chtel bych se zeptat na neco ke clanku. Kdyz pomoci kaskadoveho stylu predefinuji nadpis aby nebyl blokovym elementem a potom ho pouziji v odstavci, tak se pred zacatek nadpisu vlozi konec odstavce nebo nevlozi?
Co takhle to zkusiti?
Expert na slovo vzatý ;-) říká ANO, protože CSS má být odděleno od dat resp. HTML, takže na parsování by vliv mít nemělo.
Ale rád se poučím, pokud se pletu :-)
Tipuji, že IEčko se s tím popere a zobrazí v odstavci a ostatní (rodina Mozill a Opera a Linx) to nejspíše podle definic hodí pod odstavec.
Na CSS zapomeňte, to je jiný standard a nemá se zpracováním HTML / XHTML nic společného.
Pokud se vloží blokový element do odstavce, bude dokument nevalidní. XML parser vyhodí chybu, co má v takovém případě udělat HTML parser specifikace neříká, takže záleží na tvůrcích prohlížeče.
dgx
Pokud se vloží blokový element do odstavce, bude dokument nevalidní. XML parser vyhodí chybu, co má v takovém případě udělat HTML parser specifikace neříká, takže záleží na tvůrcích prohlížeče.
XML přece blokové a řádkové elementy nerozlišuje, tudíž tuhle poznámku nechápu. Dokument bude nevalidní, to ano, ale jinak se IMHO nic nestane a prohlížeč stránku normálně vykreslí. XML musí být well-formed (což bude) a na validitě přece nijak nezáleží.
Lozya
CSS s tímto „domýšlením“ nemá nic společného. Neplatí, že když přestyluješ nadpis na řádkový element, že ho potom můžeš dostat do odstavce. Stále se uzavírací značka odstavce domyslí ve chvíli, kdy prohlížeč narazí na nadpis. Jediný způsob, jak dostat v HTML nadpis do odstavce alespoň vizuálně je přestylovat jak nadpis tak odstavec na řádkové elementy. V tuto chvíli se bude nadpis tvářit, jako že je v odstavci, i když tam fakticky (v kódu) nebude (budou to prostě dva řádkové elementy vedle sebe). Pokud chceš nadpis na konci odstavce, stačí dát řádkový pouze ten odstavec a nadpis, pokud ho chceš uvnitř odstavce, musí být řádkový jak nadpis, tak oba odstavce okolo.
MiSHAK
Možná zapoměl DGX dopsat H mezi X a ML → XHTML, ale to je jen moje teze.
To je prakticky jedno.
Šlo o vykreslení odstavce, před nebo za… Odstavec s textem tám není.
Tady jsem chtěl pouze demonstrovat to, že XML parser nevyhodí žádnou chybu na nadpis v odstavci a že si žádnou ukončovací značku nedomyslí, tudíž styly z odstavce se aplikují i na nadpis. V HTML by nadpis červený nebyl. Doufám, že jsem Davida nějak špatně nepochopil… :-)
Asi jsem vůl, ale jak se cituje komentář?
Aby nevznikla mylka, ja nechci vkladat nadpis do odstavce. Proc taky? Jen me zajimalo co udela se zpracovanim html stranky prestylovani pomoci css. Ze to dopadne tak jak zde bylo napsano jsem si myslel, ale jisty jsem si nebyl.
„A jak to nakonec uvidí prohlížeč?“
Nejak mi porad unika odpoved na zakladni otazku, co to znamena, ze prohlizec html kod VIDI tak ci onak. Jak se to projevuje prakticky? Leo
Leo
Jak se to projevuje prakticky?
Prakticky se to projeví tak, že se to prohlížeč vykreslí správně ;-). Představuji si to tak, že při samotném vykreslování si ještě prohlížeč pro sebe doupravuje části kódu jako třeba právě ta ukončovací značky li. Kdyby si ji „nedomýšlel“ a já ji sám od sebe neuzavíral, byla by každá odrážka vnořená do předchozí odrážky. Něco podobného se dá nasimulovat v XHTML.
Má troška do mlýna: Článek je velice užitečný pro neznalé a zcela k ničemu pro ty, kteří se v tom vyznají, tzn. jediné co můžu zhodnotit je forma, kterou vše bylo podáno a hodnotím jí jako excelentní.
Teď k tomu vašemu problému, představte si, že máto za úkol naprogramovat nějaký parser, který má přeměnit značky+text na formatovany text.
Parser musí být co nejspolehlivější a nejuniverzálnější, takže když zavedeme řeba < začátek instrukcí pro formátovaní a > konec instrukcí pro formátování a všechno co není mezi < > se zpracovava zase jinak.
Osobně si parser přestavuji jako širokou strukturu plnou podmínek a už jsem nějaké ty zdrojové kódy parserů viděl a něco málo jsem také sám splodil (ale primitivního, nic jako html, to je logické).
Nyní k DTDčku, nemám ho ještě nastudováno detailně, ale je to vlastně něco jako zákon, určité pravidlo, které nám určuje posloupnost příkazů, známe tagy a dalši syntaktická pravidla.
Parses NIKDY nesmí skončit v nějaké nekonečné smyčce a proto jednodušše podle určité struktury projede celý soubor a postupně si sem tam něco doplní, ubere, nebo změní, toto se opakuje tak dlouho, dokud už není vůbec co parsovat. Celé to má určitý počet bodů, např. že každá stránka se projede 1000× a tím se zpracuje 1000 jednotlivých posloupností, ale těch druhů je více a celé je to velice komplikované na vysvětlování, nehodlám tu psát romány, souhlasím s názorem, že tagy se mohou křížit, už jen z toho důvodu že parser si s tím umí poradit. (přeměnuje značky na něco jiného, projížďí od jedné značky, ke druhé a zjišťuje podle struktury zda byla první značka uzavřena, či nikoli.
Opravdu je to velmi složité a nakonec bych musel napsat obrovský seriál jen kvůli tomu, abych lehce nastínic funkčnosti parseru. =) Jednodušše ať provedeme sebevětší „prasárnu“ kvalitní parser si vždy poradí, to jen MS Internet Explorer lze dostat do nekonečné smyčky a seknout tím systém, to víte, Microsoft šije jehlou rozžhavenou do červena.
Někomu se celá tématika zdála složitá na vysvětlování pro začátečníky. Co na tom vysvětlovat? To, že něco se nemusí psát a přece to funguje, zjistí každý velice brzo.
Obtížnost zpracování: z mých pokusů mi vyplynulo, že vynechání TBODY vadí víc než vynechání /LI. (Oboje nevadí vůbec.) Koukal jsem xmp-bookmarkletem na svojí pokusnou stránku v IE a v O, /LI tam nebylo ani jednou, TBODY bylo a opět chybělo /TBODY. Prostě /LI ani za domyšlení nestojí!!
Někdo tu chtěl alternativu. Jak můžu chtít alternativu k něčemu, co buď můžu nebo nemusím dělat???
Komentáře jsou uzavřeny