GhoUl

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Tudom, mire gondoltok… „Biztosan szükség van még egy cikkre a CSS legördülõ menükrõl?” Hadd gyõzzelek meg titeket. Mi történne, ha lenne egy tiszta, jól struktúrált menünk, ami egyszerre hordozná magában a legördülõ menük dinamizmusát, egyszerû kódját de megszüntetné a fõ problémáit (nem is beszélve a szép megjelenésrõl)?

A gondok a legördülõ menüvel:

1. az almenük pontjai nem érhetõek el addig, amíg nem kezdjük el az egész menürendszert használni, és
2. nem ad megfelelõ tájékozódási pontot a felhasználónak. Nehézkes lehet vele az oldalon belüli navigáció, mert mindig le kell gördíteni a menüt az oldalak váltásához.

Ez a technika egy bombabiztos megoldás a böngészõkkel való kompatibilitás és a hozzáférhetõség biztosítására még azon felhasználók számára is, akik régi böngészõt használnak, esetleg problémáik vannak a legördülõ menük használatával, akár mert nem tudja, akár mert nem találja kedvezõnek a legördülõ menük alkalmazásának elveit. Emellett sokkal pontosabb információt ad a hagyományos legördülõ menüknél az oldalon belüli pozícióról.

Figyelem! Ez a technika nem mûködik nagy elemszámú listákra, ahol a hagyományos legördülõ menük még jól használhatóak vagy összeomlanak a puszta tömegük alatt, a nézõponttól függõen.

Egy olyan hibrid menüt fogunk készíteni, ami vízszintesen halad keresztül az ablakon. Két szintû navigációt használ (példánkban a fõ témák és a kapcsolódó oldalak). A menünkben legördülõ hozzáférést biztosítunk minden oldalnak mindkét navigációs szinten, valamint állandóan megjelenítjük a kiválasztott témához tartozó választási lehetõségeket, emlékeztetve a felhasználót, hogy az oldal melyik részén van. Emellett a kódja egyszerû és gyorsan mûködõ lesz.

Jól hangzik? Vágjunk bele.

Elõször is vegyünk egy listát

Készítsünk egy listát az építészeti korszakokról és az õ nagyobb alakjaikról. Egy ID-t kapcsolunk az <ul> elemhez és „off” illetve „on” class-t a menülista elemeihez (ami persze feltehetõleg nem a legjobb megoldás, de a cikk céljainak megfelel):

Formázzuk meg!

Ez egy jó hely az induláshoz. Egy egyszerû, szemantikus jelölés, ami könnyen karbantartható és egy helyen található. Úgy néz ki ahogy az elvárható.

Az elsõ dolog, amit a CSS felhasználásával el fogunk érni, az az, hogy az elsõ szintjét vízszintesen jelenítjük meg (a float tulajdonság felhasználásával) és elrejtjük az alsóbb szinteket. A linkeket pedig félkövéren, színezve és kerettel jelenítjük meg.

Most helyezzük el a második listaszintet a fõ lista alá, hogy amikor újra megjelenik, amegfelelõ helyen legyen.

Végül jelenítsük meg az almenüt az aktív tématerülethez, ami a példánkban „Modern”. A legjobb megoldás erre, ha egyetlen központi, mindent lefedõ menüt használunk, egy osztály használata, mondjuk, a „Modern” elemen, és ennek megfelelõ kijelölõket használunk. Ebben a cikkben, ami egy másik oldalon belül lesz közzétéve, és önmagában is elégségesnek kell lennie, egy „on” osztályt adunk a kiválasztott témához és „off”-ot az inaktív témákhoz.

Még hozzáadunk néhány keretet, és így kapjuk az itt látható eredményt.

És akkor mindenki gördült, de egy kiesett…

Most pedig aktiváltjuk a legördülõt. Ez nem különbözik lényegesen a többi CSS legördülõ menütõl – a hover a li elemen jelenik meg, így az IE alatt nem fog mûködni a rosszul implementált :hover pszeudo-osztály miatt. Ezzel is mindjárt foglalkozunk. A következõ CSS eltünteti a kereteket a második listaszinten, a kiválasztott almenüt mindig megjeleníti, és beállítja az inaktív menük megjelenítését, ha az õsükre rámutatunk az egérrel. Beállítjuk a z-index tulajdonságot is annak érdekében, hogy az egérrel kiválasztott téma mindig elsõbbséget élvezzen az aktuális téma almenüjével szemben.

We’ll make it a little more user-friendly, with a background on the hovered tabs.
Egy kicsit felhasználóbarátabbá is tesszük azzal, hogy hátteret váltunk a kijelölt(:hover) füleken.

Itt lehet megtekinteni, hol is tartunk.

Foglalkozzunk a „különleges” böngészõinkkel…

Két választás van azon böngészõk felé, mint az Internet Explorer, amik nem támogatják a :hover osztályt a <a> elemen kívül. Hagyhatjuk úgy, ahogy van, tudva, hogy mûködni fog néhány éven belül, amikor minden böngészõ támogatni fogja a :hover osztályt (lekopogom). Ugyanakkor nyugodtak lehetünk abban a tudatban, hogy minden navigációs elem látható és elérhetõ minden felhasználó számára. Esetleg megpróbálhatunk egy kis JavaScript kódot írni, ami megfelelõen átírja a CSS kijelölõket úgy, hogy az IE is megérti, ezáltal elérhetõvé téve a legördülõ menü dinamizmusát mindenki számára.

(A mûködés IE-ben úgy-ahogy értelmezhetõ) Kicsit igazítani kell az elhelyezésen a csillag-hack segítségével:

Tehát a menü nagyszerûen mûködik a modern, szabványkövetõ böngészõkben, és korlátozottan, funkcionálisan mûködik megfelelõ elhelyezéssel az Internet Explorer 5 és 6 böngészõkben is. Egy kis segítséggel a legördülõ menüt az Internet Explorer 5-ös és 6-os verzióiban is mûködésre lehet bírni. Ehhez egy egyszerû JavaScipt kódot kell írni a kijelöléskor a kijelölõk módosítására, ez az IE 5.x és 6.x verziókon mûködik (Windows alatt). Köszönet a módszerért Patrick Griffiths-nek és Dan Webbnek, akik a „Suckerfish Legördülõ menükkel”elindítottak a CSS-alapú menürendszerek fejlesztése felé (az írás magyarul az oldalon olvasható [[Suckerfish menük]] címmel). Az õ JavaScript részletük a következõképpen néz ki:

Még egy egyszerû módosítás szükséges a CSS-en:

ahhoz, hogy az „.over” osztály hozzáadása a lista elemekhez, amelyeket kijelölünk, mûködésre bírja a rendszert az IE/Win felhasználók számára. Nem mintha nem lenne érdemes egy új böngészõben gondolkodni, de egyelõre folytatjuk a tömegek kiszolgálását olyan módon, amit már õk is megszoktak.

Tehát ez lenne az. Egy inkrementális változtatás, talán, a korábbi CSS legördülõkhöz képest, de egy másik szemszög ahhoz, hogy felfedezzük azokat az eseteket, ahol tényleg hasznos a navigáció megjelenítése ahelyett, hogy elrejtenénk egy legördülõ menü belsejében.

És lehet szép isl?

Ok, hogy nem túl szép még. Nem tehetem meg, hogy egy sokkal szebb grafikával ellátott verziót mutatok ezzel a technikával a pedánsak kedvéért a való világnak. Néhány változtatással, a CSS sprite navigációs képekkel (köszönet Dave Sheanak, egy fénykép New York Citybõl, egy kicsit több CSS, és olyan menürendszert kapunk, ami megmutatja a CSS igazi erejét, ha grafikai tervezéssel kombináljuk. Kipróbálható a végleges Hibrid CSS legördülõ menü, tökéletesen mûködõképes az összes modern böngészõven.

A szerzőről

Eric Shepherd az alapítója az arkitrave web media-nak, egy kis, webbel és grafikával foglalkozó cégnek a new yorki Buffaloban. Éppen egy építészeti diplomát szerez (Master of Architecture degree) a a Buffaloi Egyetemen. Emelett még zongorista is. A munkája megjelent a CSS Zen Garden oldalon, és stratégiai partnere a Nepo Strategies-nek, egy buffaloi e-kereskedelmi és webes stratégiai cégnek. Már foglalkozik vele, hogy hogyan magyarázza el az XHTML, a CSS és Javascript DOMmal kombinált erejét a zseniális egyhónapos lányának, Naia-nak.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Megelégelve, hogy ennyi negatív cikk sorakozik a főoldalon, ideje egy kicsit a pozitívabb dolgokról is írni. (Nem kell félni, nem lesz csöpögős ). Vége egy újabb vizsgaidőszaknak (és ezzel együtt egy újabb félévnek), így van némi idő megint az oldallal foglalkozni (más kérdés, hogy ez mire lesz elegendő).

Egy már megtörtént változás, hogy feltöltöttem néhány tárgyból aranyköpéseket – tudom, ez kicsit szembemegy azzal, amit korábban mondtam a folytatásról, de így alakult. Ennyi még összejött.

Ami viszont csak folyamatban levő változás, hogy megpróbálok csinálni valamit a fordítással. Elkezdeni elkezdtem, megvan, hogyan csinálom, most már csak időre van szükség. Meg energiára. Szóval folyamatban van.

Sajnos szükséges: a hivatalos magyar fordítás alapelvei magával vonják, hogy az eredmény magyartalan legyen. Szóval nagyon nagy részt újra kell írni a dolgokat. A nagy terv szerint ha készen van (értsd: elfogadható szintre eljut a dolog), akkor majd közzéteszem, hogy másnak is hasznos lehessen. Addig is köszönet Tompikának, hogy megosztotta velem a saját fordításait.

Ha bárki bárhol úgy gondolja, hogy érdeklik a részletek, keressen meg (akár nyilvánosan is), abban az esetben, ha valami tanácsa van, ne tartsa magában, de egyelőre fordítási hibát csak akkor jelezzen bárki is, ha biztos benne, hogy az már egy módosított szekció. Egyelőre még nagyon kevés van fenn, abban is bármikor lehetséges változás, úgyhogy abszolút nem mérvadó a jelen helyzet. Később, ha már jobb arányban lesz a fordítás, majd lesz precízebb állapotjelzés is.

Ami meg még később lesz: a template portolása. Pedig annak is lenne értelme, sőt, ahhoz több kedvem is lenne. De a fordítás sürgősebb.

Az meg, hogy a meglevő témáimból mi kerül fel az oldalra, az majd kiderül. Van pár ötlet még, amiről lehet írni, és valamilyen készültségi fázisba eljutott.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.


Miért? Mert a szoftvernek tudnia kellene, hogy szokásokat veszünk fel. Tudnia kellene, hogy azután, hogy számtalanszor válaszolunk OK-val a kérdésre, feltehetőleg akkor is az OK-t választjuk, ha nem arra gondoltunk. És azt is tudnia kellene, hogy nem lesz lehetőségünk gondolkodni, mielőtt véletlenül eldobjuk az egész munkánkat.

Miért kellene tudnia a szoftvernek ezeket a dolgokat? Mert a szoftvertervezőknek is tudniuk kellene, hogy szokásokat veszünk fel, akár akarjuk, akár nem.

A szokások felvétele tulajdonképpen egy jó dolog: segít megkímélni minket annak a gondjától, hogy gondolkodni kelljen, amikor az interfész bosszantó apróságaival találkozunk és csökkenti a valószínűségét, hogy a gondolatmenetünk eltérül. A „Biztosan ki akar lépni?” kérdésre a kezünkben van egy memorizált kattints-és-zárd-be folytonos folyamat. Ez jó, mert a legtöbb esetben nem akarunk gondolkodni a kérdésről – csak a jó dolgot csináljuk. Szerencsétlen módon, a szokásaink időnként félrevezetnek: nem lesz időnk rájönni a hibánkra, amíg meg nem csináltuk.

Így a tervezők számára egyenes út vezet az általános felhasználói felülettervezési elvhez: Ahhoz, hogy egy felhasználói felület emberi legyen, figyelembe kell vennie a szokások kialakulását.

Lehetséges megoldások

Mi lenne, ha a figyelmeztetést nehezebb lenne figyelmen kívül hagyni? Egy diszkrét figyelmeztetés felett könnyű átugrani, így vegyük elő a teljes eszköztárat: villogtatjuk a képernyőt és egy hangos, idegesítő zajt játszunk le annak érdekében, hogy biztosítsuk a felhasználói figyelmet. Próbálkozhatunk, ahogy tetszik, továbbra sem fog működni. Minél tolakodóbb a figyelmeztetés, annál gyorsabban meg akarunk szabadulni tőle (az OK-ra kattintva) és annál többször fogunk hibázni. A gond az, nem számít, mennyire tolja a képünk elé a figyelmeztetést a szmítógép, mi ugyanazt a hibát fogjuk elkövetni: akkor is az OK-ra kattintunk, ha nem azt akartuk. De ez még mindig nem a mi hibánk: addig, amíg szokások felvételével figyelmen kívül lehet hagyni a hibaüzenetet, felvesszük a szokásokat, azután pedig hibázni fogunk.

Mi lenne, ha a figyelmeztetést lehetetlen lenne figyelmen kívül hagyni? Ha a szokások okozzák a problémát, miért nem tervezzük úgy meg a felületet, hogy ne lehessen szokásokat felvenni? Így mindig rá leszünk kényszerítve, hogy gondolkodjunk a válaszadás előtt, és így mindig azt válaszoljuk, ami választ mi szeretnénk. Ez megoldja a problémát, nem?

Ez a fajta gondolkodás nem új: ez az írd-be-az-n-edik-szót-ebből-a-mondatból-a-folytatáshoz megközelítés. Például a Guild Wars játékban ahhoz, hogy egy karaktert töröljünk, először a „Törlés” gombra kell kattintani, majd a karakter nevét be kell írni megerősítésként. Sajnálatos módon ez nem mindig működik. Pontosabban:

1. Arra kényszerít minket, hogy koncentráljunk a szokatlan feladatra és nem arra, hogy tényleg el akarjuk-e dobni a munkánkat. Így a nem figyelmen kívül hagyható figyelmeztetés se sokkal jobb, mint a teljesen átlagos: mindkét esetben végeredményben elveszik a munkánk. Ez (a munka elvesztése) az elképzelhető legnagyobb bűn a szoftver világában.
2. Figyelemre méltóan idegesítő, és mert mindig szükséges a figyelem, szükségszerűen elterel minket a munkánkról (ami a második legnagyobb szoftver-bűn).
3. Mindig lassabb és több munkát igényel, mint egy egyszerű figyelmeztetés. Ezzel elköveti a harmadik legnagyobb bűnt – azzal, hogy több munkát igényel tőlünk, mint az szükséges.

A Guild Wars-os példánkban a második és harmadik pont nem túl lényeges, mert a karakterek törlése elég ritka esemény. De ha be kellene írni a dokumentum nevét, mielőtt mentés nélkül kiléphetnénk, nagyon megterhelőnek éreznénk.

Mit tanultunk? Azok a felületek, amik nem veszik figyelembe a megszokást, nagyon rosszak. A figyelmeztetés nagyobbá, hangosabbá és nem-figyelmen-kívül-hagyhatóvá tétele nem működik; akárhogy is nézzük, a figyelmeztetések egy nagy, sötét csapdát jelentenek az interfészben. Inkább szabaduljunk meg a figyelmeztetésektől.

A mentőöv: visszavonás

Ha csak simán eltávolítjuk a figyelmeztetéseket, nem mentjük meg a munkánkat a végzettől, de ha egy „visszavonási” lehetőséget beteszünk, akkor már igen. Hadd ismételjem meg: a figyelmeztetéses nyomorúságunkra a visszavonás a megoldás. Egy kellően robosztus visszavonással akár nemtörődöm módon is bezárhatjuk a munkánkat tudva, hogy mindig visszanyerhetjük. A visszavonással ezt a szörnyű „Hoppá!” érzést eltüntethetjük a munka visszaszerzésévelA „Hoppá!”-tényező egy Laura Creighton-nal folytatott megbeszélés alapján született meg..

Mivel szokásokat veszünk fel, soha nem fogjuk tudni garantálni, hogy nem lesz ilyen „Hoppá!” pillanatunk. Ezzel szemben a tervezőknek tudomásul kell venniük, hogy meg fog történni, és ennek megfelelően tervezni. Ahányszor csak megvan a lehetősége, hogy eldobjuk a munkánkat, a számítógépnek lehetővé kell tennie, hogy visszacsináljuk a dolgokat.

Ez elvezet minket az egyik legalapvetőbb és legfontosabb felülettervezési mantrához: Soha ne figyelmeztess, ha a visszavonás is elegendő!

A Google Mail egy jó példája ennek a mantrának. Ha törölsz egy e-mailt, azonnal ad lehetőséget arra, hogy visszavond ezt a lépést. Milyen felhasználóbarát! Ezzel ügyesen kikerüli a figyelmeztetések kérdését (csakúgy, mint a visszavonás láthatóságát). Ha hibázunk (ami elő fog fordulni), nem kerül túl sokba, mert egyszerűen visszavonhatjuk. A visszavonással kevesebbet aggódunk és több időt dolgozunk.

1. ábra: Még nincs túl késő. A Gmail lehetővé teszi, hogy visszavonjuk a törlést.

Természetesen ez csak egy rétege a visszavonhatóságnak – és Gmail ennél tovább megy. Ha törölsz egy levelet, az nem veszik el örökre… ott van a kukában, hogy visszaállíthasd, ha később úgy döntesz, mégsem akartad törölni.

Sajnos, ezt a leckét a Google Calendar még nem tanulta meg. És, ahogy megjósolható volt, töröltem már olyan eseményeket, amit nem akartam. Sokszor a rossz eseményt töröltem, ami különösen rossz, mert ekkor abban sem vagyok biztos, hogy mit töröltem. Visszavonás nélkül nincs is rá mód, hogy kitaláljam.

2. ábra: Légy óvatos! A Google Calendar nem engedi a téves törlések visszavonását.

Tulajdonképpen még Google Mail sem mindig használja ezt a módszert. Ha egy címkét törölsz, már jön is egy ilyen figyelmeztetés. Miért van az, hogy Google ilyen jól megcsinálja egy helyen, és alig néhány kattintással arrébb meg ilyen rosszul? Talán mert ez a figyelmeztetés alapú gondolkodás annyira beágyazódott, hogy hősies erőfeszítéseket igényel a meghaladása. Még olyan cégek is, amelyek egyébként a jó tervezés védőbástyái (ilyen a 37Signals), ezt nagyon rosszul csinálják.

3. ábra: A Highrise, a 37Signals alkalmazása is figyelmeztet visszavonási lehetőség nélkül

Figyelmeztetések használata a visszavonás helyett a legkisebb ellenállás felé mozdulás útja a programozó szemszögéből, és nem igényel különösebben újító gondolkozást a tervező nézőpontjából. De ez nem mentség a számítógépeink számára, hogy nem emberi módon gondolkodnak.

Következtetés

A figyelmeztetések miatt elveszíthetjük a munkánkat, bizalmatlanok leszünk a számítógépekkel szemben és magunkat hibáztatjuk. Egy egyszerű, de bolondbiztos tervezési módszertan megoldja a problémát: „Soha ne figyelmeztess, ha a visszavonás is elegendő!” És ha a felhasználó törli a munkáját, mindig elegendő.

Ó, és a következő alkalommal, amikor azt látod, hogy figyelmeztetnek a visszavonás helyett, küldj az alkalmazás/weboldal tervezőjének egy kedves e-mailt, amiben javaslod, hogy inkább implementáljanak egy „visszavonás” funkciót. Küldj nekik egy linket erről a cikkről. Nézzük meg, meg tudjuk-e változtatni annak a módját, ahogy az emberek a webre terveznek – és ebben a folyamatban mindenki számítógépes életét egy kissé emberközelibbé és kevésbé frusztrálóvá tegyük. Kezdődjön a háború a figyelmeztetések ellen!

Illusztráció: Kevin Cornell

A szerzőről

Aza először 10 éves korában a SIGCHI helyi, san franciscoi székházában beszélt a felhasználói felületekről, és a rabjukká lett. 17 évesen nemzetközi megbeszéléseken és konzultációkon vett rész; 19 évesen egy fizikakönyv társszerzője lett, mert túl fiatal volt, hogy alkoholt vegyen; 21 évesen elkezdett inni, és társalapítója a Humanized-nek. Aza szeret játszani a kürtjén és a laborjában tenni-venni, ha az ideje engedi.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2003. november 7. óta elérhető itt.

A „DHTML” legördülő menük maguk után vonták az otromba, böngészőspecifikus hackelésekkel teletömött Javascript kódokat, amik az egyébként elegáns, szemantikus HTML kódot meglehetősen hozzáférhetetlenné A hozzáférhető/hozzáférhetetlen fogalmakon a webtervezői szókincsben megfelelő accessibility kifejezést értem. teszik. Ó, azok a pehelykönnyű, hozzáférhető, szabványos, böngészőfüggetlen módszerek! Tekintsd meg a Suckerfish Suckerfish: Brehm és Wikipedia alapján rövidszárnyú bojtorjánhal. Ez a hal a Gályatartóhal-félék családjába tartozik. Ezek a halak már az ókorban is ismertek voltak a Földközi-tenger vidékén, a halak különlegessége, hogy más halakhoz, esetenként hajókhoz kapcsolódtak, velük vitették magukat. Konkrétan a bojtorjánhalról Brehm ezt írja: „Elterjedésének határa valószínűen egybeesik a kardoshalakéval, mivel többedmagával ezekre tapadva viteti magát. (Brehm: Az állatok világa) menüket!

Először a HTML

Először is, válasszuk a legjobb módszert a menü leírásához — egy listát. Példánkban egy egyszerű HTML sorszámozás nélküli listát használunk.

<ul>
  <li>Sunfishes

    <ul>
      <li><a href="">Blackbanded sunfish</a></li>
      <li><a href="">Shadow bass</a></li>
      <li><a href="">Ozark bass</a></li>
      <li><a href="">White crappie</a></li>
    </ul>

  </li>

  <li>Grunts

    <ul>
      <li><a href="">Smallmouth grunt</a></li>
      <li><a href="">Burrito</a></li>
      <li><a href="">Pigfish</a></li>
    </ul>

  </li>

  <li>Remoras

    <ul>
      <li><a href="">Whalesucker</a></li>
      <li><a href="">Marlinsucker</a></li>
      <li><a href="">Ceylonese remora</a></li>
      <li><a href="">Spearfish remora</a></li>
      <li><a href="">Slender suckerfish</a></li>
    </ul>

  </li>
</ul>

Tényleg eléggé magától értetődő — tiszta és elegáns HTML, ami a hozzáférhetőséget biztosítja. De ezt most átalakítjuk egy dinamikus listává — a listaelemek első szintje egy vízszintes menüsávot fog alkotni, ebből fognak legördülni a második szintű listák.

Formázzuk meg!

Kezdésként minden listaelemet piszkáljunk meg egy kicsit — nevezetesen a margót és kitöltést nullára állítjuk, a listaelemek jelzését pedig kikapcsoljuk:

ul {
  padding: 0;
  margin: 0;
  list-style: none;
  }

A következő lépésben a lista első szintjét átalakítjuk egy vízszintes menüsávvá. Többféle technika van erre, amiket máshol részletesebben kifejtenek. Megjelölhetnénk az elemeket a

jellemzővel, de ebben a példában inkább balra lebegtetjük őket.

li {
  float: left;
  position: relative;
  width: 10em;
  }

Az elemek helye

-ra lett állítva, mivel a beágyazott listákat az első szinthez képest relatívan helyezzük majd el, a fix (!) szélességmegadás meg azért szükséges, hogy elérjünk bizonyos méreteket. A legördülő menü lassan összeáll.

Ezek után nézzük a lista második szintjét, ami a tényleges legördülő menü lesz:

li ul {
  display: none;
  position: absolute;
  top: 1em;
  left: 0;
  }

Ez a listák második szintjét abszolút módon helyezi el (kiemeli a HTML folyamból, és külön kezeli őket), és alapértelmezetten meg nem jelenítettekké állítja. Abban az esetben, ha a

részt

-ra cserélnénk, akkor látjuk szükségét a top és a left értékek beállításának az Internet Explorerben, mert ezek nélkül az IE a második szintű listákat az ősük jobb felső sarkába helyezi a bal alsó helyett. Sajnos ez az IE megoldás elkavarja a dolgokat az Opera-hoz hasonló böngészőkben, így ezekben a következő CSS kódra van szükség a top és left paraméterek beállításához:

li > ul {
  top: auto;
  left: auto;
  }

És most rakjuk hozzá az összekapcsolást! Ahhoz, hogy a második listaszintet megjelenítsük, amikor az első szinten a pontok „kiválasztódnak”, egyszerűen a következő kódot kell hozzáadni:

li:hover ul { display: block; }

Ami annyit jelent, hogy bármely elem, ami egy olyan pont alatti listában szerepel, amire az egérkurzor rámutat, megjelenítendő.

Végül, mert a listaelemek balra vannak lebegtetve, a tartalmat alattuk függetleníteni kell a lebegtetéstől a

formázás kijelölésével.

Várjunk egy pillanatot!

”Ez a legördülő halandzsa nem működik!” – hallom az olvasók 102,6 százalékát (vagy a legfrissebb, éppen csökkenő hányadukat) kiabálni. Igen, mint kitalálható, az Internet Explorer felhasználóiról beszélek. Minél többet használod egyszerű szörfözőként, vagy webfejlesztőként a Mozillához hasonló böngészőket, annál feltűnőbb, hogy mennyire nevetséges az Internet Explorer, ha a webes szabványokról esik szó. A

pszeudoosztálynak elvben minden elemre működnie kellene, de az Internet Explorerben csak a linkekre működik. Pont. Mi a haszna a legördülő menünek, ha csak a böngészők -2,6 százalékán működik? Hogy őszinték legyünk, nem sok. Egy kicsit többet kell még varázsolnunk.

A mentőöv: DOM-szkriptelés

Ugyan megállapítottuk, hogy az IE ugyan nem támogatja a

pszeudo-osztályt, de a Document Object Model használatával egyszerűen kapcsolhatunk egéreseményeket (mouseover, mouseout) bármilyen elemhez. Ez jó hír számunkra, mert azt jelenti, hogy egy rövid JavaScript kódocskával hatékonyan orvosolhatjuk az IE

gondjait.

Mivel az IE vak, ahhoz, hogy azonosítsuk a

pszeudoosztály tulajdonságait, más módszert kell találni. A JavaScript segítségével manipulálhatuk a className tulajdonságát egy elemnek, így először egy kicsit a CSS-t kell megváltoztatnunk:

li:hover ul{ display: block; }

helyett a következő kód használható:

li:hover ul, li.over ul{ display: block; }

Ezután meghívhatjuk a

CSS szabályokat a kívánt elemre, ha hozzáadjuk az

osztályt a kívánt elemhez. Szükségünk lehet továbbá arra, hogy megmondjuk az IE-nek, hogy mely UL elemek szolgálnak az oldalon legördülő menüként. Ez egy

hozzáadásával tesszük meg a listánk gyökér

elemére:

Ezáltal a

<ul>

kódból a következő lesz:

<ul id="nav">

Most, hogy tudjuk azonosítani a gyökér

elemét a legördülő listánknak, kiemelhetjük ezt az elemet, és végigmehetünk az összes gyerekelemén, hozzáadva a mouseover és mouseout eseményeket az összes

elemhez a belsejében. Ezt így tehetjük meg:

startList = function() {
if (document.all&&document.getElementById) {
navRoot = document.getElementById("nav");
for (i=0; i<navRoot.childNodes.length; i++) {
node = navRoot.childNodes[i];
if (node.nodeName=="LI") {
node.onmouseover=function() {
this.className+=" over";
  }
  node.onmouseout=function() {
  this.className=this.className.replace(" over", "");
   }
   }
  }
 }
}
window.onload=startList;

A lap betöltésekor a

függvény meghívódik. Ez meghatározza, hogy a böngésző IE 5 vagy újabb a

objektum és a

függvény létezésének vizsgálatával. Ez egy picit nyers megoldás, de rövid és egyszerű, és mivel mi egy kompakt megoldást szeretnénk, ez is megteszi. Ezután végiglépked a listákon, engedélyezve a mouseover és a mouseout eseményeket, amik hozzáadják/eltávolítják a

osztályt a

tulajdonságához az elemnek.

Így már működik. Probléma esetén érdemes megnézni a megjegyzésekkel ellátott példa vázat működés közben.

Kopoltyúk, uszonyok, pikkelyek…

Eddig amit csináltunk, egy kicsit meztelennek tűnik. Ez a cikk csak az ötlet alapjait mutatja be, de CSS segítségével sokkal szebben meg lehet valósítani. Egy nyilvánvaló kiindulópont lehet háttérszín hozzárendelése a második listaszinthez.

Miután visszaállítottuk a top és left tulajdonságokat, ahogy korábban leírtuk, a legördölő menük a szép példában közvetlenül a feliratok alatt jelennek meg a legtöbb modern böngészőben, de sajnos nem mindben. A Safari 1.0-ban még mindig a képernyő bal felső sarkából gördülnek le.

További használhatósági és hozzáférhetőségi gondolatok

Ha az első listaszint elemeiből hivatkozásokat csinálunk, megengedjük a tabstop használatát azon olvasók számára, akik nem használnak mutatóeszközöket. Ha sikerül olyan oldalakra mutatnunk, amik magasabb szinten vannak, mint az almenü elemei, az még jobb eredményt ad.

A szerzőkről

Patrick Griffiths egy szabadúszó londoni webtervező, aki kedveli, tiszteli a soul-t, az evolúciót és a kedves weboldalát (megjegyzés: az eredeti pet kedvencet és háziállatot egyaránt jelent), a HTML Dog-ot. Időnként becézgeti a PTG-t a hangulatától függően.

Dan Webb egy webtervező és DJ-nek is tanul. A korábbi munkái között szerepel szabványkövető, hozzáférhető oldalak és webalkalmazások megvalósítása az Egyesült Királyság kormányzati hivatalainak és emberek táncra penderítése London homályos szórakozóhelyein.

Az eredeti cikk elérhető itt.