SPACEHAWKS WORLDNEWS ISSUE 17
HTML

Jelenlegi kiadásunk html cikke leginkább azoknak szól, akik pár százezer hajszáluktól megszabadultak már afelett érzett örömükben, hogy más-más böngészôkben jónak induló oldaluk a legelképesztôbb módokon vetette hanyatt magát, néha olyannyira szétesve, hogy rá sem lehetett ismerni...

Mert hát ez bizony így is van. Bár végül miért is lenne a html dizájner emberke, ha minden ugyanúgy jelenítené meg az adott oldalakat, meg ha nem lennének hibák az összes böngészôben?

Ahhoz, hogy a hibák és szétesések okát megismerjük meg kell ismerkednünk (ha még nem tettük volna) a html oldalak két igen fontos alkotóelemével, hogy hogyan épülnek fel, milyen paramétereik vannak, és milyen paraméterezések okozzák, ha éppen szétesnek... Lássunk is hozzá.

A táblázat

Látszólagosan elsôs tananyag html-bôl a táblázat, könyökünkön jön ki ugye. Mindenki látott már ilyet, ha máskor nem, akkor Excelben mindenképpen, amikor tanították neki. (Jobbak persze megint nem figyeltek órán, és ôk jártak jól.) (A Frame is vicces jószág, de arra egy késôbbi cikkben fogunk majd kitérni.)

A táblázat felépítésének egyszerű alapelvei vannak, mindösszesen három tagpárból építkezik, úgy mint:

<table>
<tr>
<td>
</td>
</tr>
</table>

Használati utasításuk nem különben egyszerű: a TABLE (azaz táblázat) tagpárból csak egy van (kivéve ha a táblázatunkban található másik táblázat), ez fogja körül az egész táblázatot.

A TR (table row, azaz táblázat sor) tagpárokból egymás után annyi van, ahány sora a táblázatnak. A TR tagpárok között kizárólag TD tagok által körülzárt dolgok lehetnek.

A TD (table div, azaz táblázat osztás, cella) tagpárok a táblázat tulajdonképpeni legalsó elemei. Beléjük kerül mindaz, amit a táblázatnak tartalmaznia kell.

Láttuk mindhárom elemet. És ha táblázataink valamelyike valamely böngészôben jól szétesik, akkor általában a táblázatunkkal van "baj".

Azért van a baj idézôjelben, mert nem mindig mi vagyunk a hunyók. Lehet az is, hogy elméletileg helyesen járunk el, mindent úgy csinálunk ahogy kell, a táblázatunk mégis szétesik: ekkor valószínűleg a böngészô a ludas.

Meglepô lesz azonban amit mondok, de ez rendkívül ritkán fordul elô. (Fôképpen olyankor, amikor WYSIWYG szerkesztôben dolgozik az ember, mert azokat bizonyos böngészôk mintájára alkotják, és más böngészôkben az oldalunk még úgy széteshet, hogy öröm nézni) El kell tudnunk tehát vonatkoztatnunk attól, ahogy mi helyesnek látjuk a dolgokat, valamint attól, ahogyan a képernyôn az editorban látszik: és annak a böngészônek az észjárásával kell gondolkodnunk amelyikben az szétesett. Ami sokat és egyedül tud segíteni az a tapasztalat...

Az egyik legjobban támadott böngészô ebbôl a szempontból a NetScape. Hozzá kell tennem azonban, hogy leginkább azok támadják, akik nem tudnak benne tökéletes oldalt csinálni, akik Explorer mintájú WYSIWYG editorokat használnak, és végül azok, akik nem tudják, hogy a NetScape milyen alapon építi fel a táblázatokat.

Nehéz elhinni, de ha az ember végül megismeri a dolgot, nem fog tudni egyértelműen ellenzôi oldalára állni, mert a NetScape megjelenítési elvei legalábbis méltányolhatóak. Ugyanez fordult már elô Voyagerrel, egy oldalam mindenhol jól nézett ki, kivéve ott, a forrást áttanulmányozva azonban rá kellett jönnöm, hogy ô volt az egyetlen, aki helyesen jelenítette meg, mert tényleg hiányzott az a VALIGN tag, ahol eltolva látszott a kép...

Elsôként ahhoz, hogy szét nem esô oldalakat gyárthassunk, meg kell ismerkednünk a táblázatot alkotó tagok néhány olyan elhelyezést és elhelyezkedést befolyásoló paraméterével, amelyeket mi amigások szoktunk lefelejteni, lévén a mi böngészôinkben nem feltétlen okoz látható hibát hiányuk (néha meg de, de akkor meg úgyis muszáj beállítani), máshol viszont égig érô visítozás lesz belôle... (Ugye Napi2? Láttad te már a Napi2 oldalainak címoldalát NetScape-ben? Pedig biztos HTML3 compilant... Csak van rögtön a címoldalon egy szétesett táblázat, okulásul mindenkinek :)

TD

Haladjunk a kisebbektôl a nagyobbak felé, mert általában a TD paraméterei vannak leginkább elkeverve, vagy lehagyva. (Pedig a legfontosabbak) Ha képeket pozicionálunk egy táblázatban, hogy egy nagyobb képet kapjunk, akkor legkevesebb, hogy nem árt a következô dolgok beállítása, vagy ismerete:

colspan="X"

Azt jelenti, hogy táblázatcellánk a vízszintesen következô X cella helyén terpeszkedik majd, azokat magába olvasztva. (A "beolvasztott" TD párokat ki kell hagyni a forrásból.)

rowspan="X"

Azt jelenti, hogy a táblázatcellánk a függôlegesen lefelé következô X cella helyén terpeszkedik majd, azokat magába olvasztva.

align="X"

A táblázatcella tartalma X irányban a következô irányokba kerülhet rendezésre (anélkül, hogy ezt bent meg kellene adnunk): left (balra), right (jobbra), center (középre). Vannak egyéb X lehetôségek is, használatukat azonban nem javasolnám.

valign="X"

Ha a fentebbit be is állítjuk (ritka), ezt azonban szinte soha, pedig kellene: ez adja meg ugyanis, hogy a következô táblázatcella tartalma függôleges irányban merre lesz rendezve (feltéve, hogy a rendezéshez van elég hely ugye. Ennek működésbe lépéséhez az kell, hogy a vele egy sorban levô valamelyik táblázatcellát a benne levô dolgok magasabbá tegyék mint ezt): top (felfelé), bottom (lefelé), middle (középre). Itt sem ez a teljes választék, de én itt is csak ezek használatát ajánlom.

height="X"

A cella magassága. Na ez az amit viszont lehet használni, de NE használjuk, ugyanis nagyon sok böngészô és böngészôverzió tesz rá magasról, tehát nem kapunk ennek segítségével megbízható végeredményt. Ha egy cella, vagy cellasor magasságát kell beállítanunk, akkor mindig egy képpel tegyük, amely valamelyik cellában foglal helyet, ha pedig nem szabad látszania akkor tegyük azt egy megfelelô magasságú átlátszó gif-fel.

width="X"

A cella szélessége. Ez a táblázat adott oszlopának szélessége is az adott cellától lefelé egészen a következô colspan váltásig, vagy a táblázat végéig. Ez akkor is számít, ha az adott TD tag történetesen colspanként több cellahelyet foglal, és ugyanily colspanok az alatta elhelyezkedô cellák. Nagyon fontos az, hogy szélességben a táblázatcellák szélessége pontosan adja ki, tehát lehetôleg ne legyen se több, se kevesebb a táblázat megadott szélességénél. (A cellákban elhelyezett képek pedig ne legyenek nagyobbak.)

TABLE

Jól láthatóan kihagytuk a TR tagot, ugyanis ennek paraméterei gyakorlatilag megegyeznek a TD paramétereivel, a szélességet és magasságot kivéve, és ezen paraméterek a táblázatsor összes cellájára vonatkoznak. A táblázatnak viszont van egy-két témánkat érintô paramétere, amit itt most fel is sorolunk:

width="X"

Gyakorlatilag ô Kapitális József, azaz nem megfelelô beállításával a legtöbb hiba okozója. Elsô probléma szokott lenni az, hogy a táblázat az adott böngészô mérethez képest túl nagy. Minden tervezés elôtt mérjük le az adott böngészôben betölthetô felületet a célfelbontáson, beleszámítva az esetleges scrollbar-okat is! (640x480 felbontás mellett például a legtöbb browserben kb. 600x330 pixel látszik tökéletesen) (Nem kérjük a rossz beszólásokat, hogy "de a worldnews", a worldnewst sajna mindig elrontom, és a már kész grafikánál jövök rá, hogy szélesebb mint kellene-Emeric SH)

border="X"

A táblázat keretének vastagsága. Ma már nagyon ritkán használunk olyan táblázatokat, amelyeknek látható kerete van (kivételek a tényleges táblázatadatok megjelenítései, de ott is sokkal jobb eredményt ad két egymásba helyezett táblázat, ahol a belsônek, amely a tulajdonképpeni cellákat tartalmazza X méretű cellspacingja, a külsônek pedig, amely csupán egyetlen cellából áll szintén X méretű cellpaddingja és mondjuk fekete háttere van.)

align="X"

A szokásos vízszintes helyzetmeghatározás, úgy mint balra (left), jobbra (right), középre (center). Fontos megjegyeznünk, hogy a táblázatok csak ennek, és egy befoglaló TD vagy TR align paramétereinek engedelmeskednek!

cellpadding="X"

A táblázat minden egyes cellájának tartalma ezt a távolságot tartja a cella falától mind a négy irányban. Ez legfôképpen arra használható, hogy a szöveg ne tapadjon a cella falához, rendkívül fontos azonban odafigyelnünk arra, hogy a cellában elhelyezkedô, azt mondjuk teljesen kitöltô kép szélességéhez ezt az értéket kétszer(!) hozzáadva kapjuk meg a cella teljes szélességét!

cellspacing="X"

A táblázat cellái, a cellák és a táblázat fala közötti tér mértéke. Amikor egy táblázat sorának szélességét számoljuk, akkor azt a cellák szélességének és a cellpadding értéke szorozva a cellák száma plusz egyel összeadásával kaphatjuk meg.

A gyakorlat

Nos, immár ismerünk minden fontosabb dolgot. Hogy gyakoroljunk, vegyük a manapság leggyakoribb feladatot: egy felszabdalt képet úgy helyezni el egy táblázatban, hogy annak zsebei legyenek, amelyben akármi elhelyezhetô.

		alma alma alma alma alma alma alma alma alma alma alma alma alma alma alma alma alma alma
					alma

azaz, hogy szemléletesebbé tegyük, paraméterekkel a képek helyett:

(A táblázatban található hibákért felelősséget nem vállalok, de ha megdobsz emaillal az emeric@abakusz.matav.hu címen szó lehet a kijavításról.
Ha valamely böngészőben nagyon szét van esve akkor is szóljatok :)

A fontos az, hogy a képek, celláik, a row-ok és column-ok szélességét hajszálpontosan állítsuk be, valamint ne feledkezzünk meg semmiképpen azokról a paraméterekrôl sem, amelyeknek esetleg a mi böngészônkben nincsenek látható következményei: ilyen legfôképpenis az align és a valign minden egyes cellára, amely cella sorában vagy oszlopában nála magasabb vagy szélesebb cella fordulhat elô, valamint a cellpadding, cellspacing, table border megfelelô beállítására, mert oldalunk látogatói más böngészôkkel esetleg igen-igen érdekesen fognak visszapislogni ránk...

És akkor végül egy kicsit a problámákról...

Miért is van szükségünk arra, amit most itt megtanultunk, és miért is nem működik mindig még most sem amit megtanultunk?

Egészen egyszerű. Mert ahhoz, hogy csak így szimplán működjön, a böngészôknek is jóknak kellene lenniük. Csakhogy nem azok.

Ha csak saját, specifikus kódokat szúrnának el, nem is volna különösebb gond. De az alap HTML szabványt is képtelenek betartani, vagy inkább fogalmazzunk úgy, hogy néhol igen érdekesen értelmezik. Legjobb példa erre, hogy míg például a Microsoft Internet Explorer 5 vízszintesen kezeli rosszul a táblázatokat, addig a NetScape-nek éppen függôlegesen vannak azokkal problémái. (Ebben egyformán rosszak, csak más-máson alapulnak a hibáik. A NetScape felhasználók egyébként az Explorer hibákat, míg az Explorer felhasználók a NetScape hibákat szokták ismerni, a sajátjukról általában nem is sejtik, hogy létezik.)

A NetScape akkor "szúrja" el a táblázatokat, amikor arról van szó, hogy több cellának kellene egymás alatt folyamatosan következnie, míg mellettük egy, a két cellánál magasabb rowspan található. Ennek "gyógymódja" egyszerű, csak idegesítô, hogy gyógymódra van szükség: az adott szétesett függôleges oszloprészt szét kell szedni, belerakni egy táblázatba, majd egyetlen cellaként berakni. Az Explorernek pedig az a hibája, hogy a cella teljes szélessége és a tartalmának szélessége teljesen különbözô fogalom nála: míg az elsô képes dinamikusan változni, fôként akkor, amikor nem kellene, a második teljesen statikus. Ennek örömére szoktak olyan layoutok kialakulni, amelyek teljesen téves hibát sugallnak. (Generális falióra átültetése is lehetne, meglehet "gyakorlatlanságom" az oka, hogy teljesen triviális hibákat keresek másfél órákig, mert a megjelenített kép tökéletesen más hibát sugall, mint ami a probléma valójában.) Egyébként ezen problémákra is a cellatartalom újabb táblázatba helyezése jelenti a legjobb megoldást, csakúgy mint a NetScape legáltalánosabb hibájának esetében. Persze mindkét böngészônek (Amigás böngészôket nem is említve, a jobbakról jót vagy semmit alapon :) ezernyi más hibája, és gusztustalan stiklije is van. Így azt hiszem elmondható, egyik sem jobb a másiknál... Legalábbis technikai szinten. Nagyon különbözôek, de nagyjából ugyanannyi gyengével és hibával rendelkeznek. Amit lehet, hogy az egyiket jobban szeressük a másiknál...

Ez még hagyján is volna (van a fenéket hagyján), de Internet Explorer alatt van még egy utolsó utáni stikli. Azt hiszem egy böngészôtôl már az is vérlázító lenne, hogy az elmentett HTML hirtelen MSHTML lesz, de hogy Explorer 5 alatt egyszerű view source esetén se az eredeti HTML forrást lássuk, hanem már akkor is belebarmoljon abba az azért már - véleményem szerint - több a soknál. Persze egyre nô azok tábora, akik szerint az Explorer 5 az egyetlen használható böngészô... Saját véleményemet leírva köszönöm nem kérek belôle.

(Íme egy példa az "elötte" és "utána" tipikus esetére. Eddig nem láttam más böngészôt, amelynek pofája lett volna az eredeti forrást önkényesen megváltoztatni.) (megjegyzés: ez már egy save source eredménye, view source esetén azért valamivel finomabb a beleturkálás aránya)

ELÖTTE:

<table width="75%" border="1">
  <tr>
    <td valign="top" width="160" bgcolor="#003f6e" align="center">
      <p align="center"><a href="fot_megkoz.htm"><br>
        <img src="coraszegedfront.jpg" width="160" height="136"></a><br>
      </p>
    </td>
  </tr>
</table>

UTÁNA:

<TABLE border=1 width="75%">
  <TBODY>
  <TR>
    <TD align=middle bgColor=#003f6e vAlign=top width=160>
      <P align=center><A
      href="http://abakusz.matav.hu/sh/explodertest/fot_megkoz.htm"><BR><IMG
      height=136 src="index_files/coraszegedfront.jpg"
  width=160></A><BR></P></TD></TR></TBODY></TABLE></BODY></HTML>

Azt hiszem a különbség ég és föld. (Félreértések elkerülése végett az elötte és utána még véletlenül sem lett összekeverve.) Az utána kódrészlet a tökéletes példája annak, milyen NE legyen egy HTML kód a legújabb, XHTML-t is figyelembe vevô HTML specifikáció és ajánlás szerint, bár gondolom Microsoftékat olyasmi, mint HTML szabvány nem különösebben érdekli. Ha nem kérnék számon rajtam, hogy (az általa átvariált) kód hogyan néz ki explorerben, nem is volna igazán semmi bajom...

Összefoglalás

Egyszóval ez a cikk magában még nem fogja megszüntetni az aktív, kéz által elkövetett hajritkítást. Beszéltünk ugyan egy-két vicces dologról, azonban a stiklik özönével csak tapasztalás ismertetheti meg az embert. A félreértések elkerülése végett, mint pályafutásom ezen szakasza után ráébredtem a HTML szerkesztô és webdesigner nem azért van, hogy a felhasználó helyett dolgozzon, hanem, hogy helyettük kapjon idegbajt és agyrohamot...

Azt pedig, hogy ki melyik böngészôre és szerkesztôre fog esküdni, azt nem annak kinézete, generált kódja, könnyebb használhatósága dönti el, hanem egyszerűen csak fordítottan arányos a tapasztalat elôrehaladtának természetes velejárójaként elôforduló, adott böngészôre/szerkesztôre fordított anyázás óráinak számával... Mert nemcsak a hétköznapi programozás fejleszti a szókincset...

Végül pedig egy igen mély életbölcsességet osztanék meg veletek: Mert mind közül az a legszerencsésebb HTML szerkesztô, aki csak egyetlen böngészôt ismer... Merthogy neki könnyű, oldala látogatói helyette is anyáznak...

Emeric SH