Sass File Formating - quali problemi potrebbero esserci con le seguenti regole?

2

Da un po 'di tempo ho preso in considerazione la formattazione dei file SASS per massimizzare la loro usabilità da parte di altri codificatori e penso che questo sarebbe il posto perfetto per ottenere un feedback sulle regole che cerco di applicare durante la scrittura di un file sass. Sono specificamente interessato all'usabilità del codice sorgente così come è stato creato e gestito dagli esseri umani, nonché alla corretta creazione del codice css. Alcune di queste regole potrebbero essere applicate a sass o vanilla css.

Le regole che ho perfezionato sono le seguenti:

  1. Avvia generale e ottieni specifici . Quindi inizia con la dimensione del carattere del corpo, le variabili di colore, le dichiarazioni di tag predefinite, ecc. Quindi spostati tra le parti del tuo sito comuni a tutte le pagine, quindi sugli elementi riutilizzabili del sito e infine concludendo con stili specifici della pagina, con il probabilità di riutilizzo a cascata e potenziale aumento degli stili sovrastati mentre si sposta il / i documento / i

  2. Prova a selezionare i selettori di gruppo in modo che corrisponda alla distribuzione di html tra le visualizzazioni . Quindi se guardo widget.view il file o il blocco di un file etichettato widget.scss conterrà quegli stili. NB, in particolare non intendo seguire la struttura html con gerarchico in questo caso.

  3. A seguito di ciò. Riduci al minimo la quantità di gerarchia definita in sass . Utilizza solo l'ereditarietà basata su Sassy quando necessario.

  4. Raggruppa le proprietà in insiemi logici , quindi larghezza e altezza insieme, dichiarazioni dei font insieme, piuttosto che tutto in ordine alfabetico.

  5. Sempre considera le dimensioni del file css risultante e preparati a utilizzare le classi se necessario invece di mixin, snippet di editor o altre tecniche di incoraggiamento ingannevoli.

  6. Metti più di una proprietà per riga in alcuni casi, seguendo il raggruppamento logico degli elementi, il che significa che più codice può essere montato su uno schermo monitor senza arrivare a fare linee troppo lunghe per leggere facilmente. Non più di 3/4 proprietà per riga.

  7. Blocca codice nei file facendo rientrare tutti i selettori dopo un commento introduttivo per facilitare la scansione del lato sinistro del file e per scoprirne rapidamente il contenuto. Fornisci anche una mappa dei file di questi blocchi nella parte superiore del file, se è grande.

  8. Utilizza segnaposti per le operazioni di ricerca , ad esempio ^ NAVIGAZIONE

  9. Utilizza solo le classi per gli stili . E non aver paura di usare classi per specificità e di riutilizzare più atomici. [modifica per chiarezza - non intendo usare solo classi, voglio dire usare classi invece di ID]

  10. Utilizza un insieme completamente separato di classi specifiche javascript per collegare le funzionalità agli elementi html, il che significa che sia la forma che la funzione possono essere sostituite senza danneggiare l'altra. Queste classi non sono indicate nel css.

  11. Selettori uno per riga e in ordine alfabetico poiché sono arbitrari nel nome

posta Toni Leigh 28.01.2014 - 21:34
fonte

1 risposta

1

La maggior parte dei tuoi punti è molto ovvia e ha senso, indipendentemente dal tipo di progetto su cui stai lavorando. Parlando da un punto di vista di Sass, piuttosto che un puro punto di vista dei CSS, alcuni di essi hanno molto poco senso.

# 5 (considera la dimensione del file css risultante)

Questo è un punto importante che la maggior parte delle persone non conosce bene quando si tratta di usare @extend in Sass. Se il tuo mixin sta generando un sacco di codice che può essere condiviso con altri selettori, allora @extend è una buona idea. Se hai lunghi selettori o il codice condiviso è piuttosto breve, l'utilizzo di @extend porterà a un file CSS più grande (vedi: link )

# 6 (più di una proprietà per riga)

Questa è puramente una preferenza di stile e non ha alcun impatto sulle prestazioni o sulla riusabilità del codice. A mio parere, questo riduce solo la leggibilità della fonte. Il CSS generato verrà formattato in base allo stile di output scelto, quindi il formato della sorgente è irrilevante (a meno che non si usi la sintassi SASS in cui lo spazio / indentazione è importante).

Alcuni di questi si applicano anche ad alcuni dei tuoi punti di formattazione specifici.

# 9 (usa solo le classi per gli stili)

Se il tuo obiettivo deve essere riusabile, non dovresti mai usare le classi. Una delle domande più frequenti relative alle librerie come Bootstrap sono "come uso X con solo nomi semantici" o "come ottengo il codice per X da questo modulo senza importare anche il codice per Y". Invece, crea buoni mix e funzioni in modo che gli utenti possano comporli in un modo che abbia senso per il loro progetto.

# 10 (set separato di classi specifiche javascript)

La forma segue la funzione. Se quello che hai è un interruttore, allora c'è una differenza nello stile tra gli stati aperti e chiusi . Non ha senso fare un'altra classe solo per quello.

Ci sono altre proprietà che vale la pena considerare che potrebbero avere più senso (sia dal lato JavaScript che CSS) come disabilitato , controllato o l'uso degli attributi data-* (ad esempio data-state="opened" ).

    
risposta data 29.01.2014 - 16:35
fonte

Leggi altre domande sui tag