Line Height

Rispondo direttamente qui alla domanda proposta da Molly E. Holzschlag riguardo un'utopistica implementazione di base dei CSS sulle prossime versioni stabili di tutti i browser:

Let’s put on our fantasy hats for a moment and imagine that all browser vendors agreed to implement a common baseline for CSS 2.1 in their next dot zero release. Which features of the CSS specs up to CSS 2.1 would you absolutely want for that baseline?

Usa per un momento la fantasia, e immagina che tutti i venditori di browser accettino di implementare un supporto di base comune per i CSS 2.1 nei loro prossimi rilasci punto zero. Quali delle caratteristiche incluse nelle specifiche CSS fino alla versione 2.1 vorresti assolutamente vedere implementate?

Tralasciando la traduzione un pò incolta, la mia risposta è (in ordine di importanza):

1. Supporto completo e totale ai selettori
2. Supporto completo e totale alla proprietà display: (Per saperne di più consulta anche la mia pagina di sperimentazione sui valori disponibili e/o non supportati)
3. min-height, max-height, min-width, max-width:
   • Specifiche per mix/max width
   • Specifiche per mix/max height
4. Supporto completo e totale al contenuto generato
5. Implementazione crossbrowsing della proprietà opacity: (che attualmente implica l'utilizzo di una sintassi proprietaria in base al motore che genera la pagina).

Avrei potuto inserire il supporto ai fogli di stile vocali, ma questa è una cosa che non ha senso richiedere se l'applicazione di per sè non offre il supporto alla modalità screen reader.

Voi cosa avreste risposto?

1. 13 Aprile 2005

   Viene ufficialmente segnalato l'Acid2 Test sul portale ufficiale del WaSP.
   Molti sviluppatori avevano già iniziato i lavori prima dell'annuncio, tanto che Konqueror aveva già superato il test (vedi Konqueror su Wikipedia) nel lontano 6 Aprile, grazie all'aiuto di alcune patch scritte per Safari allo stesso scopo.

2. 27 Aprile 2005

   Safari è il primo browser a superare il test, pubblicando le patch necessarie a migliorare il motore di rendering del browser.

3. 4 Giungo 2005

   Konqueror si classifica al secondo posto rilasciando le prime build non-pubbliche (vedi punto 1).

4. 6 Giungo 2005

   iCab chiude il podio e si posiziona terzo nella corsa all'Acid2, sebbene qualcuno affermi il contrario.

5. Che fine hanno fatto Firefox, Internet Explorer, ed Opera?

6. 31 Ottobre 2005

   Mac OS X 10.4.3 porta con sè Safari 2.02 (vedi Mac OS su Wikipedia), il primo browser ad essere ufficialmente Acid2-compliant. Applausi ed elogi vari.

7. 29 Novembre 2005

   Fra le novità di KDE 3.5 c'è il nuovo, atteso, Konqueror, che include il supporto completo al test. Applausi meno rumorosi, ma comunque apprezzati.

8. 10 Marzo 2006

   Benvenuto, Opera! Con quasi un anno di ritardo.

9. 12 Aprile 2006

   Zbigniew Braniecki effettua un Reflow Refactoring di Firefox e pubblica una build con Gecko 1.9. Niente di ufficiale, comunque.

10. 24 Maggio 2006

    Symbian OS, Opera Mobile passa l'Acid2 e vanta il primo posto fra i browser del ramo mobile. Finalmente qualche buona notizia!

11. 20 Giugno 2006

    Un caloroso benvenuto anche alla prima release ufficiale di Opera, la 9.0. Oltre un anno di ritardo, ma pazienza.

12. Che fine ha fatto Internet Explorer?

13. Oggi

    1. Internet Explorer e Firefox sono attualmente i due browser più utilizzati dall'utenza.

    2. Mozilla Firefox 3 (con Gecko 1.9) sarà rilasciato verso la fine del 2007. Attualmente le versioni 1.5 e 2.0 non superano il test.

    3. Internet Explorer 7 ed Acid2.

       Probably the most funny/pathetic thing I've ever seen.

       Probabilmente la cosa più divertente/patetica che io abbia mai visto.

E qualcuno comincia già a parlare di CSS 3...

Qualche tempo fa ho approfondito lo studio della proprietà CSS display: stilando una pagina di analisi e verifica della suddetta proprietà (visualizza l'articolo originale). Sono stati illustrati tutti i valori possibili sino alle specifiche CSS 2.1, correlati di markup a scopo esemplare, e di test sul crossbrowsing.

L'articolo è rimasto abbastanza inosservato, mentre è stato per me un grande piacere scoprire che Molly Holzschlag incoraggia l'utilizzo di queste proprietà relativamente sconosciute. L'autrice si sofferma in particolare sul valore run-in, dal quale - secondo lei - sarebbe possibile ricavarne molti vantaggi, se solo la comunità si interessasse maggiormente a queste caratteristiche.

Questo è un altro argomento che merita di essere discusso ampiamente, secondo me. Molti professionisti e molti appassionati probabilmente ignorano l'esistenza di almeno un buon 20% delle proprietà CSS finora esistenti (non è un dato scentifico preciso, esce dalla mia testolina ed è assolutamente inaffidabile!), che spesso si rivelano utilissime allo scopo di sistemare con maggior coerenza e forse un pizzico di originalità in più gli elementi nella pagina. La mancata conoscenza di tali proprietà porta spesso gli sviluppatori ad ingegnare più o meno complessi work-around per ottenere effetti che, semplicemente, sono già disponibili con altri mezzi.

Il problema è abbastanza grave, considerando che, anche in questo caso, una buona parte della colpa è dovuta ai browser che si ostentano a non supportare queste ignote features, nutrendo il disinteresse dei più. Il discorso è sempre quello: l'importante è che una cosa funzioni; se non funziona, il discorso non esiste nemmeno.

Molly, quindi, ci sta lanciando un avvertimento importante:

There’s a reason it’s important to advocate this for certain useful aspects of a spec that might not have full implementation. Without interest and support from the community, such features could easily get dropped from future specifications.

It’s difficult enough getting features we want into the specs in the first place, so let’s not let the good stuff we do have, such as the run-in value for display, disappear before we have a chance to see it properly implemented and available for consistent use.

C'è una ragione che è importante sostenere per certi utili aspetti di una specifica che potrebbe non avere una completa implementazione. Senza l'interesse e il supporto della comunità, alcune caratteristiche potrebbero facilmente essere tolte dalle future specifiche.

E' abbastanza difficile ottenere caratteristiche che vogliamo nelle specifiche al primo posto, quindi non permettiamo che le buone cose che abbiamo, come il valore run-in, spariscano prima che ci sia la possibilità di vederle implementate e disponibili per un uso consistente.

Interesse, supporto, comunità. Sono le parole chiave di un messaggio che personalmente sostengo e apprezzo completamente. E voi?

Luca (aka deMo) mi segnala questo approfondimento sulla specificità CSS(Cascading Style Sheets) dei links di Eric Meyer.

Il documento è vecchio (l'ultima modifica risale al 5 Febbraio 2005), ma l'argomento è interessante: come al solito non si smette mai di imparare. La frequente domanda a cui Eric risponde in questo piccolo articolo è: Ho provato ad applicare i CSS ai miei links, ma l'hovering non funziona. Come è possibile? E' colpa di questi stupidi browsers? E' in questo frangente che viene introdotta la specificità dei selettori, ed in particolare delle pseudo-classi applicate all'elemento <a>.

Il problema di fondo sta tutto nell'ordine in cui vengono specificati gli stati per un link. Io personalmente ho sempre raggruppato a:link, a:visited, a:active insieme, per poi eventualmente ridichiararne uno dopo aver definito gli stili di a:hover. Il signor Meyer invece ci illustra il metodo LVHA, ovvero Link Visited Hover Active: se scritti in questo ordine, gli stati di ogni link non si sovrascrivono, come al contrario potrebbe succedere in altri casi.

Ma allora, perchè bisogna seguire questo schema? They all have equal weight. Hanno tutti lo stesso peso.

 a:link {color: blue;}        /* specificità = 1,1 */
 a:visited {color: purple;}   /* specificità = 1,1 */
 a:hover {color: magenta;}    /* specificità = 1,1 */
 a:active {color: red;}       /* specificità = 1,1 */

E' poi interessante il metodo proposto da Eric (e valido con i CSS 2) per scavalcare il problema di specificità, senza intaccare le altre pseudo-classi e/o creare conflitti di alcun tipo. La soluzione consiste nel combinare insieme più stati:

 a:visited:hover {color: maroon;} /* specificità = 2,1 */
 a:link:hover {color: magenta;}   /* specificità = 2,1 */
 a:hover:active {color: cyan;}    /* specificità = 2,1 */

They have the same specificity, but they apply to fundamentally different beasts, and so don't conflict. In sostanza, quindi, la specificità rimane la stessa, ma cambia l'ordine e si rompe lo schema: la selezione diventa più specifica, offrendo tra l'altro una maggiore personalizzazione (possiamo infatti creare effetti di hovering diversi in base alla natura del link).

Se ne parla tanto in questo periodo. Le nuove specifiche stanno arrivando, e portano con sè tante innovazioni: nuove proprietà, nuovi attributi, nuovi selettori.
Vorrei soffermarmi proprio su quest'ultima categoria, i selettori, e proporre, a partire dai CSS 1, uno pseudo-percorso verso i patterns introdotti nella terza e nuova versione dei fogli di stile.

• Fase 1: Ripasso generale

  Russel Dyer di XML.com ha scritto un articolo sui selettori CSS 1, 2, e 3, utile per ripassare definizioni e caratteristiche introdotte per ogni versione. E' un ottimo viaggio verso le piu' recenti specifiche, e dà una visione d'insieme dell'evoluzione compiuta nella presentazione di una pagina, e nella selezione di elementi in essa.

• Fase 2: Approfondimeno sui selettori CSS 2.1

  Roger Johansson invece, in un articolo sui selettori CSS 2.1 diviso in tre parti, ci illustra attraverso alcuni esempi tutte le combinazioni e gli strumenti disponibili nei CSS 2.1 per individuare elementi in un documento. L'autore ci spiega anche il significato di alcuni termini usati nel contesto, come child, descendant, o parent.

• Fase 3: Primo sguardo ai selettori CSS 3

  Allo stesso Roger Johansson della fase precedente appartiene anche un articolo sui selettori CSS 3, decisamente ben strutturato e fornito di esempi, nel quale vengono presentati i nuovi modelli che andranno a costituire la novità nelle nuove specifiche. Da leggere anche i commenti all'articolo, in cui vengono puntualizzate alcune affermazioni e sono proposti esempi di codice utili in futuro per essere utilizzati.

• Fase 4: Approfondimento sui selettori CSS 3

  Ovviamente non potevano mancare le specifiche W3C, evidentemente le più complete ed esaurienti.
  Per chi avesse voglia di controllare quali combinazioni sono supportate dagli attuali browser, segnalo la W3C Test Suite, costituita da pagine d'esperimento per ogni selettore.
  Infine, suggerisco uno sguardo anche a SelectORacle, uno script che spiega a parole il funzionamento dei patterns CSS 2.1 e CSS 3 inviati come input.

I CSS(Cacading Style Sheets) sono uno strumento potente, poichè permettono un pieno controllo sugli elementi della pagina. Questa è una cosa che, più o meno, sappiamo tutti. Quello che non sappiamo (scusate se vi coinvolgo :P) è che i fogli di stile sono caratterizzati da una vasta gamma di proprietà e valori, alcune delle quali sono spesso poco conosciute... quasi "misteriose".

Così, qualche giorno fa, ho deciso di approfondire la questione, studiando cause ed effetti di tutti i valori possibili per la proprietà CSS display. Dopo alcuni giorni di lavoro (e di pausa), ho finalmente completato la pagina di analisi e verifica della proprietà display.

Il documento prende in esame ogni tipo di valore possibile: vengono tralasciati i parametri block, inline e none, poichè generalmente sono quelli più conosciuti ed utilizzati, e non mi sembrava il caso ritornarci sopra. Premesso questo, il test analizza le altre nove possibilità. Per ogni voce c'è una spiegazione (spesso tradotta dalle pagine del consorzio o da altre guide online), seguita da una lista di browser compatibili (purtroppo poco precisa) e da un esempio. Quest'ultimo è organizzato con bordi di diverso colore, in modo tale da facilitare la distinzione di ogni elemento. A piè di pagina, infine, ho inserito una lista di fonti dalle quali ho preso spunto durante la lavorazione, che spero possa essere utile per chi ha intenzione di approfondire ulteriormente l'argomento.

Non so quanto questo lavoro possa essere stato costruttivo. Mi auguro, comunque, di essere stato d'aiuto per chi, come me, desidera colmare alcuni dubbi nell'ambito della presentazione. :)

Vai alla pagina d'esperimento CSS: La proprietà display.

Scegliere il giusto carattere, le giuste dimensioni, le giuste misure per il testo di una pagina web non è assolutamente facile: in gioco ci sono tanti parametri, portati dagli utenti che ci visitano, e tante regole da rispettare, per ottenere dei buoni risultati nel campo della leggibilità.

We now have the tools to return typography to its true role within the sphere of design.

Come specificato in un ottimo articolo sull'anatomia dei caratteri web, il foglio stampato ed il layout web non hanno nulla in comune, nemmeno la rappresentazione dei colori (additiva per i monitor, sottrattiva per il supporto cartaceo). Questo genera alcune differenze, specialmente per quello che riguarda la famiglia di caratteri da utilizzare.

La tipologia di caratteri Serif è quella maggiormente utilizzata nella stampa: ogni tratto termina con piccole linee e/o eleganti decorazioni che accompagnano l'occhio nella lettura del testo (es. Times New Roman, Georgia, Garamond). Appartengono invece alla famiglia Sans Serif tutti quei caratteri privi di questi "fronzoli" (es. Verdana, Arial, Helvetica).

Su foglio, l'impatto di quest'ultimi agli occhi del lettore non è certo dei migliori: lo scarso contrasto e la semplicità delle lettere rendono il testo decisamente monotono e privo di interesse. Tuttavia, su un monitor, questi fattori non devono essere tenuti troppo in considerazione. Le dimensioni relativamente piccole adottate dagli sviluppatori, e il sempre più frequente utilizzo della smussatura (detta anti-alias), fa sì che la famiglia serif risulti scomoda per la lettura: tutte le linee, le curve, le terminazioni poste sulle braccia di ogni lettera diventano "puntini" fastidiosi e seccanti che rendono incomprensibili le parole e (se è attivo l'anti-alias) danno un effetto sfocato decisamente poco adatto a testi che vorremmo fossero letti con attenzione e partecipazione.

A riguardo vi rimando ad un altro breve articolo sulla scelta del giusto set di caratteri.

Una volta deciso il font da utilizzare, bisogna tener conto di alcuni importanti fattori essenziali per dare al testo una buona leggibilità: interlinea, spazio fra le lettere, allineamento, dimensioni del testo, eccetera. E' qua che entra in gioco, quindi, webtypography.net - a practical guide to web typography, un interessante riassunto dell'omonimo libro di Robert Bringhurst dedicato all'argomento tipografia, dove vengono illustrate tutte le proprietà CSS(Cascading Style Sheets) per realizzare testi altamente fruibili, e le tecniche utili per focalizzare e mantenere l'attenzione sui contenuti.

Nelle specifiche W3C dei CSS(Cascading Style Sheets) 2.1 è presente un'intera sezione dedicata ai fogli di stile uditivi. Non mi sono ancora imbattuto nella relativa appendice presente nel working draft del consorzio, ma qualche giorno fa è stato pubblicato un interessante articolo di Nicola Convertini relativo a questo argomento, ovviamente made in HTML.it.

Studi recenti stimano in 11 milioni gli statunitensi con problemi di vista di cui 1,5 milioni sono ciechi.

L'articolo inizia con l'introdurre il ruolo degli screen readers, e l'avvento di nuovi dispositivi di rendering. Dopodichè, inizia l'elenco delle proprietà specifiche.

I contenuti sono sicuramente molto esaustivi, nonostante trovi alcune definizioni ancora abbastanza oscure. Ciò che più mi ha colpito di questo piccolo "saggio" è senza dubbio la vastità di parametri offerti per personalizzare la voce del lettore elettronico: stress, frequenza, velocità e molto altro ancora. E' stato anche studiato un metodo per offrire all'utente un ascolto tridimensionale, basato sulla sorgente della voce.

Alcuni attributi non sono ancora pienamente supportati dalle applicazioni destinate alla sintesi vocale dei contenuti, anche se ammetto di aver "fantasticato" molto sull'utilizzo dell'attributo speech/aural. Sarebbe interessante, infatti, poter analizzare del codice scritto esclusivamente per la lettura di un testo teatrale, di una poesia, o di una favola (dove certo non mancano molteplici intonazioni e timbri di voce) e osservare come variano le proprietà e i valori del parlato in base a frasi, interi periodi o persino generi (mettiamo a confronto, per esempio, un racconto dell'orrore con una filastrocca).

I CSS(Cascading Style Sheets) uditivi rientrano in un campo abbastanza inesplorato e pieno di ostacoli (sebbene nell'ambito dell'accessibilità siano stati compiuti grandi passi), ma senza dubbio offriranno ad una buona percentuale di navigatori un motivo in più per usufruire dell'immensa quantità di informazioni e di contenuti che attualmente internet può già vantare.

L'affermazione può sembrare bizzarra. Eppure il messaggio di Derek Featherstone su 24 Ways.org, nell'ambito dell'accessibilità, è molto chiaro: è un metodo (a quanto pare) comune quello di inserire immagini tramite CSS(Cascading Style Sheets), per abbellire gli elementi delle nostre pagine web; ciò non è sbagliato, ma a volte può portare "fuori strada".

Le immagini, come molti sanno, dispongono dell'attributo alt (e longdesc, teoricamente più esplicativo) per fornire un contenuto alternativo ad applicazioni come gli screen readers. Lavorando tramite fogli di stile, questo discorso ovviamente non è più valido, e l'immagine non diventa nient'altro che una semplice decorazione nata per fini esclusivamente estetici.

Non vi svelo altro, buona lettura!

GrayBit è un ottimo strumento per verificare la visibilità ed il contrasto delle nostre pagine. La particolarità dello script sta nella possibilità di mostrarci una pagina in scala di grigio, eliminando quindi ogni tipo di effetto dato dai colori. Il risultato è sicuramente più "piatto" rispetto all'originale, ma è anche vero che ciò ci permette di immaginare, seppur minimamente, come quella determinata pagina viene consultata da chi ha problemi di vista (come il daltonismo).

Riferimento WCAG(Web Content Accessibility Guidelines) ai colori.

Grazie a Edit, blog di HTML.it per la segnalazione.