No. 202

Annuncio di pubblica utilità: ogni volta che definite "CSS3" una feature proprietaria, un gattino muore. Qualsiasi feature -webkit- che non sia presente in una specifica (nemmeno in Editor's draft) non è CSS3. Sì, normalmente vengono propagandate come tali, ma non fanno assolutamente parte di CSS. Questa distinzione non è pignoleria. È importante, perché incoraggia alcuni produttori (*colpo di tosse* Apple *colpo di tosse*) ad aggirare il processo degli standard, ad implementare qualsiasi cosa vogliano in WebKit, per poi evangelizzarla agli sviluppatori come la cosa migliore del mondo. I nuovi scintillanti giocattoli ci abbagliano e cominciamo anche noi a promuoverli, fungendo da cassa di risonanza.

Con il nostro spasmodico desiderio di utilizzare il nuovo gioiello, ci dimentichiamo spesso delle molte persone che hanno combattuto nei dieci anni passati per permetterci di scrivere codice senza fork e senza hack aspettandoci che funzioni in maniera interoperabile. Se siete stati in questo settore per più di dieci anni, vi ricordate sicuramente che non è sempre stato così. La ragione per cui adesso abbiamo questi vantaggi è perché ci sono gli standard web, un dura conquista ottenuta con le Browser Wars.

Potreste essere sorpresi dall'apprendere che gli standard web esistevano già durante le Browser Wars. Il W3C fu fondato nel 1994. Tuttavia, agli autori non interessava ed erano più che felici di adottare le estensioni proprietarie. Come risultato, i browser non davano molto peso agli standard web. Vi ricorda qualcosa? Le feature proprietarie di oggi non sono migliori di ActiveX o dei filtri IE: l'unica differenza è un PR migliore, dal momento che non ne abbiamo ancora affrontate le conseguenze. Credeteci o no, anche quelle feature furono accolte con gioia in quel periodo.

Sì, a volte i browser se ne escono con delle buone trovate che vengono poi rese standard (XMLHttpRequest, le API Drag and Drop, contentEditable, Web fonts, solo per citarne alcune). Comunque, nulla gli impedisce di innovare e seguire il processo degli standard. Nulla gli vieta di proporre cose fichissime, sottoporle all'appropriato Working Group del W3C e migliorarle attraverso il feedback collettivo prima di correre ad implementarle. Se Microsoft l'avesse fatto per le API Drag & Drop, non sarebbero così tremende da usare.

Le feature proprietarie che non sono passate attraverso il processo degli standard, solitamente hanno una progettazione misera, anche quando l'idea generale è buona. Ad esempio, i gradienti CSS sono stati una buona idea, ma -webkit-gradient() era un disastro verboso e facile agli errori. I web font sono stati un'idea grandiosa, ma richiedere i files .eot non lo è stato. Il processo degli standard non solo aiuta l'interoperabilità, ma aiuta anche a migliorare la progettazione di ciascuna feature, grazie al maggior numero e alla diversità di opinioni.

Quindi, quali sono queste infami feature? In CSS, alcune delle più popolari sono:

  • -webkit-box-reflect
  • -webkit-text-stroke
  • -webkit-mask
  • -webkit-background-clip: text;
  • -webkit-text-size-adjust
  • -webkit-tap-highlight-color
  • -webkit-text-fill-color

Non tutte le feature con prefisso sono proprietarie. Alcune sono solo implementazioni sperimentali di feature incluse nelle specifiche in draft. Il che ci porta alla prossima domanda.

“Come scopro se una determinata feature è proprietaria?”

Un modo che funziona per me è cercare in Google tale feature (tra virgolette) e aggiungere alla fine della stringa di ricerca site:w3.org, per cercare solo nel dominio w3.org. Due esempi:

Come potete vedere, uno dei primissimi risultati per la prima feature è una specifica del W3C. I risultati della seconda sono semplicemente delle discussioni nelle mailing list, il che indica che non c'è ancora una specifica per questa feature.

“Come posso aiutare?”

Un facile regola pratica è quella di evitare tutte le feature proprietarie. Non usatele, non diffondetele e indubbiamente non siatene dipendenti. Tuttavia, capisco che sia più facile a dirsi che a farsi: se non potete escludere completamente le cose proprietarie, ecco alcune linee guida che potete seguire di sicuro:

  • Assicuratevi che il loro utilizzo si conforme ai principi del progressive enhancement, così che il progetto funzioni bene anche senza di esse.
  • Non evangelizzatele o, se dovete, siate sicuri di spiegare che queste feature sono proprietarie e cosa questo implichi.
  • Se dovete usarle nel vostro codice, aggiungetegli un commento. Qualcosa come /* Attenzione: Non standard */ è sufficiente. Molte persone apprendono la programmazione front-end guardando il sorgente di siti esistenti. Anche quando non fate interventi a conferenze o non scrivete dei tutorial, probabilmente state insegnando indirettamente a delle persone con ogni singolo pezzo di codice che pubblicate sul web.
  • Additate gli articoli, le presentazioni a conferenze, le demo e così via che evangelizzano queste feature senza mettere in guardia dal loro status proprietario o che usano un solo vendor prefix (un altro problema molto serio). O, meglio ancora, sistemateli voi, se è possibile.

“Come posso contribuire alla standardizzazione di una feature?”

Se vi trovate nelle condizioni di dover usare una feature proprietaria molto spesso, entrate in azione per rendere standard qualcosa di simile. Quella che segue è una serie di step che vi raccomando di seguire, la maggior parte dei quali può essere applicata alle nuove proposte in generale:

Step 1: ricercate alternative standard-compliant

Prima di tutto, ricercate delle alternative conformi agli standard. Potrebbero avere un supporto da parte dei browser peggiore o inesistente, ma almeno saprete cosa spingere. Potete perfino aggiungerle come fallback, così da evitare che gli altri vendor saranno tagliati fuori dopo che avranno implementato questa feature.

Potete perfino contribuire a velocizzare l'implementazione, mandando la notifica di un bug ai browser che non la supportano. Assicuratevi prima di aver controllato che non ci siano già dei report. Se è già stato riportato, potete ancora mostrare che per voi è importante scrivendo un commento (siate educati!). I browser tengono in considerazione le richieste degli autori quando assegnano le priorità alle feature da implementare. Mostrategli che una certa feature vi sta a cuore.

Step 2: Guardate se la feature è già stata proposta

Il W3C discute quali feature aggiungere e come migliorarle per renderle perfette nelle loro mailing lists. Ce n' una per Working Group (WG), a volte di più, dal momento che i Working Group possono collaborare per sviluppare feature che toccano più tecnologie. Ad esempio, il CSS WG usa la mailing list www-style e lo SVG WG usa la mailing list www-svg. Tuttavia, per le feature che toccano sia CSS sia SVG, c'è la mailing list public-fx.

Prima di mandare un messaggio a una qualunque di queste liste, cercate tra le discussioni precedenti sul problema, per favore. Ogni minuto che un membro del WG passa a rispondere a suggerimenti duplicati è un minuto in meno che passa a sviluppare gli standard web. Per cercare tra gli archivi potete usare di nuovo il buon vecchio Google. Inserite le parole chiave come fareste di solito e aggiungete in coda alla query site:lists.w3.org.

Se vedete che la feature è già stata suggerita, ma la discussione è in stallo senza alcuna risoluzione, potete rispondere (una volta!) per riportarla a galla. Per favore, evitate di apparire impazienti o irritati nelle vostre email. Continuate a leggere la discussione per trovare delle idee su cose da aggiungere ma che nessuno ha ancora sollevato.

Step 3: proponete la feature

Cercate di includere quanti più dati rilevanti possibile.

Alcuni tipi di informazione che potreste includere sono:

  • Use cases in cui la feature si dimostra utile. Questo è molto importante: nessun WG vuole standardizzare cose che verranno usate solo in casi limite. Mostrate che quello che state suggerendo è di uso comune. Un'utile tecnica per riunire tali use cases consiste nel cercare su Google la feature proprietaria e vedere come viene utilizzata.
  • La vostra esperienza derivante dall'uso di tale feature. Cosa vi piace, cosa cambiereste nel suo modo di funzionare, come potrebbe essere generalizzata, etc.

Inoltre, decidete per quali specifiche è adatta. Potete trovare una lista di specifiche CSS qui. Poi, aggiungete all'inizio del titolo del vostro thread l'ID tra parentesi quadre di tale specifica. Ad esempio, se è per le Values & Units, aggiungete all'inizio [css3-values]. (L'ID di ciascuna specifica si trova nel suo URL). Facendo così, ci assicuriamo che gli editori di tale specifica noteranno il vostro thread più facilmente e taggarlo aiuta tutti a seguire gli sviluppi di alcune specifiche a cui sono interessati.

Un'altra cosa da tenere a mente è che le nuove feature non vengono aggiunte alle specifiche che hanno raggiunto o che stanno per raggiungere lo stato di Candidate Recommendation. Ovviamente, la stessa regola si applica anche a tutti gli stati successivi, i.e., Proposed Recommendation e Recommendation.Ad esempio, se il vostro suggerimento riguarda l'aggiunta di un nuovo selettore, non suggeritelo per Selectors Level 3 (ID: css3-selectors), che è nello stato Recommendation, ma per Selectors Level 4.

Se volete saperne di più sul funzionamento del processo degli standard, potete leggere l'eccellente serie di articoli di fantasai “Inside the CSS WG.”

“Tutto ciò è difficile e noioso!”

Lo stesso si può dire anche per il riciclaggio rispetto al buttare tutto nello stesso cestino. Sì, di sicuro è più difficile rispetto ad usare le feature proprietarie e portare a casa la giornata. Tuttavia, questo processo è nell'interesse di tutti sul lungo termine, inclusi voi stessi.

Grazie mille a David Storey, Sylvain Galineau e Eric Meyer per il loro feedback.

Illustrazioni: Carlo Brigatti

Share/Save/Bookmark
 

Discutiamone

Ti sembra interessante? Scrivi tu il primo commento


Cenni sull'autore

Lea Verou

Lea VerouLea è da molto tempo appassionata di open web standards e spesso viene chiamata “CSS guru”. Le piace cercare nuovi modi per trarre vantaggio dalle moderne tecnologie del web e condividere le sue scoperte sul suo blog: lea.verou.me. Lea crea anche dei tools e delle librarie molto popolari che aiutano i web developer ad imparare ad usare questi standard. È relatrice in molte famose conference internazionali per web developer e scrive per delle testate di settore molto importanti. Lea ha anche co-organizzato e tiene occasionalmente delle lezioni per dei corsi di web development alla Athens University of Economics and Business.

Questo sito per poter funzionare utilizza i cookie. Per saperne di più visita la pagina relativa all' INFORMATIVA