{"id":239,"date":"2012-02-28T18:39:57","date_gmt":"2012-02-28T17:39:57","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/ogni-volta-che-chiamate-css3-una-feature-proprietaria-un-gattino-muore\/"},"modified":"2012-02-28T18:39:57","modified_gmt":"2012-02-28T17:39:57","slug":"ogni-volta-che-chiamate-css3-una-feature-proprietaria-un-gattino-muore","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/ogni-volta-che-chiamate-css3-una-feature-proprietaria-un-gattino-muore\/","title":{"rendered":"Ogni volta che chiamate “CSS3” una feature proprietaria, un gattino muore"},"content":{"rendered":"
\n

Annuncio di pubblica utilit\u00e0: 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 \u00e8 CSS3<\/strong>. S\u00ec, normalmente vengono propagandate come tali, ma non fanno assolutamente parte di CSS. Questa distinzione non \u00e8 pignoleria<\/strong>. \u00c8 importante, perch\u00e9 incoraggia alcuni produttori (*colpo di tosse* Apple<\/a> *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<\/a> promuoverli<\/a>, fungendo da cassa di risonanza.<\/p>\n

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\u00f9 di dieci anni, vi ricordate sicuramente che non \u00e8 sempre stato cos\u00ec. La ragione per cui adesso abbiamo questi vantaggi \u00e8 perch\u00e9 ci sono gli standard web, un dura conquista ottenuta con le Browser Wars<\/a>.<\/p>\n<\/div>\n

\n

Potreste essere sorpresi dall’apprendere che gli standard web esistevano gi\u00e0 durante le Browser Wars<\/strong>. Il W3C fu fondato nel 1994<\/a>. Tuttavia, agli autori non interessava ed erano pi\u00f9 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 \u00e8 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<\/a>.<\/p>\n

S\u00ec, 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\u00ec tremende da usare.<\/p>\n

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

Quindi, quali sono queste infami feature? In CSS, alcune delle pi\u00f9 popolari sono:<\/p>\n