jQuery: bordi rotondi sulle immagini per sovrapposizione

Giovedì 30 Ottobre, 2008

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

Continua a leggere… »

Post correlati

CSS3: qualcuno ha visto Internet Explorer?

Giovedì 16 Ottobre, 2008

Io proprio no...

CSS:
  1. p {
  2. /* Rounded Corners */
  3. border-radius: 9px; /* CSS 3 */
  4. -o-border-radius: 9px; /* Opera */
  5. -icab-border-radius: 9px; /* iCab */
  6. -khtml-border-radius: 9px; /* Konqueror */
  7. -moz-border-radius: 9px; /* Firefox */
  8. -webkit-border-radius: 9px; /* Safari */
  9. }

Post correlati

jQuery contro tutti: un benchmark con 5 browser

Mercoledì 17 Settembre, 2008

image 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.

image

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:

JavaScript:
  1. // prototype/scriptaculous
  2. $$('h2.dropdown').each(
  3.     function(element) {
  4.         element.style.cursor="pointer";
  5.         element.observe('click',
  6.             function(event) {
  7.                 if( this.next().style.display == "" ) new Effect.BlindUp(this.next(),{duration:.5});
  8.                 else new Effect.BlindDown(this.next(),{duration:.3});
  9.                 Event.stop(event);
  10.             }
  11.         )
  12.     }
  13. );

e com'è adesso con jQuery:

JavaScript:
  1. // jQuery
  2. $('h2.dropdown').each(
  3.     function(i) {
  4.         $(this).css('cursor','pointer').click(
  5.             function() {
  6.                 if( $(this).next().is(':hidden') ) $(this).next().slideDown(); else $(this).next().slideUp();
  7.             }
  8.         );
  9.     }
  10. );

Tutto sommato, a ben guardare, non mi sembra ci sia moltissima differenza! Ma come dicevo prima... è questione "anche" di gusto personale.

Post correlati

Firebug Lite: Firebug per IE, Opera e Safari

Martedì 22 Luglio, 2008

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 è:

HTML:
  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...

Post correlati

Resa nel ridimensionamento delle immagini sui browser

Mercoledì 5 Dicembre, 2007

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. Questo significa che bisogna avere a disposizione due formati della stessa immagine: uno piccolo per il thumbnail e uno più grande. Così capita che in alcune circostante si evita di creare un thumbnail e si lascia al browser il compito di mostrare l'immagine più piccola, forzando gli attributi width ed height nel TAG IMG.

L'uso dei thumbnail ha due immediati vantaggi: il caricamento dell'immagine ridotta è estremamente veloce e il rendering è buono, o comunque ha la resa che abbiamo scelto (se ad esempio abbiamo preparato i thumbnail con Photoshop). Di contro, come detto, dobbiamo preparare due immagini separate ed eventuali modifiche al sito dovranno tenere in considerazione questo fattore.

Forzando noi una dimensione inferiore, infatti, non si accelera il processo di downloading dell'immagine stessa: se ho un'immagine di 8000x8000 pixel e la mostro come thumbnail 100x100 pixel, il browser dovrà comuqnue scaricare un'immagine 8000x8000 e dopo effettuare un resize!

Ho fatto alcune prove con diversi browser su Windows Vista, usando 4 immagini da 1024x768 pixel ridimesionate a 100x90 pixel, ed ecco i risultati di resa su diversi broswer.

FireFox 2.0.0.11 image  (scarso)
image

Microsoft Internet Explorer 7 image  (scarso)
image

Opera 9.24 image (buono)
image

Safari 3.0.4 (523.12.9) image (ottimo)
image

Safari  vince su tutti, con una resa davvero ottima anche in termini di tempo di download. FireFox e IE7,a sorpresa, sono praticamente identici, peccato per FireFox. Opera si pone a metà, con una resa decisamente migliore di IE7 e FireFox ma al di sotto di Safari che stravince!

Post correlati

Browser War: la guerra continua?

Martedì 6 Marzo, 2007

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!

Post correlati

browsershots.org: multiple browser output

Martedì 23 Gennaio, 2007

Ecco la risposta alla drammatica incompatibilità con i vari browser attualmente disponibili. Browsershots.org è un servizio - gratuito per ora e open source - che fornisce un modo semplice per verificare se un sito è visualizzato allo stesso modo su varie piattaforme e vari browser.

Grazie ad una piccola server-farm casalinga, gli autori di questo utilissimo servizio mettono a disposizione gli output video delle schermate generate dal vostro Web, così da poter verificare la correttezza dell'interpretazione HTML/CSS su varie macchine e browser: Linux PLD 2.0 (Ac), Windows 2003 (Server), Windows NT 5.1 (XP), Mac OS X 10.4 (Tiger) ed altre.

browsershot-serverform

Il sito è davvero ben curato, con tanto di documentazione wiki, sorgenti, roadmap e timeline. Inoltre è possibile visualizzare gli ultimi screenshots, lo stato delle code-di-processo e lo stato della factories. Unica nota dolente, ma superabile, è il tempo richiesto per la generazione degli screen-shot, un po' lento! Tuttavia è un grosso aiuto ai Web Developer per verificare la correttezza del loro lavoro, senza dover installare browser e/o macchine virtuali per far convivere - ad esempio - Internet Explorer 6 e 7. Sono supportati praticamente tutti i browser, da FireFox a Safari. Interessante è la possibilità di verifcare IE6 e IE7, insieme alle versioni 5.01 e 5.5.
Bravi!

Post correlati

Internet Explorer 7 e Opera: un mondo a parte

Venerdì 24 Novembre, 2006

Conitnua a stupire la totale differenza di resa tra i vari browser in commercio. IE7 tratta i PNG (ad 8 bit o 24) in modo differente da FireFox. Anche Opera non è esente da qualche strana manifestazione a riguardo. Nel particolare i PNG usati come sfondo sono resi in modo differente da IE7, Opera e FireFox. Quest'ultimo è quello che si comporta meglio di tutti e a tal proposito sarebbe ora di nominarlo browser del "secolo"! Complimenti al team di sviluppo.

IE7 crea un simpatico effetto di taglio su un'immagine PNG usata come sfondo in repeat-x. Se provate a creare un immagine di 200x200 pixel con una sfumatura che va dal nero (0x000000) a grigio (0xeeeeee) in verticale e la posizionate nel CSS come sfondo del body in ripetizione orizzonale (repeat-x), impostando come sfondo del body il colore 0xeeeeee - ovvero la fine della sfumatura, noterete che solo FireFox rende perfettamente lo stacco, IE7 e Opera mostrano un simpatico effetto di taglio (ma leggermente diverso!!!): in pratica si vede la fine della nostra immagine 200x200 e l'inizio dello sfondo a colore piatto.

Un modo per risolvere il problema è quello di salvare la nostra immagine in GIF...

Ma i PNG non erano supportati da IE7?

Post correlati