Klávesové zkratky na tomto webu - rozšířené Na obsah stránky

David se vrhl na Goliáše XHTML

09.08 - 3. února 2008 | Webdesign

DGX se rozhodl vydat článek s titulkem Konečně pravda o XHTML a HTML a moudře zakázal komentáře, protože toto je stále téma, které dokáže pěkně blafnout. Díky tomu můžu napsat svůj komentář u sebe.

  1. Dovolil bych si nesouhlasit s následujícím tím, úryvkem, z části Prasárny.

    XHTML kód zase třeba používáním řetězců abc, AbC, aBC pro různé třídy.

    Hodnoty atributů class a id jsou stejně case-sensitive jak v HTML, tak v XHTML. Pokud se tak nechoval např. Netscape 6-, byla to chyba jeho interpreteru CSS.

  2. Můj názor na DTD v XHTML je již nějakou dobu celkem jasný – přináší jen problémy, stěžuje rozšiřitelnost. Užívejme raději schéma a jmenné prostory. Jediný důvod k použití DTD v XHTML je, bohužel, přepínání prohlížeče do standard modu.
  3. Dle mého názoru je velkou výhodou XHTML v čisté podobě to, že je lépe čitelné pro lidského čtenáře, protože se může lépe orientovat (vizuálně), kde daný element končí a kde začíná.

Největším problémem bezesporu je XML samotné. Jeho striktnost a jednoznačnost vyvolává v kreativní části lidstva ranní nevolnost. Jak jinak si vysvětlit, že ani relativně velké firmy nejsou schopné dodávat dobře sestavené dokumenty?

Tagy: XHTML

Komentáře RSS

  1.  

    jirka

    11.05 - 3. února 2008 | #

    Ale i v HTML musí být uzavřené značky. To záleží pouze na lidech, jak píší a co jim dovolí parser

  2.  

    Aleš Roubíček

    11.41 - 3. února 2008 | #

    [1] jirka kdepak, některé nemusí. Virtuálně uzavřené být musí a je dáno, kde. Ale psát je nemusíme. Tudíž vizuálně chybí.

    Naopak si myslím, že by na tom jak lidé píší mělo záležet minimálně. Vždy by tu měl být nástroj, který ověří správné sestavení dokumentu a popř. i jeho validitu před jeho publikováním.

    Tady na blogu se to třeba stará texy. V práci to hlídá Visual Studio a framework.

  3.  

    jirka

    13.02 - 3. února 2008 | #

    [2] rarouš to nejspíš bude tím, jak jsem se to naučil. Tagy jsem uzavíral a atributy dával do uvozovek už před 10 lety, takže tady žádnou výhodu nevidím.

    Některé věci, které řeší David Grudl, mě překvapily. Vůbec by mě nenapadlo, že by to mohl být problém. Budu se muset nad sebou zamyslet :-)

  4.  

    jirka

    13.06 - 3. února 2008 | #

    [2] rarouš by tu být měl, lidi ho nejspíš vůbec nepoužívají. Nebo to funguje takto? : deklaruji xhtml dtd, hodím dokument validátoru, vyhodí to chyby, tož změním dtd na html?

    (berte to s úsměvem, já si myslím, že všichni lidé jsou dobří)

  5.  

    jirka

    13.08 - 3. února 2008 | #

    sakra, vypadlo slovo nástroj na začátku předchozího příspěvku

  6.  

    Tomik

    13.09 - 3. února 2008 | #

    [2] rarouš To myslím zase hodně záleží na okolnostech a subjektivním názoru.

    Mě osobně nepřijde zase takový rozdíl mezi

    <ul>
      <li>1 .položka seznamu</li>
      <li>2 .položka seznamu</li>
      <li>3 .položka seznamu</li>
    </ul>

    a

    <ul>
      <li>1 .položka seznamu
      <li>2 .položka seznamu
      <li>3 .položka seznamu
    </ul>

    Faktem ale zůstavá, že pokud člověk chce, HTML mu dovolí ten zápis udělat nečitelným, ale to v xHTML určitě je taky (jen třeba jinde).

  7.  

    Krata

    13.23 - 3. února 2008 | #

    to Tomik: No ale když máš v té položce třeba nějaký odkaz či php kod nebo něco cp prostě zabere delší místo stavá se to nepřehledným. a to nejenom u seznamů.

  8.  

    Vilém Málek

    14.29 - 3. února 2008 | #

    Problém (ne)uzavírání elementů leží trochu jinde, než se obvykle prezentuje. Z „lidského“ hlediska je snadné říci, že odstavec (p) nesmí obsahovat jiný odstavec a tudíž před začátek toho dalšího se má vložit konec předchozího. Ale kam před začátek? Za poslední tisknutelný znak předchozího odstavce? Před první (tisknutelný či jiný) znak následujícího odstavce? A mají se v potaz brát zalomení řádků? Tahle zdánlivá maličkost není nikde řešena, takže si ji každý prohlížeč musí řešit (a řeší) po svém, což ve výsledku vede k tomu, že web v jednom prohlížeči funguje podle představ webdesignéra a v druhém nefunguje vůbec. Uzavřením elementu problému předejdu a nic mě to nestojí ;–)

    (Pro ilustraci podobných problémů viz Sub-Pixel Problems in CSS. Podobné záležitosti vedli, mimo jiné, Hixieho ke vzniku HTML 5.)

    Často se také tvrdí, že z hlediska parseru je jedno, jestli je element uzavřený či ne. Jenže ono to tak jedno není. Pokud totiž všechny elementy musí být uzavřeny, stačí mi jeden algoritmický mechanismus pro parsování všech elementů. Pokud však některé elementy uzavřeny být nemusí, musím přidat pro každý takový element další algoritmický mechanismus, který bude zjišťovat, kde má element uzavřít. Parser se komplikuje, vznikají nejednoznačnosti, odlišnosti, chyby, náročnost parseru roste…

  9.  

    Timy

    16.08 - 3. února 2008 | #

    Mohl bych poprosit o nějaký zdroj co se týče toho prvního bodu ohledně case-sensitivity class a id? Nemůžu to teď nějak najít, našel jsem pouze zmíňku o atributu name, kde je – v tom červeném rámečku – zakázáno používat identifikikátory líšící se pouze velikostí písmen. Víc se mi najít nepodařilo :-).

  10.  

    emilk

    16.49 - 3. února 2008 | #

    [6] Tomik Treba zrovna u tabulek je zavirani td pro me osobne naprosto zbytecnej overhead

    uz jsem asi tisickrat ladil chybu, kdy sem si kurzor omylem postavil mezi </td> a <td> a ne o kus dal a pak jsem na strance hledal svuj chybejici content.

    vynechavani koncu td a li podle me zprehlednuje citelnost kodu pro lidi pri upravach.

    [8] Vilém Málek Jednoduchost parseru je takova akademicka diskuze. S vasim argumentem mi nejde dohromady to, ze vetsina prohlizecu v telefonech ma parser html a ne xml. Ale uprimne: nevim, proc je to tak.

  11.  

    emilk

    17.02 - 3. února 2008 | #

    [8] Vilém Málek sub-pixel> to mi prijde jako umelej problem, v css w3c doporuceni u floatu je napsany, ze kazdej float element MUSI mit explicit width.

  12.  

    Aleš Roubíček

    17.21 - 3. února 2008 | #

    [9] Timy Myslím, že je to napsáno přímo tady: Sekce 7.5.2 doporučení HTML 4.01. To [CS] za názvem atributu znamená case-sensitive.

    Ano spousta věcí je čistě subjektivních, tudíž nepatří do akademické diskuse ;)

  13.  

    Aleš Roubíček

    17.24 - 3. února 2008 | #

    [10] emilk Proč je v telefonech HTML parser? Protože většina stránek by se nedala XML parserem přežvejakt. On by to vlastně asi nedal ani HTML parser (podle specifikace).

  14.  

    Plaváček

    17.51 - 3. února 2008 | #

    [11] emilk To platilo ve verzi CSS 2.0. Verze 2.1 už pro plovoucí prvky doporučuje automatický výpočet (Shrink-To-Fit), podobně jako u tabulek. Specifikace CSS ale přesný způsob nedefinuje a tak si to každý prohlížeč řeší po svém. Čili jde o praktický, nikoliv umělý problém.

  15.  

    David Grudl

    20.35 - 3. února 2008 | #

    ad bod 1: http://www.w3.org/…syndata.html#q4

    All CSS style sheets are case-insensitive, except for parts that are not under the control of CSS. For example, the case-sensitivity of values of the HTML attributes „id“ and „class“, of font names, and of URIs lies outside the scope of this specification. Note in particular that element names are case-insensitive in HTML, but case-sensitive in XML.

    ad bod 2: zcela souhlasím, ale protože v prvním článku jsem se chtěl vyvarovat subjektivních závěrů, nechávám si to do chystaného pokračování

    ad bod 3: to je dle mého jen další mýtus, založený na špetce demagogie (že striktnější formát má vliv na čitelnost). Srovnejme příklad zapsaný v HTML, kde jsem (oproti doporučení W3C pro HTML) vynechal uvozovky kolem atributů a odstranil nepovinné koncové značky a tentýž příklad zapsaný podle všech doporučení XHTML:

    Co se čte lépe? Skutečně má syntaktický rozdíl XHTML vs. HTML vliv na čitelnost?

  16.  

    David Grudl

    21.53 - 3. února 2008 | #

    [8] Vilém Málek

    Ale kam před začátek? Za poslední tisknutelný znak předchozího odstavce? Před první (tisknutelný či jiný) znak následujícího odstavce?

    To je dobrý postřeh, nicméně jde o tzv. minimization rules SGML a přepokládám, že specifikace určuje, kam přesně značku umístit. Ale rád se nechám poučit, ovšem zajímají mě jen fakta. Takže Viléme, skutečně sis koupil a důkladně pročetl 155 stránkovou ISO 8879:1986 a tato informace tam chybí, nebo máš jen takový dojem? ;-)

    Každopádně jsem rád, že už se tu diskutuje jen o problému mezery, a nikoliv o nejednoznačnosti celého HTML dokumentu. (to není sarkasmus, fakt jsem rád)

  17.  

    Vilém Málek

    23.40 - 3. února 2008 | #

    [16] dgx Samozřejmě jsem si ISO normu nekoupil, nejsem Rockefeller, i když jsem některé části četl. Ty nejednoznačnosti tam ovšem jsou, jak je konec konců vidět i na příkladu, který jsem odkazoval výše. Hickson kdysi v nějakém článku nebo rozhovoru (bohužel si už nevzpomínám, kde přesně) přímo tyto problémy jmenoval, když mluvil o praktické zástavě vývoje CSS3 a založení WHATWG ;–)

  18.  

    Aleš Roubíček

    07.21 - 4. února 2008 | #

    [15] dgx proč na podporu tohoto mýtu voláš specifikaci CSS, bavíme se o HTML. CSS říká že case-sensitivitu nechává na cílovém strukturálním jazyku. Specifikaci HTML 4, na kterou se v úvodu článku odkazuješ, jasně říká v bodě 7.5.2, že hodnota atributů id a class je case-sensitive.

    Co se týče čitelnosti, není to demagogie, napoak je demagogie vyvracet to jednoduchou učesanou ukázkou. Vem si projekt na kterém dělá několik lidí, který má složitý layout, spoustu elementů. Pak teprve můžeme mluvit o snažší orientaci v dokumentu. :)

  19.  

    Brbla

    08.59 - 4. února 2008 | #

    [15] dgx Davide, XHTML neposkytuje zárukou snadné čitelnosti kódu pro lidi. Mohu psát jako XHTML validní čuník, což jsi krásně demonstroval. Otázkou je, co jsi tím chtěl říci. Tebou demonstrovaný příklad mi – při vší úctě – připomíná spíš výstup opilého redakčního systému, než výstup kodéra. Nicméně – ano, XHTML umožňuje (stejně jako HTML) psát nepřehledně a přitom validně ;-) Čuníkům zdar…

  20.  

    pixy

    12.15 - 4. února 2008 | #

    Že by Davidovi vázly příjmy z AdSense a rozhodl se přitlačit osvědčeným kontroverzním stylem? :-6

    Mám velmi intenzivní pocit, že prakticky se žádným ze zmiňovaných mýtů jsem se za celou svou praxi nikdy nesetkal. Fakt jsem ještě nepotkal nikoho, kdo by tvrdil, že v HTML se můžou křížit značky, že HTML parser má za povinnost si to či ono vymýšlet nebo že specifikace HTML je v něčem horší… Všechny debaty na podobná témata, která jsem kdy postřehl, se vedly jen o tom, že takové věci se v HTML dějí (a ne že by to bylo korektní) a že parsery musí leccos spolknout, zpracovat kdejakou chybu a sem tam si něco přimyslet – ale ne proto, že by to nařizovala nějaká specifikace (on to vážně někdo tvrdí?), ale proto, aby byl takový parser konkurenceschopný.

    A fakt, že mnohé RSS čtečky neustály tu chvilku, která by bývala stačila pro umravnění autorů, opustily drakonický parsing XML a začaly tolerovat chyby (navzdory noramtivní povinnosti je netolerovat), je podle mě obrovská chyba. To se prostě stát nemělo (leč odestát už se to nedá)…

  21.  

    David Grudl

    13.35 - 4. února 2008 | #

    [18] rarouš jako příklad prasárny jsem uvedl rozlišování tříd podle velikosti písmen. Žádnou hlubší logiku v tom nehledej. Je to jen příklad. Jestli tě napadne lepší, rád ho vyměním.

    ad snažší orientace v dokumentu: štábní kultura – to je to, o čem mluvíš. Netahejme do toho značnovací jazyky.

    [19] Brbla Co jsem tím chtěl říct? Že XHTML neposkytuje zárukou snadné čitelnosti kódu ;)

    [20] pixy no osvědčeným kontroverzním stylem… ehm… Co je na článku napsaném stylem „otázka & odpověd & odkaz na autoritu W3C“ kontroverzního?

    Pixy, problém je v tom, že tohle téma stále řada lidí chápe jako osobní útok. Chápeš ho tak i ty, bohužel, proto poznámky o AdSense a kontroverzi. Odpusť si to, nechci přesvědčovat zatvrzelce co věří svým mýtům, dávno vím, že je to marné. Ohýbám mladé proutky.

  22.  

    pixy

    14.43 - 4. února 2008 | #

    Ach bože, Davide, odkdy nechápeš ironii a uniká ti smysl smajlíků?

    A krom toho, já vůbec nejsem žádný zatvrzelec a XHTML jsem bral především jako osvětový nástroj. Nástroj, který mmch svou historickou úlohu splnil a dnes ho považuju za polomrtvý. Já fakt nemám jediný důvod se hádat, bránit nebo se nedejbože zastávat nějakého XHTML. Jenom a) se divím, že někde skutečně kolují mýty, které se snažíš vyvracet a které já jsem za celá dlouhá léta nikdy nikdy neslyšel; b) lituju, že to s XHTML/XML, drakonickým parsováním a striktní syntaxí nevyšlo, protože podle mě to byla dobrá cesta. To je celé.

  23.  

    Aleš Roubíček

    16.40 - 4. února 2008 | #

    [21] dgx ale to míchání velkých písmenek v class nebo id je také o štábní kultuře, míchat to jde v obou nářečích stejně. :)

    V podstatě všechno se to točí mezi profíkama a prasatama, o ničem jiném to není. Pokud má někdo za zlatou krávu pár nenáhodně promíchaných znaků, dobře mu tak. Na světe jsou mnohem přízemnější důvody ke svatým válkám.

  24.  

    David Grudl

    17.02 - 4. února 2008 | #

    [23] rarouš je možné, že jsem zvolil špatný příklad, ale o ten přeci nejde – měl demonstrovat, že citlivost jazyka na velká/malá písmenka nesouvisí s tím, jestli kód budu psát čitelně nebo nečitelně. Že jde jen o věc štábní kultury. A zcela souhlasím s druhým odstavcem.

  25.  

    Aleš Roubíček

    17.24 - 4. února 2008 | #

    [24] dgx Ano to jsem nakonec pochopil. :) Ale jak vidno, někteří o té citlivosti na velikost písmen v HTML netušili, čili mám dobrý pocit z toho že teď to možná někdo bude vědět :D

  26.  

    David Grudl

    17.32 - 4. února 2008 | #

    [25] rarouš jo, třeba já :-) Už vím, kde byl zakopaný pes. Citlivost totiž přišla s verzí HTML 4, viz příklady. Ta věta „Note in particular that element names are case-insensitive in HTML, but case-sensitive in XML.“ pochází z roku 1996, kdežto HTML 4 z roku 1999.

  27.  

    Chamurappi

    19.31 - 4. února 2008 | #

    [25] rarouš V případě atributů typu ID jde o chybu ve W3C doporučení HTML 4.01. Nejsou case sensitive, protože HTML má v SGML deklaraci NAMECASE GENERAL YES. Parser má po načtení atributů „id“ ztratit informaci o velikosti písmen, takže mu „[CS]“ ve specifikaci může být putna. Podobný úlet je třeba i zákaz entit v „id“ atributech. Stane se.

    [26] dgx Tvé příklady ukazují, že prohlížeče dodržují v quirku ISO standard a ve standardním režimu nestandardní W3C doporučení. Verze neřeš, „id“ a „class“ vznikly oficiálně až v HTML 4 (v prosinci 1997, rok a půl po první implementaci).

  28.  

    Aleš Roubíček

    08.05 - 5. února 2008 | #

    [27] Chamurappi Specifikace říká, přesně jak říkáte, že hodnoty atributů jsou obecně na velikost písmen nesensitivní, až na vybrané výjimky. NAMECASE GENERAL YES není uvedeno v kontextu, před ním se ještě ukazuje krásné slůvko NAMING. takže to dále nebudu komentovat. Váš agrument by říkal, že se všechna písmena v dokumentu považují za velká, což jak všichni víme není pravda. Vámi předkládané pravidlo se vztahuje pouze na pojmenování elementů a atributů, né jejic obsahu a hodnot. takže ono [CS] ve specifikaci putna není a je směrodatné.

  29.  

    Chamurappi

    09.37 - 5. února 2008 | #

    [28] rarouš Nemluvil jsem o všech písmenech v dokumentu. NAMING deklaruje pravidla jen pro všechna „jména“, tzn. nejen pro názvy elementů a atributů, ale i pro výčtové hodnoty atributů, názvy entit a ID — vesměs pro všechno, co se musí skládat ze jmenných znaků. U entit je NAMECASE NO, jinde YES.

    Pokud [CS] směrodatné je, nahlašte chybu ve všech SGML/HTML validátorech, protože ty vyhodnocují unikátnost bez ohledu na původní velikost písmen.

Místo pro tvůj názor

Povinné je jméno a komentář, z e-mailu se rozpoznají Gravatary.
Komentář je formátován pomocí Texy! syntaxu.
Například: **tučný text**, *kurzíva*, "text odkazu":adresa.
Internetové adresy jsou převáděny na odkazy.
Na komentáře se můžete odkazovat pomocí [číslo komentáře].

Nový komentář