Buňka v buňce

Buňku ne, tabulku ano. Většinou to však není třeba, podobného výsledku jde dosáhnout třeba slučováním buněk. Například FrontPage tak dělá "rozdělení" buňky.
<table border="1" width="100%">
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>&nbsp;</td>
<td colspan="2">&nbsp;</td>
</tr>
</table>

Což evokuje otázku k zamyšlení:
Může vůbec mít tabulka v tabulce ze sémantického hlediska smysl?

Chamurappi
Ano, vyborna vec, pouzivam do hloubky 5ti tabulek velmi casto.

Řekněme, že se dá ještě pochopit, že máme v tabulce tabulku, ale mít zanořenou v tabulce v tabulce v tabulce v tabulce v tabulce tabulku? To už by musela být sémantická černá magie.

Reaguji na petu:
Jaký má pět zanořených tabulek sémantický význam?

peta
Jestli to nebyla ironie, pak...

Chamurappi
Příklady pro dvě tabulky v sobě lze ještě vymyslet. Například:

------------------------------------------------------------------
|.....................|Prodávám............|Kupuji
#########|###########|############
|proč u nás.....|Je to super..........|Je to fajn
|-----------------|----------------------|----------------------
|co?................|Všechno..............|Co kdo nabídne
|-----------------|----------------------|------------------------
|naše provize.|do 5ks - 10%......|není
|.....................|nad 5ks - 5%......|
|--------------------------------------------------------------

Ty provize by byly v další tabulce.

Reaguji na milu:
Chápu. Ovšem ty provize by šlo řešit i rozdělením dotyčné buňky.

Chamurapi
Pokud se nepletu, tak se buňky dají jen slučovat, nikoliv rozdělovat.
Představa, že budu v každém řádku slučovat kvůli jedné buňce mi přijde dost nepříjemná...

I sémanticky mi to přijde tak nějak lepší. Mám nějakou tabulku. Tá má jasnou strukturu. A nemělo by se na ní odrážet, co v jednotlivých buňkách je. Místo tabulky provizí tam může být třeba obrázek s grafem.

Reaguji na milu:
„Představa, že budu v každém řádku slučovat kvůli jedné buňce mi přijde dost nepříjemná...“
Ano, mně také. Jenže je úplně stejně nepříjemná, kdykoliv chceš nějakou buňku rozdělit (= buňky ve stejném řádku a sloupci sloučit), nemusí jít o vnoření celé další tabulky.

„Mám nějakou tabulku. Tá má jasnou strukturu. A nemělo by se na ní odrážet, co v jednotlivých buňkách je.“
Obdobně má i řádek tabulky jasnou strukturu. U složitějších tabulek i sloupec. Je-li tabulka složitější, ovlivní vyhození či přidání buňky výrazně strukturu celé tabulky. Vím, že je to trochu něco jiného, ale jde jen o míru: co ještě smí strukturu ovlivnit a co již nikoliv. Třeba při vizuální prezentaci bývá také celá tabulka ovlivňována rozměry toho, co je uvnitř.

Půjdeme-li do důsledku, tak ze sémantického hlediska není vyjádření tabulkových dat stromovou strukturou nijak zvlášť skvostné. Řádky jsou upřednostněny před sloupci => struktura sloupce samotného není zřejmá bez hlubšího průchodu celého stromu. Řádky se přidávají a odstraňují mnohem snadněji než sloupce. A to i přesto, že jde vlastně o stejné uskupení buněk, jen jinak natočené. Bohužel jsou stávající značkovací jazyky na stromech příliš závislé, takže element <table> patrně nikdy lepší nebude.

Kdyby HTML 4 definovalo exkluzi, že element <table> a nadpisy nesmí být uvnitř elementu <table>, nemohly by se tabulkové layouty pyšnit validitou.

Mimochodem, co je pravdy na tom, že prohlížeče v mobilech mají problémy s tabulkami?
Kdybych já programoval prohlížeč a měl omezený výpočetní výkon a velmi omezenou paměť, tak by mi běžné tabulky možná nevadily, ale rozhodně bych se bránil právě těm zanořeným. Propočítávat pět petových zanořených tabulek by bylo složité, na to bych se vykašlal.

Na druhou stranu je pravda, že dnešní prohlížeče pro mobilní zařízení už zdaleka nejsou tak omezované hardwarem, takže by si mohly na troufnout na libovolné zanoření.

Ano, mně také. Jenže je úplně stejně nepříjemná, kdykoliv chceš nějakou buňku rozdělit (= buňky ve stejném řádku a sloupci sloučit), nemusí jít o vnoření celé další tabulky.
Tak jsem to myslel. Viz můj příklad. Celá tabulka by měla třeba 20 řádků. Jen v jedné buňce by byla ona provize, kde potřebuji rozdělit buňky. Kvůli tomu na dalších 19 řádkách něco slučovat se mi fakt nechce. Pak se jednoho dne rozhodnu tam dát jednotnou sazbu a budu mít naprosto zbytečně sloupec navíc, nebo budu muset opravit celou tabulku kvůli jedné buňce.

Obdobně má i řádek tabulky jasnou strukturu. U složitějších tabulek i sloupec. Je-li tabulka složitější, ovlivní vyhození či přidání buňky výrazně strukturu celé tabulky. Vím, že je to trochu něco jiného, ale jde jen o míru: co ještě smí strukturu ovlivnit a co již nikoliv. Třeba při vizuální prezentaci bývá také celá tabulka ovlivňována rozměry toho, co je uvnitř.
Tabulku si představuju jako jakýsi kartéský součin. Najdu si správný sloupec a řádek a v průsečíku je to, co hledám. A může to být text, číslo, obrázek, tabulka, odkaz nebo třeba flashová animace.
Vše co jsem teď vyjmenoval může podávat informaci o tom, jakou si bere firma provizi. A to strčím do příslušné buňky. Nevidím důvod, proč by tabulka měla mít nějaké výsadní postavení a vkládat se jinak.
Vyhození buňky si nedovedu nějak představit. Samozřejmě, když ji smažu ve zdrojáku, tak se mi to celé posune doleva - ale to je jen otázka html a jeho zápisu.

Půjdeme-li do důsledku, tak ze sémantického hlediska není vyjádření tabulkových dat stromovou strukturou nijak zvlášť skvostné. Řádky jsou upřednostněny před sloupci => struktura sloupce samotného není zřejmá bez hlubšího průchodu celého stromu. Řádky se přidávají a odstraňují mnohem snadněji než sloupce. A to i přesto, že jde vlastně o stejné uskupení buněk, jen jinak natočené. Bohužel jsou stávající značkovací jazyky na stromech příliš závislé, takže element <table> patrně nikdy lepší nebude.
Nenapadá mě lepší způsob, jak to zapsat v plaintextu.
Jinak ve většině tabulek má jeden směr opravdu přednost (nenapadá mě nic krom sportu, kde by to tak nebylo). V SQL je také jednodušší přidat řádek, než sloupec.
Uvítal bych nějakou css vlastnost, která by říkala, zda se má tabulka vypisovat horizontálně nebo vertikálně....


Kdybych já programoval prohlížeč a měl omezený výpočetní výkon a velmi omezenou paměť, tak by mi běžné tabulky možná nevadily, ale rozhodně bych se bránil právě těm zanořeným. Propočítávat pět petových zanořených tabulek by bylo složité, na to bych se vykašlal.
Nejsem si tím jist, ale možná bude jednodušší udělat pět do sebe vnořených tabulek, než jedna kde se budou různě slučovat sloupce. Když mám vnořenou tabulku, tak si ji prostě rekurzivně spočítám, jako by to byla ta první, dostanu nějaký rozměry a dále s ní pracuji jako kdyby to byl obrázek, div nebo cokoliv jiného. Naopak v jedné velké, kde se všechno různě slučuje, bych nechtěl počítat, co má mít jakou šířku a výšku, neboť se to bude navzájem různě ovlivňovat.