Segnaposto SASS per evitare regole ripetute nell'output CSS

Question

Segnaposto SASS per evitare regole ripetute nell'output CSS

#1 da (1 voti)

3

Ho una domanda per tutti i membri del frontend qui. Prima di tutto, non si tratta di segnaposto vs mixin di cui ho già un'idea, se usarne uno o l'altro.

Quindi la domanda è: usi segnaposto SASS con una sola, o forse due regole per evitare più occorrenze nell'output CSS risultante?

Ad esempio, considera una pagina, in cui devi spostare molti, molti, molti diversi elementi a sinistra. Sarebbe una buona idea creare un segnaposto con solo "float: left" ed estenderlo se necessario? Ciò comporterebbe una dichiarazione "float: left" per più selettori nell'output CSS, invece di essere dichiarata di nuovo per ogni selettore. Potrei dare più situazioni, ad esempio uguali margini / paddings per molti elementi e così via. Non si tratta di utilizzare variabili in quanto ciò comporterebbe anche una ridichiarazione per ciascun selettore. Non si tratta anche di evitare la "classite". Si tratta di dichiarare una regola da capo nel CSS compilato. E se in futuro avresti bisogno di aggiungere qualche clearing o qualsiasi cosa a tutti gli elementi floated, potresti semplicemente cambiare il segnaposto

Ecco un esempio di codice (per favore non preoccuparti della denominazione, è solo a scopo illustrativo):

// Placeholders
%left {
  float: left;
}

%margin {
  margin: 20px;
}

// Selectors, which use the defined placeholders
.selector-1 {
  @extend %left;
  @extend %margin;
  // Other rules
}

.selector-2 {
  @extend %left;
  // Other rules
}

.selector-n {
  @extend %left;
  @extend %margin;
  // Other rules
}

Risultante nel seguente CSS:

.selector-1,
.selector-2,
.selector-n {
  float: left;
}

.selector-1,
.selector-n {
  margin: 20px;
}

.selector-1 {
  // Other rules
}

.selector-2 {
  // Other rules
}

.selector-n {
  // Other rules
}

Invece di:

.selector-1 {
  float: left;
  margin: 20px;
  // Other rules
}

.selector-2 {
  float: left;
  // Other rules
}

.selector-n {
  float: left;
  margin: 20px;
  // Other rules
}

Avrebbe un impatto sul rendimento della pagina? Porterebbe a un codice più disordinato e difficile da gestire? Quale sarebbe il tuo approccio su questo?

Non sto assolutamente cercando una risposta specifica e definitiva. Solo piuttosto alcuni pensieri, intuizioni e esperienze personali.

web-development front-end websites css

posta bfj 22.01.2015 - 21:46

fonte

1 risposta

Leggi altre domande sui tag web-development front-end websites css

Tracciare un oggetto Come aggiungere rigore ai miei test?

score 1 · Accepted Answer

Questa è una domanda molto interessante e sono molto interessato a ciò che pensano gli altri. Sto usando SASS da un po 'ora e per la maggior parte tendo a non usare affatto la funzionalità @extend . Nel caso di float left o right dovrei probabilmente solo creare una classe .float-left e aggiungerla al markup che deve essere floatato o avere solo float:left nella regola del selettore.

Per quanto riguarda la qualità del codice quando si ha una sola regola nella cosa che si sta estendendo, non si ottiene realmente alcuna manutenibilità. Quando si tratta di 2 o più regole in una misura che dovrebbe aiutare da un aspetto di manutenibilità. D'altra parte, puoi semplicemente aggiungere entrambi i selettori al markup, non ho un'opinione strong su quale sia il migliore.

.float-left-pad {
   float:left;
   padding: 5px;
}

.selector1 {
   @extend:.float-left-pad
   ..
}

div.selector1

vs

.selector1 {
  ...
}

div.selector1.float-lef-pad

Non ho davvero idea di cosa sia il tuo codice base, ma sarei un po 'preoccupato dell'uso di @extends per scrivere css riassicurabili. Quando ho comunemente usato valori o markup, tendo a inserirli in mix o variabili per promuovere il codice su @extends . Questo approccio tende a lavorare per i progetti della complessità su cui lavoro ma potrebbe non essere sufficiente per i casi degli altri. Riesco a vedere casi in cui l'utilizzo di @extends produrrà un codice più laconico, ma penso che ciò si traduca a scapito della complessità del tuo codice sass.

Dubito strongmente che un approccio possa influire sul rendimento della pagina per renderlo un problema e, in caso affermativo, puoi risolvere il problema quando diventa uno. Non è necessario preoccuparsi delle prestazioni finché non si inizia a vederle degradare.