ai Gestori: Browser Opera

20/01/2012 14:03:18

zenida ha scritto:

Quoto a pieno il post Io apprezzo e mi piace molto opera infatti le land programmate e sul quale lavoro sono supportate tranquillamente da quest'ultimo.

penso sia un ottimissimo browser leggero e ben fatto :)

ammetto che invece detesto IE che non legge a stento nemmeno l'html XD

Ai miei tempi di niubbagine usavo sempre ie u.u non immaginavo cosa mi perdevo nel non usare mozzilla xD

Piuttosto, quello che non sopporto sinceramente sono quei gdr (pochi, ma ne ho visti) che, per fare il login o per registrarti, devi avere necessariamente il browser per cui la land è ottimizzata, altrimenti ti reindirizza al link dove scaricarlo >.<
(in ogni caso, per ogni evenienza io li ho istallati quasi tutti sul mio pc, mentre safari lo controllo tranquillamente sul pc di scuola che è un mac)

21/01/2012 17:30:06 e modificato da ilgrandeinverno il 21/01/2012 17:50:19

In un certo senso le vecchie icone browser per browser sono un po' vetuste. Sarebbe il caso se mai di parlare di compatibilità sulla base dei motori di rendering usati dai browser, che è ciò da cui dipende la visualizzazione delle pagine.

Abbiamo IE che è un discorso a parte visto che Trindent é usato solo da IE come motore di rendering in ambito web e nel quale tra una versione e l'altra cambiano moltissime cose. Poi c'è Geko, il motore usato da Firefox, Netscape, Seamonkey e pochi altri. WebKit, usato da Chrome e Chromium, Safari e una miriade di Browser leggeri e performanti nati di recente in ambiente Linux.

Questi tre motori di rendering rappresentano da soli circa il 98% del mercato ed è normale che l'attenzione dei gestori sia orientata a soddisfare prima questi.

Opera, che è un browser potente e performante, sfortunatamente usa un motore di rendering che nessun altro usa in ambito browser: Presto. E prima della versione 7 ne utilizzava uno ancora più "esotico", Elektra.


Diciamo che sviluppando secondo gli standard si può essere ragionevolmente sicuri di riuscire ad accontentare più o meno tutti.

Ad ogni modo a proposito degli standard andrebbe anche spezzata una lancia nei confronti di utilizzi non standard, o di feature che il w3c considera "deprecate", ma che nel ristretto ambito delle interfacce di gioco di un gdr online permettono al programmatore di risparmiare le centinaia di righe di codice che sarebbero necessarie per ottenere gli stessi risultati usando gli standard XHTML e CSS (più gli eventuali hack necessari a garantire la retrocompatibilità coi browser che non supportano nemmeno gli standard).

Ne nomino 2, sapendo che probabilmente mi attirerò gli strali dei fanatici dello standard a tutti i costi, ma francamente ci sono condizioni specifiche di utilizzo in cui un ricorso limitato al caro vecchio TABLE e al caro vecchio FRAME permette di fare cose che sviluppate secondo gli standard richiederebbero un massiccio uso di javascript e un aumento esponenziale della quantità di codice da scrivere (più tutti gli hack necessari a far vedere la stessa cosa nello stesso modo a tutti, visto che ad essere sinceri certe cose sono degli "standard" solo sui documenti del W3C).

Ma proprio il ristretto ambito di cui stiamo parlando e gli ambiti specifici di utilizzo in cui ci si muove, fanno decadere i motivi per cui alcune feature sono state "deprecate".

Come in molti ambiti che ci riguardano, andrebbe valutato in funzione dell'utilizzo e se quando l'esposizione del bollino di conformità HTML / CSS vale il tempo e la quantità abnorme di codice in più da scrivere, perchè un conto costruire un sito i cui contenuti devono essere accessibili ad utenti e motori di ricerca, un conto è un'interfaccia di gioco che genera contenuti "volatili" che non hanno alcun motivo di essere consultati esternamente alla sessione di gioco e pertanto per i quali la "deprecazione" del W3C sull'utilizzo di tag html molto più comodi delle rispettive controparti XHTML/CSS vale quanto il due di picche.