ITCSS: Architettura scalabile a triangolo invertito
3 likes1,102 views
Il documento esplora l'architettura ITCSS, una metodologia per gestire il CSS in modo strutturato e scalabile, evidenziando la sua natura di meta-framework e le problematiche comuni nel CSS tradizionale. Viene presentata una struttura a triangolo invertito con vari livelli, che consente di controllare la specificità e le dipendenze, migliorando la manutenzione e l'organizzazione del codice. Infine, si discute l'importanza di un ambiente di lavoro accessibile e della gestione efficace del source order per ridurre la complessità e le ridondanze nel progetto CSS.
ITCSS: Architettura scalabile a triangolo invertito
- 1. FABRIZIO CUSCINI UX/UI DESIGNER • FRONTEND ENTHUSIAST ITCSS Inverted Triangle CSS Architecture
- 2. Scaletta • Cos’è ITCSS • Le sorgenti dei nostri problemi • Struttura di ITCSS: il triangolo invertito • Estendere l’architettura • Organizzazione dei file
- 3. Credits • Harry Roberts • Consulente Frontend Architect • @csswizardry • inuitcss https://github.com/inuitcss • Framework CSS che implementa ITCSS (ovviamente!) • www.csswizardry.com
- 4. COSA È ITCSS
- 5. Cosa non è ITCSS • Non è un linguaggio • Non è un framework • Non è una libreria CSS
- 6. Cosa è ITCSS • Architettura a triangolo invertito • una metodologia, un approccio di alto livello • architettura strutturata e scalabile • un meta-framework (un framework per framework) • molto, molto semplice…
- 7. LE SORGENTI DEI NOSTRI PROBLEMI
- 8. “Colpa” di CSS • Cascata e ereditarietà • Altamente dipendente dal Source Order • Linguaggio poco espressivo • Specificity
- 9. Colpa nostra! • Documentazione, quella sconosciuta • Mancanza di struttura solida, di quality assurance • A volte, poca conoscenza (di CSS o del progetto) • Mix di abilità diverse, altamente soggettive • Diversi stili di programmazione, preferenze, modi di lavorare • Si fa poco caso a cosa esiste già • Aggiungere nuovi stili in coda allo stylesheet
- 10. Cascata e ereditarietà • Ogni porzione di CSS necessita della conoscenza di cosa è venuto prima e di cosa potrebbe venire dopo aka Dependencies
- 12. Cascata e ereditarietà • Ogni porzione di CSS necessita della conoscenza di cosa è venuto prima e di cosa potrebbe venire dopo aka Dependencies • Il CSS di un sito/Web App è un unico gigantesco albero di dipendenze • Abbiamo bisogno di gestire questa dipendenza a basso livello
- 13. Modi di ordinare CSS • Replicare la struttura del sito • homepage.css, contacts.css, … • segmenti tematici: tipografia, forms, buttons, etc… “alla Foundation” • @import "foundation/components/type" • @import "foundation/components/forms" • Aggiungi tutto in coda, alla fine del CSS
- 14. project.css
- 15. project.css
- 16. Houston, abbiamo perso il controllo • Undoing CSS: scrivere (ulteriori) righe di CSS per annullare l’effetto di altre righe di CSS • Source order gestito male, unito a lunghe e complesse catene di eredità possono portare ad un grosso spreco e/o a ridondanza (e perdita di controllo del progetto)
- 17. Specificity (The Specificity wars) • Non importa • quanta cura metti nell’ordinare i tuoi sorgenti, • quanto bene usi la cascata, • quale naming convention usi… • la specificità può annullare tutto.
- 20. Come si può risolvere?
- 22. Scrivi CSS in ordine di specificità.
- 24. IL TRIANGOLO NO, NON LO AVEVO CONSIDERATO
- 25. Abbiamo bisogno di… • un ambiente sano e accessibile a più persone • domare la cascata CSS e gestire il source order • creare un posto in cui far vivere e coesistere tutto (vecchio e nuovo) • ridurre lo spreco di codice (risorse) e ridondanza • mettere fine alle Specificity Wars
- 30. Organizzazione dei livelli • Settings: variabili globali, configurazioni, … • Tools: mixin e funzioni • Generic: stili ground-zero (Normalize, reset, box-sizing) • Base: elementi non classati (type selector) • Objects: cosmetic-free design patterns • Components: componenti, pezzi della UI • Trumps: helpers, overrides, utilities, …
- 31. Ricapitolando…
- 32. SETTINGS Settings disponibili globalmente Configuration Brand colors, etc…
- 34. TOOLS Tool disponibili globalmente Public mixins Helper functions
- 35. @mixin font-brand() { font-family: “UI Font”, sans-serif; font-weight: 400; }
- 36. GENERIC Stili ground-zero Bassa specificità, su vasta scala Reset, Normalize, etc…
- 37. html { box-sizing: border-box; } *, *:before, *:after { box-sizing: inherit; }
- 38. BASE Elementi HTML senza classe H1-H6, text link, liste, … Ultimo livello in cui vediamo selettori di tipo (a {}, blockquote {})
- 39. ul { list-style: square outside; } textarea { height: auto; min-height: 50px; }
- 40. OBJECTS OOCSS Design patterns Niente cosmetica Si utilizzano solo classi Nomi agnostici (.ui-list {})
- 41. .UIList { margin: 0; padding: 0; list-style: none; &__item { padding: ($gutter / 2); } }
- 42. COMPONENTS Veri pezzi di UI Ancora, solo classi Nomi espliciti (.products-list {})
- 43. .ProductsList { @include font-brand(); border-top: 1px solid $brand-color; &__item { border-bottom: 1px solid $brand-color; } }
- 44. TRUMPS Overrides, helpers, utilities Interessa solo un pezzo di DOM alla volta Solitamente, portatore di !important
- 46. .one-half { width: 50% !important; }
- 47. Da notare… • Si gestisce il source order, si doma la cascata, si alleggerisce l’ereditarietà • La specificità aumenta gradualmente, livello dopo livello • Si toccano piccoli pezzetti del DOM alla volta • Ogni livello è un “passaggio” nel DOM • Si aggiungono stili progressivamente, non si “annulla” mai l’effetto di altre righe CSS • Ogni stadio è più dettagliato ed esplicito del precedente
- 48. Come lavora uno scultore • Si ricava della roccia da una cava con dell’esplosivo • Si ricavano dei grandi blocchi • Si inizia ad abbozzare una forma molto generica • Si aggiungono man mano caratteristiche (aspetto) • Solo alla fine, si lavora sui dettagli precisi
- 50. CSS scalabile • Ora, il nostro CSS può scalare facilmente • Aggiungiamo cose nei livelli rilevanti (gli ultimi…) • Le cose non diventano più complicate, ma più grandi • Il trend del grafico della specificità rimane lo stesso
- 51. Architettura personalizzata • Aggiungi o rimuovi livelli se e quando ne hai bisogno • Non usi un preprocessor? Rimuovi i livelli Settings e Tools • Non usi OOCSS? Rimuovi il livello Objects • His bisogno di theming? Aggiungi un livello Theme (dopo Components e prima di Trumps) • Fai A/B Test, devi isolare stili temporanei? Aggiungi un livello Test (prima del Trumps)
- 53. Organizzazione dei file • Prefisso nei file per indicare il livello di appartenenza • settings.global.scss tools.functions.scss generic.ground-zero.scss base.typography.scss • Oppure una cartella per livello • 1-settings/global.scss 2-tools/functions.scss 3-generic/ground-zero.scss 4-base/typography.scss • Un main.scss che include tutto nell’ordine corretto
- 54. // SETTINGS @import "1-settings/global"; // TOOLS @import "2-tools/functions"; @import "2-tools/mixins"; // GENERIC @import “3-generic/ground-zero"; @import "3-generic/normalize"; ... // COMPONENTS @import “6-components/infobox"; ...