Amikor honlapot készítünk, tervezéskor és kódoláskor számos dolgot kell figyelembe vennünk. Technikai szempontból az egyik legfontosabb tényező, hogy oldalunk látogatói milyen böngészővel és milyen beállításokkal is nézik oldalainkat – és mennyi időt és energiát szánunk arra, hogy a várható látogatókat száz százalékig kiszolgáljuk. Természetesen amikor az első oldalunkat, oldalainkat tervezzük, nem állnak rendelkezésünkre a megfelelő információk. Néhány honlap időről-időre nyilvánossá tesz bizonyos látogatói adatokat, amelyeket érdemes alaposan szemügyre vennünk.
Így például a sorozatunkban többször is említett W3Schools.com oldal – ha nem is túl gyakran frissített – adatait bármikor megtekinthetjük a www.w3schools.com/browsers címen. Innen többek között megtudhatjuk, hogy az oldal látogatói milyen operációs rendszereket, milyen böngészőket és milyen felbontású monitorokat használtak az elmúlt öt-hat évben. Számunkra természetesen leginkább az elmúlt fél-egy év adatai érdekesek, hiszen a tervezést nem igazán befolyásolja, hogy 2003-ban hányan használtak Netscape 5-öst. Ugyanakkor igenis jó tudnunk, hogy 2009 januárjában milyen böngészőket és felbontásokat alkalmaztak a felhasználók, s ezek közül melyek érik el azt a kritikus határt, amelyeket mindenképpen figyelembe kell vennünk.
A Browser Display oldalt szemügyre véve láthatjuk, hogy a monitorok felbontása folyamatos növekedést mutat. Ma már – többek között a szélesvásznú monitoroknak köszönhetően – a képernyők közel 60 százaléka 1024 pixelnél szélesebb, és mindössze a felhasználók 4-5 százaléka használ 800×600-as (vagy kisebb) felbontást. A böngészők statisztikáját (Browser Statistics) nézegetve láthatjuk, hogy a látogatók mintegy 90 százaléka a Firefoxot vagy Internet Explorert használ, míg a maradék 10 százalékon osztozik a Chrome, a Safari és az Opera. (Az adatok elemzésekor természetesen nem szabad elfelejteni, hogy a W3Schools.com-ot elsősorban valószínűleg a webes programozás iránt érdeklődők látogatják, így ha nem is alapvetően, de jelentős mértékben mást látnánk mondjuk a velvet.hu/poronty oldal látogatói statisztikájában.)
Böngészőhöz igazodj!
Számunkra ezen adatokból a leginkább az IE6 oszlopa, vagyis az Internet Explorer 6-felhasználók száma az érdekes – és ez a szám túl magas ahhoz, hogy figyelmen kívül hagyjuk az IE6 hibáit. Ugyanis amikor honlapunkat megnézzük Internet Explorer 7, Firefox, Chrome, Safari és Opera alatt, akkor minimális eltérésekkel ugyanazt fogjuk látni – ami kimondottan örömteli. Ugyanakkor, ha betöltjük oldalunkat Internet Explorer 6-ba, akkor meglepődve és szomorúan láthatjuk, hogy bizony a látvány siralmas: a menü gombjai között hatalmas lyukak, a tartalmi rész – vagyis a jobb_panel ‹div› – a menü alá csúszottan kezdődik.
Így néz ki oldalunk az Internet Explorer 6-os változatában a javítás előtt...
Sorozatunk egy későbbi részében még visszatérünk arra, hogyan tudjuk ezt szépen kijavítani, egyelőre azonban stíluslapunkban két kisebb javító „sebtapaszt” helyezünk el, hogy oldalunk IE6 alatt is többé-kevésbé úgy nézzen ki, mint a többi böngészőben, vagyis ahogyan azt elterveztük az elején.
...és így a javítás után
Először is keressük meg a CSS-ben a jobb panel és azon belül is a div#jobb_panel beállításait, és itt a szélesség értékét csökkentsük négy pixelre, vagyis a width: 738px;-t írjuk át width: 734px;-re. Most már helyére került a jobb panel, de a gombok között még mindig hatalmas hézagok vannak. Öveges tanár úr technikáját alkalmazva („kísérletezzünk és gondolkodjunk”) kiderült, hogy a nem kívánt réseket eltüntethetjük, ha a menü lista egyes elemeinek, vagyis a ‹li› címke aljára egy 1 pixel vastagságú alsó keretet illesztünk: ul#menu li { border-bottom: 1px solid #ffffff; }. A gond csak az, hogy ettől minden böngészőben megjelenik ez a fehér csík a menüpontok között, márpedig a többi böngészőben nem szeretnénk elrontani azért a designt, mert az IE6 rosszul értelmez pár dolgot a CSS-szabványban (is). Szerencsére(?) az IE6-nak vannak más hibái is, és mi most egy ilyet fogunk kihasználni. Az imént beírt sorunk elé még biggyesszük oda azt, hogy * html. Vagyis a teljes sor immáron így fog kinézni: * html ul#menu li { border-bottom: 1px solid #ffffff; }. A szabványokat ismerő böngészők ugyanis – teljes mértékben jogosan – figyelmen kívül fogják hagyni a * html mögötti részt, míg az Internet Explorer 6 – hibásan, ám ez esetben azt is hozzá tehetjük, hogy szerencsére – az ott található beállításokkal módosítja az oldal kinézetét, és így a 18 pixel magas közökből 1 pixelesek lesznek, ami ha nem is nulla, de legalább nem olyan zavaró. Mint említettük, a későbbiekben még visszatérünk a böngészők (főként a korábbi Internet Explorerek) „patkolására”, azonban jelen pillanatban bőven elegendő ez az ideiglenes megoldás.
Hosszú éveken keresztül a webfejlesztők többsége eleve úgy írta meg az oldalak kódját, hogy azok szinte csak az Internet Explorer alatt jelentek meg az eleve elvárt módon, a többi – a szabványokat nem a Microsoft-féle értelmezés szerint kezelő – böngészővel nem igazán foglalkoztak. Ez a hozzáállás a közelmúltban élesen megfordult. Ma már a kiindulási alap többnyire a Firefox vagy az Opera, és legfeljebb kisebb finomításokkal igazítják hozzá a kódot az Internet Explorer 7, a Safari vagy a Chrome igényeihez – már ha egyáltalán ez szükséges –, és nem igazán foglalkoznak azzal, hogy az oldal hogyan is néz ki Internet Explorer 6 alatt. Márpedig ezzel a potenciális látogatók akár 20–40 százalékát is elveszítheti egy honlap!
Nem szabványos célpont
Remélhetően a Weboldalkészítő iskola azon olvasói, akik korábban egyáltalán nem foglalkoztak programozással, nekikezdtek az alapozásnak, és így nem fognak kínaiul hangozni az olyan kifejezések, mint az „utasítás”, „változó”, „függvény”, „metódus”, „tulajdonság” és a többiek.
A honlapról kimutató linkek nyíljanak meg új lapon vagy ablakban
Ahogyan azt az előző lecke legvégén írtuk, első feladatunk az lesz, hogy egy szabványmódosításból eredő problémát elegánsan kikerüljünk. Azt szeretnénk ugyanis, hogy azok a hivatkozások, amelyek nem honlapunk valamely másik oldalára vagy dokumentumára mutatnak, új lapon vagy ablakban nyíljanak meg. Akik régebb óta foglalkoznak HTML-kódok írásával, erre azt mondhatnák, hogy mi sem egyszerűbb ennél: a hivatkozást leíró ‹a› elembe bele kell írnunk azt, hogy target="_blank", és már készen is vagyunk. Próbaképpen az első hírünk szövegébe helyezzünk el egy hivatkozást a PC World Online oldalára: ‹a href="https://www.pcwplus.hu" target="_blank"›lacinia quis‹/a›
A target="_blank" kikerült az XHTML-szabványból, így oldalunk elveszíti validitását
A HTML-szabványban a target attribútumot elsősorban arra találták ki, hogy a kissé divatjamúlt keretes rendszerű oldalakon megmondhassuk, hogy az egyes hivatkozásoknak melyik keretben is kell megjelennie. Az attribútum értéke az oldal egyik keretének a nevén kívül lehetett még _self (saját keretébe töltötte be a hivatkozott oldalrészt), _parent (a hivatkozás a „szülő” keretben jelent meg), _top (az egész oldalt kitöltötte az új dokumentum) vagy _blank (ahogy említettük, a dokumentum egy új oldalon jelent meg).
Ez így látszólag nagyon jó és szép, sőt, ha most betöltjük oldalunkat egy böngészőbe, és rákattintunk az lacinia quis szövegre, akkor a pcworld.hu új lapon vagy ablakban fog megjelenni. A probléma csak az, hogy az így módosított oldalunkat ellenőrizettjük a validator.w3.org programjával, akkor kiderül, hogy bizony az megbukik a vizsgán, az XHTML-ben ugyanis más nincsen olyan attribútuma az ‹a› elemeknek, mint a target.
Első próbálkozásként használjuk a szabványos "rel" attribútumot annak jelölésére, hogy a link kimutat a honlapról
Ezért most cseréljük ki a target="_blank"-et arra, hogy rel="out": ‹a href="https://www.pcwplus.hu" rel="out"›lacinia quis‹/a›
Újra ellenőrizve oldalunkat, a W3.org programja mindent a legnagyobb rendben fog találni
A rel attribútummal már semmi baja nem lesz a W3C validátorának, viszont ettől még nem fog új ablakban megnyílni a PC World Online, amikor linkünkre kattintunk. Ettől még valóban nem, de hamarosan gondoskodni fogunk róla. Ehhez természetesen egy kis JavaScript programra lesz szükség, amit – ahogyan azt múlt hónapban már megbeszéltünk – egy külső állományban fogunk elhelyezni. Ahhoz, hogy oldalunk tudja, hol található ez az állomány, egy hivatkozást kell elhelyeznünk a ‹head› szekcióban: ‹script type="text/javascript" src="js/lorem.js"›‹/script›
Az oldal inicializálását végző funkciót elindíthatnánk a ‹body› elem eseményeként – de ez nem lenne elegáns megoldás
Ezt követően – vagy akár ez előtt – hozzunk létre egy js nevű mappát, majd abban egy lorem.js nevű üres szöveges állományt. A régi „klasszikus”, ám mára már szerencsére egyre inkább eltűnő megoldás az volt, hogy az oldalt inicializáló program indításáról a ‹body› elemben, azon belül is az onload nevű eseménykezelőhöz hozzáadták a betöltődés után elindítandó funkció nevét: ‹body id="fooldal" onload="initPage();"›
De ahogyan sorozatunkban többször is írtuk, az ilyen, úgynevezett inline megoldásokat lehetőleg kerüljük – főként, hogy semmi szükség nincsen rá.
Ehelyett nyissuk meg ugyanabban a szövegszerkesztőben a lorem.js állományt, amiben eddig az XHTML és a CSS fájlokat szerkesztettük. Ahhoz, hogy lássuk, az inicializáló funkció valóban elindul, írjuk be az alábbi nagyon egyszerű „programot”:
function initPage() {
alert("initPage");
}
Majd, hogy a program el is induljon, az ablak onload eseményéhez rendeljük hozzá az initPage függvényt:
window.onload = initPage;
Nem egy bonyolult kód, de arra alkalmas, hogy lássuk, programunk valóban el fog indulni
Ha mindent jól csináltunk, akkor oldalunk következő frissítésekor megjelenik egy – böngészőnként eltérő kinézetű – dialógusablak az initPage szöveggel és egy OK gombbal. Természetesen ettől oldalunkon semmi sem változik, hiszen egyelőre inicializálás címszó alatt csak egy üzenetet küldtünk, hogy egyáltalán sikerült elindítani első programunkat. Ennek örömére töröljük ki az alert sort, és kezdjünk neki a munkának.
Ahhoz, hogy megtaláljuk, mely link(ek)et kell új lapon vagy ablakban megnyitnunk, át kell néznünk az oldalon található valamennyi hivatkozást. Ezért először is egy links nevű tömbbe betöltjük valamennyi ‹a› elemet: var links = document.getElementsByTagName("a");
Ezt követően egy ciklussal végigmegyünk a tömb összes elemén, és azoknak, amelyeknek a rel tulajdonsága out, a target tulajdonságát _blank-re változtatjuk:
for (var l = 0; l ‹ links.length; l++) {
if (links[l].rel == "out") {
links[l].target = "_blank";
}
}
Ha egy ‹a› elem „rel” attribútuma "out", akkor hozzáadunk egy „tartget”-et "_blank" tartalommal
Ha most a böngészőben frissítjük az oldalt, és rákattintunk a lacinia quis szövegre, akkor örömmel láthatjuk, hogy a PC World Online oldala új lapon vagy ablakban nyílt meg – ahogyan azt szerettük volna. És ha az oldalt megvizsgáltatjuk a W3C Validatorral, akkor láthatjuk, hogy ő sem talál semmi kivetnivalót oldalunk forrásában. Az más kérdés, hogy ha az oldal forrásába most a Firebuggal nézünk bele, akkor bizony ott találjuk az ominózus target = "_blank" részt – amiben semmi meglepő nincs, hiszen mi írattuk bele a JavaScript programunkkal.
A Firebug megmutatja a „csalást”: a JavaScripttel hozzáadtuk a target attribútumot az ‹a› elemhez
Egyszerűsítsük a HTML-t!
Sokakban érthetően felmerül a kérdés, hogy feltétlenül szükség van-e a rel="out"-ra a HTML-ben? Hiszen csak ezeknek a hivatkozásoknak az elején szerepel a href részében a http://, nem lenne elegendő megvizsgálnunk, hogy ezzel kezdődik-e a cím, és ha igen, akkor szúrjuk be a targetet? A válasz az, hogy ötlet csak látszólag jó. Mert ha kipróbáljuk gépünkön, akkor úgy tűnik, hogy működőképes az elgondolás, de amint oldalainkat feltöltjük tárhelyünkre, minden oldalra vagy dokumentumra mutató hivatkozás „http://”-vel fog kezdődni, vagyis minden egyes kattintásra – legyen az a menü bármely gombján vagy a hírek végén található Tovább linken – egy-egy új lap vagy ablak fog megnyílni.
Ha a Firebug segítségével elkezdjük nézegetni a PC World Online-ra mutató és a többi link (esetleg az interneten megtalálható bármely oldal linkjeinek) tulajdonságait a DOM- (Document Object Model) lapon, hamar megtalálhatjuk a hostname tulajdonságot, amely mindig a hivatkozott oldal vagy dokumentum kiszolgálójának a nevét tartalmazza, helyi állományok esetén pedig üres sztring. Ha ehhez még azt is eláruljuk, hogy ilyen tulajdonsága van az aktuális oldal URL-jének adatait tartalmazó location objektumnak is, akkor már meg is van a megoldás: az if (links[l].rel == "out") feltétel helyett használjuk az if (links[l].hostname != location.hostname)-et. Így már nyugodtan elhagyhatjuk az ‹a› elemből a rel attribútumot.
Tulajdonképpen nincs is szükség a „rel” attribútumra, csak összehasonlítjuk az oldal és a link kiszolgálójának nevét
Stílusos hivatkozások
Nagyon szép és jó, hogy a honlapunkról kimutató hivatkozások új lapon vagy ablakban jelennek meg, de „jobb helyeken” az ilyen hivatkozásokat jelölni szokták, mint például a Wikipédián a kis kék nyilakkal.
Hozzunk létre néhány üres állományt, így a szükséges ikonokat elmenthetjük bármely képszerkesztővel
Ezeknek a nyilaknak (vagy más jelölőknek) a megjelenítéséhez három dologra lesz szükség. Először is egy kis (10×10 vagy 12×12 pixeles) ikonra, amit vagy „levadászunk” az internetről, vagy rajzolunk egy sajátot (erre a célra kiváló eszköz például a Xara Xtreme vektorgrafikus rajzolóprogram).
Az ikon a link háttérképeként fog megjelenni, amihez egy kis helyet csinálunk a paddinggal
Másodszor létre kell hoznunk egy új stílust, ami megmondja, hogyan is jelenjenek meg ezek az ikonok a hivatkozások mögött. CSS-ünkben a div.hir p a:hover után hozzunk létre egy új szabályt, ami az out osztályú linkek kinézetét módosítja:
div.hir p a.out {
padding: 0 14px 4px 0;
background: transparent url(../images/icon_out.gif) no-repeat bottom right;
}
Vagyis a link szövege mögött készítünk egy kicsi, egész pontosan 14 pixelnyi helyet, sőt 4 pixelnyit még lefelé is terjeszkedünk – másfeles sortávolságnál ennyi kényelmesen belefér, és így legalább az ikon „alsó indexben” fog megjelenni. Miután a hely megvan, beállítjuk a link hátterének az elmentett ikonunkat, és megadjuk, hogy ismétlés nélkül (no-repeat) jelenjen meg a jobb alsó sarokban (bottom right), vagyis pont ott, ahol a paddinggal megcsináltuk neki a helyet. Színezni nem akarjuk a hátteret, ezért használjuk szín helyett a transparent kifejezést.
A CSS-ben a honlapon használt összes link- és állománytípust fel kell sorolnunk
Végül természetesen még arra is szükség van, hogy megmondjuk, hogy melyek azok a hivatkozások, amelyeket meg szeretnénk jelölni. Ami nem is túl nehéz, hiszen amikor hozzájuk rendeljük a target attribútumot, egy mozdulattal a megfelelő osztályt is hozzáadhatjuk. Így a ciklusunk a következőképpen alakul:
for (var l = 0; l ‹ links.length; l++) {
if (links[l].hostname != location.hostname) {
links[l].target = "_blank";
links[l].className += " out";
}
}
Ha már ilyen szépen megjelöljük ezeket a linkeket, nem lehetne hasonló módon a nem HTML-oldalakra, hanem különféle dokumentumokra mutató hivatkozásokat is ellátni egy-egy ikonnal? Dehogynem. Ehhez természetesen szükség lesz a honlapon előforduló valamennyi állománytípus ikonjára (a legegyszerűbb a Windows Intézőjében található 16×16 pixeles ikonokat elmenteni), valamint mindegyikhez egy-egy osztálytípusra, amely csak annyiban tér el az out osztálytól, hogy a padding jobbra 18, lefelé pedig 6 pixelnyi helyet hoz létre, a háttérkép pedig a megfelelő állománytípus ikonjának képére mutat.
Egy ciklussal kiegészítve programunkat, a kiterjesztések osztályként hozzáadódnak a hivatkozásokhoz
Ezt követően már csak az a kérdés, hogyan döntjük el az egyes hivatkozásokról, hogy milyen kiterjesztésű állományra mutatnak? A legkorrektebb megoldás a reguláris kifejezések alkalmazása, amellyel nemcsak azt mondhatjuk meg, hogy egy adott karaktersorozat megtalálható-e a hivatkozás címében, hanem azt is, hogy valóban az-e a vége. A fenti ciklust kiegészítve például az alábbi két sorral, azon linkekhez, amelyek .pdf kiterjesztésű állományokra mutatnak, hozzáadjuk a pdf osztályt:
if (RegExp(/.pdf$/i).test(links[l].href))
links[l].className += " pdf";
Az ellenőrzéshez a nyitóoldalon helyezzünk el különféle hivatkozási típusokat: külső oldalra és mindenféle kiterjesztésű dokumentumra mutatókat
Amíg csak 2-3 különböző állománytípussal van dolgunk, addig ezt a két sort még egyszerűen tudjuk klónozni, de ha már több fájlformátum is előfordulhat oldalainkon, akkor érdemesebb a kiterjesztéseket egy tömbben felsorolni, és egy újabb ciklusra bízni az összes típus vizsgálatát, így teljes programunk a következőképpen fog kinézni:
var ext = new Array("pdf", "doc", "xls", "ppt", "cdr");
function initPage() {
var links = document.getElementsByTagName("a");
for (var l = 0; l ‹ links.length; l++) {
if (links[l].hostname != location.hostname) {
links[l].target = "_blank";
links[l].className += " out";
}
for (e in ext) {
if (RegExp(eval("/." + ext[e] + "$/i")).test(links[l].href))
links[l].className += " " + ext[e];
}
if (RegExp(/#$/).test(links[l].href))
links[l].onclick = function() { return false; }
}
}
Az utolsó ellenőrzés „bónuszként” azt vizsgálja meg, hogy az adott hivatkozás címének utolsó karaktere kettőskereszt-e, vagyis csak ott van, de nem használjuk semmire, és ha igen, akkor arra utasítja a böngészőt, hogy ne csináljon semmit – vagyis ne ugorjon fel teljesen feleslegesen az oldal tetejére.
Ha mindent jól csináltunk, akkor a linkek mögött megjelennek a megfelelő ikonok
Cikkünk mintaoldala (html, css és js forrásai) letölthető innen.
KIEGÉSZÍTŐ
Modern világ: munka az attribútum szelektorokkal
Aktuális leckénk kissé hosszúra nyúlt bevezetőjének kettős célja volt. Az egyik természetesen az, hogy felhívjuk a figyelmet: ne essünk a flegma webfejlesztők hibájába, és ellenőrizzük, hogyan néz ki, hogyan működik oldalunk az egyik legelterjedtebb böngészőben – ha szükséges, akkor valamilyen módon korrigáljuk a hibát. A másik cél pedig az volt, hogy megmagyarázzuk, egyes esetekben miért használunk a szükségesnél bonyolultabb, vagy legalábbis néha bonyolultabbnak tűnő megoldást, megoldásokat.
Az ún. attribútum-szelektorokkal is megkülönböztethetjük a különféle hivatkozásokat
Például csak azért, hogy a felhasználó számára egyértelműen megkülönböztessük a honlapunkról kimutató vagy a különféle dokumentumtípusokra mutató hivatkozásokat, nincsen szükség JavaScriptre – legalábbis az ún. modern böngészőkben. Ám az Internet Explorer 6 és a többi régi, de még használatban lévő böngésző nem sorolható ebbe a kategóriába. Ha – tanácsunk ellenére – valaki úgy dönt, hogy őt nem zavarja, hogy honlapja némiképp szegényesebben néz ki az IE6 böngészőkkel látogatók képernyőjén, akkor ezt a problémát sokkal egyszerűbben is megoldhatja az ún. attribútum szelektorok segítségével.
A CSS2-szabványt támogató böngészőkben ugyanis lehetőségünk van arra, hogy ne csak az egyedi azonosítók vagy osztályok alapján különböztessünk meg azonos típusú elemeket, hanem tetszőleges attribútumuk alapján is. Ahogyan azt Balázs a 8. leckében részletesen bemutatta, a stílusoknál az egyedi azonosítókra (id) a kettős kereszttel, míg az osztályokra (class) a ponttal tudunk hivatkozni. De mindezeken túl bármely más attribútum (vagy azok egy része) alapján is kiválaszthatunk egyes elemeket formázásra a CSS-ekben a szögletes zárójeleket használva.
Például az img[title] jelölő azt mondja meg a böngészőnek, hogy csak azokkal a képekkel foglalkozzon, amelyeknek van title attribútuma (a tartalma mindegy, a lényeg, hogy van). Ennél konkrétabban is megfogalmazhatunk egy kijelölést: az img[title="logo"] csak arra a képre vagy azokra a képekre fog vonatkozni, amelyeknek a title attribútuma „logo” szöveg. Lehetőségünk van arra is, hogy egy-egy attribútum elejére, végére vagy egy részére hivatkozzunk. Így például az img[alt^="Lorem"] csak azoknak a képeknek a tulajdonságait fogja megváltoztatni, amelyek alt attribútuma „Lorem”-mel kezdődik, míg az img[alt$="logo"] jelölő csak azokét, amelyek „logo”-ra végződnek. Ezen kívül a hullámos egyenlőségjellel (~=) azt mondhatjuk meg, hogy az adott attribútumnak tartalmaznia kell az adott szót (szóközzel elválasztva), vagy ha az egyes részeket nem szóköz, hanem kötőjel választja el, akkor a hullámvonalat le kell cserélnünk a függőleges vonalra (|=).
Ez tulajdonképpen azt is jelenti, hogy a div#oldal jelölő tulajdonképpen nem más, mint a div[id="oldal"], a h1.logo1 pedig a h1[class~="logo1"] forma rövid alakja.
Ezek ismeretében nagyon egyszerű a dolgunk, hiszen az a[href^="http://"] jelölő csak azokra a hivatkozásokra lesz hatással, amelyek más honlapokra, míg az a[href$=".doc"] szelektor csak azokra, amelyek valamilyen Word (vagy legalábbis .doc kiterjesztésű) állományra mutatnak.
