'webfejlesztés' kategória archívuma.

Az elmúlt héten két kedvenc böngészőmet, a Safarit és a Firefoxot illetően áttértem azok fejlesztői változatára, a WebKitre és a Minefieldre. A döntést egyik esetben sem bántam meg, mind a két esetben egy stabil és gyors böngészőt kaptam cserébe.

A Safari esetében a váltást az indokolta, hogy a WebKitbe épített fejlesztői eszközök jóval fejlettebbek, mint amit a Safaritól kapok, míg a Firefox esetében az új TraceMonkey JavaScript motort szerettem volna kipróbálni. Mind a két böngésző gyors, és jól használható, és nem is fagynak többször, mint stabil kiadású párjaik, de ahogyan a Chrome-nál sem, a felhasználói élményt illetően egyiküknél sem észleltem kiemelkedő gyorsulást.

Firefoxból a legfrissebb, TraceMonkey-t is tartalmazó változat letöltését javaslom a Mozilla FTP-jéről, minden operációs rendszerre megtaláljuk a legfrissebb változatot. A TraceMonkey-t engedélyezni kell a telepítés után, amit az about:config oldalon, a javascript.options.jit.content (esetlegesen a javascript.options.jit.chrome - ha magába a Firefoxban is szeretnénk a gyorsabb motort használni) változó true-ra állításával. Engem az új, a fülek közötti látványos váltás működése (miszerint nem a fülek között egymás után, hanem a legfrissebben látott fülek között egymás után lehet váltogatni a Ctrl-Tab segítségével) igencsak zavart, ezért még a browser.ctrlTab.mostRecentlyUsed változót is false-ra állítottam. Ezek után egy újraindítás kell, és voálá, máris lehet tesztelni.

A legfrissebb WebKit-et a http://nightly.webkit.org/ címről lehet letölteni, Mac OS X alatt problémamentes volt a telepítése, Windows alatt halvány emlékeim szerint egy már a gépünkön levő Safarit lehet felülvágni vele, egy script lefuttatásával.

A fejlesztői változatok nem csak a sebességben és funkcióikban tudnak többet, jobbat, de az újdonságokat is lehet próbálgatni velük.

A Google hivatalos webfejlesztőknek szóló blogjában arra kér minket, hogy a dinamikusan (értsd: adatbázis jellegű forrásból) kiszolgált tartalmakat ne rejtsük statikus (értsd: GET paramétereket nem tartalmazó) URL-ek mögé. Szerintem hülyeséget beszélnek (ingyensört osztogattak?), de ezt kiegészítem azzal, hogy érdemes figyelni egyes tanácsaikra.

A blogban definiálják azt, hogy szerintük mi a statikus, és mi a dinamikus webcím:

Mi a statikus URL?

A statikus URL nem változik, és tipikusan nem tartalmaz URL paramétereket. Így néz ki például: http://www.example.com/archive/january.htm. Statikus címekre a Google keresőjében a filetype:htm definiálásával tudsz keresni. Az ilyen oldalaknak a a frissítése időigényes lehet, főként ha a tartalom mennyisége gyorsan nő – minden egyes oldal ugyanis kézzel készül. Emiatt a sok oldalból álló, gyakran frissülő oldalaknak, mint például a webáruházak, fórumok, blogok és tartalomkezelő rendszerek, dinamikus URL-eket célszerű használnia.

Nem igazán értem, hogy 2008-ban miért kell a DOS-os időkből ránk maradt HTM kiterjesztéssel példálózni, és hogy mi köze van a dinamikusan előálló tartalmaknak ahhoz, hogy dinamikus címet kéne használnunk. De nézzük a dinamikus URL definíciójukat:

Mi a dinamikus URL?
Ha egy oldal tartalma adatbázisban van tárolva és onnan van kiszolgálva a felhasználó kérésére, dinamikus URL-ek használata a célszerű. Ebben az esetben az oldal alapvetően egy sablonként szolgál a tartalom számára. Általában egy dinamikus URL így néz ki: http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31. Egy dinamikus URL-t a benne levő ? = & karakterek segítségével tudsz felfedezni. A dinamikus URL-eknek megvan az a hátrányuk, hogy a különböző URL-ekhez ugyanaz a tartalom tartozhat. Vagyis egyes felhasználók esetlegesen különböző címeket használnak ugyanarra a tartalomra való linkeléskor. Ez egy ok, amiért a webfejlesztők statikus címekké szeretnék alakítani az URL-eket.

Ezt a logikát nem értem (vagy az angolom bűn rossz, és teljesen félrefordítottam – lehet). A statikus-dinamikus URL definícióját el tudom fogadni, avagy ha vannak GET paraméterek egy URL-ben, akkor hívjuk dinamikus címnek, ha nincsenek, akkor pedig statikus címnek. Az, hogy ezek az oldalak éppen adatbázisból, lemezről, memóriából, TDK SA90 High-Bias kazettáról vagy éppenséggel a nagymama lyukkártyájáról érkeznek, azt viszont nem mosnám össze azzal, hogy hogyan néz ki a címük.

Az ma már elég evidens megoldás, hogy a nagyon kis, vagy speciális weboldalak kivételével szinte mindenhol dinamikusan, programkód segítségével történő oldalkiszolgálás van a háttérben. Az is biztos, hogy azokat a tartalmakat, melyek jellemzően nem változnak az idő során, célszerű statikus URL-eken kiszolgálni.

A Google tanácsát nem szeretném azonban megfogadni. A http://webakademia.hu/2008/09/dinamikus-vagy-statikus URL ugyanis bár dinamikusan van kiszolgálva, de statikus, a hozzászólások és az oldalsáv kivételével változatlan tartalmat jelöl, és ha a hozzászólásokat vagy az oldalsávot viszonylag ritkán indexeli le a Google, akkor sincsen nagy gond. Ez az URL emberbarát, linkeléskor látni hogy várhatóan milyen tartalom van a cím mögött, sőt, még azt is, hogy milyen régi az a tartalom. Hozzáteszem, maga a Google alakíttatta ki velünk ezt a címet, mivel az URL-ben levő szöveges információt is felhasználja, és pozitívan díjazza a tartalmak rangsorolásakor.

De ez csak a bevezetése volt a bejegyzésnek, még folytatódik:

Statikussá alakítsam a dinamikus címeimet?
Íme néhány pont ami szem előtt tartandó a dinamikus URL-ekkel történő munka során:

1. Elég nehéz helyesen létrehozni és karbantartani azokat az újraírókat, melyek a dinamikus címeket statikusnak tűnő címekké alakítják.
2. Sokkal biztonságosabb az eredeti dinamikus cím kiszolgálása felénk, és a problémás paraméterek felismerésének és kezelésének ránk bízása.
3. Ha át szeretnél írni egy címet, a dinamikusnak tűnő címek kezelésekor távolítsd el a felesleges paramétereket.
4. Ha statikus URL-en szeretnél kiszolgálni dinamikus URL helyett, hozd létre a statikus párját a dinamikus tartalmadnak.

Az első pont nettó hülyeség. Ma már szinte a kezdő programozó is le tudja kezelni a statikusnak tűnő, ember- (és kereső-, de psszt) barát címeket, és a legtöbb CMS rendszer támogatja is azokat. Nem nehéz.

A kettes pontot illetően szép, hogy a Google saját magából indul ki, de azért mégiscsak úgy érzem, hogy nem a Google robotjának kényelmét kellene kiszolgálnom akkor, amikor eldöntöm, hogy milyen URL-eken szolgálom ki egy weblap bizonyos tartalmát. Ráadásul nem tudom, hogy miért lenne biztonságosabb rábízni a Google-re ezt a feladatot, amikor nagyon sokat tudok nekik segíteni akkor, amikor jelzem hogy mi a stabil, állandó tartalom az oldalon (statikus URL), és mi az, ami viszonylag gyakran változik, és a tartalom nagyban függ az URL-ben levő paramétertől (dinamikus URL).

A harmadik és negyedik pont ebben a megfogalmazásban nehezen feldolgozható.

Ezután FAQ jellegűen megpróbálnak eloszlatni pár tévedést, melyet most nem idéznék, de összefoglalnék és hozzáfűzném a személyes véleményemet:

• A bejegyzés írója szerint tévhit, hogy a statikus/statikusnak tűnő URL-ekből álló oldal indexelése könnyebb lenne. Ők is jelzik, hogy a statikus URL-ek előnyösek lehetnek mert felhasználóbarátabbak. Ennek ellenére jelzik, hogy a dinamikus címeket kellene favorizálnunk a statikus helyett. Valahol értem a logikát, azt, hogy egy dinamikus URL-ekből álló oldalcsoport leindexelése, feldolgozása könnyebb lehet, de az teljes homály számomra, hogy a felhasználóbarát megoldással szemben miért javasol egy olyan megoldást a Google, amely minimális előnyt jelenthet csak számukra (szerintem ugyanúgy kezelni tudják egy statikus URL-ekből álló oldal indexelését, mint egy dinamikus URL-ekből állóét, az algoritmusban egyszerűen mást kell dinamikus résznek tekinteni).
• Szeretnék eloszlatni azt a téveszmét, miszerint a dinamikus URL-eket nem (illetve nehezebben) tudja egy keresőmotor leindexelni. Azt írják, hogy problémájuk lehet abból, ha egyes a Google számára értékes információkat hordozó paramétereket esetlegesen elrejtünk, és azt tanácsolják, hogy tartozkódjunk a dinamikus címek statikussá tételétől. A miértre nem adnak kielégítő magyarázatot.
• Azt a tévhitet is cáfolják, miszerint a 3-nál több paramétert tartalmazó dinamikus URL-ek használata gondot okozna a robotoknak. Szerintem gondot okozhat, az lehet hogy az ő robotjuk bírja a strapát.

A folytatást hanyagolnám, ugyanaz, mint amiről eddig szó volt. Még azt is megtudhatjuk, hogy a session azonosítóknak, és a nulla információt hordozó paramétereknek nem az URL-ben a helye (tudtuk). Ez az egyetlen értelmes és hasznos mondanivalója a bejegyzésnek.

A zárás:

Reméljük ez a cikk hasznos volt és segít a dinamikus címek körüli kérdések megértésében. Csatlakott bátran a vitacsoportunkhoz ha további kérdésed van.
Írta Juliane Stiller és Kaspar Szymanski, a Kereső Minőségbiztosítási Csapatból

Nem, nem volt hasznos, és ez látható a hozzászólásokból is. Mindegyikben ott a kérdőjel. Oké Juliane és Kaspar, jó vicc volt, most már viszont ideje lenne törölni vagy megmagyarázni ezt a bejegyzést. Nem április elseje van.

Amikor egy weblapot rakunk össze HTML-ben, nem árt kismillió dologra figyelnünk. Másképpen szólva egyre: adjunk ki minőséget a kezeink közül. Hogy mi a minőség, mire kell figyelni, na ezt már nem ilyen egyszerű meghatározni, de legalább van egy jó listánk. Nagyon fontos, hogy ezeket az elemeket nem utólag kell leellenőrizni, hanem folyamatosan az oldal felépítése közben.

A 44 pontból álló listát csak ajánlani tudom, egy jó áttekintést ad. Egy mondatot kiemelnék: az oldal kódja legyen könnyed, tiszta, CSS alapú, hozzáférhető, használható és keresőbarát.

Összefoglalva egy kicsit a lista mondanivalóját, mindenképpen azt tudom javasolni eddigi tapasztalataim alapján is, hogy egy üres vázból induljunk ki, aholis a fejlécben egy az általunk választott, jól validálható DOCTYPE szerepel, használjunk UTF-8 kódolást és ezt a HTML kód elején jelöljük is (ki lehet küldeni HTTP fejlécben is), majd a kódot igyekezzünk átláthatóan tördelni (mind a HTML-t, mind a CSS-t). Lehetőség szerint ne használjunk se inline CSS-t (style tulajdonság), se inline JavaScriptet (script elem). Fejlesztés közben ellenőrizzük mind a HTML, mind pedig a CSS kódot – így az elgépelések is elég jól kijönnek. Ennek kapcsán célszerű a különböző hack-eket minimumra csökkenteni, vagy olyan megoldást választani, ami a validátort nem zavarja.

Az induláskor illik több dolgot eldönteni, például hogy mennyi energiát fordítunk a különböző böngészők támogatására, milyen szinten támogatjuk azokat, milyen szinten támogatjuk a vak, csökkent látóképességű, egyéb problémákkal küzdő felhasználókat, hogy mi a célunk a keresőoptimalizálás kapcsán, s hogy melyik HTML szabványt válasszuk.

A fentiek figyelembe vétele tapasztalataim szerint több ponton is segít az oldal élete folyamán. Egy a validátor szerint kevés hibát tartalmazó oldalban gyorsan és hatékonyan meg tudjuk találni az elgépeléseket ha hozzáfejlesztünk, jellemzően tömör, jól szkinezhető (alternatív megjelenések) oldalt kapunk, mely gyorsabban töltődik be, és a karbantartás is könnyebb, gazdaságosabb lesz.

A lista nem csak felsorolja az egyes elemeket, de 1-1 mondatban meg is magyarázza azokat, illetve további olvasnivalót is kínál a témában.

A Google Doctype-ról írtam már korábban, az Opera most egy hasonló lépésre szánta el magát ami a szándékot illeti. A forma itt nem wiki, hanem egy “könyvszerű” tananyag, Opera Web Standards Curriculum néven.

Kiváló összeállításról van szó, mely főleg az alapokat mutatja be, de azokat pont úgy, ahogy – szerintem – kell. Az internet/web kialakulásától, működésétől, a szabványok reális megközelítésétől kezdve design és HTML bemutatók jönnek, majd egy kis “egyéb” adalék. Az egyes írások ráadásul szabad licencelésűek, azaz semmi akadálya a lefordításuknak. Valaki jelentkező esetleg? Jól mutatnának a webbuilder.hu hasábjain – ott sajnos egyelőre nem túl olvasmányos, néhol pongyola írások vannak (de így is minden tiszteletem az ottani szerzőknek!).

Kötelező olvasmány kezdőknek!

A CSS 2 kapcsán sajnos be kellett látnia a W3C-nek, hogy az egyes böngésző gyártóknak (anno) akadtak nehézségeik (motivációs hiányosságaik) a kivitelezéssel, ezért jelent meg a visszabutított CSS 2.1 változat. A fejlesztés azonban nem állt le, csak ügyesebb lett: nem egy nagy CSS 3 szabványt találtak ki, hanem moduláris jellegűt, ahol az egyes modulok megjelenése független egymástól, és a modulok függetlenül is implementálhatóak a böngészőkben. A CSS 3 fejlesztése folyik, de nem csak a W3C-től jelennek meg ezügyben újdonságok.

A régi böngészőkben nem működik témát így az elején zárjuk is le: nem az a lényeg hogy a régi böngészők nem támogatnak valamit, hanem hogy az újak egyre szélesebb körben lehetővé teszik az újdonságok használatát. És a böngészők ma már nem csak a webről szólnak, például a Webkitben implementált újdonságokat kiválóan lehet használni iPhone-on, Adobe Air-ben, Apple Dashboardon, a Firefox-ban megjelenőket a böngésző kiterjesztésekben, és úgy általában az egyes böngészőket lehet limitálni egy intranetes/vállalati környezetben, kihasználva a modern lehetőségeket.

Friss hír a CSS változók bevezetése a WebKit böngészőkben, mely lehetővé teszi többször használt értékek változóként történő létrehozását, és használatát. A funkció hiánya korábban is felmerült már, és a vadabbnál-vadabb ötletekhez képest a megvalósítás ezúttal szerintem elég jól sikerült:

@variables {
  titleFont:bold 18px "Verdana, Arial";
  titleBG: #FF0000;
}
 
div.title {
  font: var(titleFont);
  background: var(titleBG);
}

Míg a Firefox 3 egetrengető CSS újdonságokkal nem jött ki (de sok apró fontosat megvalósított), addig a következő verziói érdekesebbek lesznek ebből a szempontból is. A Firefox 4-re (kb. másfél év múlva) ígérik a fejlesztők a CSS változókat ebben a böngészőben is, de a számított értékek támogatása, és a Webkit által már szintén implementált animációk és átmenetek is ekkor fognak megjelenni. A Firefox 3.1, melynek megjelenése közelebbi időpontban várható, támogatni fogja az összes CSS 3 kiválasztót, a text-shadow-t, a @media query-ket, a letölthető web betűkészleteket (@font-face), a font-stretch és word-wrap tulajdonságokat.

Az Opera 9.5 is az élen jár a CSS 3 implementációban, hiszen már megvalósította az FF3.1-re csak beígért összes CSS 3 kiválasztót, a text-shadow-t, a @media query-ket és még jópár dolgot, amivel részben elmaradásban volt (overflow-x, overflow-y, opacity), bővebben lásd a böngésző újdonságainak listái között.

Ami az Internet Explorer 8-at illeti, a fentiekhez képest jelentős lemaradásban van. Bár a CSS 2.1 támogatásban jelentős előrelépést fog hozni a tervek szerint támogatva a teljes szabványt, a CSS 3 kiválasztó támogatást, és a fentebb emlegetett újdonságokat még meg sem ígérték a fejlesztők (gondolom IE9-re már biztosan megérkeznek). Ezzel együtt persze ha már azt elérjük hogy a CSS 2.1 minden széleskörben használt böngészőben támogatva lesz, már annak is örülni fogunk.

A jövő stílusa, pontosabban a stíluslapok jövője a jelenlegi böngésző fejlesztési ütemben már talán nincs is olyan messze, ami látszik hogy az innovációban jelenleg az Apple/Webkit vezet, az Opera szintén egész jó, a Firefox pedig komótosan, egy népszerű böngészőhöz illő tempóban hajtja végre az ötéves tervet. A cél nem az, hogy rengeteg újdonságunk legyen, hanem hogy a már szabványnak mondható megoldások stabilizálódjanak, és erre is jó kilátások vannak.