Magyar Opera

Opera Mobile 12.1 Androidra

Bár itt a blogon elsősorban az asztali Operával foglalkozunk, be kell látni, hogy a cég mobil fronton sokkal sikeresebb. Ennek elsődleges letéteményese az Opera Mini, de azért a teljes értékű változat, a Mobile sem népszerűtlen, annak ellenére sem, hogy a gyárilag előtelepített böngészőkkel kell megküzdenie. Hogy ez így is maradjon arról a ma megjelent 12.1-es verzió hivatott gondoskodni.

Mint az Opera kiadások általában, ez is számos újítással érkezett. A lista lényegi része:

Szabvány támogatás:

  • CSS Flexible Box Layout Module (aka Flexbox) támogatás (mint a ma megjelent asztali előzetesben)
  • CSS Animations támogatás
  • CSS Transitions támogatás frissítése
  • javított WebSocket implementáció (RFC6455)
  • javított Media Queries implementáció
  • részleges HTML5 Drag&Drop támogatás
  • HTML5 Clipboard API támogatás
  • contentEditable/designMode
  • SPDY protokoll támogatása
  • Page Visibility API

Kompatiblitás:

  • egyes -webkit előtagok támogatása

Biztonság:

  • megtévesztő oldalak elleni védelem (Fraud protection)

Architektúrák támogatása:

  • MIPS
  • X86

További fejlesztések:

  • CPU szűrés támogatása a Google Play áruházban (gondolom a telefonnak megfelelő verzió települ)
  • csökkentett méretű telepítő

A fentieket részben a Presto 2.11.355 teszi lehetővé, ami már 418+11 pontra jogosítja a Mobile-t a nem hivatalos HTML5 tesztoldalon.

Az új verziót szokás szerint a Google Play alkalmazásboltból töltheted le a telefonodra.

A bejegyzés trackback címe:

https://magyaropera.blog.hu/api/trackback/id/tr674829486

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

franatixx 2012.10.09. 22:41:08

Tehát akkor ez a flexbox új specifikációja amit implementáltak (annak tűnik)? Ha igen, akkor az dicséretes, csak meg ne változzon nagyon (megint).

Mesmoryser 2012.10.09. 23:11:41

HTML5 teszten megint jól elhúzott a Mobile, a 418 pontja után a Chrome 371, iOS 360, de még a tabletes RIM browser is csak 393 pontos. És az a jó, hogy fontos specifikációk kerültek bele.

Egyébként már csak azért is várom az ilyen hivatalos megjelenéseket, mert mindig élmény olvasni Cousin összefoglalóit :)

Teddy Beer 2012.10.10. 20:19:17

@Mesmoryser: Ezzel most nem megy semmire. Pár dolgot le kéne nyúlni másoktól, nem a csimbók html5 teszteken izmozni, mivel attól nem lesz jobb a "felhasználói élmény".

cousin333 · http://magyaropera.blog.hu 2012.10.10. 20:40:12

@franatixx: Igen, ez az új specifikáció.

@Teddy Beer: A HTML5 teszt nem 3DMark, tehát eléggé releváns. Azt nézi, hogy bizonyos specifikációk támogatottak-e. Ha pedig igen, akkor az adott oldal megfelelően jelenik majd meg (legalábbis ez az elmélet). Versenyezni meg nem a többi mobilos böngészővel kell, hanem az asztali változatokkal, elvégre a honlapokat elsősorban oda írják.

Teddy Beer 2012.10.10. 20:49:44

@cousin333: Mobilos gui a lényeg, nem az oldal betöltése. Html5 még kész sincs és már az elejétől fogva saláta az egész, ami ha az oldalak és a "szabványok" arányaiban nézünk nem elterjedt. 2014-ig még van idő, addig erőforrás pocsékolás, csak az opera azt hiszi hogy ettől egyenlő lesz a net minden böngészőnek, ami már kiderült hogy közel sem igaz és nem is feltétlen a technikai elmaradottság vagy előrefutás miatt.

cousin333 · http://magyaropera.blog.hu 2012.10.10. 22:29:19

@Teddy Beer: Szerintem az Opera GUI-jával nincsen különösebb probléma. Mondjuk a gesztusvezérlés hiányát nem igazán értem.

Az, hogy a HTML5 nincs kész, az nem teljesen igaz. Legalábbis amennyire értek hozzá, a HTML5 leíró nyelv készen van, a csatolt részei meg a megvalósítás különböző fázisában. Arról nem is beszélve, hogy ilyen komplex és globális dolognál nincs olyan, hogy elkészítjük és kiadjuk, oszt' jóvan. Több iteráción kell végigmenni, valós alkalmazásokban tesztelni. Aztán jöhet az átdolgozott szabvány és annak implementációja (lásd a Flexboxot, mint legutóbbi példát). Meg aztán az egész web folyamatosan változik, nincs olyan, hogy "teljesen kész".

Attól, hogy egyes cégek visszaélnek az erőfölényükkel még nem hiábavaló a nyílt szabványok támogatásának javítása.

Darkcomet 2012.10.11. 08:12:32

A Mobilos GUI-t kicsit át kéne dolgozni. Pl. jó lenne, ha a flash playert egy mozdulattal lehetne ki és bekapcsolni, a beállításokba való turkálás helyett. Jó lenne, a turbó mód ki és bekapcsolásához is egy forró gomb. Aztán nem ártana éjszakai mód sem, természetesen valsztható módon. Jó lenne, ha a hosszú érintéses menü bővíthető lenne egyéni igények szerint. És a könyvjelzők szinkronizálása helyett vagy mellett nem ártana, ha lementhetőek lennének a bookmarkok, beállítások. Viszont hatalmas respect a fejlesztőknek, hogy a kb. 2 hete publikussá vált android rendszert böngészőkön keresztül is érintő tamadhatóságot relative hamar bezártak.

Mesmoryser 2012.10.11. 14:42:51

@Darkcomet: Az miért nem jó, hogy Flash Playert beállítod Lejátszás kattintásra? Turbo mód ugyancsak WiFi esetén ki, és nincs vele gond.
Éjszakai módnak én is örülnék, és a hosszú klikkes menü is lehetne okosabb. A többi nem igazán hiányzik.

Darkcomet 2012.10.11. 15:05:37

@Mesmoryser: Ha ki van kapcsolva a flash player, akkor bizonyos oldalaknál a videó lejátszását át lehet adni az alapértelmezett videó lejátszónak. Pl. Ilyen az indavideo.hu is, ahol ha nincs flash, akkor csak képként hozza be a videót, de rá kattintva nálam az MX player faszán lejátsza, illetve a megosztás opción keresztül közvetlenül meg lehet osztani a videó direkt linkjét letöltő programokhoz (pl. AndroGet). Viszont ezt a módszert nem minden oldal eszi meg, ezért lenne jó egy gyorsgomb a flsahplayer aktiválásához.

A turbó mód nálam alapértelmezett. Viszont a chapchat igénylő letöltő oldalak nagy, részénél turbo mód alatt nem lehet megetetni az oldallal a kódot.

Darkcomet 2012.10.11. 15:14:43

@Mesmoryser: Ja igen. A legújabb androidos Opera Minivel is meg lehet bolondítani az indavideot. Ugye az egyik új szolgáltatása az lett az androidos OM-nek, hogy faszán le tudja követni a többszörös atiranyításokat is, és ugye az inda ezzel trükközik. Ha az indavideo.hu nem egyoszlopos nézetben van megnyitva, akkor szintén képként jelennek meg a videók, amikre rányomva az OM felkinálja a letöltést. Ha ez előtt sikerül leállítani az atiranyítást, tehát amikor a videó direkt linkje megjelenik, akkor az url-t tovább lehet osztani az alapértelmezett videó lejátszónak.

Nameless® · http://dirtywindows.hu/ 2012.10.11. 15:40:25

Nagyon sokat fejlődött, kb kétszer gyorsabban indul és sokkal kevesebbet foglal. Egyetlen hiba van vele ami még mindig megkeseríti az életemet, az az amikor a rendszer elküldi aludni az Opera folyamatát vagy netán be is zárja memória hiány miatt, visszatéréskor el kezd szaggatni indokolatlanul az egész. Ha megint lerakom a háttérbe meg előhozom megjavul. Ki érti ezt.

Emiatt nem használom mert hosszú másodpercek telnek el mire megint betölt. Ha sikerülne még csökkenteni az állomány méretét, akkor jobb lenne. Meg ezt a szaggatást nem tudom hogy bugreportoljam. Amúgy sincs semmi értelme mert eddig is leszarták a bugreportokat.

Nameless® · http://dirtywindows.hu/ 2012.10.11. 15:42:13

@Nameless®: ja igen és az meg külön idegesítő hogy minden kiegészítésre entert kell ütnöm a virtuális billentyűzeten hogy megnyissa az adott oldalt, ami rettentően feltud idegesíteni amikor belassul a telefon.

Nekomajin · http://nekomajin.wordpress.com 2012.10.11. 16:57:30

@cousin333:
Van egy kis fogalmi zavar a HTML5 körül, mert ugyan maga a rövidítés, meg az előzmények a jelölőnyelvre utalnak, de maga a HTML5 egy eléggé összetett dolog. Magába foglalja a jelölőnyelvet, a CSS3-mat, egy nagyrakás JavaScript API-t és még pluszban más új technológiákat is.
Olyan értelemben készen van a nyelv, hogy az új elemek meg attribútumok készen vannak, és az implementációjuk is elég jól halad. Azoknál az elemeknél van még fennakadás, amik komolyabb JS vagy szabványosítási támogatást is igényelnek.

@Teddy Beer:
Újra és újra előkerül ez a téma, és nem hiszem el, hogy nem tudjátok megérteni, hogy ez a technológiai fejlődés menete. A böngészőgyártóknak MUSZÁJ folyamatosan implementálni a félkész specifikációkat, mert ha nem csinálnák, akkor nem derülnének ki a hibák, és sose lenne kész a specifikáció. Egy asztal körül soha nem fog kiderülni az összes biztonsági rés meg bug, ahhoz a gyakorlatban kell őket alkalmazni. Az Opera meg végképp nem teheti meg, hogy arra vár, hogy a többiek elvégezzék a munkát, mert ha ennél is jobban leszakad, akkor önerejéből nem tud visszakapaszkodni.
Azt meg nem tudom, hogy honnan szedted, hogy a HTML5 nincs elterjedve, mikor az összes Google meg MS felhőszolgáltatás arra épül, és már a Facebook meg a Twitter is elég rég óta használja. Ha ezek után nem elterjedt, akkor sose lesz az.
Ráadásul a legnagyobb hülyeség arra hivatkozni, hogy azért ne támogassák a böngészők az új specifikációkat, mert senki se használja őket, hiszen nyilvánvaló, hogy senki se fogja használni őket, ha nincs böngésző, ami értelmezze. Ebben a játszmában mindig a böngészőknek kell egy lépéssel előrébb járniuk, hogy a webfejlesztők tudjanak mire fejleszteni.

Imurai 2012.10.12. 18:27:03

Érezhetően gyorsult...

Teddy Beer 2012.10.13. 00:39:19

@Nekomajin: De nem mindegy mekkora erőforrásból. Ez nem megértés. Stratégia. A hegyeket is előmászók készítik fel a csúcshódításra. Az operának is így kéne gondolkodnia, csak az egyszerűbb végén fogták meg a dolgot, aminek az a vége, hogy a usernek nem jelent semmit az erőfeszítés, mert a felhasználói élményben nem jön ki igazán mi az a html5, így nem is alakul ki semmilyen hűség. A Mini pedig egyértelmű példa hogy ma még vidáman el lehet lenni html5 nélkül a neten.

Nekomajin · http://nekomajin.wordpress.com 2012.10.13. 08:48:16

@Teddy Beer:
Már hogyne jönne ki, mikor a világ legnépszerűbb webes szolgáltatásai mind tucatjával használják a HTML5 újításait. Tökéletes példa erre a drag and drop, amiben le volt maradva az Opera. Ég és föld a felhasználói élmény dnd-vel és dnd nélkül. És ez pont olyan, amit a felhasználó közvetlenül is érzékel. De ott van például a clipboard API, ami megváltás lesz egy csomó webfejlesztőnek, akik nem szeretnek flash-sel vacakolni. De a felhasználónak se mindegy, mert ha véletlenül tiltva van a flash a böngészőben, akkor a jelenlegi megoldás nem működik.
Ezek a fejlesztések igen is kijönnek a felhasználói élményben. A webfejlesztőknél meg főleg. Sokkal egyszerűbb egy natív JS metódust használni, mint külső JS könyvtárakat vagy flash alkalmazásokat integrálni.

cousin333 · http://magyaropera.blog.hu 2012.10.13. 19:20:31

@Teddy Beer: Nem igazán értem a hegymászós hasonlatot. Ha arra gondolsz, hogy majd a többiek kitapossák az ösvényt, aztán jöhet az Opera, akkor szerintem hibás az álláspontod. Az új szabványok támogatását senki nem fogja kifejleszteni az Opera helyett, ezt meg késő elkezdeni akkor, amikor a többiek már megjelentek vele. Tipikus példa a Google, aminek megvannak a megfelelő oldalai, amik azonnal építhetnek is az újításra (pl. SPDY, drag&drop).

A Mini is rossz példa, mert az is Presto-t használ (méghozzá viszonylag frisset), csak nem a telefonon, hanem a szervereken. A HTML5-öt még semmi nem támogatja - mert még semmi nem is támogathatja! - a maga teljességében, így legfeljebb annyit mondhatunk, hogy a Mini a támogatás alacsonyabb fokán áll. Szerintem az emberek arra a honlapra vágynak, amit a PC-n látnak, és ha ki vannak szolgálva, akkor húzzák a szájukat a visszalépésnél (lásd iOS felhasználók, amikor iPhone-ra is megjelent a Mini). Azt látom, hogy a Mini felhasználók tábora szépen növekszik, de ez - mármint a mobilos netezés terjedése - világtrend. A Mini meglovagolja ezt, talán kicsit gerjeszti is, de nem ő kiváltója. Ha azt is megnézzük, hogy hol népszerű, akkor még egyértelműbb, hogy a Mini nem azért népszerű, mert nem támogatja a HTML5-öt - ami nem is teljesen igaz -, hanem mert a megjelenítés kompromisszumait bőven ellensúlyozza, hogy: kicsi, ingyen van, minden sz@ron elfut, multiplatform, kis adatforgalmat generál és gyors.

Az erőforrások meg mindig is megoszlottak a hibajavítás, sebesség-növelés, funkcióbővítés és a szabványtámogatás javítása között. Ehhez jöttek néha hozzá olyan extrák, mint mondjuk a minialkalmazások, vagy a Unite. Amikkel egyébként szintén nincs gond, ha sikerre viszik őket.

ui: Most olvasom Nekomajin hozzászólásait, teljesen egyetértek velük.

Nekomajin · http://nekomajin.wordpress.com 2012.10.13. 22:30:25

@Teddy Beer:
Ha nem érted meg, hogy miről beszélünk, akkor tegyél fel mondjuk egy két évvel ezelőtti Operát, és próbálj vele Gmailt, Skydrive-ot, Facebookot, Twittert vagy akár csak egy Wordpresses blogot használni! Majd meglátod, hogy mekkora a különbség.

cousin333 · http://magyaropera.blog.hu 2012.10.13. 22:32:51

@Teddy Beer: :)

Átlagfelhasználóként is ez lenne a véleményem. Csak így indokolni is tudok.

Amúgy szerinted mi probléma van mondjuk a HTML5 fokozatos implementációjával? Úgy értem, ha amúgy sem használja senki, akkor mit zavar az téged, hogy ők azért fejlesztenek? Vagy azt mondod, inkább javítsanak csak bugokat? De fogadjunk te leszel az első, aki böngészőt vált ha nem megy rendesen a kedvenc oldalad (nem mintha ez nem lenne ma is probléma... :) ).

penge™ · http://www.thevenusproject.com/ 2012.10.14. 02:58:48

@Nekomajin: "Ég és föld a felhasználói élmény dnd-vel és dnd nélkül. "

Ezt konkrétan _az Opera esetében_ nem mondanám. Ugyanis se a Google szolgáltatásokban, sem máshol nem lehet DnD-t használni Operával. Máshol meg volt JS fallback, szóval a mezei felhasználó semmi változást nem vesz észre (egyébként ezen oldalak kb. 90%-án továbbra is JS fallback van, vagy alapból JS, mindenféle HTML5 nélkül).

A Clipboard API helyett ugyancsak mondhattál volna értelmesebb példát, amit azon usereken kívül (elhiszem, hogy sokan vannak), akik képtelenek megtanulni pár alapvető billentyűkombinációt (mint Ctrl+C vagy Ctrl+V) is hasznát veszi valaki. A Flash legalább letiltható volt. Már csak abban reménykedem, hogy nem lesz benne biztonsági rés és nem tudja bármilyen hülye scriptkiddie felhasználni user jóváhagyás nélkül, hogy felülírogassa a vágólapot minden látogatónak.

Persze oké, hogy working drafttól óvakodnak kicsit de azért van sok marhaság, ami attól, hogy a HTML5 része, még marhaság vagy olyannyira specifikus, hogy ezzel az erővel sokkal relevánsabb dolgokat is implementálhattak volna helyette. A teljeskörű Forms támogatás is leginkább bürokratáknak jöhet jól. A video/audio már nem rossz, de ha legalább valami félhivatalos lehetőséget biztosítanának külső codec-ek (mint H.264 és MP3) használatára meg persze kiegészítő, ami a browser sniffinget kiüti a megfelelő oldalakon, mivel Chrome-nak még mindig nem lehet oldalspecifikusan maszkolni, akkor annak is több értelme lenne. De így kaotikus az egész. Bár én már annak is örülnék, ha a YouTube nem lenne tetűlassú és a Flash (az OOPP miatt) nem lenne már jobb, mint a WebM, ami továbbra is elég erőforrásigényes + a lejátszó is bugos + a Fullscreen API sem engedélyezett Opera alatt a Google jóvoltából.

De ha már hasznos(!) HTML5 feature-öket sorolunk, akkor kezdem: egységes parser, elements, Web applications, WebGL (amihez HWA kéne) XHR2, WebSockets, Web Workers, CORS, File API, Local Storage

és ami még nincs: Sandboxed iframe, Seamless iframe, Asyncronous script execution, FileSystem API, IndexedDB, Web Notifications, Web Audio API

A Page Visibility-t valaki említette még korábban, hogy az milyen jó lenne, aztán megnéztem a specifikációt. A szándék nemes, de ha az adf.ly és a többi retek elkezdi majd használni (mert arra nagy összegben mernék fogadni, hogy előbb kezdi majd el használni, mint a tényleg csupascript oldalak a nagyokat (Google, Facebook) leszámítva), akkor visszanyal a fagyi.

@cousin333: Számomra az SPDY semmilyen változást nem hozott. Semmivel sem lettek gyorsabbak sem a Google-s oldalak, sem a Twitter. Ráadásul mivel a HTTP-re épül, így tipikusan az a cucc, aminek a hiánya még annyit sem jelent, mint egy border-radius hiánya. Ha annyit gyorsítana, ami már érezhető és nem csak laboratóriumi körülmények között mérhető, vagy ha valami funkcionális/vizuális hátrány származna a hiányából, akkor azt mondom, hogy van értelme. De így bőven jegelhették volna még. A HWA-nak is nagyobbnak kéne legyen a prioritása, mert ott azért lenne WTF effect az átlaguser részéről is, ha normálisan megcsinálnák.

Nekomajin · http://nekomajin.wordpress.com 2012.10.14. 20:54:44

@penge™:
12.02-ben kiválóan működik a dnd Gmailben és Skydrive-ban is. Az viszont lehet, hogy valami JS library-t használnak, annak nem néztem utána.

A clipboard API nagyon is értelmes példa, mert a ctrl+c - ctrl+v baromi kényelmetlen tud lenni, ha az ember az egérrel hadonászik a weboldalon. Sokkal egyszerűbb, ha csak bele kell kattintani egy mezőbe, hogy a vágólapra másold a tartalmát, vagy rákattintani egy gombra. Ilyet most is használnak sok helyen, csak egy láthatatlan flash alkalmazás kell hozzá. Ami pont nem működik, ha le van tiltva a flash, aztán a felhasználó csak néz, hogy mi van.

De ezek, ahogy írtam, csak példák. Te is soroltál egy csomó újítást, amik közül több már most is elengedhetetlen része a legnagyobb weboldalaknak. Arról nem is beszélve, hogy mennyire megkönnyítik a webfejlesztők dolgát. Elég csak arra gondolni, hogy nagyságrendekkel egyszerűbb localStorage objektumokat kezelni JS-ben, mint sütiket.

A SPDY-t csak asztali gépen próbáltad, vagy valami retek mobilnettel is?

franatixx 2012.10.15. 00:11:19

@Nekomajin:
A clipboard API az nem a másolás "megkönnyítésére" lett kitalálva, hanem a segítségével lehetővé válik bonyolultabb objektumok (formázott szöveg, képek, sötöbö) másolása/beillesztése is, szabványos módon, hekkelés nélkül.

penge™ · http://www.thevenusproject.com/ 2012.10.15. 04:43:58

@Nekomajin: Drive-ban megfogok egy fájlt, elindul a belső drag effekt. Normál méretű böngészőablakban próbálom kihúzni a desktopra, semmi.

Desktopról/intéző ablakból próbálok fájlt behúzni a Drive-ba, elindul a fájlletöltés localhostról (azaz nincs DnD).

"Ami pont nem működik, ha le van tiltva a flash, aztán a felhasználó csak néz, hogy mi van."

Fájlmegosztókon ugyanez volt és én nem éreztem szükségét, hogy engedélyezzem a letiltott Flash-t. Viszont megfeledkeztem a divatos touchscreen eszközökről. Ott valóban problémásabb lehet a Ctrl+C Ctrl+V, szóval igen, így már van értelme neki.

SPDY-t csak asztalin 80/25-ös 4-es pinges DIGI-vel. Lehet, hogy ez a baj? :) Na tessék, kimaradok minden jóból... Már előre pesszimistán várom az IPv6-ot, gondolom ott sem fog majd feltűnni a nagyobb méretű, fragmentálatlan csomagokból származó előny. :D

Nekomajin · http://nekomajin.wordpress.com 2012.10.15. 14:41:33

@franatixx:
Nem akartam belemenni ilyen részletekbe, mert már így is le lettünk geekezve.

@penge™:
Az a baj, hogy magadból indulsz ki, pedig te is tudod, hogy a te netezési szokásaid meg az átlagemberé még köszönőviszonyban sincs egymással. Te szereted fél kézzel a billentyűzetet bűvölni, mert fejből tudsz egy csomó kombót, az átlagember meg annak örül, ha a böngésző egy kattintásra kijelöli a teljes szöveget, és még a vágólapra is másolja egyből, mert neki az a kényelmes.
A SPDY-t meg szerintem próbáld ki valami gyenge kapcsolattal is, mert biztosan nem azért nyomta ennyire a Google, hogy a szintetikus tesztek pontszámaival villogjon. A JS motorok fejlesztései se a 4 magos erőműveken jöttek ki elsősorban, hanem a gyengébb gépeken. De szerintem ezt te is tudod, szóval nem is értem, hogy miért vitázunk.

franatixx 2012.10.15. 19:21:27

@Nekomajin:
Szerintem ez nem annyira részletkérdés, (nekem éppen hogy a kattintós másolás az ami eszembe nem jutott volna).

Ami viszont igen, de azért kijavítalak (:P):
A js motor gyúrása majdnem ugyanannyit számít a sokmagos erőgépeken is, mivel lényegét tekintve a scriptek egy magon futnak (workers ide vagy oda), normális, komolyabb animáció leszámolása (mondjuk valami 3D-s játék) pedig még azokat is megizzasztja. Nem hiába erőlteti a Google az NaCl-t.

Nekomajin · http://nekomajin.wordpress.com 2012.10.16. 16:21:37

@franatixx:
Ez rendben van, de az erősebb proci eddig is gyorsabban hajtotta végre a scriptet. Nyilván mindenhol gyorsabb lett a JS futatása, de arányaiban a gyengébb gépeknél szembetűnöbb a dolog.

Darkcomet 2012.10.17. 11:27:14

@cousin333: Szerintem az Opera Mini népszerűségét az adja, hogy az alapvető szolgáltatásokat (böngészés, olvasgatás, kommentelés, levelezés) tökéletesen hozza, mindezt piti adatforgalom mellet. Na már most tekintettel a mobiltelefonok kijelző méretére, ez bőven elég. Minden más csak luxus, amit nem árt, ha egy mobilos böngésző támogat, de a kijelző méret korlatoltsága miatt egész egyszerűen nincs rá szükség,mivel plussz szolgáltatások ide vagy oda, telefonon, ha van, Opera Mobillal inkább az adott oldal mobilos verzióját használom, mint a teljes desktop verziót. A tabletek világa már egy egészen más tészta. Ott tényleg ajánlott dolog az, ha egy böngésző egy asztali browser élményét nyújtja. De a tablet mint kütyü nincs egy lapon a mobiltelefonokal. Ezzel nem azt akartam mondani, hogy az Opera Mobile rossz böngésző, sőt, nálam a stock browser helyett ez az alapértelmezett böngésző, de néha idegbajt kapok tőle. Hosszú távon nem ártana, ha szétválasztanák a telefonos platformot a tabletestől.

Mesmoryser 2012.10.17. 12:30:56

@Darkcomet: Pontosan mit kéne szétválasztani, mi az ami idegesít? A UI most is szét van választva, mobilon alul van a menüsor, tableten felül. A weboldalak kinézetét pedig nem a böngészőnek kell szétválasztani, hanem az oldal készítőjének.

A mobilon luxus - nem luxus témához: a HTML5-ös API-k egy része kifejezetten mobilon óriási segítség. Például egy Geolocation API nélkül asztali gépen három másodperc alatt bárhonnan odagörgetsz a jelenlegi pozíciódra, míg mobilon megöregedsz, mire sikerül odanyomogatni. Ellenben így egy kattintás, és ott vagy. Vagy ott van a DeviceOrientation API, ami kifejezetten mobil eszközökön működik/működne, csak még semmi nem használja, pedig sok lehetőség van benne. De említhetnék pár olyan CSS fejlesztést is, ami pont a kijelzőméretek közti óriási különbséget teszi áthidalhatóvá. És ott van még egy rakat újdonság, amivel a Flash száműzhető a mobilból.
Én azt mondom, hogy a mobil = olvasgatás + levelezés hozzáállás pont azért alakult ki, mert hatékony megoldások híján kis képernyőn, gyenge számítási teljesítménnyel élvezhetetlenek voltak a weboldalak. Ezen a téren sokat fejlődtek a szabványok, már csak ki kéne használni őket.

Bluemotion 2012.10.17. 16:54:42

Nem tudom hogy ez már egy új Gúglis fícsör, de a FB-os kommenteknél nálam már nem jelennek meg a felhasználók bélyegképei. Más is tapaszt hasonlót?

Mesmoryser 2012.10.18. 15:21:28

@!Hello: Mi köze a gúglinak a fészbukkos bélyegképekhez?

Bluemotion 2012.10.28. 16:52:51

@Mesmoryser: Két dologra koncentráltam és sikerült egybegyúrni a kettőt. :)

Google: Youtube, csúszka folyamatosan ugrál léptetés közben.

Facebook: Nem jelennek meg a FB-os kommenteknél a felhasználók képei.

Bluemotion 2012.10.28. 16:54:13

@MosoMasa: Már lassan egy hónapja nincs új post.

MosoMasa 2012.10.29. 11:34:41

@!Hello: Azt látom, azért kérdeztem.

Mihics Zoltán (Med1on) 2012.10.31. 15:39:01

Nem akarom osztani az észt, de ha a blog szerkesztőinek nincs ideje az oldalra, akkor talán kereshetnének új tagokat, akik be tudnának segíteni. Csak egy ötlet.

Dzsini 2012.10.31. 18:30:18

@Med1on: Már többször feldobták, hogy várják az aktív szerkesztőjelölteket, szerintem ez azóta sem változott.

Mihics Zoltán (Med1on) 2012.10.31. 18:58:51

@Dzsini: 1 próbát viszont megérne a dolog.

penge™ · http://www.thevenusproject.com/ 2012.10.31. 22:14:44

@Med1on: Elvileg kaptál meghívót. Fogadd el, ha gondolod. Nem nagyon tolong senki, hogy szerkesztő lehessen.
süti beállítások módosítása