Non stai ancora usando i selettori CSS3? Stai perdendo un’opportunità.
Già in passato avevo parlato dei selettori CSS3, che aiutano a scrivere codice HTML ordinato e pulito. Sfruttare i fogli di stile è un ottimo modo per evitare di aggiungere id e classi inutili nelle pagine, ed in particolare nei miei post avevo affrontato due argomenti:
Una cosa fondamentale: sono passati più di 5 anni ed ormai non ci sono più problemi di compatibilità cross-browser. È possibile sperimentare, usare tutti i selettori esistenti senza problemi, e se rimangono dei dubbi c’è una risorsa imperdibile come caniuse.com a disposizione.
Essere un esperto di HTML e CSS ormai non è sufficiente: è tempo di specializzarsi.
Con l’inizio del 2014 è tornata alla ribalta una discussione non del tutto nuova: conoscere HTML e CSS è sufficiente per potersi considerare dei web designer professionisti?
La risposta è no.
È iniziato tutto dal post di Jeff Croft: Web Standards killed the HTML star.
Abbiamo attraversato un periodo in cui lavorare con IE6 ci provocava incubi ogni giorno: essere un web designer significava saper risolvere in pochi secondi i problemi più assurdi.
È stata dura battersi per il riconoscimento degli standard web e per un comportamento coerente tra tutti i browser, ma alla fine i risultati sono arrivati. Gli standard erano importanti proprio perchè i browser si comportavano in maniera diversa, con un grande caos per tutti.
Usare il title sui link di una pagina web è inutile per gli screen reader e crea solo confusione.
Ammettetelo: se avete fatto attenzione all’accessibilità dei vostri siti, fino a qualche tempo fa vi siete sicuramente preoccupati di inserire sui link poco comprensibili un attributo title. Lo scopo era chiaro: spiegare meglio la destinazione del collegamento.
Un esempio su tutti è quello dei classici “read more” o “continua…”, dove un attributo title poteva dare qualche informazione in più:
<a title="Titolo della pagina di destinazione">continua...</a>
Leggendo un post di David Ball ho fatto la scoperta: il title non serve perchè non viene letto dagli screen reader, e utilizzarlo crea solo confusione. Incredibile fino a qualche anno fa: se cercate in rete articoli che parlano di accessibilità, erano in molti a raccomandare l’uso di questo attributo.
Tutte le indicazioni per utilizzare HTML5: semantica, CSS reset, tag video e compatibilità cross-browser.
Le sperimentazioni con HTML5 sono già iniziate da tempo, e nonostante serviranno ancora degli anni prima che la specifica diventi uno standard del W3C, si possono già trovare in rete molti esempi del suo utilizzo.
Dopo avere introdotto l’argomento su questo blog, ho approfittato di un piccolo progetto basato su Sweetcron per prepararmi e testare con mano lo stato attuale di HTML5. E’ così che è nata la nuova versione di 1la.it, lavoro che mi ha aiutato a mettere in ordine le idee per scrivere questa guida.
Una collezione di link utili da cui scaricare font liberamente utilizzabili con @font-face.
Utilizzare font personalizzati sui propri siti web ormai non è più un’utopia: con il supporto ormai diffuso della proprietà @font-face è possibile in pochi passi personalizzare un progetto senza dover ricorrere ai classici Arial e Georgia.
Ricordando che è comunque fondamentale preservare la leggibilità, uno dei punti critici è l’utilizzo di font protetti da copyright: non è infatti possibile pubblicarli su una pagina web se sono tutelati dal diritto d’autore. Per questo motivo le soluzioni possibili sono utilizzare servizi esterni come Typekit, oppure scegliere font open-source che non presentano alcun problema legale.
Se optate per la seconda ipotesi, questa raccolta di web font liberamente utilizzabili potrebbe tornarvi utile:
The league of Moveable Type: una collezione appena nata di font open-source disegnati in maniera specifica per l’utilizzo su web con @font-face.
Font Squirrel: una delle migliori raccolte attualmente disponibili. Sul sito sono presenti anche diversi strumenti utili per includere font nei propri progetti.
Google Fonts: Google mette a disposizione una buona raccolta di font, che è possibile includere sui propri siti direttamente dai server di Mountain View. Sono presenti comunque anche i link per il download.
Webfonts Wiki: offre un elenco abbastanza dettagliato di font utilizzabili con vari tipi di licenze come OpenFont, GNU, CC oppure open-source.
Fonthead: una discreta collezione di font gratuiti ed a pagamento.
Ten by twenty: tutti i font gratuiti di questo sito sono espressamente utilizzabili con @font-face; quelli a pagamento no.
Dafont: una delle più ampie collezioni di font gratuiti. Potete utilizzarli con @font-face, ma fate sempre attenzione ad eventuali clausole prima del download
Come utilizzare @font-face?
Avete trovato il font che fa per voi ma non sapete come includerlo sul vostro sito? Se la semplice guida che ho pubblicato vi risulta ancora troppo complessa, troverete fantastico il @font-face generator di Font Squirrel: dovrete solo caricare il font desiderato ed avrete immediatamente un kit pronto all’uso con tutti i file necessari.
Le linee guida della BBC per i “future media” includono diverse raccomandazioni sulla scrittura dei CSS. Simili pratiche sono solo inutili complicazioni?
Uno dei siti corporate che presta più attenzione ai dettagli è quello della BBC: all’apparenza semplice ed ordinato nonostante i numerosi contenuti, si basa su molte pagine di specifiche tecniche e linee guida che devono essere rispettate dai suoi sviluppatori.
La nuova pagina foto di Flickr è un miglioramento per gli utenti?
Gli utenti abituali di Flickr se ne saranno già accorti: da qualche giorno è stata resa pubblica la nuova versione della pagina foto.
Come consuetudine la novità è stata pubblicata come preview per gli utenti, che possono decidere se mantenere la vecchia versione per qualche tempo o utilizzare la nuova: questa pratica è ormai consolidata e concede ad una buona fetta di utenti di abituarsi al cambiamento, senza imposizioni da un giorno all’altro. Le critiche non mancheranno comunque, ma sarebbe un’utopia pensare di fare felici tutti con un redesign di un’interfaccia.
Per l’elenco delle novità in dettaglio vi rimando al post ufficiale sul blog di Flickr: io preferisco soffermarmi solo su alcuni aspetti del cambiamento, e su come certi dettagli siano stati molto apprezzati dagli utenti abituali. E’ stata una sorpresa infatti leggere molti pareri positivi, cosa che non era successa con altri redesign (vedi il caso di Facebook).
I dettagli più interessanti
Foto più grandi
In un sito che ha nelle immagini la sua ragione di esistere, aumentare la dimensione di default delle stesse è una mossa vincente. Le foto iniziavano infatti ad essere troppo piccole per le risoluzioni sempre più elevate dei nuovi monitor: adesso arrivano ad una larghezza di 640 pixel, sicuramente più accettabile.
Ingrandimento con un clic
Questa è una delle novità più interessanti: molti utenti infatti inserivano nella descrizione delle foto un link alla stessa immagine più grande su sfondo nero. Sono nati anche servizi esterni per questo, e Yahoo! ha deciso di assecondare gli utenti offrendo la feature direttamente su Flickr. Adesso con un clic sull’immagine questa viene visualizzata a schermo intero su sfondo nero, e la resa è ottima:
Geotagging in evidenza
Mettere in evidenza le informazioni geografiche collegate ad una foto qualche anno fa sarebbe stata una follia. Adesso non lo è più. Con smartphone e fotocamere dotate di GPS, geolocalizzare le foto è automatico, e comunque è sempre possibile farlo anche manualmente dopo aver importato gli scatti.
Inserire questa feature al primo posto sulla sidebar destra fa capire la sua importanza. In questo modo diventa ancora più facile ritrovare tutti gli scatti di una certa località e scoprire le foto più popolari di un luogo.
I difetti
Nonostante il redesign sia positivo, alcune cose potrebbero essere ulteriormente migliorate.
Avrei apprezzato molto uno spazio dedicato ai dati EXIF delle immagini: Flickr è una community ricca di fotografi, e certe feature sarebbero sicuramente apprezzate. In questo redesign invece i metadati rimangono su una pagina separata: sarebbe stato interessante vedere almeno apertura, tempo di esposizione ed ISO.
Per quanto invece riguarda il codice e l’accessibilità delle pagine, non mi è mai piaciuta (e continua a non piacermi) l’eccessiva dipendenza da JavaScript di alcune funzioni. E’ comprensibile che certe azioni siano impossibili senza appoggiarsi a degli script, ma si potrebbe fare di meglio anche solo per quanto riguarda i menu di navigazione: con JavaScript disabilitato infatti la maggior parte dei link non funzionano ed i menu non possono essere aperti (cosa che sarebbe facile da implementare con qualche riga di CSS).
Sono invece funzionanti i nuovi link di zoom e di navigazione (foto successiva / precedente): è possibile che per alcuni nuovi elementi dell’interfaccia sia stata prestata più attenzione, ed altre parti del sito come il menu generale siano rimaste invece con i vecchi difetti. Questo redesign infatti riguarda solo la pagina foto di Flickr, tutto il resto è rimasto inalterato.
In conclusione
Il nuovo design è piacevole e più funzionale: il parere complessivo è decisamente positivo. Ci sono alcuni elementi che potrebbero essere ulteriormente migliorati, ma riguardano più la piattaforma intera di Flickr che la pagina delle singole foto. Per il momento fa piacere vedere qualcosa di nuovo in un sito che era rimasto fermo da anni: le modifiche faranno contenti i molti utenti pro che decidono ogni anno di rinnovare il proprio abbonamento.
Conseguenze dei metodi di inclusione dei CSS in una pagina web, ed i soliti problemi con Internet Explorer.
I fogli di stile possono essere inclusi in una pagina web usando principalmente due metodi: link e @import. L’obiettivo di questo post è analizzare le conseguenze dell’utilizzo delle due tecniche.
Il risultato in sintesi? Non usare il CSS @import per migliorare la velocità delle pagine ed evitare problemi con Internet Explorer.
Nonostante infatti possano sembrare differenti solo semanticamente, in realtà usare link o @import cambia considerevolmente i tempi di caricamento di una pagina. La scoperta è stata pubblicata qualche tempo fa sul blog di Steve Souders, un dipendente Google che si occupa di web performance e open source.
Metodi di inclusione CSS
Link multipli
Il metodo più diffuso, che non crea problemi, è il seguente:
In questo caso, su Internet Explorer (tutte le versioni, IE8 compreso), il CSS incluso con @import viene caricato solo dopo aver completato il primo file. Questo allunga considerevolmente i tempi di caricamento della pagina:
Lo stesso succede quando il secondo foglio di stile viene importato all’interno del primo:
In questo caso però il caricamento in sequenza succede su tutti i browser.
CSS @import multipli
Gli esempi mostrati dovrebbero già bastare per preferire l’inclusione dei CSS utilizzando solo link, ma c’è un altro caso interessante: quello con @import multipli.
Su tutti i browser diversi da IE, questa tecnica non presenta problemi, e funziona in maniera analoga alla prima mostrata (link multipli). I guai arrivano proprio su Explorer, dove gli elementi vengono caricati in maniera del tutto casuale, senza rispettare l’ordine dichiarato.
Prendendo infatti un esempio con i seguenti file, tra cui un JavaScript:
Il grafico risultante è questo, dove la seconda barra corrisponde al file .js:
Il file script.js viene caricato senza rispettare l’ordine dichiarato, e questo potrebbe portare a problemi di rendering della pagina. Il problema in questione si verifica su tutte le versione di Internet Explorer.
È bene che casi come quelli elencati siano noti, perché potrebbe essere veramente difficile indagare sui problemi di una pagina web dove gli elementi vengono caricati senza rispettare le precedenze.
In molti casi le pagine web hanno elementi più pesanti dei CSS (immagini, framework JavaScript), ma se volete ottimizzare il vostro sito tenete presente anche queste indicazioni. Non è un mistero che Google abbia iniziato a considerare anche la velocità di caricamento tra i parametri del suo algoritmo: anche la soluzione scelta per importare CSS è un fattore da valutare.
Le risposte al sondaggio 2010 di Web Directions, rivolto agli sviluppatori del web.
Sono stati pubblicati i risultati del secondo sondaggio di Web Directions, rivolto a chi lavora e sviluppa sul web. Le risposte di più di 1000 partecipanti delineano in maniera sufficientemente chiara un quadro aggiornato sulla situazione.
Tenendo presente che a rispondere non sono utenti comuni, ma superutenti, questi sono i dati più rilevanti:
Mozilla Firefox è ancora il browser più utilizzato per sviluppare, mentre Google Chrome sale al terzo posto subito dopo Safari
Internet Explorer 8 è la versione di Explorer più diffusa per la navigazione di tutti i giorni
La percentuale di sviluppatori che controllano i propri lavori su IE6 è calata dal 2008 al 2010 (da 78.44% a 59.7%)
Più della metà degli intervistati utilizza Mac OS X
JQuery è il framework JavaScript in assoluto più utilizzato, e la sua diffusione è in continuo aumento
I CSS 3 sono utilizzati anche solo sperimentalmente dal 45% degli intervistati
Mobile Safari è in assoluto il browser mobile più usato, e quello su cui vengono fatti più test in ambito mobile
Poche righe di JavaScript sono sufficienti per personalizzare il proprio sito usando font alternativi.
Da diverso tempo sto sperimentando l’uso di Typekit, un servizio che permette di utilizzare font diversi dai soliti noti (Arial, Verdana, Georgia…) in modo compatibile con tutti i principali browser. Il funzionamento è semplice e si basa su font-face e JavaScript, eliminando il problema relativo ai copyright dei font che sono interamente ospitati sui server di Typekit.
I risultati del test
Sono molto soddisfatto dei risultati ottenuti sul mio blog personale, dove sto effettuando le prove. La configurazione è semplice, e l’account trial gratuito permette di fare test senza problemi, mettendo a disposizione più di un centinaio di font (sono oltre 400 negli account a pagamento). La libreria disponibile tra l’altro cresce nel tempo, perché ne vengono progressivamente aggiunti sempre di nuovi.
Quali sono i possibili svantaggi da considerare? Sicuramente il peso della pagina, che a seconda del font scelto cambia notevolmente. Utilizzando il font Droid Serif, nelle sue forme Regular e Italic, ho una pagina che pesa ben 79kb in più del normale. Le cose potrebbero cambiare senza usare il corsivo, ma è necessario comunque fare attenzione a dettagli come questo. Il peso dei font aggiuntivi è comunque sempre visibile nel pannello di amministrazione di Typekit, non è quindi un dettaglio nascosto, da calcolare autonomamente.
Prima di scegliere un font inoltre è bene verificarne l’aspetto sui vari browser: non sempre il rendering è ottimale, soprattutto su Internet Explorer.
Questi però non sono problemi relativi a Typekit, ma fattori da considerare quando si usano font alternativi. L’unico limite del servizio, con l’account trial, è l’inserimento di un piccolo badge in basso a destra sul sito, e la banda mensile di 5Gb per i font.
Scegliere Typekit o usare i CSS?
L’alternativa CSS-only è sempre praticabile: ne avevo parlato nel 2008 quando solo Safari supportava certe proprietà e adesso potrebbe essere la soluzione ideale. Il problema però è l’esistenza di un copyright su quasi tutti i font, spesso anche quelli gratuiti, che non sempre possono essere utilizzati liberamente.
Un altro limite della soluzione autonoma è dato dalle solite differenze tra browser. Firefox supporta Web Open Font Format e TrueType, Safari e Chrome supportano solo TrueType, Explorer supporta EOT, mentre Safari Mobile (iPhone e iPad) usano SVG. Un grande caos, che obbliga lo sviluppatore a includere un font in tutti questi formati per avere risultati coerenti.
Per questo motivo soluzioni come Typekit sono l’ideale: certo, c’è da considerare una minima spesa aggiuntiva se non si vuole usare l’account gratuito con i relativi limiti, ma i vantaggi esistono.
Ci sono anche altre soluzioni alternative, come Typotheque (che concede licenze anche per la stampa) e Kernest, ma non le ho provate personalmente. Ve le segnalo se siete interessati a sperimentare, in attesa di altri servizi come Fontdeck.
Da diverso tempo sto sperimentando l’uso di 