Se ci si trova a sviluppare in un ambiente dove è impossibile usare tool di debug come FireBug, come ad esempio il simulatore Apple iPad di Xcode, può diventare frustante individuare problemi, uno tra tutto l’errato accesso alle proprietà di un oggetto. Ecco che l’uso della funziona alert() diventa fondamentale!
Articoli con Tag ‘Safari’
Very short trick: log degli oggetti Javascript
FireFox 3.5.7: come risolvere il difetto dei bordi arrotondati su un’immagine
A volte basta spostare un elemento, cambiando punto di vista, per risolvere un problema apparentemente insuperabile. Quando poi si ha a che fare con compatibilità tra i browser e CSS, inventarsi soluzioni “spettacolari” (acrobazie direi) è all’ordine del giorno. Quello che vi mostro è un modo semplice per applicare bordi arrotondati a delle immagini utilizzando -moz-border-radius, disponibile per Mozilla FireFox e -webkit-border-radius, per Safari e Google Chrome.
Very short trick: disabilitare il ridimensionamento di una textarea su Safari
In tutti i browser sviluppati partendo dal motore di rendering WebKit (come apputo Safari o Google Chrome), i campi textarea mostrano, in basso a destra, la caratteristica funzionalità di resizing. Se questa particolarità può risultare davvero utile in certi casi, in altri si trasforma in un elemento fastidioso.
jQuery: bordi rotondi sulle immagini per sovrapposizione
A causa dei diversi rendering tra i vari browser, che vedono sicuramente Microsoft Internet Explorer in testa, bisogna sempre ricorrere ad artifizi particolari per applicare effetti che, ormai, dovrebbero rappresentare uno standard. I pluri-discussi bordi arrotondati sono un classico esempio del “disastro” prodotto dalla completa incapacità di realizzare uno standard serio sul rendering delle pagine HTML/CSS. Esistono in rete numerosissime soluzioni che permettono di ottenere “effetti” (effetti che esonerano dall’HTML attuale come bordi arrotondati, effetti ombra, riflessioni, etc…) con patch sui fogli di stili, particolari trucchi con l’uso di div innestati, librerie Javascript, uso delle canvas, etc…
A titolo puramente didattico vorrei illustrare un’ulteriore tecnica (cross-browser) per applicare dei bordi arrotondati a delle immagini:
Demo e sorgenti
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.
Firebug Lite: Firebug per IE, Opera e Safari
Tramite Firebug Lite è possibile utilizzare una versione semplificata della nota estensione per FireFox sui browser Microsoft Internet Exploer, Opera e Apple Safari. Firebug Lite può essere utilizzato in due modi: come chiamata Bookmark o come libreria offline
Bookmark mode
Aggiungendo questo “indirizzo speciale” Firebug Lite ai nostri bookmark (trascina il link nei preferiti) – il codice è:
1 | javascript:var%20firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.pi&&window.firebug){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug); |
Sarà possibile attivare Firebug Lite su qualsiasi sito Web e da qualsiasi browser. Questa è forse l’opzione più interessante, nonostante le funzioni siano davvero limitate.
Offline
In alternativa, se stiamo sviluppando noi un sito Web, è possibile scaricare un pacchetto Javascript ed installarlo sul nostro Web! In questo modo possiamo usare Firebug Lite anche senza una connessione Internet ed in locale.
Firebug Lite è un modo per compensare la mancanza di questa estensione per gli altri browser, tuttavia a me è risultato lento e davvero molto limitato, soprattutto nei CSS! Come si dice: meglio di niente…
Safari, eliminare il blue border sui campi input
Safari, il browser Apple disponibile anche per Windows, produce un bordo blu (blue border) quando si clicca all’interno di un campo input. Se in alcuni casi può risultare piacevole, in altri diventa davvero fastidioso! Per eliminarlo basta inserire nel nostro foglio di stile:
1 2 | /* ____________________________ remove blue border */ input { outline: 0 none } |
O, in alternativa, direttamente come attributo nel tag input:
1 | <input style="outline: 0 none" ... /> |
Resa nel ridimensionamento delle immagini sui browser
In linea di principio quando si inserisce un’immagine in un documento HTML bisognerebbe utilizzare le sue dimensioni originali. Tuttavia il TAG IMG permette di forzare la larghezza (width) e l’altezza (height) di una qualsiasi immagine, indipendemente dalle dimensioni originali. Questa operazione di ridimensionamento viene svolta – ovviamente – dal browser.
Usare le dimensioni orginali di un’immagine è buona cosa, nonostante in alcuni casi comporta un doppio lavoro per il Web Designer e/o i motori dinamici (CMS ad esempio o librerie di manipolazione grafica) presenti sul Web Server. Un classico slide show, ad esempio, di norma mostra delle anteprime o thumbnail (immagini di dimensione ridotta) che se selezionate mostrano l’immagine originale più grande.
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.






Ultimi Commenti
Andrea: Un altra spiegazione dettagliata la potete trovare qui!! http://www.cianiandrea.it/arch ives/413
Daniela: Ciao! Provo a chiederti un aiuto per risolvere il mio problema. Sto migrando il mio blog da tumblr a...
Giovambattista Fazioli: @ale: Come indicato @Kevin vedi sul repo di GitHub: https://github.com/gfazioli/Ch roma-Key
Giovambattista Fazioli: @Kevin: See https://github.com/gfazioli/Ch roma-Key
Kevin: Very nice example – would like to see the .fla too!