I selettori dei CSS3: un'alternativa agli hack

Questa è la traduzione dell'articolo CSS Not([hacks]) di Brian Suda pubblicato originariamente su Digital Web Magazine il 7 gennaio 2008. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.

Come sa ogni sviluppatore con un minimo di esperienza, i browser possono presentare differenze nel modo in cui interpretano le regole e le proprietà dei CSS. Un modo per uscire da questa situazione senza tanti mal di testa consiste nell'uso di svariati hack; in certi casi potrebbero invalidare il CSS, ma costringono i browser a leggere solo certe parti del foglio di stile e rendere una pagina o un sito web nel modo più vicino possibile a quello desiderato. Gli hack nei CSS sono insomma uno dei modi comuni con cui impostare istruzioni specifiche per questo o quel browser, si tratti di risolvere il problema della proprietà min-width o quello della resa del box model.

Ma c'è un altro modo. Dimostrerò in che modo sia possibile usare i selettori definiti nei CSS3 come un'alternativa agli hack quando sia necessario avere come target un browser specifico. Gli hack sono un esempio di graceful degradation: si progetta per i browser più capaci e poi si fissano i problemi nei browser più datati o meno aderenti agli standard. Ma cosa accadrebbe se si adottasse l'approccio opposto e lavorassimo secondo il metodo del progressive enhancement?

In questo caso, il progressive enhancement ci porta a scrivere il CSS in modo tale che funzioni su tutti i browser, aggiungendo poi dei miglioramenti indirizzati in modo specifico ai browser più capaci e che supportano meglio le specifiche CSS. Si può pensare a questo approccio come il contrario della graceful degradation.

In verità tutti sanno come stanno le cose: la maggior parte dei problemi deriva dal modo in cui in cui Internet Explorer tratta alcune regole dei CSS. In una parola dai suoi bug di resa. Di conseguenza, molti hack sono basati su bug del parser CSS di Internet Explorer. Per esempio l'incapacità di parsare correttamente i commenti, gli underscore iniziali nei nomi delle proprietà o la resa del box model. Il problema è dunque che molti di questi hack sono specificatamente per IE e possono essere rovinati nel momento in cui il browser dovesse introdurre delle correzioni e risolvere i bug.

ll codice sopra riportato fa riferimento al box model hack: il parser CSS di IE blocca la lettura delle regole alla '}' contenuta nella dichiarazione per voice-family, e così non parsa le altre due dichiarazioni.

Non sarebbe meglio se potessimo continuare a scrivere CSS con dichiarazioni che i browser più vecchi non possono comprendere ma che sono comunque valide? Usando, per esempio, il selettore child ('>'), possiamo nascondere certi blocchi di codice a IE6:

L'esempio qui sopra si riferisce esattamente a questo scenario: tutte le versioni di IE fino alla 6 non possono intepretare questa regola, IE7 invece sì. Si può usare tutto ciò per attuare una strategia di progressive enhancement nei nostri progetti. I browser più recenti iniziano a sfruttare i benefici che portano queste regole senza dover aggiornare di continuo i nostri CSS.

Questo è un approccio molto migliore, dunque, proprio perché consente il progressive enhancement. Mentre i browser diventano più aderenti agli standard in fatto di CSS, le regole che man mano definiamo iniziano a funzionare. Non c'è bisogno di impazzire con cose come /* */ o _proprietà.

Usare i CSS3 per divertimento e profitto

Il miglior posto dove andare a cercare CSS valido che alcuni browser comprendono e altri no è la bozza della specifica CSS3. Parti di questa specifica sono supportate da Mozilla Firefox e Apple Safari -tra gli altri- ma non da Internet Explorer.

Costruendo una semplice tabella con i browser e le proprietà, possiamo rapidamente verificare quali caratteristiche sono supportate e quali no. Quindi potremmo offrire un progressive enhancement: usare le regole CSS che i browser più conformi supportano mentre quelli più datati e peggiori non supportano.

Usando i test per i selettori CSS3 del W3C possiamo rintracciare potenziali candidati per dichiarazioni specifiche rivolte a certi browser. Ho semplicemente aperto tutti i test forniti dal W3C in cinque browser differenti e ho cercato i selettori che non passano o falliscono unanimamente su tutti i browser. La tabella qui sotto mostra un campione dei test e dei loro risultati:

Nota: fail = non supportato; pass = supportato.

Una rapida occhiata alla tabella mostra che il selettore not () è supportato da Firefox e Safari, ma non da IE (6 e 7) e Opera. Il selettore lang () è supportato da Opera, Safari e Firefox, ma non da IE. Infine, usando i selettori only-child o last-child, possiamo indirizzarci esclusivamente a Firefox. Con questi selettori possiamo ora creare dichiarazioni specifiche per certi browser senza dover ricorrere ad errori nel parsing dei CSS presenti nelle diverse implementazioni.

Così abbiamo un metodo che fa leva esclusivamente sui CSS per impostare stili specifici senza usare hack. Invece di usare hack dei commenti, l'hack dell'underscore o quello per il box model, possiamo scrivere un CSS valido e ottenere regole specifiche per singoli browser: impostando prima una regola di default e poi applicando le dichiarazioni più specifiche che i browser possono intepretare.

Mettiamo tutto insieme

Illustriamo il tutto con un esempio. Supponiamo di avere un'immagine che vogliamo nascondere in IE ma rendere visibile sugli altri browser. Iniziamo con il codice HTML:

Poi, dobbiamo dichiarare la regola di base, quella con cui nascondiamo l'immagine su tutti i browser:

Questa regola nasconderà tutti gli elementi img con classe 'photo' che sono discendenti dell'elemento con id="gravatar".

Fatto questo, dobbiamo visualizzare l'immagine su quei browser che hanno un supporto migliore dei CSS:

Aggiungendo il selettore not () e verificando la presenza dell'attributo border, possiamo far sì che questa immagine venga visualizzata su quei browser che sono in grado di comprendere questa regola. Dice che tutti gli elementi img con classe 'photo' che sono discendenti dell'elemento con id 'gravatar' e non hanno un attributo border dovrebbero essere visualizzati come elemento blocco. Effettivamente, ciò rende l'elemento img nuovamente visibile. Se torniamo un attimo alla tabella, verifichiamo che solo Firefox e Safari supportano questo selettore. Abbiamo trovato un modo per indirizzare regole a browser specifici.

Usare il trucchetto del selettore not () ci consentirà di mostrare l'immagine ad un sotto-insieme di browser. Sia IE6 sia IE7 sia Opera non comprendono quella dichiarazione, così in essi l'immagine rimarrà nascosta. E se volessimo mostrare l'imamgine anche su Opera senza toccare IE?

Per ottenere questo risultato, dobbiamo di nuovo dare un'occhiata alla tabella e vedere quali selettori funzionano su Opera, Safari e Firefox ma non su IE. La pseudoclasse :lang() sembra il candidato ideale. Possiamo cambiare la regola CSS così:

Perché questo metodo funzioni è necessario aggiungere un attributo lang="en" all'elemento html.

Questo è progressive enhancement di base. Quando la prossima versione di IE arriverà con un miglior supporto dei CSS, applicherà le regole al momento specifiche per Safari, Firefox e Opera, mostrando la pagina con tutte le caratteristiche (nel nostro caso l'immagine). Quando ciò avverrà, non ci dovremo preoccupare di aggiornare il CSS: l'informazione che abbiamo aggiunto all'inizio non è un hack!

Usare una soluzione basata solo sui CSS è sempre preferibile rispetto all'adozione di hack. Anche Microsoft raccomanda di evitare gli hack per IE, invitando ad usare i commenti condizionali. Sul web, come nella vita, il mantra dovrebbe essere "tutto è moderazione". Spero di aver dimostrato come i CSS3 possano essere un ottimo metodo per ridurre al minimo il ricorso agli hack. Ecco l'esempio finale.