Share
"Odio la console, non faccio Ruby e non mi importa delle variabili, perché nel mondo dovrei imparare Sass?" Smetti di lamentarti e ascolta ...
Conosci già Sass! Si.
Sass ha esattamente la stessa sintassi che ha il CSS. Coincidenza? No. Sass è stato creato in modo che designer come te possano raccoglierlo facilmente e imparare tutti i vantaggi aggiuntivi al loro ritmo, Se loro vogliono.
Quando ho visto per la prima volta Sass, non appena la parola "terminale" ho girato dall'altra parte. Non è che io abbia paura del terminale, è uno strumento molto utile e lo sto usando (quando assolutamente necessario) per anni, ma preferisco semplicemente un'interfaccia utente. Se non ci sono UI, non lo userò.
Indovina un po? Ho scoperto che ci sono diverse opzioni.
Ho usato CodeKit poiché era nella versione beta pubblica. In tutto questo tempo ho usato il terminale per Sass circa tre volte, e avrei potuto evitarlo del tutto.
Quindi non ti piacciono le variabili. E perché nel mondo dovresti passare il tempo avvolgendo la testa a mixin, funzioni e tutto quel jazz? Beh, non lo sai. Sass non ti punirà per questo. Tuttavia, posso prometterti che anche con le tue intenzioni più pure, ti troverai a utilizzarli prima o poi. Non perché tu ne abbia bisogno, ma perché vorrai. Lo stesso vale per i mixin.
Anche se non scriverai mai una singola funzione Sass o un mixin, le userai ancora perché troverai sempre più framework che fanno il duro lavoro per te, permettendoti di trarre beneficio da quel lavoro usando un mixin.
Quindi immaginiamo che ti piacerebbe usare normalize.css per il tuo prossimo progetto. Come avresti intenzione di farlo? Aggiungi un altro tag link al tuo codice HTML? O forse basta usare un @importare dichiarazione nel tuo CSS? In entrambi questi casi si aggiungono richieste HTTP aggiuntive; forse non è un grosso problema, ma non è ottimale e non è la migliore pratica.
Potresti semplicemente copiare il contenuto di normalize e incollarlo nel tuo foglio di stile, ma improvvisamente il tuo file CSS diventa un disastro e non hai nemmeno iniziato il tuo progetto! Allora cosa farai quando gli aggiornamenti di normalize.css? Copia e incolla di nuovo?!
In Sass puoi semplicemente usare il buon vecchio @importaredichiarazione e lascia che Sass estrae il tuo normalize.css nel tuo stylesheet.css (dovresti rinominare i file in .scss invece, ma ancora una volta - non è un grosso problema).
I principi DRY (Do not Repeat Yourself) vengono spesso indicati in linguaggi di programmazione reali, ma non c'è motivo per cui non dovrebbero essere applicati in una certa misura nei CSS. Dopotutto, non era questo il motivo per cui la CSS è stata inventata in primo luogo? Invece di specificare gli stili più e più volte nel tuo codice HTML, potresti improvvisamente creare un nome di classe e dichiarare lì tutti gli stili.
Tuttavia, non appena inizi ad importare codice creato da altri (come framework, reset, ecc.) È probabile che tu ripeta qualcosa.
Ad esempio, normalize.css imposta il carattere del corpo predefinito su "sans-serif". Mi piace, è un buon default. Ma cosa succede se vogliamo usare un carattere personalizzato? Dovremmo modificare normalize.css? E se normalizzare è aggiornato? Dovremo rifare tutto da capo.
Alla fine probabilmente finiremo usando @import in CSS.
Ora dobbiamo solo assicurarci di includere la nostra normalizzazione nella parte superiore del nostro foglio di stile e siamo a posto. Sostituiremo la famiglia dei font, quindi per essere sicuri di fare uno schiaffo !importante dichiarazione alla fine, giusto? Sbagliato!
Purtroppo, normalize.css non è scritto in Sass (ancora), ma ci sono brave persone che hanno convertito normalized.css in Sass, che puoi usare nel tuo CSS. Per esempio:
$ font-family: "Comic Sans";
Ovviamente dovresti già usare Normalize 2.0.1+, che non include più una dichiarazione della famiglia di font, ma questa era più un'illustrazione del problema e la soluzione per esso.
I CSS sono un linguaggio in evoluzione. Se stai ancora pensando che le variabili siano cattive, considera questa Specifica CSS, che fornisce il seguente esempio:
: root var-header-color: # 06c; h1 background-color: var (header-color);
Bene, se quella non è una brutta versione di una variabile, non so cosa sia!
Il punto è che i CSS sono un linguaggio che si sta evolvendo, quindi anche se ignorerai i pre-processori il più a lungo possibile, in futuro ci sarà un punto in cui sarai costretto ad imparare le variabili comunque. Il mio consiglio è di rimanere in testa alla curva e adottare le cose come le variabili nella fase iniziale!
E non sono solo le variabili! Sass e altri preprocessori hanno una notevole influenza sulle future specifiche CSS. Ecco un'altra specifica in fase di sviluppo, che consentirà il nesting dei codici CSS in futuro. Sembrerà qualcosa del genere:
/ * L'esempio seguente che utilizza Gerarchie: * / div, p & .keyword color: green; font-size: 10px; &. conststant color: red; &: hover: after content: "[" attr (value) "]"; background-color: green; / * ... produce gli stessi risultati del seguente CSS: * / div, p font-size: 10px; div .keyword, p .keyword color: green; div. Conststant, p .constant color: rosso; background-color: green; div. conststant: hover: after, p. conststant: hover: after content: "[" attr (value) "]";
Nel caso della specifica, nessun codice è effettivamente compilato, questo è semplicemente il modo in cui i CSS probabilmente guarderanno in futuro!
Le specifiche CSS non sono create da un gruppo di alieni particolarmente creativi che vogliono controllare le nostre vite Web da remoto da una galassia molto lontana. No. Le specifiche sono sviluppate da persone, il che significa che altre persone, in particolare sviluppatori e designer (come te) hanno influenza su quali specifiche sono in fase di sviluppo. Usando pre-processori come Sass, stai partecipando a qualcosa di molto di più. Stai spingendo ulteriormente la tecnologia.
Se ti viene un'idea o una richiesta di funzionalità, puoi richiederla o semplicemente partecipare alla discussione su come deve comportarsi una specifica funzione e se è necessaria a tutti.
Grazie alla comunità che circonda Sass, ci sono strumenti sviluppati da altri che puoi sfruttare.
ZURB, ad esempio, ha creato un grande framework chiamato Foundation for Sass.
Se preferisci qualcosa di più leggero, potresti considerare Inuit.css.
Poi, ovviamente, c'è Compass, che fornisce un quadro con tonnellate di opzioni utili ...
... come del resto il più piccolo Bourbon.
Diciamo che oggi ti senti avventuroso e stai pensando di usare "rem" come unità di misura. Come si usano i rems che forniscono fallback per i browser obsoleti che non li supportano? Fortunatamente, dichiari semplicemente la dimensione del carattere due volte; una volta in pixel, poi di nuovo in rems per i browser che capiranno e analizzeranno.
h1 font-size: 16px; font-size: 1rem;
Probabilmente sarebbe la soluzione migliore, ma significa che dovunque tu voglia usare un rem, dovresti scriverlo due volte. Inoltre, mentre 16px = 1rem è un calcolo semplice, e se hai bisogno di 19px? Adesso fai i conti in testa. Puoi? Sì, ho usato anche una calcolatrice (1.1875rem).
Perché nella comunità di Sass ci sono dei ragazzi fantastici, puoi cercare rapidamente Github e scaricare questo file _rem.scss (che sembra piuttosto intimidatorio, non è vero?), Importalo (parleremo dell'importazione in un attimo) e ora puoi magicamente fare:
h1 @include rem (font-size, 2rem)
a quel punto Sass lo convertirà automaticamente in
h1 font-size: 36px; font-size: 2rem;
Se il giorno dovesse mai arrivare quando puoi lasciare il supporto di fallback, non dovrai fare una ricerca Regex e sostituire tutti i tuoi documenti. Puoi semplicemente aggiungere questo nella parte superiore del tuo foglio di stile.
$ print-rem-px-fallbacks: falso;
Penso che potresti indovinare che cosa fa questa impostazione di "print rem px fallbacks :) :)
Sì. In questo esempio abbiamo utilizzato tre funzioni Sass, una variabile, un mixin personalizzato e un'istruzione "import", ma è stato davvero così difficile?
Quindi ecco una cosa che farai per il resto della tua vita in Web Developer. Definizione dei colori dei collegamenti. Sai, questo genere di cose:
a colore: blu; a: hover color: yellow;
È un compito comunemente ripetuto, ma non ho intenzione di suggerirti di lanciare il tuo Sass Mixin per questo genere di cose. Invece, perché non usare Compass (un Sass Framework)?
a @include link-colors (blue, yellow);
Questo verrà compilato esattamente come sopra. E legge anche abbastanza bene ("includi i colori dei collegamenti: blu e giallo"), nel caso ti stia chiedendo come funziona, consulta la documentazione della bussola.
Se stai utilizzando qualsiasi editor che supporti frammenti, puoi impostare (o scaricare) uno snippet da anteporre automaticamente @includere alle tue dichiarazioni (non lasciare che ti spaventi).
Sass stesso offre un sacco di funzionalità molto, molto utili. Anche se la Documentazione di Sass non è la più bella di tutte le cose (dal punto di vista del designer), contiene molte informazioni molto utili sulle funzionalità di Sass, ad esempio una delle mie funzioni preferite in Sass - Color Functions. Non devo più aprire Photoshop per sperimentare il colore se ho bisogno di una variazione. Posso semplicemente fare questo genere di cose:
a color: lighten (nero, 10%);
Che è compilato in
a color: # 1a1a1a;
Sass non è quel tipo di rubino che gli sviluppatori più esperti usano. Dovrebbe ispirare te, il progettista e aiutarti nel tuo lavoro quotidiano. Non è un linguaggio di programmazione, è una Web Frontier.
Sass può essere facile come vuoi che sia. Se sei curioso di sapere se puoi fare qualcosa in Sass, basta cercare rapidamente google, potresti rimanere sorpreso!
Soprattutto, smettila di parlare di e inizia a usare Sass oggi, soprattutto se vuoi stare davanti alla curva! E tieni gli occhi aperti per tutti i tutorial di Sass, scegli le caratteristiche di Sass che preferisci e usali!
Accentsconagua