ugrás a tartalomhoz

A táblázatos oldalak ideje lejárt, de mi a helyzet a frame-ekkel?

Anonymous · 2006. Nov. 4. (Szo), 14.27
Hello!
Sokfelé olvasom (itt a weblabor-on főleg) hogy a táblázatos oldalakat már illik elfelejteni, helyettük <div> + css kombinácóval felépíteni a lapokat.
Kérdésem hogy a frame-ekkel mi a helyzet? Az is idejétmúlt?
‹ IE-ben szétcsúsznak az iframe-jeim Az oldalam kilóg a képből, mégsem görgethető ›
 ■
1

eredetileg sem voltak jók

Hojtsy Gábor · 2006. Nov. 4. (Szo), 14.31
A kertek helyett már annak idején is megvolt minden megoldás (szerver oldali programozással). A keretekkel rengeteg gond van, nehéz őket használni, nem lehet kedvencek közé tenni a keretek aktuális állapotát, sokszor nem fér be a keret területére a tartalom, és akkor nehezen görgethető stb.

A keretek tartalom-ragasztó funkcióját szerver oldalon illik megoldani (szerver oldali HTML generálással). A keretek vizuális megjelenését CSS-sel is meg tudod most már tenni. http://www.google.com/search?q=frames+with+css Így a tartalom egy oldalon marad, el lehet tenni kedvencek közé, de ha ilyen megjelenésre vágysz, akkor is megteheted.
4

Frames...

Pal_ur · 2006. Nov. 4. (Szo), 19.25
A kertek helyett már annak idején is megvolt minden megoldás (szerver oldali programozással).

Lehet, hogy érdemes egy ilyen kijelentés előtt végiggondolni, hogy a HTML nyelv segítségével nem csak szerveroldalon lehet programozni. Magam programoztam vagy 15 HTML alapú CD-ROM-ot, érdekes megoldás lenne ott szerver-oldalon megoldani valamit :)

A keretekkel rengeteg gond van, nehéz őket használni, nem lehet kedvencek közé tenni a keretek aktuális állapotát, sokszor nem fér be a keret területére a tartalom, és akkor nehezen görgethető stb.

Mint sok eszközt, ezt is lehet(ett) ügyesen használni, és van, amikor a fenti "hátrányok" nem hátrányok. És nem nehéz őket használni, csak meg kell szokni a programozásukat.

Egyébként valóban, a webes világ leszokott a keretek használatáról. Ezt nem vitatom, az utólagos "már akkor sem..." mondatokkal én azért óvatosabb lennék. (Persze... IMHO.)
9

tényleg nem voltak jók

Joó Ádám · 2006. Nov. 4. (Szo), 23.33
Pedig tényleg nem voltak jók, csak nem volt más - hiányos a szabvány. Sok gondot meg lehetett volna kerülni egy "<include>" taggel.
11

internetről van szó

Jano · 2006. Nov. 5. (V), 02.03
Amíg valaki külön nem mondja, addig internetes felhasználásról beszélünk. Az intranet és "multimédia" CD-k felülete és más felhasználási területeknél teljesen más szempontrendszer érvényesül!

Egy CD-nél az include kiváltható azzal, hogy te legenerálod előre a teljes oldalakat.
13

CD-ROM

Hojtsy Gábor · 2006. Nov. 5. (V), 14.19
Én is csináltam keretes oldalt! Sőt én is csináltam CD-ROM-ot, bár ezutóbbi esetben már legeneráltam előre a dolgokat, nem vetettem be keretet. Annó a Weblaboron is a JAMAL generátort használtuk, és előre generált HTML lapokkal ment az oldal. Ugyanezt CD készítésére is kiválóan lehet alkalmazni úgy, hogy csak a végén állnak össze a HTML lapok, és külön szerkeszthetőek a munkafolyamat során.
2

nem feltétlenül

Szekeres Gergő · 2006. Nov. 4. (Szo), 15.32
Szerintem a kereteknek van létjogosultsága. Mégpedig például adminfelületekre tökéletesen alkalmazható. Lapújratöltés nélküli technikákról nem is beszélve.. (igaz, az iframe)

Amúgy nem értek egyet azzal sem, hogy a táblázatokat nem szabad használi az oldal struktúrájának kialakításakor. Létezhet olyan szerkezet, amit táblázattal egyszerübben, gyorsabban, és böngészőktől kevésbé függő módon meg lehet oldani.

Ugyanakkor visszakanyarodva az eredeti kérdésre: ne használj frameket publikus lapokon, mert tényleg több hátránya van, mint előnye!;)
3

rossz hozzáállás

Joó Ádám · 2006. Nov. 4. (Szo), 19.16
Amúgy nem értek egyet azzal sem, hogy a táblázatokat nem szabad használi az oldal struktúrájának kialakításakor. Létezhet olyan szerkezet, amit táblázattal egyszerübben, gyorsabban, és böngészőktől kevésbé függő módon meg lehet oldani.


1) Az, hogy valami egyszerűbb, nem jelenti azt, hogy jobb is
2) A táblázat nem_arra_való. (Egyszer képzeld el, milyen lenne, ha megvakulnál és a felolvasóprogramoddal próbálnál meg kiigazodni egy ilyen táblázatban. És ez csak a jéghegy csúcsa.)
5

sokszor

TIV · 2006. Nov. 4. (Szo), 20.27
Szép dolog, hogy a vakokkal is foglalkozunk, de ha még 45000 vak is él Magyarországon - ezt hozta ki a gugli de én nem hiszem el, h ilyen sok - akkor is ez nálunk az emberek 0,0045%-a vak. Ebből mondjuk MONDJUK!!!! a fele netezik (kizárt), akkor 0,00225%. és ha még ennyi vak ember netezésre is adja a fejét, mennyi az esélye, hogy pont a te lapodra fog felmenni??? Iculi-piculi!

ui.: asszem érted mit akarok mondani
uui.: ha nem sok munka van vele, akkor én is a "LegyenMindennelKompatibilis" táborát gyarapítom!
uuui.: ezt a bejegyzést nem feltétlen a te hozzászólásodra írtam!
6

Google vak

attlad · 2006. Nov. 4. (Szo), 20.58
Google-t is a vakok közé szokás sorolni. Egy példa: táblázatos szerkezettel nem tudod teljesen befolyásolni a tartalom sorrendjét, a struktúrát, a weblap elrendezése fogja azt meghatározni.

De lehetnek esetek amikor jó a táblázat.

Btw: http://olav.dk/articles/tables.html
7

Itt se jó, csak kényszer!

Jano · 2006. Nov. 4. (Szo), 21.30
A linkelt oldalon leírt problémára se helyes a táblázat használata, csak kényszer megoldás. Jó megoldás a CSS-beli display:table-cell lenne!
8

Igaz

attlad · 2006. Nov. 4. (Szo), 22.12
Rosszul fogalmaztam.

Cikkben említi CSS megoldást, csak ugye IE..

Az a kérdés lehet még érdekes, hogy ilyenkor mi legyen: elavult megoldás vagy inkább CSS + obsolete böngésző(k)nek JS fix.
10

jéghegy csúcsa

Joó Ádám · 2006. Nov. 4. (Szo), 23.47
Mint azt írtam, ez csak egy megfelelően sarkos példa. De gondolj az attlad által is említett Google-re, és egyáltalán mindenféle gépi feldolgozásra (és gondolj a jövőre is, ne csak a jelenre).
Ismét hangsúlyoznám: a táblázat elem arra való, hogy táblázatos adatokat írjál le velen nem arra, hogy az oldal látványát kialakítsd. Szövegszerkesztőben sem használsz szóközöket margó helyett a behúzáshoz - remélem érted.
12

rossz példa

krey · 2006. Nov. 5. (V), 02.13
A szövegszerkesztős példa nagyon rossz! Ha mcedit-ben valamit szeretnék behúzni, akkor azt úgy kell, hogy...

Alapvetően ha valaki rosszul tanul meg valamit, akkor sokkal nehezebb kijavítani a hibát, mint eredetileg jól megtanulni.

Véleményem szerint a frémek ideje jóval a táblázatok ideje előtt lejárt.

üdv. krey
14

alátámasztást kérek

Szekeres Gergő · 2006. Nov. 5. (V), 21.18
"1) Az, hogy valami egyszerűbb, nem jelenti azt, hogy jobb is"

Miben nyilvánul meg, hogy jobb? Nem vitatom, technikailag egy sokkal jobb megoldásról van szó. DE! A technikai hatékonyság nem jár együtt a gazdasági hatékonysággal, ha az adott technológia 20%-al megdobja a fejlesztési időt, azt nem nevezhetjük gazdaságilag hatékonynak.
Készítettem számtalan oldalt táblázattal, és készítettem divekkel. Megrendelőnek teljesen mindegy, felhasználónak teljesen mindegy. Csak te szívsz vele 3x annyit. Én is ha lehet így készítek oldalt, de bevallom, leginkább erre csak a technikai sznobizmusom visz rá, más ésszerü magyarázatot nem tudok Ha majd lesznek mindenki által elfogadott szabványok, csak így fogok oldalakat késízteni, de egyszerűen sokszor anyagilag nem kifizetődő tabless oldalakat készíteni.

Egyetlen érv a SEO, de itt sem vettem észre olyan nagy különbségeket.

mégegyszer mondom, ne érts félre, én is az új szabványok mellett vagyok, mindent igyekszek "validan" csinálni, de ha nem éri meg, nem éri meg..

Mellesleg ugyan ez a helyzet az mvc-vel is. Ha valaki próbált már mvc szabvány szerinti lapletöltés nélküli tartalomváltást csinálni, akkor az tudja miről beszélek. Gyakorlatilag lehetetlen feladat.
15

kapsz

Joó Ádám · 2006. Nov. 5. (V), 22.26
Ha majd lesznek mindenki által elfogadott szabványok, csak így fogok oldalakat késízteni


Miben nyilvánul meg, hogy jobb?


Ha így készítesz oldalt, akkor ennyivel is közelebb vagyunk hozzá, hogy legyen egy mindenki által elfogadott szabvány ;)

Technikai hatékonyság kontra gazdasági hatékonyság: a "jobb" természetesen közösségi szempontból értelmezve jobb (egy jobb Web), nem pedig a te egyéni (pénzügyi) szempontodból. Ugye ez a kettő gyakran nem esik egybe (legalábbis kevéssé tág látókörrel szemlélve).
16

..

Anonymous · 2006. Nov. 6. (H), 07.08
Hozzaertes nelkul valoban 3x annyi idot vesz igenybe..
Kis hozzaertessel toredeket?
A kesobbi atstrukturalasrol, redesignrol nem is beszelve ?
Meg lehetne meg sorolni az ezernyi okot hogy miert is jo szemantikus kodot kesziteni ?
17

...

Anonymous · 2006. Nov. 6. (H), 07.17
Ja es kicsit utana kene olvasni ennek az egesznek, hogy mirol is van szo igazan, mert nem hinnem hogy az lenne a lenyeg hogy te diveket es css-t hasznalj es hogy a tablazat az kaki, tudni kene mit miert teszel.. mire miert van szukseg.. ertem ezalatt a szemantikus oldalfelepitest aminel ugye nem az a lenyeg hogy mindent beletegyek egy divbe es designoljam css-el, hanem az hogy minden elemet arra hasznaljak amire valo, amivel a leheto legtokeletesebben le tudom irni a kommunikalni kivant adatstrukturat. Ameg ezekrol a dolgokrol fogalma sincs valakinek addig tokmind1 hogy tablazatot hasznal-e vagy diveket meg css-t, lenyeget veszti az egesz.
18

gazdasagi hatekonysag ?

Anonymous · 2006. Nov. 6. (H), 07.24
szemantikus kod -> logikusabb, atlathatobb, konnyebben hasznalhato interface ? -> tobb user ?
19

megrendelo es user

Anonymous · 2006. Nov. 6. (H), 07.27
Megrendelonek valoban mindegy hogy milyen minosegu oldalt kap kezhez ?
Es a usernek ?
20

nincs különbség

Anonymous · 2006. Nov. 6. (H), 10.08
nincs látható különbség egy tabless és egy táblázatokból álló oldal között. Legalábbis ha jól csináltad meg...

Szekeres Gergő
21

lathato vagy nem lathato

noocx · 2006. Nov. 6. (H), 10.16
Ez a baj hogy mindig a lathato kulonbsegeken van a hangsuly..
22

user szemszögből

Anonymous · 2006. Nov. 6. (H), 10.20
felhasználókról beszéltünk. Nekik tényleg ezen van a hangsúly. Senki nem fogja nézni a kódodat..
Gergő
23

ok

noocx · 2006. Nov. 6. (H), 10.25
Akkor most akar fel is tehetnenk a kerdest, hogy mi ertelme egyaltalan szemantikus weblapokat csinalni.
28

félreérted

Szekeres Gergő · 2006. Nov. 6. (H), 11.45
nem, nem erről van szó. technikalag hatékonyabb, de a fejlesztési időt megdobhatja, és meg is dobja. Nem azért, mert nem értek hozzá, hanem azért, mert akár miyen jól írod meg, minden böngészőre át kell szabni.

Ha majd mindenhol jól jelenik meg, egyértelmüen ez lesz a legjobb megoldás
30

ertem en :)

noocx · 2006. Nov. 6. (H), 11.59
És azt mondod, hogy a sok "plusz munka" mellett nem nyujt tobb elonyt ha szemantikusan csinalod es csak css-el szenvedsz, mintha tablazattal csinalnad meg az egesz layoutot ?
31

ezt kérdeztem

Szekeres Gergő · 2006. Nov. 6. (H), 12.21
én kérdeztem tőled, hogy milyen előnyt tudsz felmutatni a szemantikus oldalfelépítés mellett. Az átláthatóbb, könnyebben módosítható kódot(elviekben) nem tudom elfogadni, mert a fejlesztési idő hosszabb. Amúgy nem azt mondtam, hogy mindig a táblázat a nyerő, de vannak esetek. És ezekeben az esetekben nincs lelkiismeret-furdalásom, hogy ha egy ilyen elavult módszerrel kell dolgozom!;)
32

Tervezés

Anonymous · 2006. Nov. 6. (H), 14.00
1. Egyrészt a felhasználók másrészt pedig a flexibilitás. Soha nem volt olyan, hogy azt mondták, hogy Te jó ég, ezt mégis csak középre kéne igazítani, az a másik felére tenni, stb.?

2. Azt, hogy ha nem csak HTMLben dolgozol, könnyebb az outputot debugolni, ha nincs olyan mennyiségű fölösleges kódod.
24

frameframeframe

Anonymous · 2006. Nov. 6. (H), 10.30
Mi a helyzet a framekkel? Frame. Nem tablazat. Frame.
25

frame

noocx · 2006. Nov. 6. (H), 10.31
Kinek van szuksege framekre egyaltalan?

http://www.useit.com/alertbox/9612.html
26

aki nem tud programozni

Cadeyrn · 2006. Nov. 6. (H), 10.39
Üdv!

A kérdésedre válaszolva: annak, aki nem programozza az oldalt, hanem szerkeszti. Egy mezei emberke, akinek valamiért HTML-t kell használnia, nem fog ezért megtanulni programozni.

Elfelejtitek, hogy a HTML eredetileg egy szövegszerkesztői nyelv, tehát kirívó esetekben el kell tudni vonatkoztatni a webserver környezetből.

Cadeyrn
27

heh?

noocx · 2006. Nov. 6. (H), 10.40
Mi koze ennek a frame hasznalatahoz ?
Egyebkent most webes kornyezetrol beszelunk.
Es aki meg nem ert hozza az ne hasznalja, vagy tanulja meg.

Mi koze ennek a programozashoz ?
33

mvc és tartalomváltás

Fekete Ferenc GDA · 2006. Nov. 6. (H), 16.02
offtopic

Ha valaki próbált már mvc szabvány szerinti lapletöltés nélküli tartalomváltást csinálni, akkor az tudja miről beszélek. Gyakorlatilag lehetetlen feladat.


Nem értem pontosan mire gondolsz, egyáltalán nem lehetetlen, erre való az ajax és mvc-ben is tökéletesen használható.
29

ízlés szerint

kerzo · 2006. Nov. 6. (H), 11.47
Szerintem mindenki döntse el, hogy a saját tervezéi és megvalósítási szempontjainak melyik a leginkább megfelelő. Viszont érdemes nem csak magunkra, hanem esetleg másokra is gondolni, mert nem biztos, hogy mindig mi fogjuk az oldalt karbantartani. Én is futottam már bele olyan kódba, amit egyszerűbb volt újra írni, mint kibogarászni az egyes részek kezdetét és végét (az oldalaim 80%-át jegyzettömben szerkesztem - mert ezt szoktam meg).

Én annak idején azért döntöttem iframe használata mellett, mert egyszerűbbnek találtam a karbantartást (pl. ha a menü változott, akkor csak egyszer kellett átdolgozni), illetve gondolva a lassabb internetkapcsolattal rendelkezőkre, nem kellett az egész oldalt újratölteni. Egy táblázatos oldalnál ugye a táblázatot felépítő cimkék növelik az oldal méretét, így növelve a letöltési időt. Persze lehet mondani, hogy ma már sokan használnak gyors kapcsolatot, de gondolni kell azokra is, akik nem ennyire szerencsések.

A div-es megoldás kétség kívül jobban támogatja a karbantartást az átláthatóság miatt, a moduláris felépítést, illetve az oldal felhasználó által befolyásolt elrendezést, illetve a már elmített akadálymentes oldalkészítést.
Nem értek egyet azokkal, akik csupán a kis létszám miatt bármilyen csoportot is kizár az "általunk" nyújtot információk eléréséből. Nem véletlenül kűzdünk azon, hogy az oldal ugyan úgy nézzen ki a különböző böngészőkben. Az oldal ne csak böngésző barát legyen, hanem elsődlegesen felhasználó barát.