Weblabor

Köszönöm, érhető volt amit leírtatok!

Fordítsuk meg a kérdést. Valljuk meg, azért hátránya is van, elég csak a böngészők egyedi izlésére gondolni. Vagy egy összetett form leírása, és formázása. Kinek mi a véleménye erről?

zmb

Szerintem egy oldalnál mindig azt a jó használni amivel a legkönyebb dolgozni tehát sok esetben hasznos a táblázat és azt abszolút marhaságnak tartom ,hogy egy oldal ha van benne táblázat akkor már nem is profi.
És a table is lehet valid.

Amikor egyforma kinézetet akartam elérni 4 böngésző esetén abszolút pozícionálás nélkül, hát bizony ott se css, se div nem segített, inkább teljes lett a káosz velük. Táblázattal (persze csak ott, ahol semmi sem segített) minden a helyére került.

Csodálkozom, hogy alig hangzott el olyan válasz, ami a táblázatok valódi hasznát mutatja meg. A szemantikusság jól hangzik, de nem maga a szemantikusság az előny, hanem az ebből következő dolgok. Aki eddig nem fogadta el az oldalkialakítás során a táblázatmentességet, az ezután sem fogja a marketingszöveg hatására - viszont vannak konkrét, kézzelfogható előnyök is.

A dives oldalszerkezettel várhatóan kisebb lesz maga az oldal, nagyobb a CSS (tehát kb. ugyanott vagyunk), ez utóbbi viszont erősen gyorsítótárazható, tehát a további oldalletöltések gyorsabbak tudnak lenni. Elég kevés céggel találkoztam, ahol ez szempont lett volna, ugyanis a szélessávú net terjedésével simán lenyomnak az ember torkán több MB-os Flash animációkat is. Az, hogy csökken a forgalmazott byte-ok száma, főként tőlünk nyugatabbra számít, Mo-on valahogy úgy alakult ki a helyzet, hogy a forgalomért jellemzően nem kell fizetni a szerverhoszting cégek felé, szemben más országokkal, ahol ha túlléped a forgalmad, egy szép kis üzenet fog fogadni az oldalon, hogy akkor most egy pici szünet jön. Pedig ez is fontos szempont lehetne, elég sokan használnak még lassabb kapcsolatot (akár mobilos, akár modemes elérést). Ide kapcsolódik még egy fontos dolog, melyet a Google címlapjával lehet a legjobban szemléltetni. Ha megnézi az ember az oldalt, akkor a HTML kód gusztustalan, viszont két szempontnak felel meg: egyrészt kicsi, másrészt pedig minden elképzelhető böngészőre "optimalizált". Vegyük észre azonban, hogy egy Google címlapnál teljsen mások a szempontok. Ahol talán több milliárdszor is letöltenek egy nap, nem dinamikus tartalmú, és a célcsoportja iszonyatosan széles, teljesen más kívánalmak merülnek fel a fejlesztő felé, szemben egy céges honlap, vagy híroldal esetén, ahol nagyobb dinamikus tartalom van, és a karbantarthatóság is rendkívül fontos lehet. Egy honlap elkészítésénél számos szempont van!

Félig felmerült, illetve fel szokott merülni, hogy a padding-border-margin hármast az egyes böngészők máshogy értelmezik, és hogy gondot okoz a margóprobléma. Ez nem igaz, ha valaki rendesen használja a DOCTYPE jelölést a HTML kód elején, ilyen problémái nem lesznek. A CSS tanulásakor előfordulhat persze pár furcsaság, amivel találkozik az ember, de ez nem a CSS jellemzője, hanem bármely új dologé, amit ha akar, akkor megtanul az ember. Böngészőhibák valóban vannak, de ezek egyrészt csökkenő tendenciát mutatnak (pár éve még illett IE5-re optimalizálni, ma egy átlag honlapot talán senki sem fog), másrészt pedig egy kis gyakorlattal kiismerhetőek.

Térjünk vissza a szemantikusságra, ami magánál az oldal szerkezeténél nem jelent sokat. Egy div elem ugyanis nem szemantikus, nem hordoz semmilyen információt arról, hogy mit tartalmaz. A div egy általános HTML blokkelem, amit sokmindenre lehet használni, egy egyszerű építőkő, nem több. Sokkal fontosabbnak tartom hangsúlyozni, hogy maga a táblázat használata az antiszemantikus, hiszen a táblázat használata a layout kialakítására egy szükséges rossz volt, amiről az évek során elfelejtődött, hogy csak egy félmegoldás. Nincs azonban ma a weben olyan alkalmazás, ami az oldal layoutjánál(!) a szemantikusságot figyelembe venné. Egy dolog van (és ez viszont tényleg fontos szempont): a szemantikus gondolkodás az oldal tartalmi részének kialakításakor, azaz a navigációs elemek listaként definiálása, a fejlécelemek, paragrafusok, form elemek és hasonlók helyes használata, előbbiek a Google és más keresőrobotok, utóbbi a használható felhasználói élmény kialakítása kapcsán. De ezzel eltérnék a tárgytól, ez nem az oldal layoutjának témaköre ugyanis.

Felmerült a 19-es hozzászólásban Gyulus részéről, hogy ha van egy egyszerű táblázatunk, akkor az milyen jól működik, felesleges azt bonyolítani. Ha azt akarom kiírni az oldalra, hogy Hello World!, akkor minden bizonnyal így van, de már ez lépéseknél észreveheti az ember, hogy ez a táblázat nem fog ilyen maradni. A probléma ott kezdődik, amikor el kell kezdenünk a designt ráhúznunk erre a szerkezetre. Ha a bal oldalsávnak kell egy hátteret adnunk, akkor azt könnyedén megtesszük, jobb esetben CSS segítségével. Ha a bal oldalsávban a kitöltés (padding) 10 pixel kell, hogy legyen, akkor sincs gond, CSS-ből, vagy helyi stílusból, adunk neki akkora kitöltést. Ha azonban margót kell állítani, azaz kell egy olyan terület, ahol az oldal háttere látszik, nem pedig a bal oldalsáv háttere, elég bonyolult lesz a helyzetünk. Lehetőség van arra, hogy táblázat szinten állítsuk be a cellák eltartását egymástól, azonban ott fognak problémák adódni, amikor a bal oldalsávnál, a fejlécnél és a jobb oldalsávnál teljesen más értékekkel kellene dolgoznunk. Bevezetünk egy másik táblázatot? Egy egyszerű margó miatt elég rossz ötlet: ami CSS-ből 1 félsor, amiatt egy teljes <table><tr><td></td></tr></table> kerül bevezetésre, kezd nem túl átlátható lenni a kezdeti "egyszerű" kód. Vagy átszervezzük a táblázatot, hozzáadunk még pár cellát, módosítjuk a fejléc colspanját, és megoldjuk? Még rosszabb, ugyanis a bal oldalsáv margójának beállításához csak túráztattuk magunkat: az új cella bevezetése a kódot bonyolította, a colspan növelése pedig nagyon rossz nézőpont: egy totál helyi problémát úgy oldottunk meg, hogy máshol módosítottuk hozzá a kódot.

Vegyük az az esetet, amikor a megrendelő kitalálja, hogy tök jó lenne, ha a design olyan lenne, hogy a fejlécbe még bejön egy menü a jobb felső sarkába. Táblázatos elrendezéssel megint két megoldásunk van: az oldal vázát adó táblázat átszervezése (isszonyú ötlet), vagy egy új táblázat bevezetése, ahol 2x2-es felosztást alkalmazhatunk, és a jobb felső sarokba odavarázsoljuk a menüt. CSS-sel a konkrét felsorolás leírása, és a fejléc jobb felső sarkába pozícionálása lett volna. Ha a layout tovább bonyolódik, vagy eleve bonyolult volt, és a fejlécbe még bele kell tennünk további elemeket, melyek nem feltétlenül passzolnak szélességükben, magasságukban a menühöz, elérkeztünk a káoszhoz. Tudom, mert sokat csináltam anno.

Mi van akkor, ha a megrendelő által hozzott design olyan, hogy a fejléc alatt van egy olyan terület, mely a tartalmi részbe is belenyúlik, meg magába a fejlécbe is, amolyan hirdetőtáblaként? Táblázattal jöhetnek a colspanok, rowspanok, és biztosan nem lesz egyszerű az így létrejövő kód. CSS-sel egyszerűen odatesszük azt a divet, minden nagyobb túrázás nélkül.

Összefoglalva: a táblázatok formázása néha iszonyat körülményes tud lenni, mivel közel sincsenek meg azok a lehetőségek, melyek egy div esetében megvannak. Egy egyszerű kérés is vagy a táblázat teljes átszervezését igényelheti, vagy legalábbis azt, hogy ott módosítsuk a kódban a colspan és egyéb összevonásokat, aminek semmi köze a problémához, csak áttételesen.

Elhangzott, hogy jó dolog lehet, ha az oldalt meg lehet nézni mobiltelefonról, és ebben a CSS elég kellemes partner tud lenni. Aki ezt írja, igaza van, de ez a célcsoport jelenleg olyan kicsi, hogy irreleváns ez a kérdéskör.

A karbantarthatóság kapcsán egy oszlop szélességének átállítása CSS használatakor egy helyen kell, hogy megtörténjen, míg táblázatok használata esetén az oldal sablonját megváltoztatni, első ránézésre szintén egy helyen (remélhetőleg sablonrendszert vagy hasonló megoldást használtunk). Első ránézésre nincsen ezzel gond, hiszen egy-egy változtatás kell. Második ránézésre nagyon sok gond van vele. Ha az oldal designja olyan, hogy jobb oldalon nincsen mindig oldalsáv, akkor a sablonrendszerben vagy trükköztünk, vagy pedig két sablont kell módosítanunk. Ha több lehetőség van, mert eltérő megjelenésűek az oldalak, akkor még jobban elveszhetünk. Szemben az egy helyen átírom az oldal megjelenést megoldással.

Az utólagos átdesignolás problémáját is fel szoktuk vetni akkor, amikor a layout kapcsán a táblázatok ellen érvelünk. Mi van akkor például, ha a megrendelő kitalálja, hogy át kéne tenni az egyik oldalsávot az egyik oldalról a másikra? A helyes válasz, hogy eszerint módosítjuk a sablont, mely a legtöbb esetben elég, s az, hogy a CSS-ből is egy mozdulattal megoldható a kérdés, nem sok embert érdekel. Van azonban egy talán egy kicsit gyakoribb helyzet, amikor egy-egy eltérő megjelenésű oldalt kell legyártanunk, úgy, hogy a fő megjelenés marad. A Nemzeti Sport oldalánál a belső oldalak szponzorációjánál merült fel egy ilyen kérdés: és új és új sablonok legyártása helyett kb. egy napos munkával sikerült egy olyan megoldást kidolgozni, hogy utána 2-3 óra alatt (ami a designtervből a színek, eltartások és hasonlók levadászását jelenti főleg) új megjelenést tudunk a rovatoldalakra húzni, elég sok szempontból. A Miniszterelnöki Hivatal kapcsán szintén hasonló helyzet merült fel, amikor egyes alosztályok (vagy már nem is tudom, hogy mik) megjelenését kellett megváltoztatni. A programozást végző kollegák rendkívül megörültek, amikor kiderült, hogy a HTML-en semmit sem kell ehhez módosítani, csak egy apró helyen, a body classában egyszerűen jelezni, hogy más oldalmegjelenés lesz. Ezek mind azt jelentették, hogy az utólagos karbantarthatóság jelentősen nőtt, napokat spóroltunk meg ezzel: nem kellett több sablont karbantartani, ha bejött egy új, általános doboz, akkor egyszerűen fel kellett vinni, és nem törődni a designnal.

Gyulus említette, hogy a táblázat jól bevált, pontosan tudja az ember, hogy hogyan fog viselkedni. No, én nem tudom. A fentieken kívül is számos, a CSS-sel hasonlatos szívás lehet a táblázattal, például az, hogy hiába állítok be egy oszlopnak fix szélességet, még véletlenül sem úgy fog megjelenni, mert valahol valami szétnyomja. Ez megoldható, de nem kevesebb munkával, mint CSS esetén egy hasonló jellegű problémánál.

Sikerült jól szétflamelni a témát, arra kérnék mindenkit, hogy a gyakorlati szempontokat próbálja meg előtérbe venni. A tapasztalat az mindenképpen az, hogy a CSS hosszútávon az egyedüli megoldás, a táblázatos oldalkialakítást pedig itt az ideje elfelejteni. Pontosabban 3-4 éve volt itt az ideje elfelejteni, úgy kellett előbányásznom megint az érveimet az akkori viták kapcsán. Lehet, hogy 1-2 az érveim között nem általános érvényű, és adott esetben nem releváns, de abban kifejezetten biztos vagyok, hogy rengeteg munkát és idegeskedést spóroltam meg azzal, hogy CSS-t használok ebben a témakörben. Hozzátenném azt is, hogy ez a tudás még pluszba értékes is, pont azért, mert hatékonyabb, könnyebben karbantartható - és nem mellesleg helyes megközelítésű, jövőbiztosabb megoldást eredményez.

Köszöntem a sok hozzászólást, aki ennyiből nem értette meg mi a lényeg, az úgysem fogja!

A téma lezárva!

ui: a témát én nyitottam, ezért jogom van zárni is!:PP

Ezt még egy régebbi témához írtam, de végül nem postoltam el... most:

0) Nem DIV vs TABLE hanem "HTML elemek CSS-sel formázva" vs "grafika altal diktalt tablazatokkal és spacer gifekkel osszetakolt vaz".

1) Úgy használod a HTML-t és a CSS-t amire kitalálták. A programozók szeretnek szép kódot írni. Általában az emberek szeretik a dolgaikat elegánsan elintézni, mindenféle kerülő és ügyeskedő megoldások nélkül. A táblázatok "ügyeskedő" megoldásnak számítanak.

2) Kód karbantartás. Egy rendes forráskódban annak írója is elveszhet és kommentek nélkül pár hét után elég nehéz lesz kitalálnia mit is csinál a programja. Egy kicsit is nagyobb oldalon tipkikus feladat, hogy egyes részei lecserélődnek, átalakulnak és ilyenkor könnyebb dolgod van belenyúlni. Egy nem egyfős cégnél pedig a kollégád munkájában is könnyebb turkálni.

3) Újra felhasználhatóvá válnak bizonyos HTML sablonok. Táblázatok használatával minden menüt újra és újra meg kell írnod. Egy UL-LI-(span) listával a felmerülő design kérdések 99%-át letudod fedni. Ha van egy keretrendszered amihez mindig csak új dizájnokat teszel az új ügyfeleknek akkor értékelni fogod.

4) Méret: A table-tr-td és a hozzáadott spacer.gif-ek mind felesleges bájtok, kilóbájtok, melyek a forrást növelik. Minden lap letöltésnél!
(Egy táblázatokkal készült bonyolultabb oldalon simán 50%-ot lehet faragni CSS-ses megoldással!)
A külső CSS fájlt cachelik a böngészők.
A képek egybevágásával csökkenthető a szervertől lekért fájlok száma.

5) Megoldható a cserélődő menüképek előtöltése.

6) Könnyű nyomtatható, pda, vagy gyengén látó embereknek kontrasztosabb verzió készítése.

Kiegészítések:
a) Egy olyan kód ami táblázatot használ dizájn kialakításhoz, még lehet szabványos!

b) Ha táblázat nélküli oldalkialakításról beszélünk nem a table elemek elhagyását reklámozzuk! A table elem táblázatos adat (olyan amit az excelbe írnál és nem a wordbe) megjelenítésére használandó.

c) Gyakorlatban, mivel a CSS szabványt a böngészők nem teljes egészében és nem tökéletesen implementálják, ezért rákényszerülhetünk 1-2 table dizájn miatti berakására. De nem akarunk oda visszajutni, hogy egymásba ágyazott táblázatok és tartó gifek adják a kód nagyrészét.

d) A tabless kódolás nem azt jelenti, hogy minden table és td elemet átírunk DIV-re! Minden HTML elem formázható CSS-sel. (Természetesen a táblázatok is :)

e) Ha már elhagytuk a táblázatokat és szépen a szerepük szerint jelöltük meg az elemeket a megfelelő HTML tag-ekkel.