ugrás a tartalomhoz

CSS lépésről-lépésre: táblázatnélküli oldalfelépítés

rrd · 2005. Dec. 4. (V), 20.00
CSS lépésről-lépésre: táblázatnélküli oldalfelépítés
Táblázat alapú egy oldal, ha a lap szerkezetét egymásba ágyazott többszörösen összetett táblázatokkal oldjuk meg. Ezekre kényszerültünk a CSS előtti időkben, ha két vagy három oszlopos megjelenést, vagy más speciális hatást akartunk elérni. A táblázat alapú oldalakkal azonban több probléma is van, de van megoldás. A cikkben egy konkrét oldalkialakítás során egy ilyen megoldást ismerhetünk meg, illetve azt, hogy miért rossz ötlet táblázat segítségével kialakítani egy oldal megjelenését.

Mindenekelőtt lássuk, milyen problémák vannak a táblázat alapú oldalkialakítással:
  • A forráskód akkor is nagyon bonyolult és szinte átláthatatlan lesz, ha jó úttörő módjára szépen betagoljuk a forrást, minden behúzandó elemet behúzva. Az a tapasztalatom, hogy hiába rakok be mindenféle megjegyzést, például "ez a navigátor tábla eleje", ez meg a "vége", ha valamit egy-két hónap elteltével módosítani akarok, akkor általában nagyon sok ideig tart mire megtalálom, hogy melyik tábla mi is tulajdonképpen. Persze a felhasználók ebből nem érzékelnek semmit, nem is érdekli őket ez a rész.
  • A táblázatokat csak akkor tudják a böngészők helyesen megjeleníteni ha már beolvasták a </table> jelet. Addig meg nem. Ez sokszor azt jelenti, hogy a böngésző tölt és tölt, mi meg nem látunk semmit. Még szélessávnál is zavaró, nem beszélve a modemes internetről.
  • A táblázatos oldalak nagyobb fájlméretben férnek csak el a sok <td> és </td> elem miatt.
  • Ha az oldalunk "quirks" módban készül (nincs megfelelő DOCTYPE az elején), vagy a böngésző egy régebbi darab, minden table elem megtöri a betűbeállításokkal kapcsolatos öröklődést, azaz ha az oldalunkon például Verdana betűtípust akarunk használni, akkor feleslegesen több helyen is definiálnunk kell, hogy az Verdana legyen (Internet Explorerben nem használható az inherit érték).
  • A táblázatos oldalkialakítás nem arra használja a táblázatokat, amire valók: táblázatos adatok leírására.

A megoldás

Használjunk CSS-t! Ez kiküszöböli a fent említett hiányosságokat. Ebben a cikkben be fogom mutatni, hogy hogyan kell megtervezni a lapunkat, hogyan kell HTML kódunkat összerakni, hogy kiszolgálja ezt az igényt. Vagyis hogyan kell elkészíteni egy CSS alapú "tableless" (táblázatok nélküli) oldalt. A táblázat nélküliség nem azt jelenti, hogy az oldalon nem szerepelhet táblázat, hanem azt, hogy nem az oldal megjelenésére, "layout"-jára használjuk, hanem ha kell, akkor arra amire való: táblázatos adatok megjelenítésére.

A feladat

A feladat az volt, hogy a lal.freeblog.hu lapot alakítsam át. Ilyen volt a lap az átalakítás előtt:

A blog megjelenése átalakítás előtt

Ebből kellett volna egy három oszlopos oldalt csinálnom (vagyis kiegészíteni plusz egy oldallal). Ugye egy többszörösen összetett táblázatba beszúrni egy új oszlopot az nem leányálom. Meghát fent már leírtam, hogy milyen problémáim is vannak a táblázatokkal. Szóval akkor úgy döntöttem, hogy a problémát egy új, CSS alapú, táblázat nélküli lappal fogom megoldani. A kész lapnak 800*600-as és 1024*768-as felbontásban, no meg ezek fölött is jól kellett kinéznie, mindenféle böngészőkkel. Internet Explorerben is. A megoldás: 1 egység alatt összerakni a lapot, hogy bármely böngészőben jól jelenjen meg, ezután 5 egység idő alatt átgyúrni úgy, hogy az Internet Explorer is nagyjából úgy jelenítse meg, ahogy azt mi szeretnénk...

Na akkor hogy is kell?

Akkor lássuk a medvét, állítsuk össze a HTML-t sok sok divvel, és csináljuk meg hozzá a CSS-t! Az biztos, hogy egy olyan cuccot kell összerakni, ami 3 oszlopból indul ki. Nevezzük őket balsávnak, jobbsávnak és középrésznek (bár ezek nem feltétlenül a legjobb elnevezések, de mindenesetre praktikusak).

Rögtön az elején jó, ha belőjük magunknak, hogy melyik rész fog a legtovább nyúlni. Esetünkben ez a középrész lesz.

A kiindulási alapként szolgáló HTML kód összeállítása

<!DOCTYPE html public "-//w3c//dtd html 4.01 transitional//en">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-2">
<title>Lál Blog</title>
</head>
<body>

	<div class="kozepresz">
	</div>
				
	<div class="balsav">
	</div>
				
	<div class="jobbsav">
	</div>
				
</body>
</html>
Be kell vallanom itt már kissé célirányosnak kell lenni, a div-ek sorrendjénél már figyelembe kell venni a leendő CSS megoldást. Bár vannak más megoldások is, én az abszolút pozícionálást (position: absolute) fogom használni a fő diveknél. Így a három fő div-et bármilyen sorrendben betehetem a HTML kódba, mivel a böngészők nem a HTML kódbeli helyük, hanem a CSS abszolút pozicionálási szabálya alapján fogják megjeleníteni. Azért rakom mégis a középrészt előre, mivel itt lesz a tényleges tartalom, és bizonyos keresőprogramok magasabb helyre teszik az oldalt, ha a keresett szó a HTML kódban előrébb szerepel.

A CSS alapja

/*html entitánsok*/
	body{font-family: "trebuchet ms", trebuchet, sans-serif;
		font-size: 12px;
		margin:0 0 0 0;
		padding: 0 0 0 0;
		background:#a44;}

/*az oldal felépítését befolyásoló elemek*/
	.balsav{position: absolute;
		left:0;
		top:0;
		width:200px;
		background:#a44;
		padding-bottom:10px;
		color:#d94;}
	.kozepresz{margin:0 200px 0 200px;
		background:#d94;
		padding-bottom:10px;
		border-right: 10px solid #333;
		border-left: 10px solid #333;}
	.jobbsav{position: absolute;
		right:0;
		top:0;
		width:200px;
		background:#a44;
		padding-bottom:10px;}

/*a középrész elemei*/
/*a balsáv elemei*/
/*a jobbsáv elemei*/
/*design elemek*/
A body elemmel megmondjuk, hogy milyen betűtípust akarunk, és 0-ra állítjuk a margókat és a kitöltést. A background definicót itt egyetlen ok miatt adjuk meg. Azt akarjuk, hogy ilyen szinű legyen a bal sáv legalsó dobozának a háttere. De akkor miért itt adjuk ezt meg? Azért mert az Internet Explorer nem tudja a bal sávunk legalsó boxát olyan hosszan lefelé megnyújtani amilyen hosszú a középrész, hanem csak olyan hosszúra hagyja amekkora a tartalma + az alsó doboz paddingja és marginja. Mi viszont azt akarjuk, hogy a legalsó doboz lelógjon a lap aljáig (vagyis a középrész aljával egy vonalban legyen). Ezért azt csináljuk, hogy a lapunk háttere olyan színű, mint amilyen szinűre akarjuk a bal alsó dobozt. Minden más doboznak adunk egy háttérszínt, ennek meg majd nem. Így a box beleolvad majd az alapértelmezett háttérbe és úgy néz ki mintha lelógna odáig. Ha ez nem világos, akkor majd ha kész az oldal, adni kell a bal legalsó boxnak egy border értéket és látható lesz, hogy minek hol a határa.

A balsávot a left: 0, top: 0 pozícióba, vagyis a bal felső sarokba igazítjuk. A jobbsávot pedig a jobb felső sarokba. Mindkettő 200 pixel széles. Ez egy 800*600-as képernyőnél azt jelenti, hogy a középrész 400 pixel, mínusz a böngésző kereteinek szélessége széles lesz. Nagyobb felbontásnál a középrész nagyobb lesz. A középrésznek jobbra és balra 200px-es margót adunk meg, hogy ne lógjon rá se a balsávra, se a jobbsávra, és adunk neki némi keretet, hogy úgy nézzen ki mint ahogy a táblázatos oldalunk nézett ki.

A középrész

A középrészen két boxunk van, egy a fejlécnek egy meg a tartalomnak. Tegyük be a CSS-be a szükséges bejegyzéseket.
/*a középrész elemei*/
	.fejlec{background:#a44;
		border-bottom: 10px solid #333;
		height:150px; 
		padding: 0 15px 0 15px;}
	.tartalom{margin: 15px 15px 0 15px;
		clear:left;
		text-align:justify}
Semmi érdekes, csak a fejlécnek adunk egy alsó keretet, hogy adja azt a kinézetet mint amit a táblázatos verzió adott. Persze ehhez be kell pár új div-et tenni a HTML kódunkba is:
<div class="kozepresz">
	<h1 class="fejlec">
	</h1>
	<div class="tartalom">
	</div>
</div>
A fejlécbe az oldal fejléc szövege fog bekerülni, illetve egy képet is szeretnénk betenni. Azért esett a választásom a h1 elemre, mivel ez az oldalnak a legfőbb fejléce lesz, illetve a h1-et jobban súlyozzák a keresők is. Azt szeretném, hogy a kép jobb szélre legyen igazítva, a szöveg pedig a maradék hely közepére. A blogcím CSS definició annyiról szól, hogy méretet és színt adunk majd a fejlécben szereplő szövegnek, beállítjuk a magasságát, plusz a hátterébe jobbra igazítottan beteszünk egy képet.
<div class="fejlec">
        Egy Krisnás szerzetes naplója
</div>
Az ehhez tartozó CSS:
/* a fejléc */
	h1.fejlec { background: #a44 url(lal.gif) top right no-repeat;
	            border-bottom: 10px solid #333;
	            height: 105px;
	            padding: 25px 15px 0 15px;
	            text-align: center;
	}
Na, jöhet a tartalom rész. Beteszünk ide is egy pár design-t módosító CSS elemet, de erről csak ennyit. Itt érdemes valamiféle tartalommal jó alaposan feltölteni ezt a részt, mivel az éles oldalon is itt van a legtöbb szöveg, és így tudjuk majd a legjobban tesztelni, hogy hogyan is néz majd ki a kész oldal.
<div class="tartalom">
	<div class="bejegyzescim">
		Változás
	</div>
	<div class="bejegyzesinfo">
		<a href="#">05-11-08 17:23</a> | 
		<a href="#">1 hozzászólás</a>
	</div>
	<div class="bejegyzes">
		Most éppen az oldalon változtatgatok. (...).
	</div>
</div>

A balsáv

A bal oldali sávban kiindulásként 3 dobozunk lesz, de persze lehet ennél több is, az is ugyanígy működik.
/*a balsáv elemei*/
	.balegy{background-color:#357; 
		text-align:right;
		padding:10px 10px 10px 10px;
		font-size: 14px;
		border-bottom: 10px solid #333;}
	.szlogen{margin-bottom:50px;}
	.elerhetoseg{color:white;
		margin-bottom:50px;}

	.balketto{background-color:#050;
		border-bottom: 10px solid #333;
		padding:10px 10px 10px 10px;}
	.balharom{text-align:right;
		padding:10px 10px 10px 10px;}

Magyarul semmi különös, csak színek, keretek, kitöltések és más szépítőszerek. A balegy lesz felülről az első dobozunk, a balketto a második, a balharom pedig a harmadik. Így utólag, ezek az elnevezések rosszak, helyesen a bennük levő tartalom szerint kellett volna nevet adni (pl. kereses, archivum, linkek, stb.), hiszen ha a másik oldalra kerülnének, vagy másik pozícióba a bal oldalon, a nevük teljesen értelmetlen lenne.

A balharom lesz az, ami miatt a bodynak adtuk azt a bizonyos background értéket. Itt látszik is, hogy a balegynek és a balkettonek is adunk háttérszínt, a balharomnak pedig nem, hanem hagyjuk, hogy örökölje a balsavtól.

És az ehhez tartozó HTML kód. Itt aztán végképp nincsen semmi érdekes. Fogtam és az eredeti lap forráskódjából bemásoltam minden ide tartozó dolgot. Persze a forrást kicsit pofásítottam, mert a régi nagyon össze volt dobálva. Itt jól lehet látni, hogy a táblázatos oldalakkal ellentétben - ha rendesen betagoljuk tabulátorokkal a forrást - milyen szépen lehet látni, hogy melyik doboz meddig tart. Szóval ha később majd valamit az egyik dobozból át akarunk rakni a másikba, akkor biztos, hogy könnyen meg fogjuk találni.
<div class="balsav">
	<div class="balegy">
		<div class="szlogen">
			Már régóta gondolkoztam, hogy...
		</div>
		<div class="elerhetoseg">
			<b>Elérhetőségeim:</b><br>
			Skype: manoram<br>
			MSN: manorama##kukac##freemail.hu<br>
			Mobil: (30) 231-8722
		</div>
	</div>
	<div class="balketto">
		<div>
		<!-- SiteSearch Google -->
		<form method="get"
			action="http://www.google.com/search">
		  <input name="ie" value="iso-8859-2" type="hidden">
		  <input name="oe" value="iso-8859-2" type="hidden">
		  <b>Keresés:</b>

		  <input name="q" size="10" maxlength="255" 
			value="" type="text">
		  <select name="sitesearch" id="sitesearch">
			<option value="lal.freeblog.hu"
			selected="selected">A blogon</option>
			<option value=".hu">Magyar oldalakon</option>
			<option value="">Weben</option>
		  </select>
		  <input name="btnG" value="Keres" type="submit">

		  <input name="domains" value="lal.freeblog.hu"
			type="hidden">
		</form>
		<!-- SiteSearch Google -->
		</div>
		<div>
			<b>Audió blog / Podcasting:</b>
			<ul>
   			<li><a href="/index.php?adas=8">2005.10.08</a>
				19:26" - 8,9 MB</li>

			<li><a href="/index.php?adas=7">Vidám
				szerzetesek videó 2.</a></li>
			<li><a href="/index.php?adas=6">Vidám
				szerzetesek videó 1.</a></li>
			<li><a href="/index.php?adas=5">2005.07.21</a>
				26:54" - 12,3 MB</li>
			<li><a href="/index.php?adas=4">2005.04.30</a>
				29:11" - 13,3 MB</li>
			<li><a href="/index.php?adas=3">2005.03.12</a>
				25:42" - 11,7 MB</li>

			<li><a href="/index.php?adas=2">2005.02.27</a>
				20:22" -  9,3 MB</li>
			<li><a href="/index.php?adas=1">2005.02.04</a>
				26:08" - 10,4 MB</li>
			</ul>
			<a href="/info.php" target="_blank">Infó a
				letöltésekről</a>
		</div>

	</div>
	<div class="balharom">
		<b>Régebbi bejegyzések</b><br>
		<a href="#">2004. szeptember</a><br>
		<a href="#">2004. október</a><br>
		<a href="#">2004. november</a><br>

		<a href="#">2004. december</a><br>
		<a href="#">2005. január</a><br>
		<a href="#">2005. február</a><br>
		<a href="#">2005. március</a><br>
		<a href="#">2005. április</a><br>
		<a href="#">2005. május</a><br>

		<a href="#">2005. június</a><br>
		<a href="#">2005. július</a><br>
		<a href="#">2005. augusztus</a><br>
		<a href="#">2005. szeptember</a><br>
		<a href="#">2005. október</a><br>
		<a href="#">2005. november</a><br>

		<a href="#">mostanság</a><br>
	</div>
</div>
A balharom boxban volt még egy fontos honlapok nevezetű rész, még azt is hozzá kell tennünk. Ennek a links nevet adtam. Itt egy nem trükkös megoldást használtam ahhoz, hogy három oldalon legyen keret, először megadtam, hogy mind a négy oldalon legyen 6px, majd a jobb oldalit felüldefiniáltam. A CSS validator warningol is rá, de csak azért, mert buta.
.links {border: solid black 6px;
	border-right: 0;
	background: #CA7;
	padding: 10px 10px 10px 0;
	margin: 14px 0 0 0;
	color:#000;}
És itt megintcsak fogtam az eredeti HTML kód ide vonatkozó részét és bemásoltam ide.
<div class="links">
	<b>Fontos honlapok:</b>
	<ul>
		<li><a href="http://www.krisna-volgy.hu/"
		target="_blank">Krisna-völgy</a></li>
		<li><a href="http://www.krisna.hu/"
		target="_blank">Krisna.hu</a></li>
		<li><a href="http://www.mantra.hu/"
		target="_blank">Mantra.hu</a></li>

		<li><a href="http://www.haribol.hu/"
		target="_blank">Haribol.hu</a></li>
		<li><a href="http://www.krisnaudvar.hu/"
		target="_blank">Krisna Udvar</a></li>
	</ul>
</div>
No, akkor a bal oldali sávval meg is vagyunk.

A jobbsáv

Ide nem tudtam, hogy mit akar a kedves kuncsaft, szóval csináltam 2 dobozt a balsavval megegyező színekkel és gondoltam majd ha kiderül, akkor a beltartalmat meg lehet változtatni. Hát lássuk a CSS-t, amiben csak a szokásos szépítőszerek és keretek szerepelnek:
/*a jobbsáv elemei*/
	.jobbegy{background-color:#357;
		padding:10px 10px 10px 10px;
		font-size: 14px;
		border-bottom: 10px solid #333;}
	.jobbketto{background-color:#050;
		border-bottom: 10px solid #333;
		padding:10px 10px 10px 10px;}
A HTML-t meg csak feltöltöttem valami szöveggel, hogy lehessen látni a várva várt végeredményt.
<div class="jobbsav">
	<div class="jobbegy">
		Most éppen az oldalon változtatgatok.
		Ha valami furcsaságot látsz, akkor amiatt van.. :)
	</div>
	<div class="jobbketto">
		Most éppen az oldalon változtatgatok.
		Ha valami furcsaságot látsz, akkor amiatt van..
	</div>
</div>
Na ha ezen mind végigjutottunk, akkor kész is vagyunk. Meg lehet nézni a végeredményt. Persze pár szemfüles olvasó bizonyára észreveszi, hogy a CSS-ben van pár megjelenést módosító definíció, de ezeket már az előttem szólók úgy is elmagyarázták, így én nem tettem.

Megjegyzések

  • Az elnevezésekkel jó vigyázni. Ahogy az előbb is írtam: most úgy hívjuk az egyik dobozunkat, hogy balketto. Ha ezt egyszer csak szeretnénk átrakni a jobb oldalra, akkor azt ugye a HTML kód változtatása nélkül tisztán a CSS módosításával is meg tudjuk tenni. Pár position:absolute; top:valami; right:valami; meg is oldaná. Például a CSS Zen Garden oldalán 500 különféle design van hozzárendelve egyetlen HTML oldalhoz. No ilyenkor félrevezető lehet, hogy balketto-nek hívunk egy jobb oldali boxot...
  • Ez a design jól néz ki 1024*768 és annál nagyobb felbontásban Explorerrel, Firefoxxal, Operával. 800*600-on tűrhető a Exploreren kívül mindegyikkel. Az Explorer 800*600-on eltünteti vagy megtöri a jobbsáv és a középrész közötti sötétszürke csíkot (a kozepresz border-jét). Ezen nem aggódtam annyira, mert tudom, hogy a lapot 10-15%-ban nézik 800*600-on és ennek kb. 50%-a Explorerrel. Nekik meg úgy kell. De még úgy se olyan csúnya.
  • Az oldal kialakítása során abszolút pozícionálást alkalmaztam. Másképp is meg lehet oldalni egy oldal felépítését, sőt, egy adott design kapcsán lehet, hogy abszolút pozícionálással nem is fogjuk tudni megoldani a feladatot. Hasznos tippekkel szolgálhat az In search of the One True Layout cikk, mely egy olyan megoldást kíván nyújtani, mely a legtöbb feladatra ráhúzható.

Tanácsok táblázatnélküli oldalak létrehozásához

  • Először rajzoljuk le magunknak, hogy mit szeretnénk legyártani.
  • Rajzunkat fordítsuk le a CSS nyelvére valahogy így: "Egy három oszlopos oldalt akarok, amin a fejléc a középső oszlop része", vagy mondjuk: "Egy teljes szélességet lefoglaló fejlécet és alatta egy három oszlopos lapot akarok". Ez segíteni fog az alap HTML összerakásában, és a fő dobozok beazonosításában.
  • Ezután készítsünk egy HTML file-t, amiben még nincsen semmi, csak a fő divek. Ennek valahogy úgy kell kinéznie mint a "A kiindulási alapként szolgáló HTML kód összeállítása" részben csináltuk itt. Más szavakkal ez azt jelenti, hogy lesznek olyan divek amikben nincsen más tartalom, csak másik divek.
  • A CSS-ünket először design nélkül, csak az oldal felépítésére koncentrálva kezdjük el. Vagyis nem kellenek betűk, szinek, stb, hanem csak position, float, stb elemek.
  • Ezután szépen építkezve fejlesszük a HTML-t és a CSS-t egymás melett, először egy-egy elemet teljesen elkészítve (pl. balsáv) és utánna tovább a többi elemet.
  • Legyünk óvatosak a fix szélességek használatával. Pl. egy 200px széles divben elhelyezhetünk egy 190px széles képet/táblázatot, de a padding és a border értékek miatt lehet, hogy nem fog elférni. Az Explorer biztosan hibásan jeleníti meg, a többi böngészőnél is nem várt hatásra számíthatunk ha pl. a 190px széles képünket betesszük egy 200px széles divbe aminek 15px jobb és baloldali paddingja van.

A szerk. megjegyzése: A cikkhez ajánlani tudom a Miért butaság a táblázatos szerkezet című prezentációt, ha még nem látta valaki. A cikk képének egy részét is innen kölcsönöztük.
 
rrd arcképe
rrd
rrd 1998 óta foglalkozik webes fejlesztéssel. A HTML-től indulva először a PHP majd a JavaScript felé fordult. A mobil tech előrelépésével belekóstolt az Android fejlesztés világába is.

Nagy rajongója a CakePHP, a jQuery, a Prototype, és a Scriptaculous keretrendszereknek, az open sourcenak, és a pizzának. Mindezek folyamatosan jelen vannak a webes munkáiban.
1

BR helyett UL, LI

Fekete Ferenc GDA · 2005. Dec. 4. (V), 22.28
a sok br-t pedig kiválthatnád ul li-vel.
grat a cikkhez:)

Fekete Ferenc
2

Érdekes...

Anonymous · 2005. Dec. 4. (V), 23.45
Az a b-tag ott a példában valami Keresd a hibát játék része, vagy a szerző nem ismeri az xhtml-t? Kicsit sánta nekem ez a cikk, bocs...
3

Mit javasolsz?

Bártházi András · 2005. Dec. 5. (H), 00.33
A cikkben szereplő példák én úgy látom, hogy nem XHTML, hanem HTML kódok. Egyébként jó ötlet, játsszunk keresd a hibát a játékot! :) Te hogyan oldanád meg az adott részletet, és miért úgy oldanád meg?

-boogie-
4

fejlécek, listák

Hojtsy Gábor · 2005. Dec. 5. (H), 00.40
Szerintem a példákban nagyon jól megfigyelhetők, hogy sokhelyütt <b> elemet használ a szerző a láthatóan fejléc szerepű szövegekre (Audió blog / Podcasting, Elérhetőségeim, Fontos honlapok stb). Ezekre kérdés nélkül fejléc jelölőt kellene használni, szerintem ez nem lehet vita tárgya.

Másrészt furcsa, hogy a podcast listát valóban HTML listákkal írta le a szerző, a régebbi bejegyzéseket viszont nem. Ez eléggé értetlenül hagy, olyan, mintha a podcast listát valami más állítaná elő...

Végülis hogy pozitívumot is kiemeljek, nekem örömet okoz, hogy megmutatja valaki, hogy nem kell XHTML a táblázat nélküliség eléréséhez, ez sokak téveszméjét oszlathatja el. Ha jól csinálják.
7

html / xhtml

rrd · 2005. Dec. 5. (H), 10.53
:) mondjuk úgy, hogy az ember összerak valamit xhtml-ben. Aztán a user (akinek persze elképzelése sincs az xhtml és a html fogalmairól) elkezd bele szerkesztgetni. És akkor lesznek furcsaságok.

Másrészt meg vannak részek amit a freeblog generál le, olyan formátumban amilyenben.

De kösz a kritikát, jogos :)
5

800*600

KergeKacsa · 2005. Dec. 5. (H), 02.09
Viszont azért egy webmester nem állhat úgy hozzá, hogy nem érdekel a 800*600-as IE-sek nagy része. Rengeteg ember (főleg munkahelyekről, iskolákból) netezőknek ez van, nem tud változtatni.

Én is szívok eleget ezzel, de sajnos ez van, igenis 800*600 és afelett, MINDEN böngészőre pöpecül kell megcsinálni az oldalt...
6

Saját oldal vs megrendelt meló

Jano · 2005. Dec. 5. (H), 02.57
Nem derült ki számomra egyértelműen, hogy saját oldal, vagy valakinek megrendelésként készült. Saját oldalán mindenki azt csinál és olyan böngészőkre, felbontásokra optiamlizál vagy nem optimalizál ami neki jól esik.

Megrendelésre dolgozáskor más a helyzet, ott nem lehet alaptalanul ráfogni, hogy már pedig ha ez nem megy akkor így jártak. A cikk szerzője is kiemeli azonban, hogy az oldalhoz tartozó statisztikák alapján azt állíthatja, hogy adott oldalon nem érint sok embert.
8

800*600

rrd · 2005. Dec. 5. (H), 10.57
Nem volt igény, hogy 800*600-on IE alatt jó legyen. Sőt ha megnézed a végleges oldalt a fejléc grafika ki is nyírja a 800*600-ra tett erőfeszítéseket. Meg hát nem egy kereskedelmi oldal, hanem egy blog. Én sem szeretek senkit kizárni abból,hogy kényelmesen megnézhessen egy oldalt. De amit a "megrendelő" akar végül az lesz a döntő.
38

még valami...

connor · 2005. Dec. 10. (Szo), 04.33
Plussz hozzátenném hogy ha megrendelésre de intranetre készül még akkor is van lehetőség néhol kikötni a böngésző típusát/verzióját.

--
connor
9

Újrakódolás

ballor · 2005. Dec. 5. (H), 12.01
Nekem nagyon tetszenek az olyan leírások, ahol egy már meglévő, működő lap átkódolásáról van szó. Láttam már ilyet talán a Jano oldalán, ahol az Index felső menüjét oldotta meg a CSS lehetőségeit figyelembe véve. Lehetne több ilyen cikk. Jó volt ez, megérte elolvasni.

Egyébként a 800x600-as felbontást nem lehet lenézni. Tényleg sokan neteznek így. Mindenképpek szükséges, hogy az oldal ezen is jól mutasson és ne jelenjen meg alsó gördítősáv.

Azt meg el kell fogadjuk (mert mást nem tehetünk), hogy az IE eléggé érdekesen dolgozik. Majd az új? Meglátjuk...
10

800*600

Anonymous · 2005. Dec. 5. (H), 12.20
Egy napi több, mint 2000 látogatót vonzó honlapot üzemeltetek, statisztikázásra a Google Analytics-et használom, amely képes a felhasználók képernyőfelbontását is naplózni.

A statisztikák szerint a netezők 18,5%-a még 800*600-as felbontást használ, a többiek ettől nagyobbat. (640*480 aránya elenyésző, 0,2%)

18 százalék még elég jelentős mérték, ezért egyetértek a korábbi hozzászólásokkal: sajnos egyelőre a kisebb felbontással rendelkezőket is figyelembe kell venni a sablon tervezésénél. Ez néha korlátokkal jár, de ez van.

Üdv: Laci
11

egyedi webhely statisztika

Hojtsy Gábor · 2005. Dec. 5. (H), 12.33
Nos, az, hogy nálad milyen értékek mutatkoznak még nem jelenti azt, hogy máshol is. Az utóbbi egy hét adatai alapján például nálunk a látogatók 44.70%-a Firefoxot használt, míg második helyen van az Internet Explorer 43.54%-kal. Abban biztos vagyok, hogy ebből nem lehet általános következtetéseket levonni. Mindenkinek a saját statisztikái alapján kell megítélni, hogy mibe fektet energiát. Apropó, nálunk a 800x600-as felbontás az 7.34% ugyanerre az időszakra.
12

Analytics

Jano · 2005. Dec. 5. (H), 13.06
Google Analytics képes azt is megmondani, hogy böngésző verzió és felbontás hol találkozik. Ugyanis előfordulhat, hogy pl a Firefox felhasználók között nagyobb a 800 feletti, így IE felhasználók között a 800-as felbontása aránya. Nálam pl egész oldalra nézve 35% IE, de 66% a 800-asok között. Egyébként nálam 6% mindössze a 800x600 de ez egy webfejlesztőknek szoló lap.

Statisztikáknál még arra kell figyelni, hogy csak akkor építhetünk az adatokra, ha az oldal azon a felbontás, böngészőn használható is. Láttam már olyat, hogy valaki azt mondta, hogy Firefoxos látogatóm alig van, aztán kiderült, hogy oldal FF alatt szét esett.

Ez mondjuk a jövőre tetintettel lehet igaz, ha azon gondolkodunk PDA vagy mobil eszközöket akarunk-e figyelembe venni. Tyúk vagy tojás esete.
13

deejayy.hu

Anonymous · 2005. Dec. 5. (H), 14.00
mondjuk az meg vicces, hogy azt mondjak "a felhasznalok 18% hasznal csak operat, arra minek fejlesszunk?", de ha arrol van szo, hogy a 800x600-ban IE-vel nezok aranya 18%, egybol mindenki mashogy all hozza.

nem fura ez egy kicsit?
15

Opera 18%?

Anonymous · 2005. Dec. 5. (H), 15.37
Azért az Opera nem áll ilyen jól... SZVSZ sokkal többen használnak IE-t 800x600-ban, mint Operát bármilyen felbontásban.
22

Ha ezt vki mondta volna, akkor is más...

Anonymous · 2005. Dec. 6. (K), 23.01
... mert egy Operát le lehet cserélni Ff-ra, egy 800*600-at meg csak sok pénz befektetésével lehet 1024*768-ra vagy nagyobbra. Egyébként Operára nem kell annyit külön fejleszteni, mint egy másik böngészőre, amit most nem mondok, mert mindenki tudja h mire gondolok, szócsatázni meg nem akarok...
51

<Nincs cím>

Anonymous · 2006. Feb. 22. (Sze), 13.09
Azért az úgy nem igaz, hogy a 800x600-nál magasabb felbontáshoz csak befektetés szükséges. Ez csak afféle arrogáns, szakmai soviniszta álláspont.

Nagyon sok embernek gondja van a nagyobb felbontással, mert nem bírja elolvasni. A nagyobb monitor se megoldás, mert az emberi szem által fogható látószög is egy természetes korlát, tehát egész nap bólogatnia kell, hogy át tudja tekinteni a képernyőjét.

Nekem nagyon sok olyan felhasználóm van, akiknél 800x600 képpontra kell fejleszteni (nem csak webes dolgokat), és ebből nem engednek.

Kicsit olyan ez a kérdés, mint kb. tíz évvel ezelőtt a DOS-os alkalmazások voltak. Sokan azt mondták, hogy aki Windowst akar, az írassa újra az alkalmazásait. Aztán meg azért cikizték az embert, hogy DOS-os gépeket üzemeltet. És aki hajlandó volt ezeket a programokat karbantartani, az egyre keresettebb volt.
28

Opera

Anonymous · 2005. Dec. 7. (Sze), 20.08
Véleményem szerint az Opera a legkiemelkedőbb, a három legnépszerűbb böngésző között. Nem feltétlenül statisztikára gondolok, hanem használhatóságra, a megoldásokra, és a funkciókra.
14

Render

Anonymous · 2005. Dec. 5. (H), 14.03
A táblázatokat csak akkor tudják a böngészők helyesen megjeleníteni ha már beolvasták a </table> jelet. Addig meg nem. Ez sokszor azt jelenti, hogy a böngésző tölt és tölt, mi meg nem látunk semmit. Még szélessávnál is zavaró, nem beszélve a modemes internetről.

Ez ti. nem igaz, hisz pl. a gecko és az opera motorja is más-más progressziv renderelő algoritmust használ. Ezen persze lehet vitatkozni, hogy jó-e, de ezen böngészők filozófiája is más mint az IE-nek.
16

Statisztikák

suexID · 2005. Dec. 5. (H), 20.43
Elnézést mindenkitől, a 2. hozzászólást én követtem el, de akkor még név nélkül. Én úgy tudtam (javítsatok ki, ha tévedek), hogy a HTML 4.01-ben a b tag helyett a strong használatos. Nyílván ez igaz az XHTML minden verziójára is. Abba pedig már nem akartam külön belekötni, hogy miért nem h1..h6 elemek valamelyikével oldotta meg a szerző a dolgot.

A statisztikákhoz kapcsolódva: a statgép áílltása szerint a napi 80-100 egyedi találatot számláló blogomat jórészt 1024x768-ban nézik, azon belül a színmélység változó. Ennek ellenére én igyekszem 800x600-ra optimizálni, mert még emlékszem, mikor 1-2 éve vízszintesen is scrolloznom kellett, ha némelyik lapot meg akartam nézni. De ez valóban olyan dolog, amit mindenki a saját belátása, és a látogatóinak szokásai alapján kell eldöntenie.
17

b vs. strong

Bártházi András · 2005. Dec. 5. (H), 20.59
A b és a strong elemek közötti különbség "szemantikusságukban" rejlik, mind a kettő használata szabványos. A b elemről a következőt írja a szabvány:

The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets.
Vagyis még csak nem is "lejárt"-nak minősítettek, bár sokkal inkább a CSS-t javasolják a betűk vastagítására. A strong elem akkor használandó, mikor valamit ki szeretnél emelni, de itt nem a megjelenésről van szó, hanem az adott szöveg hangsúlyozásáról, fontosságáról. Az egy dolog, hogy erre a böngésző a vastag betűket használja - egy felolvasószoftver hangsúlyosabban, hangosabban fogja mondani (ellentétben a b-vel, amit bár lehet, hogy feldolgoz, de mégsem az a jelentése, hogy hangsúlyos, hanem hogy vastag). Az XHTML és a HTML között ebben az értelemben nincsen különbség.

A h1..h6 elemek hiányába pedig tessék belekötni, arról szól ez az egész oldal, hogy mindannyian okosodjunk, beleértve a cikkek szerzőit is.

-boogie-
18

IE vs Opera

Anonymous · 2005. Dec. 6. (K), 00.50
Sziasztok!

A cikket érdeklődve olvastam - mivel tanulgatom a CSS-t.
Kipróbáltam a leírésa alapján a kódokat.
A Dreamweaver code and design nézetében látszik minden, az Operában is, az IE-ben semmi hatása a css-nek. Valamit én rontotam el?

Üdv, Imre
23

IE vs CSS

tudor · 2005. Dec. 6. (K), 23.39
Válaszolok magamnak:
Igen, én voltam figyelmetlen, én rontottam el a CSS-t.
Javítás után az IE-ben is működik.
Kösz a cikkért, én várok még továbbiakat is - hogy tanuljak.

Üdv és kösz: Imre
19

már kellett

docker · 2005. Dec. 6. (K), 01.51
Üdv!

Már régóta vártam ezt a cikket. Nekem éppen ebből az okból kifolyólag nagyon tetszett. Amikor elkezdtem érdeklődni ez iránt a technika iránt akkor még sajna nem volt ez, de sebaj mert közben megtaláltam a csszengarden-t (amit mindenkinek ajánlani tudok, aki tovább akar mélyedni a css-ben).
Kérdés: gugli is figyelembe veszi, hogy a tartalom előbb van-e a kódban?
20

tartalom előbb a kódban

rrd · 2005. Dec. 6. (K), 10.23
Nem tudom, hogy a google hogyan optimalizál, de biztosan figyelembe veszi. Ha jól tudom a google jobban súlyozza, hogy hány másik oldalon szerepel a link.

Másik szempont, hogy a tartalom előbb legyen mint a navigációs elemek az a feolvasószoftverek. Ugye, ha egy vak emberke olvasgatja az oldalakat akkor biztos unalmas neki 17-szer végighallgatni a menüt. Ezt azért nem írtam bele a cikkbe, mert nem tudom, hogy valójában hányan használnak ilyen felolvasóprogramot.
21

Nem is lényeges

suexID · 2005. Dec. 6. (K), 20.21
Szerintem nem lényeg, hogy hányan használják a felolvasószoftvert. Optimalizálni kell arra is, mert a vak ember nem tehet arról, hogy ilyen szorult helyzetben van és nem is tud rajta változtatni. Míg mondjuk a prosztó gyerek tud IE helyett Firfeoxot telepíteni, a vak nem tud szemet varázsolni magának.
27

google optimalizálás

rrd · 2005. Dec. 7. (Sze), 17.56
Itt el lehet olvasni az irányelveket: http://www.google.com/intl/hu/webmasters/
24

Előrébb van

Anonymous · 2005. Dec. 7. (Sze), 00.12
Azt ugyan én sem tudom, hogy a keresők hogyan súlyoznak, azt viszont kipróbáltam, hogy a felolvasószoftverekhez hasonlóan a parlagi text módú böngészőkben (pl. lynx, links) is a cikkben leírt sorrend látszik helyesnek (azaz tartalom után a menük a div-ekben).
Ezek a böngészők ugyanis nem ismerik a css-t, a div-ekkel pedig általában sima bekezdésként bánnak. Ergo ha a lényeges tartalom van elöl, akkor a lényegi szöveget kapják ők is.

Kérek mindenkit, ne hördüljön fel égig zendülően, hogy "ki használ még text böngészőt". Néha rákényszerül az ember, és olyankor áldás, ha ki lehet igazodni egy ultramodern weboldalon is...

Rrd, gratulálok a cikkhez, nagyon tetszett.

vonbraun
25

szöveges böngésző

rrd · 2005. Dec. 7. (Sze), 12.10
Én szoktam néha használni links-et. Amennyire tudom sokan mások is. Ez csak az Ablaxot használóknak tűnik olyan borzasztónak. :-)
26

<Nincs cím>

Anonymous · 2005. Dec. 7. (Sze), 12.57
Ablax..... Ez naggyon jóóó! :)
29

mefi

mefi · 2005. Dec. 7. (Sze), 20.20
Kedvenc operációs rendszerünk :)
30

Text based browser

presidento · 2005. Dec. 8. (Cs), 15.14
Néha nekem is az jut, de sajnos a Weblaboron es a Gmailon kívül nem sok olyan oldal van, ami rendesen használható.

FARKAS Máté
44

A "lényeg"

yaanno · 2005. Dec. 21. (Sze), 15.54
ha a lényeges tartalom van elöl, akkor a lényegi szöveget kapják ők is.

Jó, de ne a dizájner stb. akarja megmondani, hogy mi a lényeg. A navigációs elemek éppen olyan fontosak, mint a tartalom, mert ezek segítik az eligazodást egy oldalon. Szerinted mely elemeket könnyebb átugrani, a navigációt vagy a tartalmat, ha csak a felolvasószoftver alapján tudsz tájékozódni? Ebből a szempontból bizony, hogy a navigáció, keresés (a tájékozódást segítő funkciók) az előbbrevalóak. Persze a dolog rövidre zárható azzal, hogy a csak text alapú böngészők számára (vagy css-t nem figyelembevevők számára) készítesz egy dobozt, amiben a "Skip to ..." jellegű linkek vannak. Ha a cikkben ismertetett módon építed az oldalt, akkor ez a doboz kötelező :)
31

fejléc

Anonymous · 2005. Dec. 9. (P), 12.50
.fejlec img{width:100%;max-width:550px}

Ezt a sort kell hozzáadni a középrész elemeihez, hogy a fejléc-kép átméretezze magát. Fx-ben müxik, másban nem néztem. Az egyetlen gond vele, hogy az átméretezést a böngésző nem éppen profi képfeldolgozó módjára teszi, ezért kicsit pixeles lesz, de még mindig jobb, mint hogy ne látszodjon a vége.
32

Trükk

Jano · 2005. Dec. 9. (P), 13.00
Az is egy trükk amikor minél nagyobb felbontásban nézi az ember a lapot annál több látszik egy grafikából. Ha jó a kép akkor ez abszolút nem tünik fel.
33

<Nincs cím>

Anonymous · 2005. Dec. 10. (Szo), 00.31
Jó a táblázat. Érthető és könnyen módosítható. Nem kell divatmajomnak lenni. Cross-browser kompatibilitást úgyse lehet másképpen elérni. Mondjuk egy olyan projekt ahol IE 5.5 Netscape 6.0 a minimum követelmény ott elvérzel a csoda css oldaladdal.
34

Jajj

Bártházi András · 2005. Dec. 10. (Szo), 00.41
Hát nem tudom, én simán megcsináltam az IE5.5/Netscape 6.0 támogatást, ahol kellett - táblázatok nélkül. Rég volt. Ezzel az állásponttal utoljára két éve találkoztam. :) Elismerem, hogy van néhány téma manapság, ami divat, ez viszont korántsem az.

Ha valakinek van kedve, majd leírja a CSS alapú oldalkialakítás előnyeit, nekem már nincs. :)

-boogie-
35

<Nincs cím>

Anonymous · 2005. Dec. 10. (Szo), 01.07
Pixelpontosan? Grat! Gondolom nem volt túl bonyi az oldal :)
36

Elég jól

Bártházi András · 2005. Dec. 10. (Szo), 01.12
A web nem a pixelpontosanról szól. Amúgy elég közel voltak egymáshoz, igen. Erről az oldalról van szó: http://magyarorszag.hu. Szerintem is egy egyszerű oldal. Mondjuk azóta nem tudom, milyen állapotban van, de nem sok embert hat meg szerintem, ha szétesik az általad említett böngészőkben. Amit látsz táblázatot benne, az nem a layout miatt ilyen, hanem mert a CMS nem tudta, csak a táblázatos megvalósítást. De az egyes részei jól megvannak táblázat nélkül.

-boogie-
40

<Nincs cím>

Anonymous · 2005. Dec. 10. (Szo), 20.30
"A web nem a pixelpontosanról szól"

Na ezen rögöhtünk vagy fél órát. Probáld ezt eladni egy nagy corporate szintű megrendelő designerének :D Te sza(g)kértő LOL

Tibi
41

Hát pedig

Bártházi András · 2005. Dec. 11. (V), 02.49
Gúnyolódhatsz, de tényleg nem a pixelpontosanról szól. Megnézem, hogy mikor lesz pixelpontosan ugyanaz az élmény nekem egy Mac-en, ahol nincsen meg ugyanaz a betűkészlet, vagy Firefox-on, ahol a user direkt átállítja a betűméretet eggyel nagyobbra. A többi téren tényleg törekedni kell arra, hogy jól nézzen ki, illetve hogy "pixelpontosan" úgy nézzen ki, de én úgy gondolom, hogy a felhasználói élmény sokkal fontosabb, mint egy hülye designer gondolatai, és hogy vannak más szempontok is, mint a designer által megálmodott design. És ezt el is szoktam adni az ügyfélnek, és nem a designerének. Ez nem azt jelenti, hogy nem tudok megcsinálni valamit olyanra, amilyenre a designer megálmodta, sokkal inkább azt, hogy van, amikor jobb megoldást tudok nyújtani, mint amit a designer megálmodott. Persze vannak jó designerek is, akik értik a munkájukat, sajnos viszont pont a "nagy corporate szintű designerek" nem szoktak ilyenre sikeredni. :(

Egyezzünk ki abban, hogy én tök jól elvagyok ezzel a filozófiámmal, nektek pedig más a filozófiátok. És örülök, hogy a Weblabor (vagy én) szórakoztató szerepet is betölt, és vidám perceket szereztem számotokra. Majd még mondok ilyeneket, és mindenki boldog lesz. :D

-boogie-
42

Engedd meg, hogy gratuláljak

suexID · 2005. Dec. 11. (V), 09.18
Engedd meg, hogy gratuláljak értelmes, a témát emelő hozzászólásaidhoz. Nagyon bírom az olyan embereket, akik nagy szavakkal dobálóznak és még csak arra sem képesek, hogy legalább a nickjüket adják hozzá.

Először is, a "nagy corporate szintű megrendelő designere" kicsit furcsán hangzik egy magyar ember szájából, nemde? Ráadásul legjobb tudomásom szerint elég ritka, hogy a grafikai tervezés (vagy trendin fogalmazva designolás) és az oldal összepakolása (sitebuild) két külön cégnél történne. Azt pedig még nehezebben tudom elképzelni, hogy 2 ugyanazon cégnél dolgozó ember (1 grafikus és 1 html kódoló) ne tudná az ilyesmit megbeszélni.

Másik érdekes dolog, hogy IE 5.5-ről és Netscape 6-ról beszélsz. Nem tudom te mikor jártál utoljára a neten drága barátom, de a Netscape 6 akkora bukás volt a maga idejében (pár éve), hogy öröm volt nézni. Az IE 5.5-öt meg szinte senki nem használja, helyette van IE 6.

Szeretnék gratulálni azokhoz a megrendelőkhöz, akik tőled azt várják el, hogy IE 5.5 alá optimalizáljál, sok hasonló embert kívánok még neked!
43

Sajat terulet

Jano · 2005. Dec. 11. (V), 12.36
Ezen en mindig csodalkozom, hogy ha a HTML koder "nevem Kuss" modban tevékenykedik es minden szart lenyel és sziv egy-egy design részleten.

Más területeken a különböző szakterületek ismerői együtt dolgoznak, közöttük kommunikáció van és közösen próbálják meg a felmerülő problémákat megoldani és betartják a másik oldal hatarait.

Persze néha sokkal kényelmesebb behúzni a fejet és csak összerakni úgy ahogy kaptad, mert akkor nem kell senkit győzködni, nem kell lefutni hülye engedélyezési köröket.

Néha viszont nem is kéne köröket futni, mert vannak abban a grafikus által elkészített psd fájlban olyan részletek amik egyáltalán nem fontosak (ha rákérdezel a grafikusnál azt mondja: "ja azt csak oda dobtam"). A logó, a fejléc grafikája, a szín kombinációk mind mind betartandók, dehogy mondjuk a menüben egy kis piszoknyi elem 1px-lel odébb van az senkit nem fog zavarni. Persze ha tudom én is oda helyezem, de ha tudok egy egyszerűbb módszert ami mondjuk több sornyi HTML koddal könnyiti mg az oldalt és ez 1px-be kerül akkor azt fogom preferálni.

Abban különbözik a véleményünk és azért nem tudod értékelni a CSS előnyeit, mert neked egyedül az szempont, hogy a kapott psd-t pixelre leképezd és letöltési méret, idő, elérhetőség, használhatóság, kereső optimalizáció stb pontok nincsenek az értékelési listádon. Ezekutan nincs mirol vitatkozni. Kb annyi a kulonbseg mint amikor valaki kurvahoz jar vagy inkabb baratnot keres. Elso esetben csak egy celja van...
39

pixelpontosan?

rrd · 2005. Dec. 10. (Szo), 13.55
Hm. Anonymous! Mit szólsz ahhoz, ha azt mondom, hogy bármilyen általad gyártott táblázatos oldalt megcsinálok css-sel táblázatok nélkül, úgy hogy jó lesz minden nagyobb böngészőben?

Ha akarod veheted kihívásnak. :-) Bár hozzátenném, hogy ezt a két böngészőt mintha követte volna már pár újabb verzió nem? Megnéztem most pár statisztikát pár oldalunkról. Netscape 7 alatt 0 felhasználó volt, IE 5.5 meg 0,56%.
37

Forgalom

Jano · 2005. Dec. 10. (Szo), 02.15
Mondok egy indokot amit igen kevesszer szoktak felhozni:

Volt itt nemrég egy amerikai fizetésekről szoló cikk, meg egy olyan megjegyzés, hogy bizony ez a meló amit mi csinálunk teljesen megfelelő távmunkára is és azok a fizetések amik olyan nagy számokat tartalmaznak akár valóság is lehet mindenféle kiköltözés stb nélkül.

Ott kint az a divat, hogy nem csak a tárhelyért, szerver elhelyezésért fizetsz, hanem a látógatóid által letöltött forgalom után is. Ezért ott egy fontos tényező, hogy az oldal milyen méretű. Tapasztalati tény, hogy táblázatok elhagyásával CSS-sel jelentős forgalom csökkenés érhető el, ami dollára váltható kiadás csökkenést jelent.

Tehát olyan embert aki táblázatokkal kodól nem fognak alkalmazni. Tehát ha te egyszerűen "divatmajomnak" tartod az olyan embereket akik megtudnak felelni a fenti követelményeknek, akkor te nem fogsz annyit keresni mint ők.

Egyébként érdemes lenne néha emberek közé menni, elolvasni a szakmai híroldalak, cikkeket, megpróbálni végig gondolni, kipróbálni az ott látott módszereket, megnézni néhány profi által készített CSS-sel készült oldalt és utána megnyilvánulni.
45

css listat keresek

Anonymous · 2005. Dec. 22. (Cs), 23.45
hali

tetszettek a cikkek :) az nem tetszik, hogy a nekem eppen most jol jovo dolgokat nem tamogatja (meg) az ie :( de errol nem a cikk irok tehetnek :)

keresek olyan levlistat, ahol feltehetem css kerdesimet. elsosorban tablazatok kivaltasarol van szo, csak a net olyan pedakkal van teli, ami oszlopokkal mahinal, nekem a sorokkal van bajom.
(pl fofejresz + tablafejlec + tablatorzs + tablalablec
de ugy, "sose legyen" (na jo, extremre osszenyomom, akkor persze lesz) fuggoleges gorgetom csak a tablatorzson (overflow: auto) es a fejreszek meg a lablec az albak (canvas?) tetejehez, aljahoz illeszkedik.
Nu, ez nem akar osszejonni sehogy :( )


Pötyös
46

Nem értem

Jano · 2005. Dec. 23. (P), 13.00
Nem egeészen értem mit akarsz mondani de:

1) Táblázatok helyett csak akkor kell mást használni, ha nem táblázatos adatról vanm szó, hanem a table, td stb elemek csak azárt kerülnek bele a kódba mert a designt úgy könnyebb kialakítani. Amit excelben csinálnál az HTML-ben is táblázat, amit Photoshopban az CSS.

2) CSS-sel foglalkozo lista van. Keresd a Weblabor fejleceben a levlistakat.
48

table without table

akosbacsi · 2006. Jan. 11. (Sze), 01.23
Meg lehet oldani táblázatos adatok megjelenítését is table nélkül csak css-el, de én is azt javaslom, hogy arra használjuk a table-t és a css-t amire való, ahogy Jano írta.

A cikk teccett nagyon.

üdv,
akosbacsi
47

Safari

babem · 2006. Jan. 2. (H), 02.30
Hali
Nagyon tetszett a cikk, amúgy OsX-es böngészőkön is teszteli valaki a css-eket?
Safari, Opera, Camino, Shiira
49

css vs. table

Anonymous · 2006. Feb. 2. (Cs), 11.50
Szükségem lenne egy olyan felépítésre, ami kb. így nézne ki:

<--grafika :: -----fix szélességű content----- :: grafika-->


Tehát nem elég 1 fő rész középre, hanem 3 oszlopos felépítés kéne. A két szélső column egyforma szélességű, viszont nem lehetnek fix szélességűek. Ezeknek mindig igazodniuk kéne az aktuális ablakmérethez, nyúljanak vagy épp csökkenjen a szélességük ennek megfelelően. A középső rész fix szélességű, és teljesen középen van.

A szélső oszlopokban konkrét tartalom nem lenne, viszont a grafikákat be lehet pakolni fix és jobbra/balra pozícionált háttérnek, ekkor szépen eltűnnek a két szélen, ha az ablak keskenyebb.

Ez táblázatos megoldással nem téma, viszont css-sel eddig nem jöttem rá, hogyan lehetne értelmesen megcsinálni. Van valakinek ötlete?
50

css-ben 1 sor

Jano · 2006. Feb. 2. (Cs), 13.06
Valoszinuleg a megoldas annyi, hogy a hatteret egy nagyon szeles kepken keszited el, amin rajta van a kozepso oszlop hatterszine, es a 2 oldali grafika is. Ezt aztan a body-nak beallitod hatterken, vizszintesen kozepre pozicionalva es fuggolegesen ismeteltetve. Szerintem igy van itt a weblaboron is.

background:white url(oldalhatter.png) repeat-y center top;
52

CSS

Anonymous · 2006. Feb. 22. (Sze), 15.17
Igazán remek írás, egyszerű, átlátható és mégsem primitív.

San
53

?

nyta · 2006. Feb. 22. (Sze), 17.22
Tényleg jó cikk.
A honlapszerkesztőm is div-ekkel dolgozik és ezzel az a gondom, hogy firefox alatt, ha a betűméretet növelem szétesik az oldal (összevissza belóg a szöveg, szövegdoboz meg ilyenek). A cikkben található oldallal is ez a helyzet. Mit lehetne ez ellen tenni?
55

betűméret növelés

rrd · 2006. Már. 17. (P), 16.55
Hát nem sok mindent. Tilthatod az overflow tulajdonsággal (nem próbáltam), de akkor meg elvileg nem fog látszani a szöveg vége. Mivel a monitor mérete úgyis véges valami nem lesz kerek ha a user elkezd a végtelenségig betűméretet növelni. Én próbálok általában valami olvasható betűméretet választani és úgy összerakni a design-t, hogy 1-2 betűméret növelésig ne essen szét. Aztán van, hogy a megrendelő azt mondja, hogy nem érdeklik azok akik növelik a betűméretet...
56

itt jó igazán a CSS

Táskai Zsolt · 2006. Már. 17. (P), 17.17
nagyonis erőssége a CSS-nek az ilyesmi kezelése. csak okosan kell csinálni. a "zoom layout"-ra kell keresni az érdeklődőknek. én most ezt az összefoglalót találtam: http://www.stopdesign.com/log/2005/06/24/zoom-layout.html
54

kérdés

kolboid · 2006. Már. 3. (P), 00.13
yo

tetszik a cikk, abszolút egyetértek a CSS használatával, az egyáltalán nem kérdés. annyi előnye van, hogy egyszerűen nem hagyható figyelmen kívül.

a kérdésem:
miért van az (és már több css layouttal készült oldalon megfigyeltem, mint pl. itt is), hogy nem tudom kijelölni a szöveget?! szerintem ez nagyon fontos, mert sokszor szükség van egy oldalról szövegek másolására. hogy lehet elkerülni?
megnézem firefox alatt, ott minden rendben van, de ie6 alatt nincs. egyelőre az ie az uralkodó böngésző, hiába is értek egyet a firefox támogatással.
58

válasz

Anonymous · 2006. Már. 21. (K), 20.28
én nem látok ilyen problémát. Mindent ki bírok jelölni IE 6 alatt is.
59

kijelölés ie6-ban

erenon · 2006. Már. 21. (K), 21.45
Ez szerintem egy Ie bug (meglepetés lenne...), pont tegnap tapasztaltam egy másik oldalon. Egy idő után elmúlik :)
60

ie6 és a kijelölés

kolboid · 2006. Már. 22. (Sze), 10.03
lehet, hogy IE bug, de nekem nem múlik el. Valami van a kóddal, amit nem szeret az IE. Több CSS designnal készített oldalt csináltam már és ott nem jelentkezett ez a gond. A kódokat meg nem böngésztem itt. mind1
57

Fix szerkezet

Anonymous · 2006. Már. 21. (K), 20.22
Helló!
Tetszett a cikk! Az oldalamat neki is áltam átszerkeszteni ez alapján. De gondban vagyok. Egyszerű oldalról van szó: fejléc felül, alatta bal oldalt menű mellette a tartalom (a menűt és a tartalmat egy háttérrel rendelkező DIV-be ágyaztam bele).
Egyik gondom: a tartalom margin-ját beállítanám, hogy ne lógjon bele a menűbe, de a margin-left-et nem fogadja el. A margin-top meg bottom viszont működik nem értem miért (ugyanez a helyzet a vertical-align utasítással is (nem reagál rá) ). Próbáltam a DIV-ek tipusát block-ra álltani, de az sem segít. Úgy oldottam meg hogy a tartalom DIV-jének width értékét lecsökkentetttem a kívánt méretre és úgy helyezném el, de:
Második gondom: az oldalon fix méretek az uralkodók. Egyik elem sem nyúlik a felbontástól függően. Tehát az egész középen van és 1024-ben látszik két oldalt a háttér. De az absolute pocíciózással egy adott képpontra teszi a menűt és a tartalmat így nem ugyanazon a helyen van 800-as és 1024-es felbontásnál. Tehát ha az egyiket balra másikat jobbra poziciónálom elcsúszik egymástól meg a középen lévő háttér DIV-től is amibe beleágyaztam a kettőt. Az lenne az üdvözítő ha a pozicíót nem a explorer méretéhez számolná hanem a 0,0 koordináta a háttér DIV bal felső sarka lenne.
Remélem érthető voltam.
61

Saját magamnak válaszolok

Anonymous · 2006. Már. 22. (Sze), 19.03
Szóval rájöttem a dolog nyitjára! Az első gondomra nem de arra nincs is megoldás ahogy itt a weblaboron olvasgattam. Paddingal stb más trükkös megoldással kell megoldani.
A második problémámra pofonegyszerű volt a megoldás: egyszerűen a háttérként alkalmazott DIV elememre is position:absolute-t kellett alkalmazni. Persze ezzel még korántsincs vége mert középre kéne igazítani az egészet + firefoxon nem látszik a háttér DIV-em és a két sáv is egymás alá került valamiért de erre is lesz megoldás bizonyára.
62

FRAME -k kiváltása

nevergone · 2006. Május. 29. (H), 13.29
Nagy jó a cikk, igazán hasznos volt elolvasni.
Lenne két kérdésem, ami azzal kapcsolatos, hogy egy ilyen megoldással ki lehet -e váltani a frame -ket az oldalon.
Az egyik kérdés (a kevésbé fontos) az lenne, hogy meg lehet -e oldalni valahogy, hogy az egyes oldal-részeket a felhasználó átméretezze, hasonlóan a frame -khez.
A másik pedig az lenne, hogy egy ilyen felépítésű oldalon az egyes <DIV> -ek általt kijelölt oldalrészeket meg lehet -e adni linkek target -jának, vagyis oda betöltve egy adott cím tartalmát?
Egyátalán, egy CSS -es megoldással ki lehet -e váltani használhatóság szempontjából a frame -ket? Mondjuk a felhasználói átméretezés ilyenkor nem igazán fontos.
63

Nem

Jano · 2006. Május. 29. (H), 13.36
A frameknek az átméretezős tulajdonságát és egy másik HTML bekötését CSS-ből nem lehet megoldani. (Saját vélemenyem, hogy felhasználók 99%-nak fogalmas sincs arról, hogy frameket át lehet méretezni ha nicnsen letiltva, de 99% meg le van tiltva.)
64

válaszok

rrd · 2006. Jún. 13. (K), 13.28
ki lehet -e váltani a frame -ket az oldalon

attól függ miért használsz frame-t. ha azt akarod, hogy az oldal bizonyos része ne gördüljön, rögzítve legyen akkor ajánlom figyelmedbe a position: fixed tulajdonságot.

az egyes oldal-részeket a felhasználó átméretezze, hasonlóan a frame-khez.

hát megmondom, hogy én még nem láttam olyan oldalt a weben ahol az átméretezés engedélyezett lett volna. Intranetre csináltam ilyesmit (frame-mel). Ha css-sel akarod akkor talán a javascript segíthet, de szerintem nem éri meg a bonyolítást.

az egyes <DIV> -ek általt kijelölt oldalrészeket meg lehet -e adni linkek target -jának

nem, ehhez továbbra is kell egy <a name="valami">. A div nem erre való.
66

frém kontra div

loogan23 · 2006. Aug. 30. (Sze), 12.55
Üdv!

Nekem akadt egy kis problémám a position: fixed-del,
ha ezt beállítom akkor az adott div mellé nem tudok egy másikat illeszteni csak alá.

"az egyes <DIV> -ek általt kijelölt oldalrészeket meg lehet -e adni linkek target -jának

nem, ehhez továbbra is kell egy <a name="valami">. A div nem erre való"

Ennek a gyakorlati alkalmazására nem sikerült rájönnöm.
Pontosan hova is kell ez az"<a name="valami">"?:)

Előre is thx

loogan23
65

Lál

kuvéra · 2006. Aug. 18. (P), 21.27
Most lett időm elolvasni. Gratulálok, kedves prabhu. A cáfokat majd szóban elmondom :)
67

kérdés

gnagy · 2007. Ápr. 16. (H), 19.29
Az lenne a kérdésem, hogy itt is meg lehet azt csinálni, mint a framekben, hogy ha pl. a menüben rámegyek egy linkre/menüpontra, akkor a content/középső rész helyén helyén jelenjen meg? Ha igen, hogy?

Köszönöm előre is a segítséget!