Temat: Dobre zwyczaje w dokumentowaniu pliku css

Macie swoje dobre zwyczaje w dokumentowaniu css-a? Właśnie pracuję nad cudzym kodem i przeklinam każdą z tysiąca nieudokumentowanych linijek kodu, w których jedyne komentarze są typu /*dalej wywalić*/

Sama przywykłam do dokumentowania pliku css, bo z racji tego, że dla przeglądarki kolejność deklaracji jest praktycznie nieistotna, w css-ie łatwo zrobić skrajny bajzel. Dlatego staram się trzymać kolejności:
- reset przeglądarek,
- definicje podstawowych elementów pływających (basic layout),
- definicje wspólne dla wszystkich elementów strony (klasy hidden, left, right, elementy a, h1-6, ul, ol, embed etc.),
- a potem po kolei klasy właściwe poszczególnym elementom strony, w miarę w tej samej kolejności, co w html-u.

Chętnie poznam Wasze zwyczaje w czynieniu css-a bardziej przejrzystym dla innych osób z nim pracujących.Julia Krysztofiak-Szopa edytował(a) ten post dnia 28.01.09 o godzinie 02:53

Temat: Dobre zwyczaje w dokumentowaniu pliku css

Najpierw reset predefiniowanych ustawień, później lecę ze stylami selektorów, następnie style dla #id, a na samym końcu klasy.

Dodatkowo stosuję wcięcia np.

ul { regułka }
ul li { regułka }

Czyli prawie jak Julia :)

Temat: Dobre zwyczaje w dokumentowaniu pliku css

Ja wolę nie dokumentować CSSa - sam w sobie ma być czytelny. Nie uznaję żadnych komentarzy poza oznaczeniem grupy stylów dla jednego elementu - np.:

/* ============== menu ============= */

#menu {}

#menu li {}

#menu a {}

Kolejność:
- przypisanie domyślnych stylów dla elementów HTML
- struktura strony (layout)
- poszczególne elementyDawid L. edytował(a) ten post dnia 28.01.09 o godzinie 12:06

Temat: Dobre zwyczaje w dokumentowaniu pliku css

popieram Dawida, tez lubie krotki nagłowek nad grupa ktora formatuje mi dana czesc strony :)

Temat: Dobre zwyczaje w dokumentowaniu pliku css

1. Totalny reset ustawień domyślnych

2. ustawienie wszystkiego co się da ustawić dla body

3. Dbanie o to aby elementy w html były tak jak są na stronie od góry do dołu od lewej do prawej (wiem nie trzeba ale można...)

4. każdy element html ma ID (jak później go potrzebujesz to wymyśla się dziwne nazwy). ID i class są sugestywne

5. Definicja wszystkiego zgodnie z kolejnością w html (na tyle na ile się da)

6. Jak najmniej kopiuj wklej w css: jak np dwa obiekty różnią się tylko jednym elementem a mają 20 tych samych to pakujesz je w jedną klasę, a różnicę pakujesz w ID

7. Nie zostawiam kodu w /* */ po zakończonej pracy

8. Na koniec sprawdzam, czy nie ma nadmiarowych selektorów: np

 div {padding: 0;}

/* ten selektor poniżej jest niepotrzebny bo all to div*/

#all {padding: 0;}

9. Elementy z którymi pracuje JS oznaczam sugestywnie /* JS do IDobiektu */

10. Za 2 dni sprawdzam jeszcze raz poprawność kodu i dopiero kończę pracę

11. Plik ma strukturę:

selektor {

      reguła1: wartość;

}

nie w jednej linii bo wtedy nie wiadomo jak to czytać

12. Maksymalna ilość łączenia reguł, a więc nie oddzielnie padding-left, padding-right jak te wartości są identyczne.

13. Jak są duże strony i jest dużo selektorów to rozbijam czasem css na kilka plików, np: body.css, menu.css, tresc.css itd...

14. Unikam tworzenia dodatkowego css dla IE, no chyba że już się nie da. Jak masz dodatkowego css dla IE to jest duża pokusa dziwne zabiegi, które utrudniają życie.Marcin Gronowski edytował(a) ten post dnia 28.01.09 o godzinie 17:12

Temat: Dobre zwyczaje w dokumentowaniu pliku css

Marcin Gronowski:
1. Totalny reset ustawień domyślnych

A co kiedy klient wstawi sobie listę <ul> np przez FCKeditor, a zobaczy tylko kilka zwykłych umieszczonych linijek pod sobą?

4. każdy element html ma ID (jak później go potrzebujesz to wymyśla się dziwne nazwy). ID i class są sugestywne

Czy to aby nie przesada? Sporo nadmiernego kodu, który staje się ciężki i nieczytelny?

7. Nie zostawiam kodu w /* */ po zakończonej pracy

Dlaczego? Komentarze są dla ludzi - czasami przyjdzie coś później edytować.

11. Plik ma strukturę:

selektor {

      reguła1: wartość;

}

nie w jednej linii bo wtedy nie wiadomo jak to czytać

Mi osobiście lepiej wzrokowo wyłapać blok linijek zaczynających się od np. #selektor niż znaleźć coś w rozstrzelonym kodzie.

13. Jak są duże strony i jest dużo selektorów to rozbijam czasem css na kilka plików, np: body.css, menu.css, tresc.css

IMHO nie ma potrzeby. Rozumiem, jeśli byłby to osobny moduł, który nie występuje na wszystkich stronach, a jest dosyć obszerny - np. calendar.css
W podanym przez Ciebie przypadku przeglądarka wysyła więcej żądań, a co za tym idzie strona wolniej się wczytuje.

14. Unikam tworzenia dodatkowego css dla IE, no chyba że już się nie da. Jak masz dodatkowego css dla IE to jest duża pokusa dziwne zabiegi, które utrudniają życie.

Ja nie widzę w tym nic złego. Plik dla IE to o wiele lepsza sprawa niż zaśmiecanie poprawnego kodu hackami - wtedy dopiero nie wiadomo po co wstawiony jest np position:relative, height:1%, czy inne takie rzeczy.Dawid L. edytował(a) ten post dnia 28.01.09 o godzinie 19:35

Temat: Dobre zwyczaje w dokumentowaniu pliku css

1. Totalny reset ustawień domyślnych

A co kiedy klient wstawi sobie listę <ul> np przez FCKeditor, a zobaczy tylko kilka zwykłych umieszczonych linijek pod sobą?

1. Uzytkownik który bierze się za edycje strony powinien wiedzieć co robi
2. Nie powiedziałem, że nie ustawiam parametrów takiej listy później. Jak coś robimy to rozsądnie, a nie na siłę.

4. każdy element html ma ID (jak później go potrzebujesz to wymyśla się dziwne nazwy). ID i class są sugestywne

Czy to aby nie przesada? Sporo nadmiernego kodu, który staje się ciężki i nieczytelny?

Nie. Tych elementów nie jest aż tak dużo (ok nie dodaje ID do każdego a,h1,h2,h3... ale do wiekszych ementów głownie do div i img, a te raczej nie wstawiasz sobie dla rozrywki, jak napcha się div-ów bo nie wie jak coś porawnie ustawić to dopiero jest nadmiarowy kod.

7. Nie zostawiam kodu w /* */ po zakończonej pracy

Dlaczego? Komentarze są dla ludzi - czasami przyjdzie coś później edytować.

Ale kod w komentarzach (czyli coś takiego

/* margin: 5px */

)niczego nie dodaje, to jest zbędny kod

11. Plik ma strukturę:

selektor {

      reguła1: wartość;

}

nie w jednej linii bo wtedy nie wiadomo jak to czytać

Mi osobiście lepiej wzrokowo wyłapać blok linijek zaczynających się od np. #selektor niż znaleźć coś w rozstrzelonym kodzie.

Kwestia subiektywna, jak kto lubi, ja wolę tak, Ty tak, nic dziwnego. Swoja drogą jak Ci się czyta kod zajmujący 3 linijki

body{background-image: url( 'tlo1.jpg' ); background-position: center; font-family: Georgia; font-size: 13px; font-weight: normal; font-style: normal; font-variant: normal; color: #400040; background-color: #999999; background-repeat: repeat-y; width: 1010px;}

13. Jak są duże strony i jest dużo selektorów to rozbijam czasem css na kilka plików, np: body.css, menu.css, tresc.css

IMHO nie ma potrzeby. Rozumiem, jeśli byłby to osobny moduł, który nie występuje na wszystkich stronach, a jest dosyć obszerny - np. calendar.css
W podanym przez Ciebie przypadku przeglądarka wysyła więcej żądań, a co za tym idzie strona wolniej się wczytuje.

Może i prawda, ale nikt nie powiedział, że menu, body musi być identycznie formatowane na wszystkich stronach i wtedy z serwera nie potrzebnie są pobierane nadmiarowe ilości danych, każdy kij ma dwa końce :D. Rozdzielenie na kilka css ma sens jak podstron jest dużo i mogą być niektóre inaczej formatowane (o takiej sytuacji była mowa)

14. Unikam tworzenia dodatkowego css dla IE, no chyba że już się nie da. Jak masz dodatkowego css dla IE to jest duża pokusa dziwne zabiegi, które utrudniają życie.

Ja nie widzę w tym nic złego. Plik dla IE to o wiele lepsza sprawa niż zaśmiecanie poprawnego kodu hackami - wtedy dopiero nie wiadomo po co wstawiony jest np position:relative, height:1%, czy inne takie rzeczy.

Z IE trzeba umieć walczyć, a każdy ma na to swoją technikę, absolutnie subiektywnie (btw z height nigdy nie miałem problemów z IE6 i IE7 poza min-height i max-height)

Temat: Dobre zwyczaje w dokumentowaniu pliku css

No to trochę się wyjaśniło.

Marcin Gronowski:
Kwestia subiektywna, jak kto lubi, ja wolę tak, Ty tak, nic dziwnego. Swoja drogą jak Ci się czyta kod zajmujący 3 linijki

Tak nie:

body{background-image: url( 'tlo1.jpg' ); background-position: center; font-family: Georgia; font-size: 13px; font-weight: normal; font-style: normal; font-variant: normal; color: #400040; background-color: #999999; background-repeat: repeat-y; width: 1010px;}

Ale tak o wiele lepiej:

body {width:1010px; font:normal 13px Georgia; color:#400040; background:url(tlo1.jpg) center repeat-y #999;}

Poza tym mam takie swoje pedantyczne zasady przy ustalaniu kolejności w pisaniu stylu:
selektor {wymiary(width, height, margin, padding); fonty i inne pierdoły; background; zachowanie:(float, display, position);}

To tak najogólniej. Jak ktoś w miarę inteligentny, przejrzy kilka linijek, to od razu zauważy jakąś zależność i łatwiej będzie się poruszać po takim CSSie.

Z IE trzeba umieć walczyć, a każdy ma na to swoją technikę, absolutnie subiektywnie (btw z height nigdy nie miałem problemów z IE6 i IE7 poza min-height i max-height)

height:1% to jedna z metod na wymuszenie ustawienia hasLayout dla elementuDawid L. edytował(a) ten post dnia 28.01.09 o godzinie 20:56

Temat: Dobre zwyczaje w dokumentowaniu pliku css

Nie komentuję kodu, zazwyczaj wszystko wrzucam do jednego pliku poza sytuacjami, w których np. trzeba ostylować ten jeden konkretny formularz na tej jednej podstronie.

Wychodzę z założenia, że jak ktoś będzie chciał zmieniać, to i tak wejdzie najpierw w źródło, gdzie sobie zobaczy, co ma jakie id, czy klasę, a później użyje magicznego ctrl+f, żeby w edytowanym pliku .css znaleźć, co chce.

Jeśli chodzi o konwencje to tylko i wyłącznie jedna właściwość - jedna linia kodu, czasem z dodatkowymi wcięciami, gdy dziedziczenie i ilość elementów potomnych robią się pokaźne.

Jeśli chodzi o cross-browser, to oddzielne pliki ssą, hacki na IE w zasadzie też, przynajmniej odkąd trzeba oddzielnych na 6 i 7... Osobiście używam CSS Browser Selectora, który odkryłem przy okazji szukania hacków na tylko i wyłącznie Firefoxa, który czasem też wyświetla inaczej, niż reszta.

Temat: Dobre zwyczaje w dokumentowaniu pliku css

Ja daję komentarz przed każdą sekcją, np.

/* naglowek */

...

/* wyszukiwarka */

A poza tym to jedna reguła - jedna linijkia. I najważniejsze: wcięcia, szalenie ułatwiają późniejsze skanowanie CSS-a:

#menu {

	cośtam:cośtam;

}



	#menu li {

		cośtam:cośtam;

	}



		menu li a {

			cośtam:cośtam;

		}

Przy dużym monitorze takie wcięcia się spokojnie mieszczą, nawet jak mam gVima podzielonego w pionie na dwie części. Oczywiście z każdą sekcją wcięcia idą od zera.

Pliki może i więcej ważą, ale i tak je gzipuję dla przeglądarek, więc po spakowaniu różnicy praktycznie nie ma.

Jeżeli plik niespakowany dochodzi do 30kB, zastanawiam się czy nie dałoby się go podzielić. Wówczas jeden plik common.css z resetem i stylami wspólnymi (layout, nagłówek, stopka, stronnicowanie itp.), a w osobnych plikach style dla działów strony.