Vagy pontosabban megfogalmazva lehetne ezen post címe Biztonság vs. őrült sebességű implementáció is. Ez jobban fedné a valóságot. Ugyanis már harmadszor történt olyan eset, ami elkerülhető lett volna, ha egyes böngészőfejlesztők nem játszadoznak Working Draft besorolású specifikációkkal.

Az első a sokak számára már ismert WebSockets volt, amikor is kiderült, hogy biztonsági szempontból kérdéses a specifikáció. Ekkor már több böngészőfejlesztő, köztük az Opera is implementálta. A Chrome kivételével a többiben (Firefox és Opera) a fejlesztők gyárilag letiltották. Ezekben az about:configból, illetve opera:configból lehetett manuálisan engedélyezni igény szerint, így itt már nem képezett biztonsági rést.

A második a <device> elem volt, de ennek nem volt biztonsági jelentősége, egyszerűen csak plusz felesleges munka volt vele.

És végül elérkeztünk a harmadik, eddigi legnagyobb esethez, amit a Microsoft indított el és sokak által (lásd például az ITCafén a kommenteket) ellenérzéseket váltott ki melyek a már örökzöld "csúnya, gonosz Microsoft" típusú kommentek formájában fogalmazódtak meg.

A probléma viszont nagyon is valós és komoly, függetlenül mindenféle járulékos haszontól.

Konklúzió: Természetesen a WebGL szó szerint új dimenziókat nyit a böngészés terén, de azért mint minden újdonsággal körültekintőnek kell lennünk, mert nyilván nem szeretne senki egy második Adobe Flash-hez hasonló biztonsági rést a böngészőbe építve.

Éppen ezért kár lenne ekézni a böngészőfejlesztőket azért, hogy milyen sorrendben és milyen sebességgel implementálják az adott specifikációt, ugyanis az egy bolond százat csinál elvét követve esélyes, hogy eleve lyukas alapokra építjük a jövő webes alkalmazásait, aminek beláthatatlan következményei lehetnek, amiket a linkelt blogon elég jól kifejtettek. A kékhalál a legenyhébb formája.

Az Operának a piaci részesedésénél fogva nem sok lehetősége van megfontolt lépésekre kényszeríteni a piacot, de jó látni, hogy a Microsoft is észhez tért, még ha van némi hátsó szándékuk is. Így talán többen átértékelik a kérdést és nem az lesz a legnagyobb probléma, hogy melyik böngészőben hogyan úsznak a halak.

Bő egy hónapja annak, hogy több éves fejlesztés után napvilágot látott az Opera webfejlesztő eszköztára, a Dragonfly. Azóta a programozók mély hallgatásba süllyedtek, és látszólag elégedetten dőltek a hátra a megfeszített munkát követően.

Nyilván így is volt, de a pihenő nem tarthatott sokáig, mert tegnapelőtt este befutott az 1.1-es verzió (b4527), pontosabban annak előzetes, még nem kiforrott változata. Amint azt a verziószám is mutatja, az előrelépés nem olyan óriási, de több ponton is komolyodott a szoftver tudása. A részleteket a Dragonfly blog bejegyzésében olvashatjátok, a lényeg címszavakban:

Továbbfejlesztett keresők - Az eddigi változatban a Dokumentum és a Szkriptek nézetben egyaránt lehetett keresni, méghozzá egy, az eszköztáron lévő dedikált gomb megnyomását követően. Ez legördített még egy eszköztárat - az oldalon belüli gyorskereséshez hasonlóan -, ide kellett gépelni. Ha több fájlban akartunk kutakodni, akkor további kattintásokra volt szükség.

A mostani verzióban a keresés - a fenti képen látható módon - egy külön panelt kapott a jobb oldali sávon, ahol egyszerre láthatjuk a kiemelt találatokat, illetve, - kattintás után - azok helyét a teljes dokumentumban és magán az oldalon. Ráadásul már nem csak szövegre, hanem reguláris kifejezésre is kereshetünk, akár a nagy- és kisbetűk figyelmen kívül hagyásával. Hasznos apróság - vagy inkább egy hiba javítása -, hogy már az egész DOM dokumentumban kereshetünk, nem csak az éppen látható, kibontott csomópontokban.

Pszeudó osztályok és elemek - az 1.0-ás verzióban csak akkor jelentek meg a pszeudó stílusok, ha kattintáskor aktívak voltak. Például a :hover, és a hozzá tartozó szabályok csak akkor jelentek meg, ha mondjuk az oldalon a kiválasztáskor a megfelelő felbukkanó elemek fölött volt a kurzor. De ha a DOM fában választottuk ki az adott elemet (mint mondjuk itt a blogon a legördülő menüket), akkor nem listázta ki a stílusok között. Egy legördülő listával már bekapcsolhatjuk az ilyen típusú elemeket is.

Helyi tárhely - Ilyen eddig is volt benne, az újítás az egységes megjelenési stílus.

Konzolok - A hibakonzol és a konzol szintén át lett kissé szabva. Előbbiben kevesebb helyet foglalnak el, és jobban átláthatóak a bejegyzések, utóbbiban színekkel is kiemelték a hibaüzeneteket és figyelmeztetéseket.

Javítások, optimalizációk - Bár a végleges verzió sem volt rossz ebből a szempontból, az 1.1-el még tovább csiszolták a szitakötőt, így még kevesebb hibát "tartalmaz", és a helyzet remélhetőleg később is javul majd. Mindemellett az optimalizációk sem kerülték el a szoftvert, így az eddig is gyors Dragonfly még fürgébb lett.

A munka persze ezzel nem ért véget, a későbbiek során további hibajavításra, optimalizációra, mi több, új funkcióra lehet majd számítani. Mikor? A fejlesztők reményei szerint még a nyári szabadságolási szezon előtt, ami véleményem szerint körülbelül egy 1 hónapos intervallumot jelöl.

Ha viszont már most ki szeretnéd próbálni ezt az előzetest, akkor semmi akadálya. Ha a Swordfish (Opera 10.50) valamelyik legfrissebb előzetesét használod - ami az új funkciók miatt erősen ajánlott is - akkor nincs más dolgod, mint elindítani a Dragonfly-t, hiszen automatikusan a legfrissebb változat töltődik be. Ha a stabil 11.11-et részesíted előnybe, akkor váltanod kell a kísérleti Dragonfly csatornára.

Főbb változások:

• Határozatlan állapot a HTMLInputElement.indeterminate és a checkboxok részére.
• EventSource engedélyezve a Web Workers részére.

Változások listája (Desktop):

• DSK-292114 Hibernációból való visszatérés után fülsáv újrarajzolási problémák
• DSK-338103 Összeomlás mikor Ctrl+Enterrel fület váltottunk és nyitva volt egy modális dialógus
• DSK-323390 Alt+Up és Alt+Down nem görgeti az üzeneteket többé
• DSK-336210 Menu > Mail > Read Mail nem jelenítette meg a leveleket
• DSK-337889 Privát füleken környezeti menüből indított keresés új lapon vagy új lapon a háttérben normál tabon nyílt meg [...]
• DSK-338097 "Suppress External Embeds" konfig beállítás nem működött
• DSK-338342 Mail fület tartalmazó mentett munkamenetek nem töltődtek be aktív levélfiók nélküli profilban
• DSK-338303 Egy munkamenet fájl ablakra húzása nem nyitotta meg az adott munkamenetet
• DSK-276827 Kukába dobott könyvjelzők továbbra is megjelentek a panel eszköztáron
• DSK-336892 Flash beépülő által okozott beragadt opera.exe processz üzenet túlcsordulás miatt.

Változások listája (Core):

• CORE-1886 Gyorsítótárazott HEAD kérések (XMLHttpRequest) hatással voltak a normál GET kérésekre
• CORE-6596 Továbbfejlesztett popup blocker (több popupot blokkol)
• CORE-7874 Rossz radial gradients (???)
• CORE-29798 parseInt sokkal gyorsabb lett
• CORE-30596 JS összeomlás
• CORE-37342 Magas memóriahasználat a browser.js miatt.
• CORE-37501 Érvénytelen dátummal rendelkező Link bejegyzések jobb kezelése
• CORE-38123 Form összeomlás
• CORE-38688 Kevesebb memóriát használ az ECMAScript kód forgatásához
• további Core javítások

Változások listája (Windows):

• DSK-286597 Az Opera újbóli elindítása, hogy új ablakot nyissunk SDI módban, nem működött

Változások listája (Mac):

• DSK-337930 QuickTime beépülő nem jelent meg, mikor háttérben lévő fülön töltöttük be (vagy az oldal nem látható területén)
• DSK-318787 Láthatóság attribútummal rendelkező szöveg nem rajzolódott ki, mikor a a baseline a rajzolási bufferen kívül esett
• DSK-314922 Fix the Save dialog's dislike for extension preferences

Változások listája (Linux/FreeBSD):

• DSK-337721 Kiválasztott (vagy aktív) nyomógombok nem voltak natívak GTK toolkitben

Letöltés (Opera 11.50 b1040) a jobboldali menüből. Vagy menü Segítség - Frissítések keresése pontjából