La delicata questione del vendor prefix: Eric Meyer di ALA intervista Tantek Çelik

Eric Meyer di A List Apart, mago dei CSS e fan dei vendor prefix, intervista Tantek Çelik, web standard lead di Mozilla sul controverso piano di Mozilla per supportare le proprietà con il prefisso -webkit-. Tantek ha fatto esplodere l’attuale crisi nella Terra dei Web Standard durante un public meeting del W3C CSS Working Group, in quale cha notato la predominanza di siti mobile WebKit-only, che quindi creano una monocoltura del browser. Tantek ha discusso la soluzione di Mozilla, consistente nel far sì che Firefox Mobile finga di esser come WebKit e facendogli supportare alcune proprietà CSS -webkit-, che ha accesso molti animi nella comunità degli standard, specialmente quando i rappresentati di Opera e Microsoft sono stati immediatamente d’accordo sul problema e hanno annunciato piani simili a quello di Mozilla. La seguente discussione è avvenuta via EtherPad, messaggistica istantanea, e-mail e telefonate.– Ed.

Cominciamo dall’inizio. Che cosa stanno pianificando di fare esattamente i team di Mozilla, Opera e Internet Explorer?

Non posso parlare per i team di Internet Explorer e di Opera, ma Mozilla sta attualmente analizzando i siti web mobile per un paio di comportamenti problematici: siti che fanno browser sniffing cercando una stringa per lo user agent WebKit e mandando di conseguenza solo contenuto mobile “high fidelity” e siti che usano solo o principalmente proprietà con il prefisso -webkit-

Basandoci sulle nostre analisi, stiamo pianificando di implementare una stringa UA per Firefox Mobile che passi questo UA-sniffing, ironicamente, in maniera simile al modo in cui WebKit aggiunse “like Gecko” alla sua stringa UA quando venne lanciato Safari, e implementando delle proprietà specifiche con il prefisso produttore -webkit-, caso-per-caso, quando ciò è giustificato dai dati raccolti.

Non mapperete semplicemente in maniera universale -webkit- con -moz-? Il piano è di supportare solo un limitato sottoinsieme di tutte le proprietà -webkit-?

Esattamente. Il nostro obiettivo qui è di minimizzare il numero di proprietà con altri prefissi produttori che dobbiamo supportare a quelle che sono giustificate dai dati e che faranno una differenza per gli utenti web di Firefox Mobile. I dati che abbiamo raccolto finora non giustificano un supporto globale di tutte le proprietà -webkit-.

In aggiunta, stiamo considerando di supportare solo la versione con il prefisso -webkit- di una proprietà se e/o quando supportiamo anche la versione senza prefisso. Questo darà ai web developer un’opzione basata sugli standard piuttosto che usare le proprietà con il prefisso.

Ma al momento, non sappiamo di quali proprietà si tratta. O lo sappiamo?

Non abbiamo una lista specifica al momento. Siamo molto cauti riguardo a questo aspetto e stiamo scrutinando i nostri dati di conseguenza per essere sicuri di avere una giustificazione guidata dai dati, che supportiamo solo quello per cui i dati giustificano il supporto, ed efficacemente, il che implica essere sicuri che aggiungere un tale supporto faccia davvero la differenza per gli utenti di Firefox Mobile.

Immagino che tale lista cambierà con il tempo. Sembra che genererà ancora più confusione per i developers, dal momento che supporterete il prefisso -webkit- per alcune proprietà ma non per altre. Come vi aspettate che rimangano aggiornati gli sviluppatori con chi supporta i prefissi di chi e su quali proprietà?

Non si è mai pensato che le proprietà con i prefissi dei produttori fossero qualcosa da cui dovessero dipendere gli sviluppatori. Avevano, e hanno, lo scopo di implementazioni sperimentali e di tecnologie in fase di sviluppo da iterazioni delle working draft di CSS nel processo di standardizzazione. Mi aspetto che gli sviluppatori rimangano aggiornati con le proprietà senza prefissi e con le implementazioni che li supportano. Questo è quello da cui possono dipendere gli sviluppatori.

Questo non sembra tuttavia realistico. Se gli sviluppatori si bloccano su quello da cui possono dipendere (le proprietà senza prefisso), non ci troveremmo in questa situazione.

Infatti, gli sviluppatori che si fissano sulle cose da cui pensavano di poter dipendere sono il motivo per cui siamo in questa situazione. Alcune proprietà con i prefissi sono state presentate come se si potesse dipendere da loro e poi supportate come tali senza nessun avanzamento adeguato negli standard.

Mozilla manterrà una lista di quali prefissi sono supportati su quali proprietà?

Mozilla continuerà a documentare quali proprietà sono supportate da Firefox, con qualunque prefisso, su developer.mozilla.org.

Ok, quindi questo è quello che pensate di fare, ma parliamo del perché pensate di farlo. Qual è l’obiettivo del vostro piano?

L’obiettivo di Mozilla è di aprire la parte specifica di WebKit del web ad altri produttori nello stesso modo in cui, anni fa, Mozilla e Opera hanno dovuto avere un atteggiamento pratico riguardo quali tecnologie proprietarie di IE o IE-only supportare. Abbiamo sollevato il problema sia di una monocoltura WebKit del mobile web sia dell’insufficienza dell’evangelizzazione da combattere, nonostante i numerosi evangelisti di Mozilla, Opera e Microsoft stiano lavorando con i web developer per pubblicare contenuti basati sugli standard web e cross-browser.

Con così tante persone che evangelizzano la cosa giusta, perché è insufficiente?

Negli scorsi dieci anni e più, l’evangelizzazione degli standard web è stata piuttosto efficace, facendo prendere coscienza e adottando HTML+CSS validi, il progressive enhancement, scripting non intrusivo, i microformat, etc. Tuttavia, nonostante gli sforzi di evangelizzazione di Mozilla e di altri durante lo scorso anno, il mobile web specifico per WebKit è cresciuto più rapidamente di quanto non potessimo evangelizzare, specialmente in contrasto con l’evangelizzazione specifica di WebKit, sia implicita che esplicita.

Penso che sia giusto chiederci: cosa è andato storto, come siamo finiti con una monocoltura WebKit nel mobile web nonostante ci sia stata almeno un po’ di evengelizzazione nella direzione opposta, quella degli standard? Non sono sicuro che si sia trattato di un’unica ragione, penso ci siano stati diversi fattori che anno contribuito e che insieme hanno creato le condizioni per la comparsa ed il rafforzamento di questa particolare monocoltura.

Per prima cosa, le innovazioni in WebKit hanno contribuito all’innalzarsi delle aspettative di quello che era possibile sulla piattaforma web, che, per essere chiari, era e tuttora è una buona cosa, poiché l’avanzamento del potenziale della piattaforma dell’open web è un obiettivo che tutti condividiamo.

In secondo luogo, l’adozione estesa di WebKit in iPhone, Android e BlackBerry. Questo avrebbe dovuto essere un avvertimento: ossia, quando più produttori usano tutti una singola implementazione, è molto probabile che emerga una monocoltura.

Terzo, abbiamo visto una forte evangelizzazione delle feature -webkit- da parte di Apple e Google, in special modo come parte delle presentazioni e dei siti che dimostrano le capacità di “HTML5”. Alcuni di questi siti “HTML5” sono stati successivamente aggiornati con dei prefissi specifici per il produttore per feature CSS sperimentali (per dimostrazioni e programmazione ancora più cross-browser). Comunque, risuona ancora oggi l’eco del messaggio implicito delle prime versioni WebKit-only

Quarto, ci sono stati anni di presentazioni in quasi tutte le conferenze sul web design/development in cui i presentatori, bramosi di discutere e dimostrare le ultime novità, hanno mostrato siti e codice creato con le proprietà con il prefisso -webkit-. Ciò ha incoraggiato implicitamente, quando non esplicitamente, di avere come obiettivo e di utilizzare codice primariamente o esclusivamente solo per WebKit, specialmente per i siti mobile.

Infine, tutto quello che ho citato qui sopra è stato esacerbato dal tempo che ci ha messo il CSS working group per standardizzare alcune di queste innovative proprietà con il prefisso -webkit-, così che tutti i browser engine, incluso WebKit, potessero supportarle senza prefissi e fornissero ai web developers un’opzione basata sugli standard da cui dipendere.

Hai detto che state facendo tutto questo per gli utenti di Firefox Mobile. Quindi, questo piano è solo per il vostro prodotto mobile e non per il browser desktop?

La stringa UA per Firefox Mobile è già diversa da quella di Firefox Desktop, quindi, sì, la parte di cui ho parlato prima è specifica del prodotto mobile. Per quel che concerne l’implementazione di particolari proprietà -webkit, stiamo attualmente ponderando l'opzione di supportarle solo nel mobile, limitando così l'esposizione, rispetto a fornire una piattaforma consistente Firefox/Gecko da cui possano dipendere gli sviluppatori web.

Dal momento che l’obiettivo qui è quello di fornire un’esperienza consistente per tutti gli utenti mobile, sembra piuttosto probabile che alla fine deciderete di fornire un’esperienza consistente a tutti gli utenti Firefox, no? Pertanto, di conseguenza questa strategia si espanderà dal mobile al desktop.

Il problema che abbiamo trovato è specifico per i siti mobile che sono stati programmati solo per WebKit. Dal momento che c’è moltissima varietà di browser sul desktop, c’è molto meno codice WebKit in quest’area. Qui entra in gioco il requisito dell’efficacia: se qualcosa in effetti non aiuta l’utente, non c’è motivo di implementarla. Quindi, potremmo implementarlo attraverso le piattaforme Firefox, ma ha molto meno senso se farlo non rende migliore l’esperienza desktop per gli utenti. Tuttavia, dobbiamo ancora considerare l’impatto sugli sviluppatori e questo potrebbe essere sufficiente. Potremmo provare le cose nelle beta build per avere del feedback.

Sulla stessa linea, non sembra qualcosa che rimarrà limitato a poche proprietà qua e là. Sembra che una volta aperta la porta, alla fine arriverete al punto di trattare -webkit- come se fosse un vostro prefisso. Oppure, anche se non lo fa Mozilla, allora Opera e Microsoft lo faranno ad un certo punto e di conseguenza, sarete costretti a seguirli. Vero o no?

Penso che dipenda dal fatto se si riuscirà ad aprire la monocoltura mobile di WebKit oppure no. La storia ha mostrato che Mozilla ed altri hanno avuto successo aprendo la monocoltura web di IE con implementazioni limitate di alcune feature IE-only, come innerHTML e XMLHttpRequest, entrambe i quali sono stati successivamente standardizzati con il W3C. Non c’è stata nessuna implementazione generale di feature IE-only in Firefox. Mozilla ha un passato solido di implementazioni di feature per la compatibilità web sui cui si è riflettuto molto e con un approccio pragmatico caso-per-caso.

Ma supponi che, ad esempio, Opera vada avanti e supporti universalmente -webkit- per ragioni simili a quelle di quando per un certo tempo la loro stringa UA di default aveva come valore Internet Explorer. Questo non forzerebbe Mozilla a seguire lo stesso percorso? E, in caso contrario, perché no?

Se un altro mobile browser supportasse -webkit- in maniera totale, non vedo come questo potrebbe avere un impatto sulla situazione, dal momento che il browser engine dominante, WebKit, supporta già -webkit- globalmente?

Peter-Paul Koch ha affermato piuttosto energeticamente che “non c’è un unico WebKit.” La vedete in maniera diversa, ovviamente.

Non importa se Peter-Paul Koch dice che “non c’è alcun WebKit”, quello che importa è quello che credono i web developer e agire come se ci fosse un WebKit: stanno programmando e consegnando siti mobile di conseguenza, facendo lo sniffing della stringa UA di WebKit ed usando solo le proprietà -webkit-. Questo effetto è misurabile. Negarlo non lo fa cambiare.

E facendo così gli sviluppatori stanno dando un’esperienza ridotta o, nei casi peggiori, compromessa agli utenti di browser non-WebKit come Mozilla, Opera ed Explorer.

Esatto. Stiamo vedendo delle esperienze di livello inferiore o “feature-phone” ultra-minimalistiche e ridotte funzionalità mandate dai siti mobile ai browser mobile non-WebKit.

In almeno alcuni di questi casi, supportate pienamente quello che stanno facendo, tranne l’averlo nascosto dietro i prefissi -webkit-?

Sì. Le attuali versioni di Firefox supportano le versioni con il prefisso -moz- dei gradienti, delle transform, delle animazioni, etc. di CSS3. Stiamo lavorando attivamente con il CSS Working Group per far avanzare rapidamente le rispettive specifiche e per eliminare i vendor prefix dalle feature stabili. In questo modo possiamo tutti aiutare a far avanzare la piattaforma web con gli standard piuttosto che con una manciata di vendor prefix.

Quanto spesso non funziona completamente un sito? Se un sito è diverso ma pur sempre funzionante, è quello che ci si aspetta già sul web. Sembra che la vostra vera obiezione sia che il rendering del vostro browser sia meno elegante, non che gli utenti non possano accedere ad un sito. Questa è davvero una minaccia per l’adozione e l’uso di browser non-WebKit?

Sono spesso malfunzionanti. Questi siti mobile abbassati di livello sono diversi e significativamente meno funzionanti. Quando gli utenti vedono un’esperienza sostanzialmente peggiore in un browser diverso nello stesso sito sullo stesso dispositivo, danno la colpa al browser, non al sito e nemmeno al device.

La promessa dei prefissi del produttore era che le implementazioni avrebbero potuto essere testate e i problemi avrebbero potuto essere corretti prima che il comportamento fosse formalizzato. Ha funzionato particolarmente bene con la sintassi per il gradiente, ad esempio, per cui sono state provate sintassi totalmente incompatibili e alla fine è stata trovata una sintassi unificata. Questo piano sembra metta in pericolo questa capacità, ossia, una volta che produttori cominciano a supportare i rispettivi prefissi, potremmo evitare i prefissi tutti insieme. È una conclusione ragionevole?

A volte ci aspetta che le tecnologie siano perfette, senza nessun difetto o irregolarità. Ovviamente, tali aspettative non hanno basi nell’esperienza quindi non è chiaro da dove derivino. Il vendor prefix di CSS non sono diversi: hanno in effetti avuto un certo successo, molti browser hanno sperimentato con iterazioni di svariate feature per anni, standardizzando alla fine quelle che funzionano.

In particolare, Mozilla ha un’eccellente storia alle spalle di pioniere nel provare le cose per primo con un prefisso -moz- e, una volta standardizzata, includere la versione standard della proprietà, senza prefisso, e abbandonare quella sperimentale con il prefisso -moz-. A volte, ci sono stati anche problemi lungo il percorso: ad esempio, quanto tempo ci ha messo la proprietà border-radius prima diventare standard, ossia adesso. Tuttavia, con la monocoltura WebKit per il mobile web è probabilmente la prima volta che vediamo un problema serio con i vendor prefix. Dobbiamo rinunciare ai vendor prefix adesso, nonostante i loro imperfetti ma impressionanti precedenti?

Ci sono state iniziative per rimpiazzare i vendor prefix con dei prefissi “universali”, come -x- o -beta-. Qual è la vostra opinione in merito?

L’esperienza ha mostrato che, negli altri standard in cui si è utilizzato un prefisso beta o sperimentale come -x-, tutti finiscono con il supportarli per sempre oltre alla versione senza prefisso. Ad esempio, controllate gli header della vostra email: troverete molti header X-*. Oppure il fatto che i browser offrono il supporto per image/x-png oltre che image/png per le immagini PNG.

Al contrario, con i vendor prefix di CSS, Mozilla ha mostrato che è possibile lasciar perdere le proprietà con il prefisso -moz- e far progredire il web. Credo che almeno un altro produttore di browser sia stato in grado di dismettere il supporto delle proprietà con il prefisso del produttore dopo aver rilasciato le versioni standard senza prefisso.

Perché i prefissi “universali” non sono stati dismessi allo stesso modo dei vendor prefix? Qual è la differenza?

I prefissi universali hanno man mano cominciato a essere visti come affidabili tra tutti i browser e pertanto gli effetti della rete hanno rinforzato il loro uso e il supporto è migliorato: forse è diventato sufficientemente buono da richiedere di supportarli indefinitamente per la compatibilità, come i già citati header X-* delle mail e i content type.

C’è un rischio simile quando più browser supportano le proprietà con il prefisso -webkit-. Questo rischio potrebbe essere mitigato e forse addirittura superato se più browser supportassero le equivalenti proprietà senza prefisso e potremmo incoraggiare gli sviluppatori web ad usare queste invece delle altre, progredendo. Tuttavia, questo non sistemerebbe i siti mobile specifici per WebKit che sono già stati rilasciati.

Quindi, ci stiamo concentrando a risolvere il problema adesso, rischiando di creare un problema simile in futuro. Non state solo allontanando il momento della sofferenza?

È sicuramente un problema complesso con molte variabili e molti attori. La combinazione di mettere delle patch ai problemi passati e di mettere nelle condizioni di creare un percorso affidabile per lo sviluppo futuro fornisce un buon equilibrio per l’aiuto degli utenti e degli sviluppatori. Stiamo basando il nostro approccio sullo studio e sulla raccolta di dati e ci aspettiamo di evolvere ed iterare in questo modo.

Nessun approccio è immune dai rischi, ma non fare assolutamente alcunché o far finta che non ci siano problemi è più rischioso perché lascia solo che peggiori la monocoltura WebKit del mobile web. L’ultima volta che c’è stata una monocoltura nel web, ha fatto rallentare l’open web per anni.

Daniel Glazman, co-chair del CSS Working Group, ha emesso una call for action in risposta al tuo piano. Avete suggerimenti riguardanti quello che potremmo fare per migliorare la situazione?

Come web developer, ci sono alcune cose chiave che possiamo fare.

Per prima cosa, non usiamo più l’UA-sniffing ed il content-serving specifici di “WebKit”, specialmente sul mobile.

Secondo, non usiamo più solo le proprietà con il prefisso -webkit- e usiamo o una proprietà senza prefisso dove è standardizzata o “stabile” per il Working Group, oppure, se non è stabile, usiamo le proprietà con tutti i vendor prefix dove sono stati annunciati o dove è già stato rilasciato il supporto.

Terzo, aiutiamo ad evangelizzare le correzioni per tutti i siti che vedete che fanno UA-sniffing specifico per WebKit e/o usano solo le proprietà con il prefisso -webkit-. In maniera simile, aiutiamo ad evangelizzare le correzioni per tutti i siti webdev che promuovono, anche implicitamente, l’uso del WebKit UA-sniffing e/o l’uso delle proprietà con il solo prefisso -webkit-.

Ancora più importante, impostate un buon esempio: usate innanzitutto gli standard web nei vostri siti, articoli e presentazioni. Quando discutete o dimostrate delle features sperimentali o degli standard-in-progress, sia in un browser o in molti, siate schietti con gli avvertimenti e rendete evidente che un brillante oggi può significare un oscuro domani.

Illustrazioni: {carlok}