Nie pisz nagłówków w CSS
Po prostu podziel sekcje na pliki. Wszelkie komentarze CSS powinny być tylko komentarzami.
reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css
Użyj skryptu, aby połączyć je w jeden; Jeśli to konieczne. Możesz nawet mieć ładną strukturę katalogów i po prostu skanować rekursywnie skrypt w poszukiwaniu .css
plików.
Jeśli musisz pisać nagłówki, na początku pliku przygotuj spis treści
Nagłówki w spisie treści powinny być idealnie równe nagłówkom, które napiszesz później. Szukanie nagłówków jest uciążliwe. Aby dodać do problemu, jak dokładnie ktoś powinien wiedzieć, że masz inny nagłówek po pierwszym nagłówku? ps. nie dodawaj podobnej do doc * * (gwiazdki) na początku każdego wiersza podczas pisania spisu treści, po prostu bardziej denerwuje go wybór tekstu.
/* Table of Contents
- - - - - - - - -
Header stuff
Body Stuff
Some other junk
- - - - - - - - -
*/
...
/* Header Stuff
*/
...
/* Body Stuff
*/
Pisz komentarze zgodnie z regułami lub wewnątrz nich, nie poza blokiem
Po pierwsze, kiedy edytujesz skrypt, istnieje szansa 50/50, że zwrócisz uwagę na to, co znajduje się poza blokiem reguł (szczególnie jeśli jest to duży glob tekstu;)). Po drugie (prawie) nie ma przypadku, w którym potrzebowałbyś „komentarza” na zewnątrz. Jeśli jest na zewnątrz, jest to 99% czasu tytuł, więc zachowaj go w ten sposób.
Podziel stronę na komponenty
Komponenty powinny mieć position:relative
, nie padding
i nie margin
, przez większość czasu. Upraszcza% rządzi los, jak również pozwala na znacznie prostsze absolute:position
„ing elementów, ponieważ jeśli istnieje absolutna pozycjonowane pojemnik absolutny elementu pozycjonowanego użyje pojemnik przy obliczaniu top
, right
, bottom
, left
właściwości.
Większość DIV w dokumencie HTML5 jest zwykle składnikiem.
Składnik jest również czymś, co można uznać za niezależną jednostkę na stronie. W kategoriach laików traktuj coś jak komponent, jeśli ma sens traktowanie czegoś jak blackbox .
Powtarzając przykład strony QA:
#navigation
#question
#answers
#answers .answer
etc.
Dzieląc stronę na komponenty, dzielisz swoją pracę na łatwe do zarządzania jednostki.
Umieść reguły z łącznym efektem na tej samej linii.
Na przykład border
, margin
i padding
(nie outline
) wszystko dodać do wymiarów i wielkości elementu jesteś stylizacji.
position: absolute; top: 10px; right: 10px;
Jeśli nie są one tak czytelne w jednym wierszu, przynajmniej umieść je w pobliżu:
padding: 10px; margin: 20px;
border: 1px solid black;
Jeśli to możliwe, używaj stenografii:
/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;
Nigdy nie powtarzaj selektora
Jeśli masz więcej instancji tego samego selektora, istnieje duża szansa, że nieuchronnie skończysz z wieloma instancjami tych samych reguł. Na przykład:
#some .selector {
margin: 0;
font-size: 11px;
}
...
#some .selector {
border: 1px solid #000;
margin: 0;
}
Unikaj używania TAG jako selektorów, kiedy możesz użyć id / klas
Po pierwsze tagi DIV i SPAN są wyjątkiem: nigdy nie powinieneś ich używać, nigdy! ;) Używaj ich tylko do dołączania klasy / identyfikatora.
To...
div#answers div.answer table.statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
outline: 3px solid #000;
}
Powinny być napisane w ten sposób:
#answers .answer .statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}
Ponieważ dodatkowe zwisające DIV nie dodają nic do selektora. Wymuszają także niepotrzebną regułę tagów. Jeśli było zmieniać, na przykład, .answer
od A div
do article
swojego stylu pęknie.
Lub jeśli wolisz większą przejrzystość:
#answers .answer .statistics {
color: pink;
border: 1px solid #000;
}
#answers .answer table.statistics {
border-collapse: collapsed;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}
Powodem tego border-collapse
jest własność specjalna, która ma sens tylko w przypadku zastosowania do table
. Jeśli .statistics
nie jest, nie table
powinno mieć zastosowania.
Ogólne zasady są złe!
- jeśli możesz, unikaj pisania ogólnych / magicznych zasad
- chyba że dotyczy to resetu / resetu CSS, cała twoja ogólna magia powinna dotyczyć co najmniej jednego głównego komponentu
Nie oszczędzają czasu, powodują wybuch głowy; a także uczynić utrzymanie koszmarem. Pisząc regułę, możesz wiedzieć, gdzie mają one zastosowanie, jednak nie ma gwarancji, że reguła nie zadziała z tobą później.
Dodanie do tego ogólnych zasad jest mylące i trudne do odczytania, nawet jeśli masz pojęcie o dokumencie, który projektujesz. Nie oznacza to, że nie powinieneś pisać ogólnych reguł, po prostu ich nie używaj, chyba że naprawdę zamierzasz, aby były ogólne, a nawet dodają tyle informacji o zakresie do selektora, ile możesz.
Takie rzeczy ...
.badges {
width: 100%;
white-space: nowrap;
}
address {
padding: 5px 10px;
border: 1px solid #ccc;
}
... ma ten sam problem, co używanie zmiennych globalnych w języku programowania. Musisz dać im zakres!
#question .userinfo .badges {
width: 100%;
white-space: nowrap;
}
#answers .answer .userinfo address {
padding: 5px 10px;
border: 1px solid #ccc;
}
Zasadniczo brzmi to:
components target
---------------------------- --------
#answers .answer .userinfo address
-------- --------- --------- --------
domain component component selector
Lubię używać identyfikatorów za każdym razem, gdy znany mi element jest singletonem na stronie; twoje potrzeby mogą być inne.
Uwaga: Najlepiej byłoby napisać tylko tyle. Wymienienie większej liczby komponentów w selektorze jest jednak bardziej wybaczającym błędem w porównaniu z wymienianiem mniejszej liczby komponentów.
Załóżmy, że masz pagination
komponent. Używasz go w wielu miejscach w swojej witrynie. Byłby to dobry przykład, kiedy piszesz ogólną regułę. Powiedzmy, że display:block
poszczególne linki do numerów stron nadają im ciemnoszare tło. Aby były widoczne, musisz mieć takie zasady:
.pagination .pagelist a {
color: #fff;
}
Załóżmy teraz, że używasz paginacji do listy odpowiedzi, możesz napotkać coś takiego
#answers .header a {
color: #000;
}
...
.pagination .pagelist a {
color: #fff;
}
To sprawi, że twoje białe linki będą czarne, czego nie chcesz.
Niepoprawny sposób to naprawić:
.pagination .pagelist a {
color: #fff !important;
}
Prawidłowy sposób to naprawić:
#answers .header .pagination .pagelist a {
color: #fff;
}
Złożone komentarze „logiczne” nie działają :)
Jeśli napiszesz coś w stylu: „ta wartość zależy od bla-bla w połączeniu z wysokością bla-bla”, to jest nieuniknione, że popełnisz błąd i wszystko spadnie jak domek z kart.
Uprość swoje komentarze; jeśli potrzebujesz „operacji logicznych”, rozważ jeden z tych języków szablonów CSS, takich jak SASS lub LESS .
Jak mam napisać paletę kolorów?
Zostaw to na koniec. Przygotuj plik dla całej palety kolorów. Bez tego pliku Twój styl powinien nadal zawierać użyteczną paletę kolorów w regułach. Twoja paleta kolorów powinna nadpisać. Łączymy selektory za pomocą komponentu nadrzędnego bardzo wysokiego poziomu (np. #page
), A następnie piszemy swój styl jako samowystarczalny blok reguł. Może to być tylko kolor lub coś więcej.
na przykład.
#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
color: #222; background: #fff;
border-radius: 10px;
padding: 1em;
}
Pomysł jest prosty, paleta kolorów jest arkuszem stylów niezależnym od stylu podstawowego, do którego kaskadujesz .
Mniej nazw, wymaga mniej pamięci, dzięki czemu kod jest łatwiejszy do odczytania
Używanie mniejszej liczby nazw jest lepsze. Najlepiej użyj bardzo prostych (i krótkich!) Słów: tekst, treść, nagłówek.
Uważam również, że kombinacja prostych słów jest łatwiejsza do zrozumienia niż zupa z długimi „odpowiednimi” słowami: postbody, posthead, userinfo itp.
Utrzymuj słownictwo w ten sposób, nawet jeśli jakiś nieznajomy przychodzi, aby przeczytać twoją zupę (jak ty po kilku tygodniach;)) musi tylko zrozumieć, gdzie używane są słowa, a gdzie każdy selektor. Na przykład używam.this
gdy element jest rzekomo „wybranym elementem” lub „bieżącym przedmiotem” itp.
Posprzątaj po sobie
Pisanie CSS jest jak jedzenie, czasem zostawiasz za sobą bałagan. Upewnij się, że posprzątasz ten bałagan, inaczej kod śmieci po prostu się zbierze. Usuń klasy / identyfikatory, których nie używasz. Usuń reguły CSS, których nie używasz. Upewnij się, że wszystko jest w porządku, a nie masz sprzecznych lub zduplikowanych reguł.
Jeśli, tak jak zasugerowałem, traktowałeś niektóre kontenery jako czarne skrzynki (komponenty) w swoim stylu, używałeś tych komponentów w swoich selektorach i trzymałeś wszystko w jednym dedykowanym pliku (lub właściwie podzieliłeś plik z TOC i nagłówkami), wtedy twój praca jest znacznie łatwiejsza ...
Możesz użyć narzędzia, takiego jak rozszerzenie firefox Dust-Me Selectors (wskazówka: skieruj go na swoją stronę sitemap.xml), aby pomóc Ci znaleźć część śmieci ukrytych w twoich css nuklearnych i carnies.
Zachowaj unsorted.css
plik
Załóżmy, że projektujesz witrynę kontroli jakości i masz już arkusz stylów dla „strony odpowiedzi”, którą nazwiemy answers.css
. Jeśli musisz teraz dodać dużo nowego css, dodaj go do unsorted.css
arkusza stylów, a następnie ponownie prześlij do swojegoanswers.css
arkusza stylów.
Kilka powodów:
- szybciej jest refaktoryzować po zakończeniu, a następnie szukać reguł (które prawdopodobnie nie istnieją) i wstrzykiwać kod
- będziesz pisać rzeczy, które usuniesz, wstrzykiwanie kodu utrudnia jego usunięcie
- dołączanie do oryginalnego pliku z łatwością prowadzi do powielania reguły / selektora
simplicity
,complexity
,maintenance
,structure
irefactoring
.