Ezt a plugint csak az Aptana erőlteti, néküle ugyan nem válik használhatatlanná, de az update/plugin kezelése és a css/js fileok zökkenőmentes szerkesztése sajnos nem megy e nélkül. Ma reggel rövid hajtépés után visszapakoltam 32bites Java-t és Eclipse-t, de továbbra is 64bites windows-on a memória miatt.

Azt még értem, hogy sokminden nincs még 64bitre elkészítve, mert a hétköznapi felhasználók között nincs ennyire elterjedve, de a fejlesztők között azért gyorsabban terjed, ha más nem, az Aptana kiadhatna egy saját fordítású XULrunner plugint 64bitre az Aptana stúdióhoz.

Bárkinek van hasznos tanácsa, szívesen fogadom.

Követelmények: szabványos html (xhtml) és css kódolás, javascript (DOM, prototype, jquery), smarty-php, photoshop alapok, böngészőfüggetlenség (főleg IE6, IE7, FF2/3)

Plusz jó pont ha ismered a CVS-t, van diszkrét, netán oop javascript gyakorlatod, esetleg flash/actionscript tapasztalataid.

Ha érdekel, dobj egy mailt a részletekért: nec@shell8.net

Explorerben következetesen oda rak vissza hol kattint az ember, ezért is idegesített ez a – látszólag véletlenszerű – viselkedés.

Ez így valójában egy erős usability hiba az oldalon, hosszabb találati listáknál nagyon frusztráló tud lenni, így nem árt odafigyelni rá. JS és CSS kukázások után végül a HTTP fejlécek vizsgálatába kezdtem, s meg is lett az ok.

Cache-Control: no-store, no-cache

Ez a dög valahogy bennemaradt az oldallal küldött fejlécekben, lehet hogy alapértelmezett webszerver beállítás, akkor pedig – hacsak a site szerveroldali részében felül nem bírálják – így marad.
Próbaképp átírva valami értékre, az a működés fogadott amit szerettem volna.

header("Cache-Control: max-age=300");

Valószínűleg emiatt a header miatt a FF valóban nem cachelt, s emiatt a Vissza gomb után újratöltötte az oldalt, ami viszont az oldal tetejére ugrott, mint megnyitáskor.

Viszon az, hogy ebbe viselkedésbe a Cache-Control HTTP fejléc hogyhogy nem szól bele IE, safari, opera, chrome böngészőkben… az más kérdés.

A Google persze, akárcsak az IE8 beta fejlesztői, rögtön gondol a fejlesztőkre, beépíett JS konzol (Page ikon Developer > JavaScript Console) JS debugger (kb ugyanott) és Element Inspector is vár ránk majd a Chrome-ban.

Nagy erősségnek a tabonként szeparált processzeket tartják, azaz pontosan azt amit a Firefoxban tarthatunk gyengeségnek, ha egy tabon megjelenitett site nagy terhelést okoz, az összes tab az egész böngészőben lelassuk, behal. Itt ezt kiküszöbölik azzal, hogy minden tab külön processz szál, tehát elméletben ha az egyik lassuk a többi vígan működhet tovább.

Furcsaság a faq alapján:

új ablak(tab) nyitása emiatt a processz szeparáció miatt kettéválik,

• az eddig megszokott alapeset, mikor új ablakot nyit a site ugyanabban a processzben maradunk, illetve
• lehetőség van az új ablakot/tabot külön processzként indítani, ezt javascriptel a nyitott ablak opener tulajdonságának nullázásával teszik meg a mutatott példában

Egyéb extrák:

• privacy mód – amit sokan csak úgy hívnak, hogy pornómód, azaz az ilyen módon nyitott ablakok nem logolnak semmit
• webalkalmazásokat megnyithatunk böngésző kezelőfelület nélkül, olyasféle módon mint ahogy Mozilla Prism
• frissített feketelista siteokról egyenesen a google-től, adatlopás védelem érdekében

update 1

tabok közötti processz menedzser, ami nagyonjó, nézzük melyik nyomorult site öli épp a rendszerünk!

update 2

google chrome képregény

update 3

a képregény 9. oldala alapján, a google miden verziót kiereszt tesztelésre akár siteok ezreire valamiféle chrome-botokkal, így elsőkézből kapnak információkat ha valami félremegy

És igazuk van. A felhasználók tömeges frissítése nehezen fog az ő oldalukról indulni, az oldalak, webalkalmazások fejlesztőinek is lehet lépéseket tenni ebbe az irányba. Ha valami elavult, indokold meg miért nem támogatod, ne csak a felhasználóknak, de az ügyfélnek, a főnöködnek és a pénzügyesnek is.
Egyszerű a dolog: mert egyáltalán nem, vagy többletmunka árán tudja ugyanazt a felhasználói élményt nyújtani. A többletmunka pénz, és a hatékonyságot rontja más munka kárára.

Frissíteni megéri a felhasználónak is, el lehet neki mondani, hogy ettől csak jobb lesz neki, az ő érteke is.

Addig is ott a graceful degradation elv, ami annyit tesz, hogy minél régebbi, vagy képességeiben gyengébb a böngésző, annál több felhasználói élményszintű szolgáltatás tűnik el az oldalról, meghagyva két alapvető pontot:

• az adatok megjelenjenek,
• navigálható legyen az oldal.

PNG helyett egy csúnyább gif, flash helyett alternatív tartalom, ajax helyett aloldalak, apróságok.

Ahelyett, hogy kiírod: márpedig ez csak firefox alatt fog futni, inkább csak közöld, hogy a böngésződ nem nyújtja mindazt a szolgáltatást ami igazából ehhez a sitehoz kéne, frissíts. Tedd kíváncsivá a látogatót.

Amíg ezeket a lépéseket nem kezdjük el mi, fejlesztők, addig egy szavunk se lehet arra, hogy sokan használják még az Explorer 6-ost.

• csak részben betöltött CSS
• néhol hiányzó képek, háttérképek

és persze mindezek miatt el lehet képzelni, hogy egy site mennyire szarul képes kinézni.

Pánik indult, elkeztünk hibákat keresni, más böngészőkkel vizsgálni, de minden más rendesen viselkedett. Ráadásul az IE6 teljesen kiszámíthatatlanul csinálta, ütögettük az F5-öt, a hiba hol előjött, hol nem, ha előjött akkor se biztos hogy ugyanúgy mint korábban, más képek hiányoztak, más oldalrészleket vesztették el a stílusokat. A Fiddler használatával (ami egy nagyszerű debug proxy IE alá, bár néha képes fura dolgokra) láttuk, hogy a fileok letöltődnek, minden jónak tűnhetett volna.

Ami fura volt, hogy az ügyfél, aki külső tesztkörnyezetet nézte, nem jelzett hibát. Ott a site jól viselkedett.

Az egyetlen különbség a két környezet között az url volt.

Fejlesztés során elég hosszú urleket használunk, mivel a fejlesztői környezetek más-más szerveren, más-más projektet, más fejlesztők készítenek közösen. Ebben a projektben kötőjelet használtunk a névben ami az urlbe került. Próbaképp átirattuk kötőjel mentesre, és a probléma eltűnt, az IE6 a megszokott (de úgyahogy ismert) bugjaival működött szépen.

Összegzés:

Aloldalak esetén az url utáni elemek, ha tartalmaztak kötőjelet, nem okoztak ilyen problémákat. Biztos ami biztos, maradjunk meg kötőjel mentes urleket használni, amíg az IE6 életben van…

Legjobb példa erre az oldalon elhelyezett, valamilyen módon tabulált adatszerkezet lekódolása. Nem Amazon féle tabos menüre gondolok itt, hanem inkább egy doboz, widget az oldalon, melynek a tartalmát vizuálisan tabokra osztották fel.

Gyakran kódolják a tab füleit és tartalmát logikailag külön, ami eléggé rossz. Vegyük ezt például:

<!-- rossz tabolás -->
<ul>
	<li class="tab1"><a href="#">Tab 1</a></li>
	<li class="tab2"><a href="#">Tab 2</a></li>
	<li class="tab3"><a href="#">Tab 3</a></li>
</ul>
<div class="tab1">Tab 1 tartalom</div>
<div class="tab2">Tab 2 tartalom</div>
<div class="tab3">Tab 3 tartalom</div>

Ez a megoldás szétválsztja a tab címét, kapcsolóját a tartalmától amihez tartozna, s így az információ az oldalon valami inkoherens masszaként lebeg, mely a vizuális értelmezésre vagy javascript kontrollokra hagyatkozik a működését illetőleg.

Miért ne tehetnénk a tartalmakat egymásba ágyazott listákba, vagy definíciós listákba (dl, dt, dd) egy logikusabb elrendezésért. A megjelenítés finomhangolása ugyan továbbra is a stíluslapoktól függ, a működése lehet css alapú vagy javascript hajtotta, de a kódszerkezet maga utal arra, mit is szeretnék valójában kihangsúlyozni.

<!-- egy jobb tabolás -->
<ul>
	<li class="tab1">
<h4>Tab 1</h4>
<div class="tab1">Tab 1 tartalom</div></li>
	<li class="tab2">
<h4>Tab 2</h4>
<div class="tab2">Tab 2 tartalom</div></li>
	<li class="tab3">
<h4>Tab 3</h4>
<div class="tab3">Tab 3 tartalom</div></li>
</ul>

Igy az üres linkeket is eldobhatjuk, a címsorokat kontrollnak formázhatjuk, és íme, van egy szép, akadálymentesebb és keresőbarátabb kódunk.