{"id":83,"date":"2010-07-19T22:16:10","date_gmt":"2010-07-19T20:16:10","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/prefisso-o-post-hack\/"},"modified":"2010-07-19T22:16:10","modified_gmt":"2010-07-19T20:16:10","slug":"prefisso-o-post-hack","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/prefisso-o-post-hack\/","title":{"rendered":"Prefisso o Post-Hack"},"content":{"rendered":"

Man mano che il supporto dei browser per i CSS aumenta, inclusi i notevoli progressi del team di IE9, sempre pi\u00f9 autori si stanno immergendo in CSS3. E sul loro cammino stanno incontrando i vendor prefixes<\/em> [prefissi per i produttori, ndr<\/em>]\u2014le propriet\u00e0 precedute da -*-<\/code> come -moz-border-radius<\/code>, -webkit-animation<\/code> e cos\u00ec via.<\/p>\n

Forse inevitabilmente, ci sono state un po’ di lamentele rispetto a questi prefissi. Ci sono stati inviti a lasciarli perdere o a riunire tutti i prefissi specifici per ciascun vendor in un singolo prefisso come -beta-<\/code>. La principale riserva nei confronti dei vendor prefix \u00e8 che nessuno in realt\u00e0 vuole scrivere la stessa cosa quattro o cinque volte in fila per ottenere, ad esempio, gli angoli arrotondati su un elemento.<\/p>\n

Mentre tale lamentela \u00e8 comprensibile, \u00e8 esattamente l’opposto di quel dovrebbe accadere. Dovremmo encomiare i produttori che usano i prefissi e realmente incoraggiarli a continuare su questa strada. Oltre a ci\u00f2, ritengo che i prefissi debbano diventare una parte centrale del processo di standardizzazione dei CSS. Sostengo questo non per amore della ripetizione, ma per il desiderio di vedere i CSS evolversi consistentemente. Credo che i prefissi possano effettivamente accelerare l’avanzamento ed il miglioramento della specifica CSS.<\/p>\n

\n

Guardare al passato con orrore<\/h2>\n

Per capire come mai esistano i vendor prefix, \u00e8 istruttivo guardare indietro al box model<\/a>, 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<\/em> inventare una nuova classe di hack.<\/p>\n

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\u00f2 il box model che si trova nella specifica CSS. Questo significa che width<\/code> e height<\/code> facevano riferimento alla larghezza e all’altezza dell’area del contenuto. Ma Internet Explorer implement\u00f2 il box model intuitivo: il che significa che width<\/code> e height<\/code> dichiaravano le dimensioni del bordo pi\u00f9 esterno della box.<\/p>\n

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\u00f9 non posso per lasciarci alle spalle il pantano dei badge \u201csito ottimizzato per\u202f\u201d e ci trovavamo in una situazione in cui un layout che andava bene in un browser era completamente sfasciato in un altro.<\/p>\n

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\u00f2 vorrebbe dire che decine, perfino centinaia di migliaia di siti che fino a quel momento funzionavano in IE si sarebbero rotti.<\/p>\n<\/div>\n

\n

Immaginate un risultato diverso<\/h2>\n

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

Anche se avevano deciso che ci\u00f2 fosse impossibile da realizzare, il danno della “cattiva” implementazione avrebbe messo in quarantena la versione con la propriet\u00e0 con il prefisso. Altri produttori avrebbero implementato la nuova versione di clip<\/code> (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.<\/p>\n

Questa \u00e8 la promessa che fanno i prefissi: un modo per segnalare le propriet\u00e0 come “in progress,” e, quindi, non \u00e8 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\u00e0 di cui si ha bisogno affinch\u00e9 CSS possa avanzare.<\/p>\n

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\u00f9 semplice da raggiungere, grazie agli allarmi che i prefissi impersonano. Senza i prefissi diventa molto pi\u00f9 difficile, perfino impossibile. Microsoft non ha mai cambiato il modo in cui gestisce width<\/code> e height<\/code> nelle pagine legacy—al contrario, ha usato il DOCTYPE switching per comportarsi in maniera differente sulle nuove (in teoria pi\u00f9 “standards compliant”) pagine. Era un trucco utile e necessario, ma quel tipo di trucco ha funzionato una sola volta.<\/p>\n<\/div>\n

\n

Soffriamo ancora adesso<\/h2>\n

Affinch\u00e9 non pensiate che tutta questa pazzia sia un artefatto storico, eccovi due esempi di inconsistenze che accadono al giorno d’oggi<\/em>:<\/p>\n