Táblázat vs div - miért jobb a div?
hi, Tényleg nem szeretnék akadékoskodni, de valószínűleg sokan vannak itt akik okosabbak mint én. Én táblázattal csináltam eddigi lapjaim és semmi hátrányt nem vettem észre. Tudom, nem erre való. Lassan meg fogom tanulni a divek használatát is keretezésre, de ha egyszer odajön hozzám egy kezdőwebes aki még táblázatokkal lámázik akkor mondani szeretném neki, hogy ne táblázz, divezz...és akkor meg fogja kérdezni tőlem, hogy de miért? az mivel jobb?
Na erre a kérdésre nem tudom a választ, kérlek írjátok le!:) Kösziii
■ Na erre a kérdésre nem tudom a választ, kérlek írjátok le!:) Kösziii
szemantika
érthetőbb példa: "Elmegyek kapát enni tegnap este." szintaktikailag jó, mert van állítmány, (rejtett) alany, tárgy, időhatározó stb stb, de szemantikailag nem helyes a mondat. a div vs table téma kb ugyanez.
a table adatok táblázatos formában történő megjelenítésére lett kitalálva, a div pedig más egyéb elemek blokkba foglalására.
persze vannak más szempontok is, mint pl tisztább kód, mert div-es megoldásokkal általában kisebb, átláthatóbb kódot lehet készíteni, mint 1000 tr td és társai kombinálásával. hogy folytassam: ha kedvezőbb a hasznos tartalom aránya a kódban, az keresőoptimalizálási szempontból is előnyös.
stb stb stb
logout
re
- kisebb mérete lesz a div-es szerkezetű fájloknak.
- ha jól emléxem szabvány szerint div-ben lehet form, táblázatban nem
- a táblázatra nekem nem igazán működött az overflow css tulajdonság
- ha pl. fix szélességű elemekre van szükséged: div-vel könnyebb megoldani, mert nem kell figyelembe venned egy halom keretet, paddingot, margin-t, stb.
Mert ugye ha pl. két oszlopról van szó: a divnél két téglalapot képzelj el, a táblázatnál pedig a cellákat, a tr-t és a table részeit is..
- sőt, a keretekkel is lehet gondod, ha padding-ot használsz (itt ott lehet egy-egy pixelnyi "lyuk")
Táblázatot akkor érdemes használni - és most nagyon meglepő megállapítást teszek - ha pl egy táblázatot szeretnél felvinni az oldaladra. :))
(mindenféle cellaegyesítéseket is figyelembevéve) Ezt div-vel, floatolással, stb. megcsinálni... :)
Nah, ez jó hosszúra sikeredett és nem sok újdonságot mond, de ilyen korán még nem tudok gondolkodni :)
Köszönöm!
link
Ez egy igen jó összefoglaló, a kérdést minden lényeges szempontból megvizsgálja, érdemes végigolvasni.
Üdv,
Cadeyrn
link
Ez az undorító prezentáció(?) évről évre előkerül. :) Amikor először végigolvastam, és megnéztem a siralmas képeit is, annyira feldühödtem, hogy szinte elhatároztam, amikor csak tehetem, azért is táblázatot fogok használni.
"csökkenti a tárhely-költségeket". Na persze... :)
Gyulus
marketingízű írás, de csökkenti
html
Egy példa: olyan admin felület, ami HTML kimenetet állít elő, és csak akkor frissíti, amikor valaki belenyúlt - tehát nem dinamikusan állítja elő az oldalt, mert esetleg nagyon terhelné a szervert.
Ebben az esetben nem mindengy, hogy egyetlen oldal 4k vagy 40k. Szerintem.
A másik, hogy a forgalomért sok helyen vagy tényleg fizetni kell, vagy aszerint is vannak tárhelykategóriák, és ez igencsak beleszámít a forgalomba.
Mellesleg szerintem jók a fóliák, mert akárkinek íródtak, és mindent rendesen, korrektül megindokol.
Az, hogy Te még mindig nem látod át az értelmét a dolognak, nem azt jelenti, hogy rossz az, ami ezt leírja...
html
Azt hiszem, eléggé félreértettél. Nem a táblázatnélküli layout-on háborodok fel, hanem azon a prezentáción, a tenyérbemászó szövegén, és az undorító képein. Mire alapozod, hogy én még mindig nem látom át az értelmét?
Gyulus
Miért rosszabb a div?
zmb
Nekem az a véleményem ...
20 éves honlap
20 éves honlap
Egyébként nincs is benne táblázat. :)
Gyulus
Félreértettél ...
Erre írtam azt, hogy meg kell nézni a Te honlapodat, hogy táblázat helyett div-ekkel oldottad meg a dolgot. Részemről ez pozitív véleménynyílvánítás volt, hogy tetszik, amit csináltál ...
Félre... :)
form formázás
zmb
ezek csak kifogások
Szóval ezt csak kifogásnak tartom.
Az űrlapok elrendezésére is meg vannak a megfelelő módszerek (fieldset, legend, label).
Azt kellene végre megérteni a táblázatokba görcsösen kapaszkodóknak, hogy hiába embereknek készítünk oldalakat, felhasználói felületeket, első körben gépek értelmezik a dokumentumokat. Az emberek gépek segítségével találnak meg egy oldalt. Ahhoz, hogy a gép (kereső) azon a helyen kezelje az oldalunkat, ahova mi szántuk, számára is érthető módon kell azt összeállítani.
Tudom, hogy manapság rettentően fontos az arculat, a dizájn, a megjelenés, de nem kell mindent ennek alárendelni.
Eddig voltak az észérvek, most szeretnék hatni a lélekre :) Úgy kell hozzáfogni, hogy kihívás. Az nem lehet, hogy én nem tudok megcsinálni egy ilyet...
tikuVoltam
Profik?
Ennél már csak az szörnyűbb, amikor egy magát profinak és ügyfélközpontúnak beállító cég (legalábbis a honlapjuk ezt sugallja), idióta megoldásokat alkalmaz (framset utánzás div-vel, de teljesen felhasználóellenes megvalósításban) és egy árva DTD-t sem alkalmaz. Itt megkérdőjelezem a cég alkalmazottainak hozzáértését ...
hm...
De alapvetőbb probléma, hogy nagyüzem megy. ImageReady, slice eszköz, mentés másként, mail, készen is vagyunk a html-lel.
Ez van. Ott a pénz az pénz, és a vezetőket nem érdekli, hogy szabványos-e. IE-ben minden a helyén van, a megrendelő fizet, mindenki boldog. Ennél tovább nem néznek ők sem, a megrendelőik sem.
Végülis ja
Tapasztalat mutatja, hogy elég rendesen be lehet bukni a "húzzuk le jól az ügyfelet" dolgot. Az egyik ismerős csapat - igaz nem web, de programozás - több millát bukott el, mert nagyot akartak akasztani az ügyfélen. Az ügyfél meg ment máshova és feleannyiból megúszta jobb színvonalon a dolgot. Ez a nem mind1 ...
miért jobb?
1. Az a tapasztalatom, hogy egy saját gyártású oldalhoz hozzányúlni 6 hónappal később a táblázatos elrendezés esetében sokszoros időt igényel, mire újra összeáll a kép, hogy melyik beágyazott táblázatnak hol az eleje és meddig tart és tulajdonképpen minek is van ott.
2. Más által készített oldalak esetében, főleg ha azt valami program állítja elő az oldalfelépítés feltérképezése és átalakítása nagyon nehéz feladat. Most nemrég csináltam két projectet, a táblázatos átalakítása 4 napig tartott, a div-es pedig 4 óráig.
Nem jobb a div csak más
És a table is lehet valid.
Sztem ...
Csak példa képpen: Jelentkeztem egy html builder állásra, ahol kaptam egy template-et, amit át kellett alakítanom a feladatnak megfelelőn. Had nem mondjam, hogy mit gondoltam amikor megláttam a táblázatos layout-ot. Arra gondoltam, hogy nem tökölök sokat a template-tel csak az oldal tartalmi részéből szedem ki a táblázatokat és csak ott használok div-eket. Kb. 2 óra tökölés után amikor már minden böngészőben szétesett az oldal (a táblázat miatt), begurultam és az egész oldalt újraszerkesztettem táblázatos layout nélkül. Tehát csináltam egy css tableless felépítést.
Mit nyertem:
- az oldal 2 kb-tal kisebb lett
- a forrás átlátható és könnyen módosítható lett
- a div-ek úgy variálhatom ahogy akarom, ezáltal több apró képet össze tudtam vonni
- IE, FF, Opera alatt teljesen ugyanúgy néz ki az oldal
Tény és való, hogy a 2kb-tal kisebb oldalhoz tartozik egy 4,5 kb-os css file, de ha belegondolunk, akkor a css tableless megoldásnál már csak a szöveges tartalom fogja növelni az oldal méretét. Míg a táblázatos layout esetében, főleg, ha megfelelően bonyolúlt oldalszerkezetet alakítunk ki, maga a táblázatrendszer több helyet foglal a tényleges tartalomnál.
Tehát az css tableless megoldás átláthatóbb, könnyebben módosítható és nagyobb mennyiségű tartalomnál (pl. sok kisebb box egy blogban a kommenteknél) jóval kisebb végső méretet jelent még akkor is ha 10 kb-os css file-t használuk. Mert a css tableless megoldásnál egy kis box-ot csak egyszer írunk meg a css-ben míg a táblázatos layout esetén minden kis box egy újabb táblázat, újabb haszontalan bájtok, amik végső soron hatalmasra duzzasztják a html file méretét.
táblázat
Hadd legyek az ördög ügyvédje egy kicsit. Lássuk be, oldala válogatja. Azért, mert egy layout táblázatból van, nem jelenti azt, hogy kusza táblázatok kiismerhetetlen dzsungelével van dolgunk. Nézzük csak meg, alapesetben mennyi is egy layout táblázattal:
Természetesen nem rosszabb (sőt) a DIV-es layout sem, az valóban kevesebb html-ből áll. Máramelyik. Fura módon éppen maga a Yahoo áll elő olyan DIV-es layouttal, ami ránézésre egyenesen rémisztő, és hát igen, valljuk be, átláthatatlan, és szerkeszthetetlen:
http://developer.yahoo.com/yui/examples/grids/example_gc.html
Még mielőtt valaki a fentiek miatt torkomnak esne, én is DIV-ekkel dolgozom... :)
És innen koppintok: http://www.dynamicdrive.com/style/layouts/
A DIV-es layout valódi előnye a divatos lózungolás helyett a gyorsabb letöltődés, illetve az, hogy adott esetben az oszlopok felcserélhetők, (bár ez utóbbinak a gyakorlati haszna elenyésző).
Gyulus
Persze ...
nem csak a végletek...
Értem ...
Érted
Feleslegesen győzködsz arról, hogy a táblázat az táblázat, hiszen én is tudom. Amiről szó van, az az, hogy attól, hogy egy layout táblázattal van megolva, nem feltétlenül gányolás és kuszaság, és fordítva, ami div-ekkel, az nem biztos hogy szép és tiszta kód.
(Mellesleg a fentebb bekódolt táblázatos layout Netscape 3-astól kezdve az Explorer 7-ig teljesen egyformán nézne ki, már ha emlékszel a Netscape 3-asra.)
(Nem mellesleg, ha valami aláírásfélét firkantanál, akkor nagyjából lehetne tudni, hogy az ember kivel beszél.)
Gyulus
nem ganyolas.
Valoban nem ganyolas a tablazatot nem rendeltetesszeruen hasznalni ?
Kivancsi lennek szamodra mi a ganyolas :)
ui.: Egy vak embert nem fog erdekelni hogy az az oldal ugyanugy nez-e ki minden bongeszoben.. Miert is kellene egyaltalan ugyanugy kineznie, ha ugyanazt az informaciot ugyanugy kepes kommunikalni anelkul hogy tokeletesen ugyanugy nezne ki ? Nem a kinezeten kellene lennie elsodlegesen a hangsulynak szerintem, ugyanis az kivitelezhetetlen meg tablazatos layoutolassal is..
</noocx>
hogyan lehet praktikusabb ?
Attol mert szamodra talan egyszerubb az oldal prezentaciojanak elkeszitese, nem jelenti azt hogy mas teruleteken pedig eppen megnehezited a dolgodat ezaltal ?
</noocx>
hm
igazad lehet
Asszem en kb itt be is fejezem ezt a "szelmalomharcot".
</noocx>
nem nem
nem kell tuzzel vassal..
Betartani? Szerintem az a baj hogy sokan meg sem tanuljak helyesen a hasznalni az egyes dolgokat, mert onnantol nem kell semmit betartani, hanem csak csinalni ugy ahogy tanultad, ami egyaltalan nem okoz plusz munkat, ellentetben azzal ahogy most beszelsz rola.
</noocx>
határ
ha te még nem találkoztál a tableless és vakbarát stb. kialakítás igaz, hogy ritkán, de bizonyos esetekben (bizonyos layoutoknál) fennálló pluszmunka vonzataival, akkor nincs elég tapasztalat a hátad mögött.
ekkor viszont óvatosabban kéne fogalmazni a más véleményen levő kollégákkal kapcsolatban. (lásd: "nem fogod fel", "sajnálatra méltó", "fogalmad sincs" és társai)
nem kell tuzzel vassal..
Ha te is napi 8 órában gyártanád a legkülönbözőbb oldalakat, site-okat, egyszerre többet is akár, akkor te is észrevennéd magadon, hogy ha nagyon kell sietni, akkor odavágsz egy táblázatot, (mert halálpontosan tudod, hogy fog viselkedni) ha meg ráérsz float-olgatni, meg margin-olgatni, akkor div-ekkel oldod meg.
Gyulus
szintaxis
Vagy lehet nem azoknak kellene szakmat valtaniuk akik normalisan szeretnek csinalni a dolgokat ?:)
</noocx>
minek??
ertelme..
de ha ez eddig nem esett le akkor szerintem ne is ragozzuk tovabb.
</noocx>
gondoltam...
Kétkedőknek
Azért néha nem árt a táblázat
aha..
..vagy a javascript es css nelkuli bongeszomben ? esetleg linksben ?
</noocx>
pf
szeretnék egy weblapot, legyen ff,opera,ie6-7,safari, wap, pda és vakok számára készített írásfelolvasó kompatibilis.
röhej...nem telefonokra fejlesztünk elsősorban, sztem.
ui.: átlagfelhasználó meg vesz egy gépet a TEschoban XPvel, nem hiszem, h első feladata lenne a javascriptet és CSSt kikapcsolni.
ok zarjuk le
Tema reszemrol lezarva.
Udv,
</noocx>
Gyakorlati szempontok
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.
cikk?
gex
részemről nem
Webbuilder
Wiki
(Betettem ezt a témát is a linkek közé.)
Wiki
Gyulus
Basszus
Basszus
Gyulus
Honnan szedted ezt?
Honnan szedted ezt?
A sapkás példa nem jó. Akkor lenne jó, ha azt bizonygatnám, hogy a header elemre nem a H1 való, hanem egy style-olt div. De nem.
Nekem is ez az utolsó hozzászólásom.
Gyulus
Re: Gyakorlati szempontok
Mivel András többször is az én érveimet cáfolta, csak írok néhány gondolatot én is.
Magam is azt éreztem a túláradó szematikusság-ömlengést olvasva, hogy jó-jó, szemantikus, de micsoda?
Azt is olvashatjuk, hogy a div-es layout nem gányolás, a táblázatos meg igen. A táblázatos valóban az, de legalábbis nehézkesebb, de nézzük csak meg egy picit, hogy a div-ekkel hogyan is csinálunk "táblázatot"?
Van egy egyszerű, jól használható, magabiztos layout sablon, a következőképpen néz ki:
A div-es, CSS-es layout akkor lenne megnyugtató, és "szemantikus", ha körülbelül úgy lehetne definiálni egy layoutot, hogy rendelkezésre áll egy szemantikus html tag, például a layoutcol nevű, a CSS meg ennyi lenne:
A div-est karbantartani valóban könnyebb. De vegyük észre, hogy a CSS-es trükkökkel megerőszakolt div-ek egyáltalán nem valók a webszerkesztés aranyoldalaira, mondhatnám úgy is, hogy bizony, az a webszerkesztés szégyene, hogy a mai napig nem találták ki a layout kialakítására való szemantikus megoldásokat.
Gyulus
kitalálták
kitalálni kitalálták, már csak a megvalósításra kell várni, szvsz olyan 10 évet...
gex
Én csak azt nem értem ...
Én csak azt nem értem
http://www.dynamicdrive.com/style/layouts/item/css-fixed-layout-31-fixed-fixed-fixed/
Egyébként éppen erről beszéltem, hogy ez mind csak sima trükközés, ügyeskedés, a css szabályainak kijátszása. Ugyanarra a megjelenésre van százféle megoldás, és ez nem jó.
Nem véletlenül van a weben annyi tutorial, mintaoldal, layout gyűjtemény, hogy azt se tudjuk, hova nézzünk. Mindenki gányol valamit, aztán ha sikerül átvernie a böngészőt, mert egy div beállt valamelyik oldalra jól, akkor örül, és kirakja a webre, hogy tutorial.
Gyulus
Témazárás
A téma lezárva!
ui: a témát én nyitottam, ezért jogom van zárni is!:PP
Gyokorlati példa ...
A feladat: Csináljuk egy táblázatot, aminek alapértelmezetten 5 sor van megjelenítve. A user egy gomb megnyomásával további sorokat adhat hozzá (a hozzáadható sorok száma limitálva van). Az egész lényege, hogy a cég jelenleg e-mail alapú megrendelési procedúráját átültessük web-re (ahonnan pedig időközönként szinkronizálódik az SAP-val).
Tehát adott egy XLS dokumentum egy egyszerű táblázattal, melynek van X sora és Y oszlopa (a példa szempontjából lényegtelen).
A problémát úgy akartam megoldani, hogy összedobom a táblázatot és adok neki egy border-collapse : collapse; stílust. Majd teszek ki egy gombot, ami kap egy onClick-et, ami meghív egy JS függvényt. A függvény annyit csinál, hogy megnézni, hogy hány sor van megjelenítve (ha a <TR>-nél a display : table-row) majd a következő ID-jű sort megjeleníti.
A megoldás FF alatt tökéletesen működött. Opera alatt már jöttek a gondok. A collapse miatt az újonnan megjelenített soroknál a jobb szélső cella jobb oldali szegélye hibásan jelent meg. Ha collapse helyett separate volt, akkor nem volt hiba, de nekem collapse kellett. IE alatt meg ugye a JS nem ment, mert szerinte a <TR>-nek nincs display tulajdonsága.
Ekkor jött a gondolat, hogy vessük el a táblázatot és oldjuk meg a dolgot DIV-ekkel. Gyakorlatilag a HTML felépítése ugyanaz lett, csak a CSS változott. És láss csodát a DIV-vel felépített táblázat már helyesen működik mind FF, IE és Opera alatt is.
CSS vs TableSpacerGif
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.
Van még mit javítani a szabványokon és a böngészőkön
Javában a panelok felelnek meg a diveknek. Ott is először létrehozod a panelt, aztán kedvedre egymásba ágyazod őket, mint a diveket. Aztán Javában fogsz egy layout managert, ami szépen elrendezi neked a panelokat. Minden panelba külön layout managert tudsz beállítani, így a panelek egymásba ágyazásával és a megfelelő laoyut manager használatával akármilyen elrendezés létrehozható. A kinézet pedig tökéletessen elválik a tartalomtól.
Namost, CSS-ben is azt kéne, hogy feléptíted az oldatl divekkel, aztán megmondod külön a divekre, hogy a benne lévő diveket hogyan rendezze a böngésző: egy sorban, táblázatosan, egymás alá stb.
Pl. Javában van a Borderlayout elrendezéskezelő, ha ilyen lenne CSS-ben is, akkor egy háromoszlops, fejléccel, lábléccel rendelkező oldalt egy sor lenne CSS-ben megcsinálni. És az elrendezéskezelő figyelembe veszi a margókat, kereteket, belső margókat is, és szépen elrendezi ezekkel együtt is az oldalt.
Aztán ha hirtelen más oldalfelépítés kell, akkor egyszerűen csak át lehetne váltani egy másik elrendezéskezelőre, ami mondjuk egymás mellé tenné be az oszlopokat.
Mintha CSS 3-ban már valami ilyesmi megoldás lenne.
Van ez a One ture layout cikk, ebben az a vicces, hogy a kívánt elrendezést egy CSS, XHTML gurunak is ilyen rohadt nehéz volt elérnie, és még ez sem működik tökéletesen!
Aki Javát most kezdi tanulni, és elér a laoyut managerekhez, annak pár óra tanulás után különb elrendezést sikerül létrehoznia, mint amit CSS-ben izzadva sem lehet elérni.
Ezen az oldalon 3 oszlopos elrendezések vannak összegyűjtve. Az össes létező trükkot bevették, hogy a kívánt elrendezés létrejöjjön. De ha IE7-tel nézzük az elrendezéseket, akkor sajnos sok már nem jó, szétugrik IE7 alatt. Megint csak Javát felhozva, erről sosem kellett topicot nyitni, egyféle működő megoldás van erre a problémára, mindehol ugyanúgy néz ki és kész. Egy kedző is könnyen megcsinálja.
Mi van, ha egy kezdó CSS-t tanuló olyan elrendezést akar, mint a One true layout, és nem szabad táblázatot használnia? Jó, most már lekoppinthatja a mostani megoldást, de ilyen megoldásokat látva elmehet az ember kedve a táblázat nélküli oldalfelépítéstől!
Na a dolog lényege, hogy ha a böngészők (IE) végre 90-100%-ban értelmezik a szabványt, és a szabvány és könnyűvé teszi az elrendezést(CSS 3), akkor fele ennyi pénz és idő lesz megcsinálni egy honlapot, mint most.
Java más
Ezt tudom
De ami a lényeg, hogy a Java szemléletű layout managereket át lehetne hozni a CSS-be.
És mi kéne ahhoz, a hogy a fenti mondat érvényes legyen a CSS-re?
1) Jobb szabvány, ami jobban támogatja az oldal elrendezésének megvalósítását.
2) Olyan böngészők, amik be is tartják ezt a szabványt.
És ha ezek meglesznek, akkor tényleg fele annyi idő, pénz lenne egy honlap elkészítése.
Amúgy a CSS nem annyira szétcincált, a specifikációját tudtommal egy szervezet adja ki, mint a Java specifikációját is. A gond az implementációval van, azaz a böngészőkkel.
Meg amit mondani akarok, hogy sokan azért használják a táblázatos oldalfelépítést, mert sokkal könnyebb használni egyes esetekben, mint a CSS-t. Talán megbocsátható egy kezdőnek, ha inkább táblázatot használ egy One true layout kinézet eléréséhez, mint az ottani megoldást.
Majd ha egyszerűbben működik a dolog (új szabvány, új böngészők), akkor fognak szerintem csak eltűnni a táblázatok.
Tehát az, hgoy ennyi oldal táblázatos felépítésű, nem csak a honlapot elkészítők hibája, hanem főleg a mostani böngészőké és a szabványé.