Mniej: lepiej używać dziedziczenia lub wielu klas

Mam plik LESS Z klasą inputbase(){}. Używam go na wiele, ale nie każdy typ wejścia. Podczas kompilacji mam wiele powtarzających się stylów w wyjściowym pliku CSS.

Przyjrzałem się, jak bootstrap używa mniej dla swojej siatki i używają tego samego podejścia; gdzie column 1 etc dziedziczy z column klasy bazowej. Znowu wydaje się to generować dużo CSS.

Czy powinienem używać .inputbase .specificClass w każdym <input /> zamiast używać mniej dziedziczenia?

 30
Author: WoJ, 2013-11-14

2 answers

Różne Opcje, Brak Odpowiedzi Zestawu

To będzie zależeć w dużej mierze od Twojego kodu, Twoich celów itp., jak dostać style do różnych elementów. Oto kilka możliwości, każda z mocnymi i słabymi stronami.

1. Mixin (what you currently do)

mniej

.inputbase() {
  /* your base code */
}

.someInput {
  .inputbase;
  /*some input special code */
}

.someOtherInput {
  .inputbase;
  /*some other input special code */
}

.andAnotherInput {
  .inputbase;
  /*and another input special code */
}

wyjście CSS

.someInput {
  /* your base code */

  /*some input special code */  
}
.someOtherInput {
  /* your base code */

  /*some other input special code */    
}
.andAnotherInput {
  /* your base code */

  /*and another input special code */    
}

Jeśli w .inputbase() jest więcej niż jedna lub dwie linijki kodu, a jeśli jest ona mieszana w więcej niż kilka instancji, spowoduje to generuje dużo dodatkowego kodu. To jest problem, z którym się borykasz.

2. Extend A Class

Wygląda na to, że LESS jest już prawie gotowy, aby pozwolić na rozszerzenie mixinów , ale obecnie (mniej 1.5) wymaga to tylko definicji klasy, więc to:

mniej

.inputbase {
  /* your base code */
}

.someInput {
  &:extend(.inputbase);
  /*some input special code */
}

.someOtherInput {
  &:extend(.inputbase);
  /*some other input special code */
}

.andAnotherInput {
  &:extend(.inputbase);
  /*and another input special code */
}

wyjście CSS

.inputbase, /* this is gone once mixin extending allows .inputbase() extension */
.someInput,
.someOtherInput,
.andAnotherInput {
  /* your base code */   
}
.someInput {
  /*some input special code */    
}
.someOtherInput {
  /*some other input special code */   
}
.andAnotherInput {
  /*and another input special code */   
}

Zaletą jest to, że cały kod podstawowy nie jest powtarzany, ale to, co się powtarza, to selektory, ponieważ są najpierw pogrupowane wraz z kodem bazowym, a następnie ponownie są wyprowadzane dla pojedynczego kodu. Jeśli ktoś lubi trzymać swój kod pogrupowany w jednej definicji selektora, to nie jest to droga do zrobienia. W przeciwnym razie oferuje to dobry sposób na zmniejszenie wyjścia CSS.

3. Dwie klasy (dodatkowe znaczniki html, które proponujesz)

To jedno rozwiązanie, które zaproponowałeś, mając dwie klasy (to dlatego, że stwierdziłeś, że nie zawsze chcesz .inputbase zastosować do elementu wejściowego).

LESS i CSS Wyjście *

.inputbase {
  /* your base code */
}

.someInput {
  /*some input special code */
}

.someOtherInput {
  /*some other input special code */
}

.andAnotherInput {
  /*and another input special code */
}

To ma najmniejszą ilość CSS, ale ma tę wadę, że wymaga również dodatkowych znaczników HTML dwóch klas, <input class="inputbase someInput" /> itd.

4. Jedna klasa z nadpisaniem bazy

To może być lepsze niż powyżej.

LESS I Wyjście CSS

input {
  /* your base code */
}

.someInput {
  /*some input special code */
  /*override input base code if needed */
}

.someOtherInput {
  /*some other input special code */
  /*no override if not needed */
}

.andAnotherInput {
  /*and another input special code */
  /*no override if not needed */
}

Jeśli większość wejść będzie miała kod baseinput, możesz po prostu zdefiniować swój podstawowy kod wejściowy w definicji elementu input, a następnie nadpisać właściwości, których nie chcesz mieć w swoim specjalnym kodzie css. Pozwala to na mniej html tylko z jedną klasą <input class="someInput" />. Spowoduje to, że zarówno CSS, jak i HTML będą mniej zaśmiecone, ale ma tę wadę: zapamiętywanie kodu podstawowego i możliwość nadpisania go w razie potrzeby.

Podsumowanie

Co będzie Najlepsze zbyt wiele zależy od konkretnych okoliczności, z którymi się spotykasz. Ale być może dwie dodatkowe opcje pomogą Ci przemyśleć sprawę. I osobiście w większości przypadków wybrałbym #2 lub #4, ale znowu są aplikacje na #1 i #3, jak również.

 72
Author: ScottS,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-14 15:01:35

W pierwszej kolejności wydaje się zależeć od wersji Less używasz. Spójrz na https://github.com/twbs/bootstrap/issues/8947. najpierw został zidentyfikowany jako błąd. W takim przypadku możesz wybrać poczekaj na poprawkę błędu lub zmień kod.

Później omówi, czy jest to błąd, czy nie. Różne użycie nawiasu da różne wyniki. Również ich będzie problem z mixinami o tej samej nazwie co klasy, Zobacz też: https://github.com/less/less.js/issues/1437

 0
Author: Bass Jobsen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-14 13:19:34