Az olvashatóság javításában két remekbe szabott kiterjesztés lesz a segítségünkre, név szerint a CleanPages és a Readability.

Gyakran előfordul, hogy a számítógép előtt töltött huzamosabb idő után a betűk összefolynak, az olvasás egyre nehezebbé válik. Ilyenkor természetesen a legjobb egy kis szünetet tartani, de előfordulhat, hogy erre nincs lehetőségünk.

A CleanPages segítségével egy kattintással átalakíthatjuk az éppen látogatott weboldalt, ahol így eltűnnek a reklámok, a betűméret, a betűtípus és a színek pedig olyan formát öltenek, mint amilyet mi szeretnénk. Az egyéb lehetőségeknél kikapcsolhatjuk a képeket, a videókat, a haladó beállításoknál pedig útmutatást láthatunk ahhoz, hogy egérmozdulattal aktiváljuk az átalakítást - ajánlott itt is szétnézni, mert további érdekességeket is olvashatunk. Telepítés után érdemes testre szabni a különböző paramétereket, hiszen később ezen beállítások fognak érvénybe lépni.

A hasonló feladatokra hivatott Readability valamivel összetettebb, hiszen több közösségi szolgáltatás található benne. Ettől függetlenül egyszerűen használható kiterjesztésről van szó, az adott weblap átalakítása itt is ugyanazon módszerrel történik. Igazi finomság, hogy billentyűkombináció alkalmazására is van lehetőségünk. Az előbb említett funkció mellett hasznát vehetjük még az úgynevezett Read Later opciónak is, amivel későbbi áttanulmányozás céljából elmenthetjük a kiszemelt anyagot.

Sajnos a CleanPages és a Readability is kudarcot vallhat egy-egy bonyolultabb weblapnál, ám egy jól megírt oldalnál (elvileg) nem lehetnek problémák. Előbbi kiterjesztés kiforrottabb, nagyobb népszerűségnek örvend, utóbbi viszont számos speciális funkciót kínál - ilyen például a megosztás a Twitteren és a Facebookon vagy a küldés a Kindle e-book olvasóra.

Kattintásra megnő, s PNG formátumba vált. [+]

+1

Az olvashatóság az úgynevezett text shadow használatával is javítható. Ehhez készítettem (egész pontosan némiképp megvariáltam) egy interneten fellelhető stíluslapot, amit ide kattintva lehet letölteni. A művelet után át kell helyeznünk a fájlt a felhasználói CSS mappába - az Opera névjegye megmutatja az elérési utat -, majd a böngésző újraindítása után a Stílusok között (a Lap menüponton belül) megtaláljuk a Reader nevezetű fájlt. A várható változást a fenti kép demonstrálja. Az alsó fele CSS nélkül, míg a felső rész már a text shadow alkalmazásával jelenik meg.

Eme remekbe szabott kiterjesztést olvasóink egy része már biztos ismeri, de mivel (még) nem jelent meg az Opera bővítmények katalógusában, és nálunk sem kapott elég figyelmet, ezért mindenképpen megérdemel pár sort.

Az Imagus előtt is felmerült már, hogy a nagyítható képeket miként lehetne egyszerűen, gyorsan megtekinteni. Erre született meg az ImagePreviewPopup és az ImgTip, de mostanra mind a kettő fejlesztése leszállóágba került. Időközben további ötletek láttak napvilágot, illetőleg az Opera is hatalmas fejlődésen ment keresztül a böngésző kiterjesztések terén. Az Imagus szerencsére követi a norvégok újdonságait.

A fejlesztő, név szerint "Deathamns" kérdésemre elmondta, hogy bár az Imagus már napi szinten jól alkalmazható, azonban addig nem szeretné feltölteni az Opera kiegészítők katalógusba, amíg az 1.0-s verziót el nem készíti. Ez sajnos idén nem fog összejönni, ám ahogy előzőleg olvasható volt, az alkalmazás már most is stabil lábakon áll.

Nagyító

Fontos megjegyezni, hogy az Imagus egyáltalán nem a már korábban megjelent kiegészítők másolta (ImagePreviewPopup, ImgTip), sokkal több azoknál. Elsőnek is: a felugróban megjelenő képeket forgathatjuk, tükrözhetjük, a méretét az ablakhoz, a szélességhez és a magassághoz igazíthatjuk. Arra is lehetőségünk van, hogy a megtekintett állományokat egy galériába küldjük, amit az Imagus beállításainál találunk meg.

Nézőke

A kiterjesztés révén lehetőségünk van feltuningolni az Opera alapértelmezett képnézegetőjét. Az egyik kedvencem, hogy a Shift + az egér vonszolása nagyít a kijelölt részre (Ctrl lenyomásával mozgatni lehet), ezenfelül a Shift + jobb klikk egy menüt csalogat elő, mely számos további funkciót kínál. Ismét csak a legérdekesebbeket említve: transzformáció, méretezés, képfeltöltés a pixlr.com-ra (ingyenes online képszerkesztő). Érdemes rászánni pár percet a nézőke áttanulmányozására, hiszen a görgővel történő nagyítástól az oldalháttérig mindent beállíthatunk - az egyéni ikonról és a képkeretről már nem is beszélve.

Sokak szemében mostanra talán túlságosan bonyolultnak tűnik az Imagus. Számukra jó hír, hogy van magyar nyelvi támogatás, ezenfelül afelett sem szabad elsiklani, hogy a kiterjesztés az alapértelmezett beállításokkal is igen jól használható.

Letöltés:

• Opera kiterjesztés: Imagus

Mivel az Opera 12.10 biztonsági okokból letiltja a külső kiterjesztések telepítését, ezért fel kell vennünk az oldal címét (http://files.myopera.com/Deathamns/extension/imagus/) a biztonságos weboldalak listájába ((Ctrl+F12) / Haladó beállítások / Biztonság / Megbízható weboldalak). A másik megoldás, hogy lementjük a fájlt, majd bedobjuk a böngészőbe.

A végleges Opera 12.02 már ma megjelent, a 12.5 alias Marlin viszont még csak a távoli(?) jövő zenéje. Ebben a fejlesztési szakaszban pedig jellemző (legalábbis mostanában, hisz' nem volt ez mindig így), hogy a szorgos javítgatások mellett időről-időre komolyabb újdonság kap helyet a böngésző lelkét jelentő Presto renderelő motorban.

Érdekes módon a legutóbbi nagy javítás szinte egybeesett a 12.01 érkezésével, két nappal később jött, most viszont ugyanennyivel előzi a 12.02-t. Az, hogy az ezekről szóló cikkek nálunk pontosan egybeesnek inkább a mi hibánk...

De vissza a 12.50.1577 újdonságaihoz, mert akad belőlük jócskán. Illetve esetenként az az új, hogy bekerültek a fősodorba, hiszen a teljes képernyős (Fullscreen) API, vagy az SPDY protokoll támogatás nem új azoknak, akik  bő másfél hónapja már olvasták a Labs kiadásról szóló cikkünket. Ezek tehát helyet kapnak majd a 12.5-ben, ha nem is pont ebben a formában. A Fullscreen API ugyanis még a februári szabványvázlatot tükrözi, de az Operánál már dolgoznak a frissebb, júliusi állapot kódba öntésén. Hiába, ezek még nem kiforrott technikák.

Ami viszont az és már régóta hiányolható a böngészőből, az a színprofilok támogatása. Arról van szó, hogy bizonyos képtípusokban lehetőség van a kép adatain túl extra információk elhelyezésére, például a színtér definiálására, amiknek inkább professzionális felhasználásnál lehet jelentősége. Viszont bizonyos webhelyeken már használatosak egy ideje és a különbség igen látványos lehet.

Vegyük például a lenti képet a kissé lökött Opera alkalmazott Bruce-ról, aki - bár a kép alapján ki nem találnánk - meglehetősen otthon van a HTML5 területén, olyannyira, hogy könyvet is írt róla. Ha a böngésződben a felső képen is inkább navii-nak látszik, mintsem embernek (azaz kék a bőre), akkor nem támogatott a színprofilok használata. Mint a 12.50.1577 előtt egyik Operában sem.

Bonyolítja a dolgot, hogy alapvetően két fő verzió létezik, a v2 és a v4 (a legfrissebb egészen pontosan a v4.3). Egyes böngészők - például a Chrome - csak az előbbit támogatják, mások - például az IE9 és most már végre az Opera is! - az utóbbit is. Az ICC honlapján lévő tesztkép alapján erről mi is meggyőződhetünk. Ha a kép teljesen normális, böngészőnk a v4-et támogatja. Ha két negyed is furcsa színű, akkor v2-ről van szó, ha pedig mind a négy rész torz, akkor még nem frissítettük az Operánkat a legfrissebb előzetesre.

A dolog gyakorlati hasznát talán jobban le lehet mérni más példákkal. A megadott oldalon számos képet látunk, alattuk linkekkel. A felső sorbeli gombokra  állva megnézhetjük, hogy az egyes színterek milyen különbséget jelentenek. Az alsó soron végigmenve ugyanezeket láthatjuk, de már beágyazott színprofillal, aminek segítségével a böngésző - elvileg - ugyanazt az eredményt adja minden esetben, változást tehát nem tapasztalunk.

Ha már kiörvendeztük magunkat, lépjünk is túl ezen, hiszen van még más is. Nem is olyan régen az Operánál úgy döntöttek - jól vagy rosszul ezt most ne feszegessük - hogy mások mellett süllyesztőbe teszik a Unite-ot és a minialkalmazásokat, hogy jobban a kiegészítőkre fókuszálhassanak. Amikre rá is fér a támogatás, hiszen még a Chrome-os megfelelőikben is több a potenciál, nemhogy a firefoxos változatban.

Persze csak lépésről-lépésre haladnak, most például a környezeti menü (Context Menu) API került bele, aminek segítségével a fejlesztők képesek elemeket hozzáadatni az Opera környezeti menüihez. Az erre fogékonyak itt olvashatják az API dokumentációját.

Ezen felül jutott még a jövevénybe fordított lista (HTML5-ös reversed ol), valamint beágyazott @media támogatás, ezekről bővebben az ODIN blogon lehet olvasni. De hozzányúltak a billentyűzet kezeléshez is, amit főleg a Mac tulajdonosok fognak értékelni. A többieknek marad a lehetőség, hogy billentyűzettel jelöljenek ki szöveget.

Mindezen túl érkezett még egy raklapnyi javítás és apró optimalizáció a WebGL-hez, a Dragonfly-hoz, a hálózat kezeléshez és úgy általában az Operához. Egy jópofa újítás a ráncfelvarrott opera:cpu, ami már négyzet alakú narancssárga jelölőket használ, de ami sokkal fontosabb: a fülek listájában szereplő kis vissza-nyílra kattintva, alul windows feladatkezelős stílusú grafikonban tájékoztat az adott oldal időbeli processzor-éhségéről, ami további segítséget jelent a gépet "megfogó" renitens oldalak felkutatásában és elliminálásában.

A sok jó mellé pár bug is jutott: a Gyorshívó bejegyzései automatikus frissítés után kiüresedhetnek, illetve - és ez a durvább - Linux/Unix alatt minden beépülő fagy...

Ha még mindig érdekel, a teljes változási közleményt megtalálod a Desktop Team bejegyzésében.

Letöltés (Opera 12.50.1577):

Ez az írás nem lesz olyan hosszú, mint a korábbiak és részben a 11.10 által bevezetett display:none módosítás kapcsán jött létre.

Akik követték az eseményeket, tudják miről van szó, akik nem, azoknak pár mondatban: Az Opera a kompatibilitás növelése érdekében a 11.10-ben megváltoztatta a működését a CSS display tulajdonság esetében.

Az ajánlás nem tér ki minden részletre, mint például arra, hogy be kell-e tölteni az elrejtett tartalmakat addig, amíg azok meg nem jelennek az oldalon. A többi böngésző fejlesztői úgy gondolták, hogy igen. Ez azt okozta az évek során, hogy sokan kényelemből, sokan JS tudás hiányában olyan esetekben alkalmazták a display:none szabályt, amikor nem kellett volna.

A probléma inkább esztétikai jelentőségű volt, vagyis ilyenkor az Operában, az egyetlen olyan böngészőben, ami nem töltötte be a display:none tulajdonsággal ellátott tartalmakat, elkezdtek villogni, mivel akkor töltötte be, amikor az adott eseményre (például mouseover) megváltozott az elem display tulajdonsága.

A két legszembetűnőbb példája, hogy mikor egy menü fölé vittük az egeret az vagy 1-2 másodperc késéssel jelenítette meg az animációt az első alkalommal, illetve áttűnős diavetítést tartalmazó oldalakon az első alkalommal a képrenderelést (felülről lefelé) láttuk a képváltáshoz társított effektus helyett.

Az előnye viszont a csökkent adatforgalom és ennél fogva csökkent betöltési időn túl az volt, hogy CSS szabályokkal el lehetett rejteni a reklámokat, így bizonyos esetekben sokkal egyszerűbb volt a dolgunk, habár a megbízható tartalomblokkolás továbbra is az urlfilter.ini maradt.

Ezt a lehetőséget kezdetben (8.x verziók körül) még csak UserCSS-vel lehetett kihasználni, utána Lex1 készített egy hibrid megoldást, végül pedig a Local Storage bevezetésével megszületett a NoAds, először userJS, később kiegészítő formájában.

Azóta megjelent a sokkal hatékonyabb URL Filter API is és az arra épülő megoldások, mint az Opera Adblock De sajnos az URL Filter korlátai megmaradtak, vagyis a RegExp hiánya és a element alapú blokkolás hiánya.

Viszont itt jön képbe Dither, aki elkészítette a NoAds Advanced 1.2.1b-t, ami nem pótolja az elveszett display:none-t, de az URL Filter API-nak köszönhetően legalább egy részét visszakapjuk a korábbi lehetőségeinknek.

Változások, a NoAds óta:

• URL Filter API támogatás a hatékonyabb Adblock Filterlista integrációért.
• widgets storage-nak köszönhetően exportálási lehetőség
• Átdolgozott beállítások
• MagicFunction/MagicVariable alapú blokkolás

MagicFunction/MagicVariable példák:

##var GTracking
##var NO_msnads
##function poker_pp
##function print_download_ads
##function trackEvent 
##function trackPageView
##function trackPageViewCustom
##function wmx_counter
##function wmx_track
##function wtslog

A HTML5 rendelkezik egy autoplay attribútummal a video és audio elemeknél. Emiatt sokan szitkozódhatnak, mivel látszólag ez problémát okoz bizonyos körülmények között, például irodában, vagy képernyő felolvasó szoftverek használatakor, de teljesen egészséges embereket, otthoni környezetben is az őrületbe kergethet, ha felüvölt egy videó.

Simon Pieters most rámutat, hogy valójában miért is jó ötlet az autoplay attribútum.

Removing the attribute will not make pages stop autoplaying video. Instead they will use script to make videos autoplay, and then it becomes harder for the user to prevent videos from autoplaying. (You could have a pref in the UA to disable autoplay.)

Magyarul:

Az attribútum eltávolításával nemhogy megakadályoznánk, hogy automatikusan induló videókat készítsenek a tartalomszolgáltatók, hanem ehelyett különféle scripteket alkalmaznának a célra, amellyel megnehezítenék a felhasználók számára, hogy kiiktassák az automatikusan induló videókat.