ugrás a tartalomhoz

Táblázat vs div - miért jobb a div?

Anonymous · 2006. Nov. 30. (Cs), 19.06
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
 
1

szemantika

Anonymous · 2006. Nov. 30. (Cs), 20.21
egyik legegyszerűbb válasz, hogy mert a div használata a szemantikus út. szemantikus kb = tartalmában a div a megfelelő "eszköz". szintaktikailag a table is jó lenne, de a div van erre kitalálva.

é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
2

logout

Gal Kristof · 2006. Nov. 30. (Cs), 20.22
amúgy ez én voltam, bár nem számít túl sokat :)
3

re

EL Tebe · 2006. Nov. 30. (Cs), 21.11
1-2 dolog ami hirtelen eszembe jut, persze annyira nem vagyok penge..
- 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 :)
4

Köszönöm!

Anonymous · 2006. Dec. 1. (P), 00.07
Köszönöm, érhető volt amit leírtatok!
5

link

Cadeyrn · 2006. Dec. 1. (P), 00.21
Miért butaság a táblázatos oldalszerkezet?

Ez egy igen jó összefoglaló, a kérdést minden lényeges szempontból megvizsgálja, érdemes végigolvasni.

Üdv,
Cadeyrn
6

link

Anonymous · 2006. Dec. 1. (P), 01.40
Miért butaság a táblázatos oldalszerkezet?

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
7

marketingízű írás, de csökkenti

Táskai Zsolt · 2006. Dec. 1. (P), 09.28
amerikai fóliák fordításáról van szó. ott forgalom alapján (is) fizetnek. tehát az ellen is véd.
8

html

Cadeyrn · 2006. Dec. 1. (P), 12.13
Üdv!

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...
18

html

Anonymous · 2006. Dec. 2. (Szo), 00.12
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...


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
9

Miért rosszabb a div?

Anonymous · 2006. Dec. 1. (P), 13.55
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
10

Nekem az a véleményem ...

Anonymous · 2006. Dec. 1. (P), 14.14
..., hogy elég megnézni Bártházi András honlapjának forrásást és választ kapunk a kérdésre (táblázatos megjelenítés div-ekkel) ...
20

20 éves honlap

Bártházi András · 2006. Dec. 2. (Szo), 07.32
Ugyan már, nehogy már a 20 éve készült honlapom alapján ítélj meg. Nézzed meg a Weblabor forrását, vagy a wish.hu-ét, vagy a mo.hu-ét. Majd ha jut rá időm, egyszer a saját honlapomat is rendbeszedem, de az egy nagyon-nagyon kezdő állapotomat tükrözi.
21

20 éves honlap

Anonymous · 2006. Dec. 2. (Szo), 08.56
Nem az a fontos, hogy milyen a honlap! Aki 8 évesen ilyet tudott, annak megengedhető, hogy ma már szégyellje. :)
Egyébként nincs is benne táblázat. :)

Gyulus
23

Félreértettél ...

Anonymous · 2006. Dec. 2. (Szo), 13.15
Vagy egy összetett form leírása, és formázása. Kinek mi a véleménye errő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 ...
46

Félre... :)

Bártházi András · 2006. Dec. 2. (Szo), 19.15
Valóban félreértettem a hozzászólást, viszont tényleg nem a saját honlapomat ajánlom kiindulási pontként. :) Enyhén szólva elavult, illetve számos olyan dolog is van rajta, amit ma már nem használnék szívesen.
25

form formázás

Anonymous · 2006. Dec. 2. (Szo), 14.03
Jó magam is a tableless layoutot részesítem előnyben (egyszerűen hatékonyabb, és logikusabb), de a formok kialakítása mindig komoly fejfájást okoz nekem. Vegyük például a keresomarketing.blogter.hu oldalt. A felső kereső sávot pl. az istennek se tudtam középre beilleszteni explorer alatt, pedig ez még nem is bonyi. Persze az is lehet, hogy alapvetően rossz irányból közelítettem meg a problémát, majd még agyalok alternatív megoldásokon.

zmb
11

ezek csak kifogások

tiku I tikaszvince · 2006. Dec. 1. (P), 14.25
Szinte minden a böngészők értelmezésében rejlő különbség kikerülésére létezik kipróbált, bejáratott, elfogadott módszer. Főleg az olyanokra, amelyekkel a kezdő "divelők" találkoznak. Nézz csak szét a fórumban. Mindig ugyanazok a (sokak számára unalmasan) alapvető kérdések merülnek fel (float, 3pxBug, nyúló konténer, stb).
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
12

Profik?

Anonymous · 2006. Dec. 1. (P), 14.37
Én a mai napig szörnyülködöm, amikor meglátom egy nevesebb cég munkáját és a forrást megnézve (mert ugye csak belenézek, hogy mit csinált egy profi(?)) azt látom, hogy táblázatos a layout. Ilyenkor egyszerűen nem tudom mire véljem a dolgot. Neves cég, valószínűleg tényleg jó webfejlesztőket foglalkoztatnak, akkor mi a francért használnak még mindig táblázatos layout-ot.

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 ...
14

hm...

amonrpg · 2006. Dec. 1. (P), 15.47
Az alkalmazottak sem mindig vannak a top-on az ilyen cégeknél.
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.
15

Végülis ja

Anonymous · 2006. Dec. 1. (P), 15.55
Csak akkor ne hirdesse magát úgy a cég, hogy profik. A cég honlapjából és a szövegből az jön le, hogy vérprofik, vágják a tmát. Aztán a honlapjaik elég rendesen hasonlítanak egymásra, sok helyen a design megvalósítás izléstelen, a kódról már nem is veszélve. Én azon vagyok, hogy a user az első. Egy normális megrendelővel lehet tárgyalni. Készítettem egy honlapot, igaz baráti alapon, de nem is ez a lényeg. A srácnak volt több elképzelése, ami sok sebből vérzett. Elmagyaráztam neki, hogy mit hogyan lenne célszerű és megértette. Ha a megrendelőben vagy kompromisszumkésség és nem csak az kell neki, hogy csilli-villi legyen (lásd full flash honlapok, amitől hányok) és a készítő pedig van annyira userfriendly, hogy nem csak a nagy zsét nézi, akkor működhet a dolog. Lehet, hogy nem akaszt sokat 1 melóval, de jön 10 ember és már többet keresett.

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 ...
13

miért jobb?

rrd · 2006. Dec. 1. (P), 15.10
Pár (személyes) indok:
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.
16

Nem jobb a div csak más

Anonymous · 2006. Dec. 1. (P), 17.49
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.
17

Sztem ...

Anonymous · 2006. Dec. 1. (P), 20.00
... nem érted miről van szó. Van egy oldal. Van benne egy qrva nagy táblázat, amiben pl. statisztikai adatok vannak. Ezzel semi baj. A bajok ott kezdődnek, amikor vki az egész oldalt táblázattal építi fel. Tehát a fejlés nem div-ekből áll, hanem egy táblázat celláiba teszi bele a képeket. Szóval maga az oldal egy rohadt nagy táblázat. Ami azt jelenti, hogy dinamikusan szinte lehetetlen előállítani és megfelelően átláthatatlan, szerkeszthetetlen és még nagy is, mert rengeteg <td> és <tr> van.

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.
19

táblázat

Anonymous · 2006. Dec. 2. (Szo), 00.52
Szóval maga az oldal egy rohadt nagy táblázat. Ami azt jelenti, hogy dinamikusan szinte lehetetlen előállítani és megfelelően átláthatatlan, szerkeszthetetlen és még nagy is, mert rengeteg <td> és <tr> van.

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:
<table>
<tr>
<td colspan="3">FEJLÉC</td>
</tr>
<tr>
<td>BAL OSZLOP</td>
<td>TARTALOM</td>
<td>JOBB OSZLOP</td>
</tr>
<tr>
<td colspan="3">LÁBLÉC</td>
</tr>
</table>
Akinek ez átláthatatlan, és dinamikusan nem állítható elő, az keressen más szakmát. Ezt a táblázatot természetesen CSS-sel kedvére variálhatja bárki, nem lesz sokkal kuszább, már persze ha a class-okat meg id-ket kuszaságnak tekintjük.

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
24

Persze ...

Anonymous · 2006. Dec. 2. (Szo), 13.22
... a fenti példával alapvetően nincs gond, mert használható. A problémák ott kezdődnek, amit már említettem. Tehát van egy blog (vagy akár a weblabor) ahol az egyes hozzászólások ugye mind-mind külön táblázatok lesznek a fő layout-ot képező táblázatban. 20-30 házzászólásnál már elég szép mérete lesz csak ezeknek a belső táblázatoknak.
26

nem csak a végletek...

Gal Kristof · 2006. Dec. 2. (Szo), 14.36
léteznek. pl én is ismerem és használom a tableless megoldásokat, de bizonyos problémákat egyszerűen sokkal egyszerűbb és praktikusabb table-el megoldani. pl bizonyos esetekben az alap elrendezés 2-3 oszlopát table-el oldsom meg, minden más div és a társai. én ebben nem látok problémát, a hozzászólásokat se muszáj táblásítani, azért mert egy táblát már alkalmaztál...
27

Értem ...

Anonymous · 2006. Dec. 2. (Szo), 15.20
Természtesen használható a megoldás amit említesz. De mi értelme táblázatot használni egy 3 oszlop-os megoldásnál, amikor a div-es sokkal rugalmasabb. Azt kellene már megérteni, hogy a táblázat az táblázat. Az arra van, hogy adatokat jelenítsél meg vele és nem arra, hogy egy oldal szerkezetét írd le. Egy hasolnat: excel-ben is lehet levelet írni, de nem erre találták ki. A word-ben is lehet táblázatokat csinálni, ha szükséges. Tehát csak azért mert akarsz egy-két táblázatot betenni egy levélben nem excel-ben írod meg az egészet. Tudom, hülye hasonlat, de talán már érthető, hogy miről beszél mindenki.
28

Érted

Anonymous · 2006. Dec. 2. (Szo), 15.35
Azt kellene már megérteni, hogy a táblázat az táblázat.

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
30

nem ganyolas.

noocx · 2006. Dec. 2. (Szo), 15.57
Valoban nem ganyolas a tablazatot prezentaciora hasznalni ?
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>
29

hogyan lehet praktikusabb ?

noocx · 2006. Dec. 2. (Szo), 15.52
Hogyan lehetne praktikusabb a tablazat alapu layoutolas, prezentacio az eszkozfuggetlen, kevesebb munkaval jaro, kisebb fajlmeretet eredmenyezo, megmegezeregyelonnyel biro szemantikus kodnal?

Attol mert szamodra talan egyszerubb az oldal prezentaciojanak elkeszitese, nem jelenti azt hogy mas teruleteken pedig eppen megnehezited a dolgodat ezaltal ?

</noocx>
33

hm

Gal Kristof · 2006. Dec. 2. (Szo), 16.15
nem értem mire jó ez a szélmalomharc, amit vívsz. ha neked a div az überalles, attól még másnak nem biztos. :) de ez nem azt jelenti, hogy mindenki más gányol, és nem tudja a div vs table téma minden előnyét és hátrányát, illetve az esetek 95%-ban nem tableless módszerrel dolgozik.
36

igazad lehet

noocx · 2006. Dec. 2. (Szo), 16.28
Hat igen, erre nem igazan tudok mit mondani, ha te csak ezt latod ebben az egeszben hogy div -vs- table akkor az sajnalatra melto.
Asszem en kb itt be is fejezem ezt a "szelmalomharcot".

</noocx>
39

nem nem

Gal Kristof · 2006. Dec. 2. (Szo), 17.02
a baj nem ez. hanem az, hogy neked ez a saját keresztes háborúd, és nem próbálod megérteni mások mit mondanak. azért mert most a nyakadba vetted a tableless és a szemantikus téma hirdetését, nem jelenti azt, hogy pl én nem tudok annyit a témáról, mint te, de a tapasztalataim alapján nem próbálom tűzzel vassal betartani a szabványokat és a különböző használhatósági eszméket, csak az értelmesség határáig.
40

nem kell tuzzel vassal..

noocx · 2006. Dec. 2. (Szo), 17.14
Mi az ertelmesseg hatara, es mi tud ertelmetlen lenni egy olyan dolgon ami elore visz es epito jellegu? Konkret peldat varok.

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>
41

határ

Gal Kristof · 2006. Dec. 2. (Szo), 17.22
értelmesség határa = amikor már az előnyök lényegesen elmaradnak a hátrányoktól (ami jelen esetben a plusz munka)

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)
42

nem kell tuzzel vassal..

Anonymous · 2006. Dec. 2. (Szo), 17.29
Szerintem te ott tévedsz, hogy ha valaki ki merészel rajzolni egy weblapra akár egyetlen táblázatot is, ami nem adattábla, akkor úgy tekintesz rá, mintha nem értene hozzá. Pedig erről nincs szó.
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
32

szintaxis

noocx · 2006. Dec. 2. (Szo), 16.15
Es ez a tablazat igy szerinted rendben van ?:) nem talalom a caption-t, nem latok benne egy th elemet se, nem latok benne se scope, se headers attributumokat, ja hogy nem kotelezo ? ..w3c-ek nagyon elszurhattak valamit..
Vagy lehet nem azoknak kellene szakmat valtaniuk akik normalisan szeretnek csinalni a dolgokat ?:)

</noocx>
35

minek??

Gal Kristof · 2006. Dec. 2. (Szo), 16.21
megmondanád nekem, mi értelme lenne egy layout célú táblában captionnek, th-nak, stb.-nek? hogy a felolvasóprogram felolvassa "most a bal oszlopban vagy"? néha nem árt végiggondolni minek mi az értelme...
37

ertelme..

noocx · 2006. Dec. 2. (Szo), 16.31
Ja es a layout celu tablanak az az ertelme hogy nincs ertelme
de ha ez eddig nem esett le akkor szerintem ne is ragozzuk tovabb.

</noocx>
38

gondoltam...

Gal Kristof · 2006. Dec. 2. (Szo), 16.58
...hogy kb ez lesz a válaszod. nem vagyunk egy súlycsoportban (mármint nem ütöm meg az értelmi mércédet)
22

Kétkedőknek

Cirby · 2006. Dec. 2. (Szo), 09.17
A kétkedőknek a css Zen Garden oldalt szoktam megmutatni és elmagyarázom, hogy ezen oldalak HTML kódja azonos, "csak" a css változik. Sokan nem hiszik! :-)
31

Azért néha nem árt a táblázat

Anonymous · 2006. Dec. 2. (Szo), 16.09
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.
34

aha..

noocx · 2006. Dec. 2. (Szo), 16.16
Aha. Megnezhetem az oldaladat a mobilomon es a pdamon ?

..vagy a javascript es css nelkuli bongeszomben ? esetleg linksben ?

</noocx>
43

pf

TIV · 2006. Dec. 2. (Szo), 17.41
bocs má, de szted ki fog úgy odamenni hozzád, hogy...

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.
44

ok zarjuk le

noocx · 2006. Dec. 2. (Szo), 18.47
Szinvonalas, komoly hozzaszolasokat, indokokat, erveket hallhattunk. Csak igy tovabb, mindenki csinalja ahogy szeretne, ahogy megszokta, ahogy teheti, ugy erzem szamomra ez max kifizetodo lehet ha nem probalok meggyozni masokat rola hogy hogyan csinalja jol.
Tema reszemrol lezarva.

Udv,

</noocx>
45

Gyakorlati szempontok

Bártházi András · 2006. Dec. 2. (Szo), 18.55
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.
47

cikk?

Anonymous · 2006. Dec. 2. (Szo), 19.52
nem lehetne ebből a hozzászólásból egy hasonló cikket csinálni, mint anno az objektumorientált programozás előnyeiből? az is egy fórumtémából indult. :]

gex
52

részemről nem

Bártházi András · 2006. Dec. 3. (V), 09.09
2006, illetve hamarosan 2007 van. Részemről nem vagyok hajlandó ennél több időmet a témára szánni. Pár éve volt ez kérdés, nem most.
53

Webbuilder

Anonymous · 2006. Dec. 3. (V), 09.27
Mi lenne, ha átdobnád a Webbuilderbe? Elvégre a Te irásod, de had használják. NAGYON sok kezdőt ismerek, akit szivesen irányitanék át rá.
54

Wiki

jeti · 2006. Dec. 3. (V), 11.56
Elég gyakran merült fel eddig ez a probléma, ezért én tipikus hibának gondolom. Kerestem a wikiben, de nem találtam, ezért tegnap este írtam róla egy vázlatot. Viszont csak ma olvastam el végig ezt a fórumi témát... Nem akarom elvenni senki elöl a lehetőséget, ezért nyugodtan bárki kiegészítheti, átírhatja. Remélem legközelebb erre a kérdésre elég csak ezzel a linkkel válaszolni: http://webbuilder.hu/index.php/Táblázatos_oldalszerkezet
(Betettem ezt a témát is a linkek közé.)
55

Wiki

Anonymous · 2006. Dec. 3. (V), 13.36
Megemlíthetnéd a szövegben az is, csak a tisztánlátás végett, hogy a táblázatokat kiváltó div-es megoldás sem üdvözítő teljes mértékben, mert az ugyanúgy valamilyen nem odavaló html tag megerőszakolása, mint ahogyan a táblázat is az. Csak éppen van egy jónéhány előnye a táblázattal szemben.

Gyulus
56

Basszus

Bártházi András · 2006. Dec. 3. (V), 15.42
Mivan? A div egy általános HTML elem, amit igenis célszerű oldalkialakításhoz használni. Csak a tisztánlátás végett.
57

Basszus

Anonymous · 2006. Dec. 3. (V), 16.20
Célszerű. De nem arra való. Amikor kitalálták, szó sem volt layout kialakításáról.

Gyulus
58

Honnan szedted ezt?

Bártházi András · 2006. Dec. 3. (V), 17.09
Igen, az egész HTML nem a prezentációról, hanem adatok leírásáról szól. A prezentációról a CSS szól. Ahogy írtam, a div egy általános célú elem, amit használhatsz jellemzően bármire, így tökéletes az oldal layoutjának kialakítására. Azt bizonygatod, hogy az általános célú mosópor nem sapka mosására való, mert arra a sapkamosópor való. Csakhogy nem létezik sapkamosópor, mert az általános célú mosópor van erre a feladatra. Részemről ez volt az utolsó hozzászólásom ehhez a témához.
59

Honnan szedted ezt?

Anonymous · 2006. Dec. 3. (V), 18.02
Kár hogy ilyen ideges vagy. Én annyit sugalmazok itt már napok óta, hogy a css layout bűvészkedés semmivel sem "arra valóbb", mint a táblázatos gányolás. Mind a kettő pótol valamit, ami nincs.
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
48

Re: Gyakorlati szempontok

Anonymous · 2006. Dec. 2. (Szo), 20.49
Nagyszerű összefoglaló, szinte minden szavával egyetértek.
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:
#maincontainer {
	width: 840px;
	margin: 0 auto;
}
#topsection {
	height: 120px;
}
#contentwrapper {
	float: left;
	width: 100%;
}
#contentcolumn {
	margin: 0 190px 0 180px;
}
#leftcolumn {
	float: left;
	width: 180px;
	margin-left: -840px;
}
#rightcolumn {
	float: left;
	width: 180px;
	margin-left: -180px;
}
#footer {
	clear: left;
	width: 100%;
}
Jól működik, a html is tiszta, egyszerű hozzá, ám vegyük észre a margin-okkal való hihetetlen bűvészkedést, hogy mást ne mondjak, gányolást: -840px, -180px, stb.

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:
layoutcol {
	header-height: 100px;
	footer-height: 30px;
	col-width-1: 150px;
	col-width-2: 480px;
	col-width-3: 170px;
	col-width-1-background: #FFCC00;
	height: ha a tartalom kisebb mint az ablak, akkor is 100%-ra nyúljon.
	align:center;
}
Ekkor mondhatnánk azt, hogy szemantikusan oldjuk meg a layoutot, addig azonban a táblázattal is, és a div-vel is csak bűvészkedünk, ügyeskedünk, helyettesítünk valamit, ami nincs, de nagyon kellene.

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
49

kitalálták

Anonymous · 2006. Dec. 2. (Szo), 21.08
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

kitalálni kitalálták, már csak a megvalósításra kell várni, szvsz olyan 10 évet...

gex
50

Én csak azt nem értem ...

Anonymous · 2006. Dec. 2. (Szo), 21.25
..., hogy minek kellenek a negatív margók? Meg egyébként is minek margó?

#page    { width: 760px; margin: 0 auto; padding: 0; }

#header  { width: 760px; height: 150px; }
#menu    { width: 180px; float : left; }
#content { width: 560px; float : left; padding: 10px; }
#footer  { width: 760px; clear : left; }
51

Én csak azt nem értem

Anonymous · 2006. Dec. 2. (Szo), 21.37
Itt van az eredeti, tanulmányozásra:
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
60

Témazárás

TIV · 2006. Dec. 3. (V), 19.39
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
61

Gyokorlati példa ...

Max Logan · 2006. Dec. 6. (Sze), 12.59
... hogy táblázat helyett DIV-et kell használni adott esetben a táblázatos adatok megjelenítésére.

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.
62

CSS vs TableSpacerGif

Jano · 2006. Dec. 6. (Sze), 13.48
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.
63

Van még mit javítani a szabványokon és a böngészőkön

Charybdis · 2007. Már. 3. (Szo), 12.02
Nem értem, mért nem csináltak egy olyasmi megoldást, ami pl. a Java nyelvben a layout managerek.

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.
64

Java más

janoszen · 2007. Már. 3. (Szo), 12.30
Csak azt felejted el, hogy a Java a Sun kezében van, a CSS esete meg egy teljesen szétcincált dolog.
65

Ezt tudom

Charybdis · 2007. Már. 3. (Szo), 12.46
Ezt tudom, a Java platformfüggetlen, egyszer megírod pl. a GUI elrendezését, és ugyanúgy néz ki minden platformon.

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é.