I browser sono oggi uno strumento indispensabile e, molto probabilmente, l’applicazione software più nota in circolazione. Se un tempo questo primato spettava ad applicativi come Microsoft Word, oggi il podio è occupato dall’applicazione che ha rivoluzionato l’informatica, la comunicazione e forse il mondo intero. Grazie alla sua semplicità, il browser si è diffuso rapidamente e con capacità adattive che pochi altri applicativi hanno saputo mostrare: cross platforms (multi-piattaforma) e cross devices (multi-dispositivo).
Navigare su Internet è possibile proprio grazie al browser; possiamo usarlo da un PC, da un Mac, da un palmare, dai nuovi “telefonini”.
Articoli con Tag ‘Internet-Explorer’
Internet Explorer: la più grande campagna virale mai realizzata?
Internet Explorer 6: eliminare il baco del doppio margine
Tra le varie simpatiche “interpretazioni” che Internet Explorer 6 riesce a fare con HTML/CSS, quella del “doppio margine” è sicuramente la più noiosa e frequente. In pratica (udite, udite…) il buon browser Microsoft riesce – misteriosamente – a raddoppiare i margini sugli elementi impostati in float! Dato ad esempio il seguente codice CSS, applicato ad un div con id box:
CSS3: qualcuno ha visto Internet Explorer?
Io proprio no…
1 2 3 4 5 6 7 8 9 | p { /* Rounded Corners */ border-radius: 9px; /* CSS 3 */ -o-border-radius: 9px; /* Opera */ -icab-border-radius: 9px; /* iCab */ -khtml-border-radius: 9px; /* Konqueror */ -moz-border-radius: 9px; /* Firefox */ -webkit-border-radius: 9px; /* Safari */ } |
jQuery contro tutti: un benchmark con 5 browser
Un buon sviluppatore non ha problemi a passare da un linguaggio di programmazione ad un altro. La scelta di concentrarsi su un particolare linguaggio, framework o ambiente di sviluppo, è dettata più dalla disponibilità di tempo e dal tipo di lavoro che si svolge. Tuttavia, un fattore importante che può influire sulla scelta di “framework” simili, è la simpatia o l’affezione che può maturare con il tempo.
Nello specifico, ho voluto analizzare alcuni – non certo tutti – framework Javascript disponibili oggi, anche perchè “consigliato” a dare un’occhiata soprattutto a jQuery.
I creatori di mootools (uno dei più noti framework Javascript) hanno reso disponibile uno strumento per eseguire un test di velocità e validità su cinque noti framework Javascript: Slickspeed. Questo test, dagli esiti non affatto scontati, è importante in quanto i framework Javascript operano lato client, cioè vengono eseguiti dal nostro browser. È proprio per questo motivo che alcuni trovano Safari più rapido di Internet Explorer o Google Chrome più rapido di FireFox. Tuttavia ciò spesso dipende anche dal tipo di pagina che si sta visualizzando. Infatti può benissimo capitare che un particolare sito sia davvero più “veloce” se visualizzato in Safari, ma questo non significa che “tutti i siti” saranno più veloci con Safari! Ovviamente questo discorso è valido per qualsiasi altro browser.
Il benchmark
Nel test che ho effettuato con Slickspeed ho messo a confronto i browser disponibili sulla mia macchina (Windows Vista Utilmate 64bit – Intel core 2 quad a 2.4GHz con 8Gb RAM).
Purtroppo il test non sono riuscito ad eseguirlo con Internet Explorer 7, in quanto bloccava la macchina, andando anche fuori scala con i risultati! Ancora una volta complimenti Microsoft.
Ho crercato di mantenere identico lo stato del PC durante l’esecuzione dei test, aprendo singolarmente i browser e non mandando nessun altro processo in esecuzione.
Nota: se avete voglia di eseguire anche voi uno o più di questi test, potete commentare questo post in caso di “curiosi” e diversi risultati.
Google Chrome è risultato davvero veloce, con un valore di 68 (media) nell’esecuzione dei test con jQuery. Il più lento, invece, è risultato Flock, nonostante provenga dalla stessa “madre” Mozilla. Questo pessimo risultato di Flock è davvero curioso visto il suo taglio Social Network; perchè sono proprio i Social Network Web 2.0 a sfruttare molti dei framework Javascript disponibili, così da fornire un’esperienza di navigazione ed interazione davvero innovativa.
A sorpresa Opera batte FireFox e anche di un bel po’, ottenendo addirittura un 74 nell’esecuzione di Dojo! FireFox e Safari, tutto sommato, si assomigliano, con Safari più rapido nei test con Mootools e jQuery.
Quale framework scegliere?
Se non badiamo ai test sulla velocità di esecuzione e non ci preoccupiamo della dimesione in Kbytes dei framework stessi, la risposta potrebbe essere “quello che più vi piace” o, se preferite, “quello che conoscete meglio o vi risulta più armonico con il vostro stile di programmazione”.
In ultima analisi questi framework si assomigliano un po’ tutti (vedi l’uso del $ ad esempio), nonostante alcune importanti e sostanziali differenze che possono saltare agli occhi di un esperto o nell’uso davvero spinto di una particolare libreria. In linea di massima, infatti, tutto quello che si può realizzare con jQuery, ad esempio, lo si può fare benissimo con mootools o prototype! Se jQuery vanta una sintassi estremamente compatta, in quanto tutti i metodi restituiscono sempre l’oggetto base jQuery, creando così file interminabili di oggetto.metodo().metodo().metodo()... non è detto che questo sia a tutti i costi un punto di forza, soprattutto per chi dovrà fare il debug!
Librerie come prototype.js peccano forse in assenza di effetti grafici, anche semplici, costringendo lo sviluppatore ad implementare spinoff come scriptaculous.js, pesanti e distanti dalla libreria inizialmente scelta.
Un esempio
Proprio quest’ultimo motivo, ad esempio, mi ha portato a sostituire l’accoppiata prototype/scriptaculous con jQuery per realizzare i pannelli interattivi/animati qui nella sidebar di undolog.com. In effetti, usando anche Google API per importare le librerie, è uno spreco caricare tutta la libreria scriptaculous per uno slideDown e slideUp. A titolo informativo e di esempio, ecco com’era il codice Javascript con l’accoppiata prototype/scriptaculous:
1 2 3 4 5 6 7 8 9 10 11 12 13 | // prototype/scriptaculous $$('h2.dropdown').each( function(element) { element.style.cursor="pointer"; element.observe('click', function(event) { if( this.next().style.display == "" ) new Effect.BlindUp(this.next(),{duration:.5}); else new Effect.BlindDown(this.next(),{duration:.3}); Event.stop(event); } ) } ); |
e com’è adesso con jQuery:
1 2 3 4 5 6 7 8 9 10 | // jQuery $('h2.dropdown').each( function(i) { $(this).css('cursor','pointer').click( function() { if( $(this).next().is(':hidden') ) $(this).next().slideDown(); else $(this).next().slideUp(); } ); } ); |
Tutto sommato, a ben guardare, non mi sembra ci sia moltissima differenza! Ma come dicevo prima… è questione “anche” di gusto personale.
Unobtrusive SWFObject 2.0
SWFObject è uno script Javascript utilizzato per inserire contenuti Flash all’interno delle pagine Web. La sua principale funzione è quella di eliminare la richiesta di attivazione del controllo da parte di Microsoft Internet Explorer (che, comunque sia, è in fase di dismissione – vedi qui) e, più interessante, la capacità di verificare ed installare automaticamente il Flash Player ove richiesto. SWFObject può considerarsi un’ottima alternativa al kit di install/detect fornito dalla stessa Adobe e generabile all’interno dell’IDE Flash (in tutte le sue versioni). Con la versione 2.0, SWFObject migliora le sue performance e il suo utilizzo. Come indicato sulla documentazione ufficiale, spostata su Google Code, le novità di questa release sono talmente tante da renderlo NON compatibile con le precedenti versioni. Questo si traduce di fatto in una revisione completa del codice per chi decidesse di aggiornare una precedente versione SWFObject alla 2.0.
Lo script è ora allineato agli ultimi standard, sia dal punto di vista sintattico che da quello “non intrusivo”. Supporta tutte le precedenti features, come l’installazione rapida del Flash Player, con un codice più chiaro e facile da usare. Il passaggio dei parametri, ad esempio, da Javascript al Player Flash (e quindi al nostro filmato) è ora assai più chiaro e versatile. Inoltre sono stati introdotti due principali modi di funzionamento: statico e dinamico, in base al tipo di pagina e processo di design che stiamo effettuando.
Utile e davvero bon fatto è il tool online che genera il codice SWFObject per noi.
LINK:
Addio IE7, seguito da Sage: leggere i feed RSS su Windows
Sinceramente le ho provate tutte! Non mi andava di usare un’applicazione esterna per leggere i feed RSS! Pensavo (e mi sono ricreduto) che avendo già un browser aperto fosse scomodo legarsi ad una diversa applicazione.
Così ho iniziato con il lettore RSS presente in Internet Explorer 7. Ma da quando ho installato Windows Vista mi è negato visualizzare i feed… problemi di protezione. Se “sblocco” IE7, a tempo debito, mi cominiciano ad apparire “alert” sparsi (un po’ da Windows e un po’ dal buon Norton 360) che mi invitano a ripristinare le impostazioni di protezione del browser in modo corretto, pena essere “bucato” da mezzo mondo. Insomma, con IE7 – almeno su Windows Vista – non è proprio possibile leggere in santa pace i feed RSS.
Abbandono IE7 (era ora!) e promuovo il buon FireFox come browser predefinito (era davvero ora!). 
Installo quindi Sage, una estensione per FireFox. Semplice… Forse anche troppo!
Diciamo pure “limitata”. Comunque sia, oggi, ho scaricato FeedReader, versione 3.12, uno dei più noti, almeno dando uno sguardo in giro per il Web. Fantastico! Un nuovo mondo davvero. Segnalo anche questo lettore, sempre per Windows, FreeDeamon, secondo me fatto molto bene… anche se per certi versi preferisco FeedReader.
Aprile 2008: addio all’attivazione dell’ActiveX per Flash
Sul blog di Internet Explorer (IE Automatic Component Activation (Changes to IE ActiveX Update)) è stato annunciato un’importante cambiamento che avverà introno ad aprile 2008, con il rilascio di importante patch, compresa la tanto attesa Service Pack 3. Un’anteprima, tuttavia, sarà disponibile entro dicembre 2007 dal centro download di Internet Explorer.
Nell’aprile 2006, infatti, Microsoft aveva introdotto una patch in Internet Explorer che bloccava l’interazione con i componenti ActiveX presenti in una pagina Web. Questo “blocco”, alla fine, si risolveva nella richiesta esplicita – diretta all’utente/navigatore - di attivare il controllo (filmato Flash, QuickTime, etc…) tramite la barra spaziatrice o un click del mouse.
Nel tempo, tuttavia, sono state introdotte tutta una serie di scorciatoie per evitare questa fastidiosa richiesta, scorciatoie ufficiali (proposte ad esempio dalla stessa Macromedia per Flash e da Apple per QuickTime) e non ufficiali (SWFObject o UFO, ad esempio – vedi anche Unobtrusive Flash Objects).
Secondo Microsoft gli sviluppatori non dovranno modificare nulla ad aprile 2008 nei “vecchi” siti che utilizzavano scorciatoie, tuttavia è bene dare un’occhiata al blog di Internet Explorer per i casi particolari.
Microsoft torna quindi sui suoi passi, ed effettivamente ci eravamo chiesti un po’ tutti che idiozia fosse questa dell’attivazione del controllo, “pezza” adottata per una carenza nella gestione degli ActiveX (TAG OBJECT) più che a falle nei componenti stessi. Negli altri browser, infatti, l’uso dei Plugin è accompagnato dal più solido TAG EMBED. Ultima nota:
In the coming weeks, we’ll be updating the MSDN article with descriptions of the new behavior. Keep an eye out here for when the preview goes live.
Note sul testing e debug in Adobe Flash
Una considerazione, ovvia ma sottovalutata, durante lo sviluppo di applicazioni in Adobe Flash: la differenza tra il Player utilizzato per il testing all’interno dell’IDE Flash e l’oggetto (ActiveX o EMBED) usato dal nostro browser. Chi possiede la versione “Macromedia” Flash MX (la versione 8 per intenderci, ma questo discorso in realtà vale per qualsiasi versione di Flash…) quando sviluppa un filmato e lo prova all’interno dell’IDE Flash manda in esecuzione il Player legato al pacchetto di sviluppo. Quando poi si pubblica il filmato sulla rete e lo si “prova” con il Player Flash del browser si potrebbero riscontrare alcune – sostanziali – differenze!
 |
 |
Xopus: editor XML in WYSIWYG
Xopus è un editor XML (HTML) in WYSIWYG mode funzionante all’interno del browser. L’avevo già notato qualche tempo fa, grazie ad un articolo uscito su Ajaxian. Ne parlo ora in quanto rimane un’interessante proposta nel panorama web2.0/editor. È un’esperienza interessante! Xopus è sviluppato davvero bene (con supporto italiano), con un’ottima implementazione del menu contestuale, anche se ancora non pienamente cross-browser; alla attuale release 3.1 è supportato solo Microsoft Internet Explorer (versione 6 e 7) tuttavia gli sviluppatori hanno promesso quanto prima una versione compatibile almeno con Firefox (il 1 febbraio è stata rilasciata in alpha la versione 3.1.1 compatibile in Firefox 2.0+).
Come già discusso altrove, la questione della compatibilità (il cross browser) attraverso i browser, rallenta e penalizza lo sviluppo di strumenti che, anche non ricorrendo a tecnologie particolari come Applet Java o Adobe Flash, potrebbero portare un notevole contributo alla Comunità! Conttibuto impedito – alla fine – dalle inutili lotte interne degli attuali produttori di browser: IE, Firefox, Opera, Mozilla, Safari, … !
Visionando i demo si intravede anche qualcosa in più del semplice editor HTML, per dirla in parola povere. Xopus propone infatti sia la struttura classica dell’editor, sia funzioni avanzate sullo stile di Microsoft Word. È possibile, infatti, inserire all’interno della pagina veri e propri oggetti intelligenti che rispondono a determinate caratteristiche, rendendo Xopus un caso particolare.
Come indicato sul sito:
Xopus is a good solution for any business that has a back-end content management system and a front-end publishing-system and therefore two systems which use the same information. To structure that information, to make both ends meet, is therefore a must.
Poete guardate il video dimostrativo che introduce le avanzate caratteristiche di editing. Inoltre potete provare direttamente una demo.
Browser War: la guerra continua?
A Sunnyvale, California, Yahoo riunisce al Silicon Valley WebBuilder Mike Shaver di Mozilla, Chris Wilson del team Microsoft di IE e Hoon Lie di Opera, per confrontarsi sull’attuale state dell’eterna guerra tra i browser.
Da sottolineare sono le parole di Mike Shaver di Mozilla:
Don’t look to the W3C for the future
E le critiche alla mancata presenza di Apple:
They refused to send someone saying that “we are busy writing software”.
Che, tra l’altro, dista 10 miglia da dove si è tenuto l’incontro!
Ultimi Commenti
Marco: Ti ringrazio moltissimo, mi hai illuminato
ho risolto impostando [cc_objc] //OptionViewController.m -...
Giovambattista Fazioli: @Marco: Ti consiglio un approccio credo più corretto. Se hai eseguito il subclass del tab...
Marco: Scusa lo spam.. ho notato che c’è un errore.. ecco la correzione [cc_objc] /** PrimaClasse.h **/ #import...
Marco: dimenticato.. in [cci]OptionViewController[/cci ] il [cci]@syntetize[/cci] del delegato l’ho messo
luigi: molto chiaro e semplice devo ammettere che anche scrivendo da un pà difficilmente uso delegati creati da...