Prefisso o Post-Hack

Guardare al passato con orrore#section1

Per capire come mai esistano i vendor prefix, è istruttivo guardare indietro al box model, che aveva quasi ucciso i CSS prima del cambio di millennio. Le inconsistenti implementazioni del box model avevano creato una crisi. Per salvarsi dal pericolo, abbiamo dovuto creare un comportamento completamente nuovo in cima ad una caratteristica del markup e inventare una nuova classe di hack.

Per i giovincelli presenti tra pubblico e che si sono persi tutto il divertimento, ecco quello che accadde: nella prima tornata di browser che supportavano CSS, Netscape implementò il box model che si trova nella specifica CSS. Questo significa che width e height facevano riferimento alla larghezza e all’altezza dell’area del contenuto. Ma Internet Explorer implementò il box model intuitivo: il che significa che width e height dichiaravano le dimensioni del bordo più esterno della box.

Quale che fosse il vostro preferito tra i due, rimase il fatto che c’erano due tra i maggiori browser con un’ampia base di utenti che erano totalmente incompatibili tra loro. Era la fine degli anni ’90 e noi stavamo combattendo a più non posso per lasciarci alle spalle il pantano dei badge “sito ottimizzato per ” e ci trovavamo in una situazione in cui un layout che andava bene in un browser era completamente sfasciato in un altro.

Ad aggravare il problema c’era il fatto che nessun browser potesse cambiare il suo comportamento per rispecchiare quello dell’altro. Assumiamo per un momento che il team IE decidesse di cambiare il loro supporto per CSS per riflettere la specifica. Fare ciò vorrebbe dire che decine, perfino centinaia di migliaia di siti che fino a quel momento funzionavano in IE si sarebbero rotti.

Immaginate un risultato diverso#section2

Supponiamo che invece di implementare clip, il team di IE avesse implementato -ms-clip. In quel caso, un cambio nel comportamento in una successiva specifica non sarebbe stato così difficile da superare. Dal momento che un vendor prefix segnala una proprietà come “in progress” è molto più facile per un produttore tornare sui suoi passi e cambiarla. Così, il team di IE avrebbe potuto cambiare il modo in cui -ms-clip funzionava nella loro release successiva, spiegando agli sviluppatori di aver aggiornato la loro implementazione sperimentale per adattarsi ai cambiamenti nella specifica.

Anche se avevano deciso che ciò fosse impossibile da realizzare, il danno della “cattiva” implementazione avrebbe messo in quarantena la versione con la proprietà con il prefisso. Altri produttori avrebbero implementato la nuova versione di clip (usando il loro prefisso), senza essere influenzati da quello che il team IE aveva fatto. Un singolo produttore non avrebbe potuto inchiodare l’evoluzione della specifica CSS e gli altri produttori a causa delle sue azioni.

Questa è la promessa che fanno i prefissi: un modo per segnalare le proprietà come “in progress,” e, quindi, non è necessariamente garantito che funzionino sempre allo stesso modo nelle release future: una scappatoia per i produttori che devono fare quei cambiamenti ed infine una difesa nei confronti delle implementazioni pessime o premature che capitano quando si va per la prima volta in produzione. Aggiungono l’estremamente necessaria flessibilità di cui si ha bisogno affinché CSS possa avanzare.

Di sicuro, potremmo semplicemente dire: “Quando un browser sbaglia rispetto alla specifica, allora va cambiato, anche se rompe il layout dei siti web esistenti.” Con i prefissi questo diventa molto più semplice da raggiungere, grazie agli allarmi che i prefissi impersonano. Senza i prefissi diventa molto più difficile, perfino impossibile. Microsoft non ha mai cambiato il modo in cui gestisce width e height nelle pagine legacy—al contrario, ha usato il DOCTYPE switching per comportarsi in maniera differente sulle nuove (in teoria più “standards compliant”) pagine. Era un trucco utile e necessario, ma quel tipo di trucco ha funzionato una sola volta.

Soffriamo ancora adesso#section3

Affinché non pensiate che tutta questa pazzia sia un artefatto storico, eccovi due esempi di inconsistenze che accadono al giorno d’oggi:

• I browser Mozilla e WebKit rendono il blurring del box-shadow in modi molto diversi e nessuno dei due è completamente conforme alla specifica. Mentre sto scrivendo questo paragrafo, c’è in corso un lungo ed accalorato dibattito sulla mailing list www-style. Almeno una, e forse entrambe, le implementazioni dovranno cambiare il modo in cui gestiscono il blurring dell’ombreggiatura per ottenere l’interoperabilità. La stessa cosa vale per qualsiasi implementazione Microsoft o Opera.

• I browser Mozilla e WebKit supportano entrambe i gradienti, ma usano sintassi radicalmente diverse per ottenere lo stesso risultato base. Ora, immaginate un mondo in cui i produttori avessero implementato i gradienti senza i prefissi. Avreste tre scelte:

  1. Selezionare quale browser mostra un gradiente e quale non lo fa.
  2. Usare i CSS hacks o il browser sniffing per mandare diversi stili a diversi browser.
  3. Decidere di non usare affatto i gradienti.

  E ci sono tre scelte qui solo perché i gradienti utilizzano sintassi per i valori estremamente differenti, aprendo così la porta ad all’opzione numero uno. In un caso in cui le implementazioni usano la stessa sintassi per i valori ma si hanno diversi effetti —così come succedeva con clip— allora sono possibili solo le due ultime opzioni: hack e sniff per mandare stili totalmente differenti o semplicemente per non usarlo.

Abbiamo già visto questo film tante volte nel corso della storia di CSS. Non ci sono motivi per volerlo riguardare. Era già abbastanza brutto la prima dozzina di volte.

Prefisso o post-hack#section4

Ma i prefissi sono migliori? Dopo tutto, si è detto che i vendor prefixes sono i nuovi CSS hacks. Come ha evidenziato Aaron Gustafson in un recente articolo, questo:

	-moz-border-radius: 10px 5px;
	-webkit-border-top-left-radius: 10px;
	-webkit-border-top-right-radius: 5px;
	-webkit-border-bottom-right-radius: 10px;
	-webkit-border-bottom-left-radius: 5px;
 	border-radius: 10px 5px;
     
  

ricorda molto da vicino questo:

	
	  padding: 10px;
	  width: 200px;
	  w\idth: 180px;
	  height: 200px;
	  heigh\t: 180px;
	
  

In termini di ripetizione e seccatura, sì, i due sono molto simili. Ma sono fondamentalmente diversi in questo: i prefissi ci danno controllo sul nostro destino di hacking. In passato, abbiamo dovuto inventare un insieme di prodezze del parser solo per ottenere implementazioni inconsistenti che agissero allo stesso modo una volta che avevamo scoperto la loro inconsistenti. Era un approccio totalmente reattivo. I prefissi sono un approccio proattivo.

Inoltre, i prefissi sono un hack temporaneo. Man mano che il tempo passa e che le implementazioni diventano consistenti, i browser abbandoneranno i prefissi. Da lì in poi, gli autori saranno in grado di scrivere una riga per border-radius invece di più di sei righe di CSS. Senza di essi, stiamo solo aspettando la prossima implementazioni scombinata che ci obblighi a supportarlo attraverso gli hack per anni e anni.

Ecco perché la creazione di un prefisso unificato, come -beta- o -w3c-, è almeno mezzo passo indietro: preserverebbe l’abilità dei produttori di segnare le proprietà come “in progress” e apportare i cambiamenti necessari ma sfortunatamente, priverebbe completamente gli autori dell’abilità di omettere, o perfino dare un valore differente ad un particolare browser se ha un’implementazione inconsistente. Dal punto di vista di un autore, un prefisso unificato non è migliore di un mondo senza prefissi.

A volte, mi sento allo stesso modo nei confronti dei metodi di pre-processing per gestire i prefissi, sia lato server (usando tool come Less) sia lato client (uno qualsiasi dei framework JS). Quando si usano questi tool, è possibile semplicemente scrivere dichiarazioni border-radius e far sì che il tool lo espanda nella lista richiesta di dichiarazioni con prefisso. Da un lato, sono un modo veramente utile di ridurre il numero di cose da scrivere e mantengono l’authoring bello e pulito. Dall’altro, sono una sorta di prefissi unificati o assenza di prefissi: è sufficiente un’implementazione brutta da parte di un browser per rompere le pagine.

Il vantaggio è che se qualcosa viene fatto un po’ alla carlona, ciascun autore può tornare indietro, disabilitare il pre-processor e scrivere a mano i prefissi. In alternativa, il pre-processor può essere aggiornato per gestire il problema. Comunque sia, si tratta di un piccolo overhead cognitivo in aggiunta per l’autore, ma non è troppo.

Lo svantaggio è soprattutto filosofico, ma non è per questo meno importante: nascondendo le proprietà con prefisso dietro ad un processor, gli autori potrebbero dimenticarsi che quello che stanno usando è sperimentale e soggetto a cambiamenti. Cognitivamente, potrebbero cominciare a trattare quello che stanno usando come radicato e stabile, quando in realtà potrebbe non essere così.

Fare in modo che i prefissi siano davvero importanti#section5

Credo così fermamente che i vendor prefixes siano una buona cosa che mi sono preparato per fare il prossimo passo logico: i vendor prefixes dovrebbero essere resi più centrali nel processo degli standard. Dovrebbero essere richiesti tra le nuove proprietà implementate e dovrebbero essere il meccanismo attraverso il quale viene dichiarata l’interoperabilità.

Ecco cosa intendo: supponete che qualcuno inventi una nuova proprietà chiamata text-curl. Immediatamente, tre produttori la implementano. A ciascuno di essi dovrebbe essere richiesto di aggiungere un vendor prefix alla loro implementazione. In questo modo vedremmo cose così:

    
	h1 {
	  -webkit-text-curl: minor;
	  -moz-text-curl: minor;
	  -o-text-curl: minor;
	  text-curl: minor;
	}
    
  

Nel tempo, i produttori rifiniscono le loro implementazioni in risposta ai bug report e ai chiarimenti del Working Group. Alla fine, il Working Group decide che due delle tre implementazioni sono completamente interoperabili. Queste implementazioni poi supportano il puro text-curl. Il terzo no.

A questo punto, gli autori potrebbero decidere di semplificare i loro stili così:

    
	h1 {
	    -webkit-text-curl: minor;
	    text-curl: minor;
	}
    
  

Invece che far proliferare gli hack nel tempo, li faranno sparire. Alla fine, avremo bisogno di una singola riga text-curl.

Quindi, cosa accade quando una nuova implementazione fa il suo debutto? Usa il prefisso nella sua prima realizzazione, non importa quante implementazioni già interoperabili ci sono. Questo potrebbe voler dire che dovremmo tornare indietro e cambiare il CSS perché dica:

    
      h1 {
	-ms-text-curl: minor;
	text-curl: minor;
	}
    
  

Poi, non appena il Working Group giudica interoperabile l’implementazione di -ms-text-curl, il prefisso può essere messo da parte nella nuova release di IE. A questo punto il CSS può essere ridotto ad una singola riga senza prefisso. Di nuovo, il numero di hack diminuisce nel tempo.

Ovviamente, ciascuno di questi produttori continuerà a supportare le proprietà con i prefissi, così anche se non togliamo le linee con i prefissi, ciascun browser che li supporta riconoscerà la proprietà senza prefisso ed userà quella (dal momento che viene dopo la dichiarazione con il prefisso). Per ogni browser che implementa la versione con i prefissi che non riesce ad avere un proprio stato senza prefisso, la sua proprietà con il prefisso funzionerà ancora. Anche se il CSS non verrà mai più toccato, continuerà a funzionare.

Detto ciò, tornate per un momento all’epoca in cui il Working Group ha detto che due implementazioni erano interoperabili e potevano così eliminare i prefissi. Questa cosa ha un duplice scopo: primo, come ho detto prima, segnala che una proprietà ha sufficiente interoperabilità per permettere il progresso nel processo degli standard.

Ma l’altra cosa —e questo è intuitivamente più importante— è che costringe i produttori ed il Working Group a lavorare insieme per inventare test necessari a determinare l’interoperabilità. Questi test possono poi guidare quelli che seguiranno, aiutandoli a raggiungere uno stato di interoperabilità molto più velocemente. Potrebbero letteralmente rilasciare l’implementazione con i prefissi in una public beta ed eliminare i prefissi nella successiva release.

Questo capovolge il modo in cui si fanno le cose adesso. Così com’è, il processo è impostato in maniera tale che quando un qualunque modulo CSS raggiunge lo stage di Candidate Recommendation, i produttori possono eliminare i prefissi dalle proprietà in quel modulo. Ma questo apre di nuovo la possibilità di un’altra implementazione scombinata e di un futuro di hack per aggirare l’errore.

Come proposto qui, ad un modulo sarebbe permesso di raggiungere la Candidate Recommendation una volta che tutte le sue proprietà abbiano avuto almento due implementazioni senza prefisso nelle release pubbliche. Qualsiasi implementazione che venga dopo comincerà con i prefissi e li eliminerà una volta che avranno provato, nelle release pubbliche, che le loro implementazioni con prefisso siano compatibili con quelle esistenti senza prefisso. Invece di essere un azzardo minore, le proprietà senza prefisso saranno tanto simili ad una garanzia come non abbiamo mai visto finora.

Conclusioni#section6

Se la storia dei web standard ci ha mai insegnato qualcosa è che gli hack sono necessari. Caricando dal davanti gli hack usando i vendor prefixes e conservandoli come reliquie nel processo degli standard, possiamo effettivamente sistemare alcuni dei potenziali problemi con il processo e possibilmente accelerare lo sviluppo CSS.

Quindi, la prossima volta che vi troverete a lamentarvi riguardo la quadruplicazione di una stessa cosa all’interno di una dichiarazione, una volta per ciascun browser, ricordatevi che la sofferenza è solo temporanea. E’ un po’ come un vaccino— la puntura fa mal al momento, è vero, ma è un male molto minore rispetto a quello che previene. E in questo caso, vi state vaccinando contro un brutto caso di parser hacking e browser sniffing che durerà per anni. Abbiamo già sofferto questa lunga piaga una volta. I prefissi, se usati propriamente, scanseranno un’altra epidemia per molto tempo.

Illustrazioni dell’articolo: {carlok}