Dovrebbe essere aggiunta una classe CSS genitore al markup o @extended?

Naviga le tue risposte
2

Leggendo le funzionalità di base SASS sul loro sito web, mi sono imbattuto nella funzione @extend .

L'esempio che danno è il seguente: 

.message {
    border: 1px solid #ccc;
    padding: 10px;
    color: #333;
}

.success {
    @extend .message;
    border-color: green;
}

.error {
    @extend .message;
    border-color: red;
}

.warning {
    @extend .message;
    border-color: yellow;
}

Che compila in 

.message, .success, .error, .warning {
    border: 1px solid #cccccc;
    padding: 10px;
    color: #333;
}

.success {
    border-color: green;
}

.error {
    border-color: red;
}

.warning {
    border-color: yellow;
}

Quindi con questo frammento di codice HTML 

<div class="success">hello world</div>

stili il tuo elemento con le proprietà di .message e .success . Tuttavia ritengo che questo modo di scrivere HTML (e CSS) sia molto scarso, in termini di semantica (non si vede esplicitamente dal markup sopra che l'elemento ha anche lo stile di .message ).

Non dovrebbe lo snippet sopra essere 

<div class="message success">hello world</div>

Ritengo che sia più descrittivo e più facilmente riusabile. Ad esempio, potrei assegnare la classe .success (come scritto nel CSS precedente ma senza @extend ) ad altri elementi che non sono messaggi, e quindi usare la classe come modificatore, in modo BEM.

Quindi la mia domanda è: l'approccio di esempio SASS è più desiderabile del mio?

    
posta mattecapu 03.08.2014 - 14:09
fonte

2 risposte

4

Entrambi gli approcci sono preziosi e semanticamente, non sono molto diversi. Ricorda che puoi usare entrambi in Sass.

Credo che ciò che ti fa pensare che il tuo sia più descrittivo è la loro scelta dei nomi di classe: success class non è abbastanza descrittivo: come qualcuno dovrebbe intuire che success si riferisce a un messaggio, e non, per esempio, un piccola icona di controllo verde sul lato di un oggetto che mostra se è passato un test unitario? Se scegliamo un esempio (senza significato) con nomi migliori, le cose diventano più chiare: 

.animal { ... }
.cat { @extend .animal; ... }
.dog { @extend .animal; ... }

Preferiresti scrivere: 

<div class="animal cat">...</div>

o 

<div class="cat">...</div>

Probabilmente la seconda variante, poiché evita la ridondanza e rende il tuo HTML più leggibile.

Se conosci la programmazione orientata agli oggetti, pensa a:

  • Il loro approccio come ereditarietà: Cat class eredita Animal , e può avere solo zero o una classe base.

  • Il tuo approccio come interfacce: l'interfaccia ISuccessful può essere implementata sia da Message class che TestResult ; allo stesso tempo, Message può implementare allo stesso tempo ISuccessful , IImportant e IMandatory .

risposta data 03.08.2014 - 15:01
fonte
-1

Tornando indietro di un anno, ora sostengo la visione esattamente opposta: @extend è di solito migliore del riempimento del tuo markup con le classi.

Prendiamo ad esempio questo codice 

.component1 {
   font-family: 'custom font', sans-serif;
   text-transform: capitalize;
   border: 2px dashed red;
}
.component2 {
   font-family: 'custom font', sans-serif;
   text-transform: capitalize;
   text-align: center;
   padding: 10px;
}

<div class="component1"></div>
<div class="component2"></div>

Ho notato che component1 e component2 condividono uno stile comune, che potrebbe essere potenzialmente utilizzato anche in altri componenti: è un buon candidato per una classe separata (secondo il principio DRY), 

.utility1 {
   font-family: 'custom font', sans-serif;
   text-transform: capitalize;
}
.component1 {
   border: 2px dashed red;
}
.component2 {
   padding: 10px;
}


<div class="component1 utility1"></div>
<div class="component2 utility1"></div>

Ma questo codice porta almeno 2 nuovi problemi in città:

  1. Se sto codificando sensibilmente, gli stili component1 e component2 vivranno in fogli di stile diversi. Ciò significa che guardando a component1.css , posso vedere tutti gli stili che verranno applicati al componente, tranne che non è più il caso: utility1 , che probabilmente risiederà è un foglio di stile separato, cambia gli stili del componente senza alcun riferimento esplicito ad esso nel proprio foglio di stile del componente .
    Un altro modo per vedere questo è che non stai legando gli stili utility1 a component1 , ma li lasci come entità separate che potrebbero anche vivere separatamente, ma questo è un falso assunto perché component1 ha bisogno di sempre quegli stili, e non può vivere senza (non è uno stato come una classe modificatore, fa parte della sua propria natura ).

  2. Ancora peggio, questo riferimento viene spostato nel markup .
    Nella domanda, parlo di semantica, ma mentre nel caso di una classe modificatore (cioè --active , --hidden , --warning/--error/--success ), una classe extra nel markup sarà in realtà fornirà ulteriori informazioni semantiche sul componente, non è il caso qui. utility1 è un hook puramente stilizzato e lo styling non ha spazio nel markup della pagina ad eccezione delle dichiarazioni dei fogli di stile nella sezione <head> . Inserire utility1 nel markup del componente non è diverso da cose di stile dall'attributo style . Stai facendo affidamento sul codice di markup per modificare gli stili visivi dei tuoi componenti, e non va bene .

Comprendo che questi punti di vista non sono assolutamente condivisi o giusti (non esiste una verità assoluta nella codifica, ma possiamo essere d'accordo su alcuni principi generali), perché ci sono scuole di pensiero che vedono styling dal markup come completamente legittimo .

    
risposta data 10.11.2015 - 22:53
fonte

Leggi altre domande sui tag

Diverse classi di enumerazione che dichiarano costanti con lo stesso nome Organizzazione della soluzione / struttura del progetto e classi per l'applicazione Line of Business (LOB)