![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/01\/gufo.jpg\")
<\/p>\n<\/p>\n
Lo scorso Giugno, al CSS Day<\/a> ho presentato, con un po’ di trepidazione, un peculiare selettore CSS composto da tre caratteri. Detto \u201clobotomized owl selector\u201d (selettore gufo lobotomizzato, ndr<\/em>) per la sua somiglianza con lo sguardo vacuo di un gufo, si \u00e8 dimostrata essere la sezione pi\u00f9 popolare del mio talk<\/a>.<\/p>\n Non so dirvi se il pubblico applaudiva il ragionamento dietro all’invenzione o se, al contrario, stavano ridendo nervosamente della mia audacia nell’includere un costrutto cos\u00ec strano e apparentemente inutile. Forse stavo inconsapevolmente parlando a un pubblico pagato di supporter di un santuario per gufi. Non lo so.<\/p>\n Il lobotomized owl selector ha questo aspetto:<\/p>\n Nonostante il suo nome irriverente e la sua forma precaria, il lobotomized owl selector non \u00e8 un semplice esperimento per me. \u00c8 il risultato di sperimentazioni continue nell’automazione del layout del flow content. L’owl selector \u00e8 un selettore \u201cassiomatico\u201d con una portata vorace. Come tale, molti esiteranno ad usarlo e terrorizzer\u00e0 qualcuno sapere che lo includo nel production code. Voglio dimostrare in che modo il selettore pu\u00f2 ridurre gli eccessi, velocizzare lo sviluppo e aiutare ad automatizzare il contenuto dinamico arbitrario.<\/p>\n In maniera quasi universale, i web interface designer professionisti (ingegneri o qualunque cosa siano) si sono abituati a dare stili agli elementi HTML in maniera prescrittiva<\/em>. Concepiamo un oggetto dell’interfaccia, poi creiamo gli stili per quell’oggetto che vengono scritti manualmente nel markup come \u201chook\u201d.<\/p>\n Nonostante appartenga solo alla presentazione, non all’interoperabilit\u00e0 semantica, il selettore di class \u00e8 ci\u00f2 a cui ricorriamo pi\u00f9 frequentemente. Mentre gli elementi e la maggior parte degli attributi sono predeterminati e standardizzati, le class sono dei segnaposti che ci regalano la libert\u00e0 della authorship. Le class ci danno controllo.<\/p>\n I framework CSS sono sostanzialmente delle librerie di codice non standard basate sulle class, intese a formare relazioni esplicite tra gli stili e i loro elementi. Sono celebrati per la loro abilit\u00e0 di aiutare i designer a produrre interfacce attraenti in maniera rapida e sono criticati per gli inevitabili limiti di accessibilit\u00e0 che risultano quando si parte dallo stile (forma) piuttosto che dal contenuto (funzione).<\/p>\n Sia che usiate un framework o la vostra metodologia, il modo di assegnare stili prescrittivo rende impossibile la creazione del contenuto agli editor non tecnici in quanto richiede non solo la conoscenza del markup presentazionale, ma anche l’accesso a quel markup per codificare gli stili prescritti. Agli editor WYSIWYG e ai tool come Markdown manca necessariamente questa complessit\u00e0 cos\u00ec che l’assegnamento degli stili non impedisca il processo editoriale.<\/p>\n<\/div>\n Indipendentemente se siate in grado o meno di creare e mantenere il markup presentational, la questione se dobbiate<\/em> rimane. Aggiungere codice presentational al vostro markup precedentemente intonso, lo congestiona necessariamente, ma qual \u00e8 il compromesso? Ci permette di ridurre l’eccesso e la congestione nel foglio di stile?<\/p>\n Scegliendo di assegnare stili interamente in termini di elementi identificati con nomi, facciamo l’errore di asserire che gli elementi HTML esistono nel vuoto, non soggetti all’ereditariet\u00e0 o alla condivisione. Trattando l’elemento come \u201cquesta cosa a cui devono essere assegnare stili\u201d, siamo responsabili dell’impostazione di alcuni valori per l’elemento in questione che avrebbero gi\u00e0 dovuto essere definiti pi\u00f9 in alto nel \u201ccascade\u201d. Aggiungere nuovi moduli a un progetto favorisce la congestione, che \u00e8 una cosa difficile da tenere sotto controllo.<\/p>\n Dai pre-processori con la loro aggiunta di variabili a metodologie CSS basate sugli oggetti e la loro applicazione di classi \u201coggetto\u201d riutilizzabili, siamo alle prese con i sacchi di sabbia per arginare questa marea di bloat. \u00c8 l’ossessione del nostro settore. Comunque, pochi rimedi respingono la filosofia prescrittiva che richiama il bloat per prima cosa. Alcune interpretazioni del CSS object-oriented insistono anche nella gerarchia appiattita di stili, citando la specificit\u00e0 come problema da superare<\/a> – riducendo in realt\u00e0 il CSS a SS e negando una delle sue feature chiave.<\/p>\n Non sto scrivendo per condannare completamente questi approcci e tecnologie, ma ci sono altri metodi che possono essere pi\u00f9 efficaci sotto certe condizioni. Tenetevi stretto il cappello!<\/p>\n<\/div>\n Sono felice di ammettere che quando qualcuno tra voi ha visto i due asterischi in Tutti gli studi che ho letto, inclusi quelli di Steve Souders<\/a> e di Ben Frain<\/a>, hanno concluso che la performance comparativa di diversi tipi di selettore CSS \u00e8 insignificante. In effetti, Frain conclude che \u201cimpazzire sui selettori usati nei browser moderni \u00e8 futile\u201d. Non ho ancora letto alcuna prova convincente per smentire questi risultati.<\/p>\n Secondo Frain \u00e8 al contrario, la quantit\u00e0 di selettori CSS, il bloat, che pu\u00f2 causare problemi: egli cita nello specifico le dichiarazioni non utilizzate. In altre parole, adottare i selettori di class per la loro \u201cvelocit\u00e0\u201d \u00e8 di poca utilit\u00e0 quando la loro proliferazione \u00e8 in realt\u00e0 la causa dei reali problemi di performance. Beh, quello e i JPEG giganti e i web font di cui non sono stati selezionati solo alcuni sottoinsiemi.<\/p>\n Al contrario, il controllo simultaneo da parte del selettore * di pi\u00f9 elementi accresce la brevit\u00e0, aiutando a ridurre la dimensione del file e a migliorare la performance.<\/p>\n Il vero<\/em> problema con il selettore universale \u00e8 che da solo non rappresenta un assioma molto convincente, nulla di pi\u00f9 intelligente di \u201cassegna uno stile a qualsiasi cosa\u201d. Il trucco sta nell’imbrigliare questo selettore di base e formare espressioni pi\u00f9 complesse che siano consapevoli del contesto.<\/p>\n<\/div>\n Il problema del confinare gli stili agli oggetti \u00e8 che non tutto dovrebbe essere considerato come propriet\u00e0 di un oggetto di per s\u00e9<\/em>. Prendiamo in considerazione i margini. Questi sono un qualcosa che esiste tra gli elementi. Assegnare semplicemente un margin top ad un elemento non ha senso, indipendentemente dalla frequenza con cui lo fate. \u00c8 come applicare la colla a un lato di un oggetto prima di aver determinato se volete che davvero si appiccichi a qualcosa o che cosa sar\u00e0 quel qualcosa.<\/p>\n Ci\u00f2 di cui abbiamo bisogno \u00e8 un’espressione (un selettore) che colleghi solo gli elementi a cui serve un margin, ossia, solo gli elementi in relazione contestuale con altri elementi di pari livello (sibling elements). L’adjacent sibling combinator<\/a> fa proprio questo: usando la forma x + n, possiamo aggiungere un margin top a qualunque n che sia preceduto da x.<\/p>\n Questo diventerebbe verboso molto rapidamente, come con lo styling prescrittivo standard, se dovessimo creare regole per ogni singolo elemento che si accoppia all’interno dell’interfaccia. Pertanto, adottiamo il sopracitato selettore universale, creando le nostre facce da gufo. L’assioma \u00e8 il seguente: \u201cTutti gli elementi nel flusso del documento che precedono altri elementi devono ricevere un margin top di una linea.\u201d<\/p>\n Supponendo che il font-size<\/var> dei paragrafi sia 1 Invece di scrivere stili, abbiamo creato un assioma di stile: un principio generale per il layout del flow content. Si pu\u00f2 inoltre mantenere molto bene: se si cambia la line-height<\/var>, basta cambiare semplicemente un singolo valore di margin-top<\/var> per abbinarlo.<\/p>\n Comunque, \u00e8 meglio di cos\u00ec. Applicando solo il margin tra gli elementi, non generiamo altro margin ridondante (colla esposta) destinato a combinarsi con il padding degli elementi padre. Confrontate la soluzione (a), che aggiunge un margin top a tutti gli elementi, con la soluzione (b), che usa l’owl selector.<\/p>\n I diagrammi nella colonna di sinistra mostrano il margin in grigio scuro e i padding in grigio chiaro.<\/p>\n<\/div>\n Ora, considerate come questo si comporta nei confronti dell’annidamento. Come mostrato, usando il selettore gufo e il solo valore di margin-top, nessun primo o ultimo elemento di un insieme presenter\u00e0 mai un margine ridondante. Ogni volta che si crea un sottoinsieme di questi elementi, inserendoli in un genitore annidato, si applicheranno al sottoinsieme le stesse regole del super-insieme. Nessun margin, indipendentemente dal livello di annidamento, incontrer\u00e0 mai il padding. Con una specie di eleganza algoritmica, ci proteggiamo dal “compound whitespace” in tutta la nostra interfaccia.<\/p>\n Questo \u00e8 considerevolmente meno verboso e pi\u00f9 robusto dell’approcciare il problema senza gli assiomi e rimuovendo la colla rimasta dopo il fatto<\/em>, come ha proposto Chris Coyier in maniera riluttante in \u201cSpacing The Bottom of Modules<\/a>\u201d. Devo sottolineare che \u00e8 stato questo articolo che ha contribuito a farmi elaborare l’idea del gufo lobotomizzato.<\/p>\n Notate che questo funziona solo se si \u00e8 definito un contesto di \u201cmodule\u201d (una grande richiesta da parte di un content editor) e richiede la stima dei possibili livelli di annidamento: in questo caso ne supporta tre.<\/p>\n<\/div>\n Finora, non abbiamo dato nomi ad alcun elemento, abbiamo semplicemente scritto una regola. Adesso possiamo trarre vantaggio dalla bassa specificit\u00e0<\/a> del selettore gufo e cominciare a costruire delle espressioni in maniera giudiziosa, sfruttando il cascade piuttosto che condannarlo come fanno altri metodi.<\/p>\n Notate che vengono indentati solo i paragrafi successivi, come da convenzione. Un’altra vittoria per l’adjacent sibling combinator.<\/p>\n Potete utilizzare un pochino di orientamento agli oggetti basato sui nomi delle classi se volete, per creare uno stile riutilizzabile per moduli pi\u00f9 compatti. In questo esempio, tutti gli elementi che hanno bisogno di un margine lo ricevono solo di met\u00e0 riga.<\/p>\n L’owl selector \u00e8 un selettore significativo e influenzer\u00e0 widget come le mappe, in cui tutto \u00e8 posizionato esattamente. Questo \u00e8 un semplice interruttore di spegnimento. Sempre pi\u00f9 spesso, widget di questo tipo occorreranno come web component in cui il nostro algoritmo per il margin non verr\u00e0 comunque ereditato. Questo grazie alla feature di incapsulamento dello stile di Shadow DOM<\/a>.<\/p>\n<\/div>\n Sebbene alcune eccezioni siano inevitabili, imbrigliando l’unit\u00e0 Nel caso degli heading, abbiamo ancora pi\u00f9 fortuna. Avendo impostato le dimensioni del testo dei titoli in Questa dichiarazione di stile \u00e8 destinata ad essere ereditata. \u00c8 il modo in cui essa, e CSS in generale, devono funzionare. Tuttavia, apprezzo che qualcuno si sentir\u00e0 a disagio con la voracit\u00e0 di questo selettore, specialmente dopo che si \u00e8 stati abituati ad evitare l’ereditariet\u00e0 ogni volta che si pu\u00f2.<\/p>\n Ho gi\u00e0 coperto alcune eccezioni che potrete usare, ma, se vi \u00e8 di ulteriore aiuto, ricordatevi che i phrasing element con un tipico valore di display Se vi trovate a dover sovrascrivere il selettore gufo frequentemente, ci potrebbero essere dei problemi sistemici pi\u00f9 profondi con il design. L’owl selector gestisce il flow content e il flow content dovrebbe costituire la maggior parte del vostro contenuto. Non suggerisco di dipendere pesantemente dal contenuto posizionato nella maggior parte delle interfacce perch\u00e9 questo rompe le relazioni implicite di flusso. Anche i grid system, con le loro colonne a cui \u00e8 applicato float, dovrebbero richiedere non pi\u00f9 di un semplice selettore * + *<\/code><\/pre>\n\nStili da prescrizione<\/h2>\n
.my-module {\n\t\/* ... *\/\n}<\/code><\/pre>\n< !-- An unfocusable, semantically inaccurate \"button\" -->\n<a class=\"ui-button\">press me<\/a><\/code><\/pre>\n\nBloat<\/h2>\n
.module-new {\n\t\/* So\u2026 what\u2019s actually new here? *\/\n}<\/code><\/pre>\n\nPerformance del selettore<\/h2>\n
* + *<\/code> all’inizio dell’articolo, avr\u00e0 scosso la testa con vigorosa disapprovazione. C’\u00e8 un precedente per questo. Il selettore universale<\/a> \u00e8 sicuramente uno strumento potente, ma pu\u00f2 essere potente in maniera positiva, non solo negativa. Prima di addentrarci in questo, per\u00f2, voglio parlare della questione della performance percepita.<\/p>\n\nDistribuire i margini<\/h2>\n
.module-new {\n\tmargin-bottom: 3em; \/* what, all the time? *\/\n}<\/code><\/pre>\n* + * {\n\tmargin-top: 1.5em;\n}<\/code><\/pre>\nCompletezza<\/h3>\n
em<\/code> e la sua line-height<\/var> sia 1.5, impostiamo semplicemente un margine di una riga tra tutti gli elementi successivi nel flusso, di qualunque tipo siano e in qualunque ordine. N\u00e9 noi sviluppatori n\u00e9 le persone che creeranno il contenuto per il progetto dovranno preoccuparsi di dimenticare un qualsiasi elemento e di non adottare almeno un margine standard quando verranno visualizzati uno dopo l’altro. Per ottenere questo nel modo prescrittivo, dovremmo anticipare specifici elementi e dare loro valori individuali per il margin. Noioso, verboso e soggetto ad incompletezza.<\/p>\nConsapevolezza del contesto<\/h3>\n
![\"Diagramma](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/01\/owl_1.png\")
<\/p>\n![\"Diagramma](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/01\/owl_2.png\")
<\/div>\n.module > *:last-child,\n.module > *:last-child > *:last-child,\n.module > *:last-child > *:last-child > *:last-child {\n\tmargin: 0;\n}<\/code><\/pre>\n\nDesign exception-driven<\/h2>\n
Paragrafi giustificati in stile libro<\/h3>\n
p {\n\ttext-align: justify;\n}\n\np + p {\nmargin-top: 0;\ntext-indent: 2em;\n}<\/code><\/pre>\nModuli compatti<\/h3>\n
.compact * + * {\n\tmargin-top: 0.75em;\n}<\/code><\/pre>\nWidget con il posizionamento<\/h3>\n
.margins-off > * {\n\tmargin-top: 0;\n}<\/code><\/pre>\n\nLa bellezza degli
em<\/code><\/h2>\nem<\/code> nel nostro valore di margin, i margini si sistemano gi\u00e0 automaticamente in base a un’altra propriet\u00e0: font-size<\/var>. In qualunque istanza in cui cambiamo il font-size<\/var>, il margin si adatter\u00e0 ad esso: gli spazi di una riga rimarranno spazi di una riga. Questo \u00e8 particolarmente di aiuto quando si imposta un font-size<\/var> aumentato o ridotto al body con una @media<\/code> query.<\/p>\nem<\/code> nel foglio di stile, \u00e8 stato impostato un margine appropriato (leading whitespace) per ciascun heading senza che dovessimo scrivere una singola riga di codice in pi\u00f9.<\/p>\n![\"Diagramma](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/01\/owl_3.png\")
<\/div>\n<\/div>\n\nPhrasing element<\/h2>\n
inline<\/code> erediteranno il top margin ma in termini di layout non ne saranno influenzati. Gli elementi inline rispettano solo i margini orizzontali, che \u00e8 il comportamento specificato e standard in tutti i browser.<\/p>\n![\"Diagramma](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2015\/01\/owl_4.png\")
<\/div>\n.row > *<\/code> che applica margin-top: 0<\/code> per resettarle.<\/p>\n
![\"Diagramma](\"https:\/\/alistapart.com\/wp-content\/uploads\/2014\/10\/owl_5.png\")
<\/div>\n<\/div>\n