TechLife devBlog

[CSS] Pionowo czy poziomo?

Internet, Kodowanie, Techblog 25 listopada 2011 23:51

Nie będzie to flame, chciałem przedstawić Wam tylko mój punk widzenia. Do chwili zatrudnienia się w Firmie byłem święcie przekonany, że jedynym słusznym formatowaniem jest formatowanie pionowe, gdzie elegancko mamy podane jak na tacy wszystkie atrybuty.

poziomo

W Firmie przyszedł czas bardzo intensywnego kodowania. Często pracowałem z dużymi arkuszami stylów, których ciągłe przewijanie stawało się bardzo niewygodne. Nierzadko trzeba było też wrócić do poprzednich projektów i szybko poprawić jakieś drobne niedociągnięcia. Dopiero wtedy uświadomiłem sobie, że w CSS-ie jest coś ważniejszego niż atrybuty i ich wartości. Najważniejszą rzeczą są selektory! Dopiero zrozumienie tej kwestii pozwoliło mi inaczej spojrzeć na elegancję poziomego formatowania.

poziomo

Rzeczą oczywistą jest to, że najpierw wyszukujemy obiekt, który chcemy zmodyfikować a następnie dodajemy mu kolor tła czy zmieniamy margines. Priorytetem jest więc szybkie odnajdywanie selektorów a później dopisanie czy odnalezienie potrzebnego atrybutu jest już dość proste, mimo że wszystkie atrybuty są w jednej linii. IMHO o wiele więcej czasu zajmuje znalezienie odpowiedniego selektora w rozciągniętym pliku niż odpowiedniego atrybutu w liniowym zapisie.

Aby jeszcze bardziej ułatwić sobie sprawę należy trzymać się prostej zasady: najpierw definiujemy box model: display, width, height, float, margin, padding (najlepiej zachować taką kolejność) a później całą resztę (position, background, color, font-size itp). Trzymając się tej zasady od razu wiemy czy szukamy atrybutu z końca czy początku linii.

Jeszcze raz poglądowo. Formatowanie pionowe - mało widać, dużo szukania

pionowo

Formatowanie poziome - szybkie odnajdywanie selektorów i (trzymając się zasady) w miarę szybkie odnajdywanie atrybutów.

poziomo

Komentarze z jogger.pl

mt3o 26 listopada 2011 / 07:51

A jakby tak użyć LESS zamiast CSS i edytora który to obsłuży? Selektory zagnieżdżają się wtedy w sposób znany z wąsatego C albo kojarzący się z dowolnym XMLem. A łatwiej szukać odpowiednich wartości stylów niż w długiej linijce.

Dla krótkich regułek styl poziomy jest ok, ale gdy chcemy osadzić na warstwie parę łańcuchowatych styli z CSS3 to całość rozrasta się niemiłosiernie w prawo.

Stanisław 'dozzie' Klekot 26 listopada 2011 / 09:36

Nie rzadko trzeba było [...]

"Nierzadko".

najpierw wyszukujemy obiektu

Najpierw wyszukujemy temu misiu.

Radosław Mejer 26 listopada 2011 / 09:49

Dla mnie poziome formatowanie CSS jest tragiczne. Wydaje mi się, że jest więcej problemów z dopisaniem kolejnych stylów (nie mówiąc o tym jak już trzeba przewijać ekran w poziomie).

Co więcej - to jest taka "skondensowana paczka", w której brak przejrzystości (no, poza tym, że doskonale widać jakie selektory są użyte).

Jeśli mam coś szybko znaleźć to wystarczy Firebug i znalezienie za jego pomocą odpowiedniej linii CSSa.

Ostatnio korzystam z FireFile. Do prostych edycji CSS jest po protu mega przydatne. Wszelkie zmiany robi się naprawdę szybko.

Gorzej niestety z tym, że to rozszerzenie ma problemy z niektórymi elementami CSS3, oraz nie obsługuje vendor prefixes (poza -moz).

Mimo to całkiem uprzyjemnia pracę.

kjhank 26 listopada 2011 / 10:28

Pionowe, natomiast selektory mające pojedyncze atrybuty ─ poziomo. Z przewijaniem nie ma problemu, daję / w vim-ie i znajduję, co mi potrzebne.

RSWRC 26 listopada 2011 / 10:56

Wolę jednak pionowe i nie przewijam styli. W Netbeans mam Navigatora,w Eclipse Ctrl + O i szybko mam to co potrzebuję.

dotintegral 26 listopada 2011 / 11:03

Oczywiście, że CSSy powinny być pionowe.
Pisząc o szybkim wyszukiwaniu po selektorach widać, że nie masz doświadczenia z narzędziami typu firebug. A są to narzędzia podstawowe w webdeveloperce. Przeglądając samemu selektory, nie odnajdziesz konfliktów, wynikających z tego, że jeden selektor jest bardziej szczegółowy i nadpisuje inny w zupełnie innym miejscu. Nie mówiąc już o ewentualnym błędzie w selektorze i jego wyszukiwaniu. A firebug załatwia te problemy z marszu, wskazując dokładnie gdzie jaka klasa się znajduje i które z jej atrybutów są wykorzystywane.

Nierzadko też się zdarza, że definicje styli są długie, a będą jeszcze dłuższe, gdy zastosujesz CSS3 (gradienty, zaokrąglenia i cienie). W jednej linii stworzysz wtedy niesamowity spagetti-code. A systemy kontroli wersji? Widać, że nie wykorzystujesz nic takiego w projekcie, bo inaczej szybko zauważyłbyś, że porównywanie zmian w dłuuugich liniach to istne piekło.

SebaS86 26 listopada 2011 / 11:19

Gdyby każdy programista tak podchodził do problemu, większości kodu nie dałoby się czytać. Na szczęście mamy do tego odpowiednie narzędzia (zgadzam się tutaj w 100% z przedmówcami). No i słuszna uwaga z VCS, nawet bardzo słuszna...

trójkąt 26 listopada 2011 / 12:23

@ mt3o: z LESS-a chętnie bym korzystał, gdyby tylko dało się stosować jego składnię edytując arkusz stylów na żywo w przeglądarce, co jest obecnie moim podstawowym i najwygodniejszym trybem pracy. Gdyby jednak przeglądarki zaimplementowały LESS wtedy byłoby ciekawie...

@dotintegral: źle mnie oceniasz, z Firebuga korzystam niemal od początku jego istnienia (obecnie z wbudowanych narzędzi Chome'a). Kiedy mam dokonać kilku korekt wtedy badam dany element i modyfikuje jego atrybuty a następnie powtarzam operacje w arkuszu styli. Najczęściej jednak, kiedy projektuję coś od zera używam edycji akrusza na żywo. O wiele szybciej jest mi się poruszać po pliku znając jego strukturą i wykonując szybki scroll w górę czy w dół, niż za każdym razem wyszukiwać selektora przez wyszukiwarkę.

Z narzędzi kontroli wersji korzystamy w firmie od początku a sam korzystam z nich nawet przy własnych projektach. To prawda, diff całej linii jest minusem, ale też zupełnie niezauważalnym, bo raczej nikt nie zajmuje się śledzeniem zmian w plikach CSS (przynajmniej u nas). W kodzie strony to co innego ale styli raczej nikt nie obserwuje. Poza tym nawet jak zdarzy się od czasu do czasu wycofać jakąś zmianę patrząc na diff to i tak nie jest to wielce trudne.

- .selektor { width: 600px; height: 260px; float: left; background: #F5F5F5; }
+ .selektor { width: 600px; height: 240px; background: #F5F5F5; }

@SebaS86: a ja nadal pozostanę przy swoim zdaniu że ważniejsze są selektory niż atrybuty i tutaj czytelność kodu jest znacząco większa. Nikt nie lubi przecież bałaganu w kodzie, różnimy się tylko priorytetami.

Cichy 26 listopada 2011 / 12:45

Heh, przypomniał mi się mój wpis sprzed lat na ten temat. Też optowałem za poziomym układem (zdania do dziś nie zmieniłem) i też większość była przeciw.

damnat 26 listopada 2011 / 14:35

no akurat przy wczorajszym projekcie przerobiłem sobie css z poziomego ułożenia do pionowego, znacznie bardziej czytelne i użyteczne przy firebugu (jak już wspomniano wyżej). a przy edycji samego pliku nie scroll tylko "Idź do linii". być może to kwestia narzędzi jakich się używa, ale nie wyobrażam sobie inaczej.

trójkąt 26 listopada 2011 / 14:52

@damnat: nie rozumiem o czym mówisz, przecież przy narzędziach typu Firebug czy Chromowym inspektorze kodu i tak wyświetlane są tam numery linii selektorów a nie atrybutów. Więc dla takiego narzędzia nie ma żadnego znaczenia czy kod jest poziomy czy pionowy.

Kret 26 listopada 2011 / 17:17

Ja zagnieżdżam w taki sposób : http://mkulpa.pl/dev/iltoro/css/style.css

Pionowe style plus zagnieżdżanie całych bloków, które są dziećmi. Im bardziej specyficzny selektor tym bardziej cały blok jest zagnieżdżony.

Druga sprawa, życzę powodzenia komuś, kto pracuje z systemami kontroli wersji i wypisuje wszystkie pary właściwość-wartość w linii. Chyba każdy wie czym to się kończy.

Kret 26 listopada 2011 / 17:22

Zapomniałem jeszcze dodać, że LESS CSS posiada podgląd na żywo, auto-refresher:

less.watch();

damnat 27 listopada 2011 / 10:11

numery linii selektorów, ale teraz szukaj w prawo wybranego atrybutu. a tak wystarczy iść do danej linii i masz to bez scrollowania

d4rky 27 listopada 2011 / 20:52

Ze swojej strony polecam po prostu indentację i logiczne grupowanie styli. Ja robię to tak, że po pierwsze dzielę style na sekcje (w zależności od fragmentu strony), a oprócz tego selektory zależne od siebie dodatkowo tabuję, np tak

#top
{
    background: #c0c;
}

    #top h1
    {
        color: #0c0;
    }

Nie jest to może SCSS, ale znacznie ułatwia przeglądanie klasycznych styli CSS. Poza tym kto normalny szuka selektorów przewijając plik? Od tego jest Ctrl+F (czy odpowiednik), żeby znajdować szybko takie rzeczy. Chyba, że ma się burdel w kodzie.

A jeśli przewijanie dużych plików sprawia ci problem to polecam Subline Text 2 jako edytor. Ma taki fajny pasek z prawej strony do przewijania całości dokumentu.

eL 27 listopada 2011 / 21:23

Miszczu na przyszłość wrzucaj screeny wynikowe jak działa kod

Programowanie obiektowe w C#
http://pwsz-bp.neostrada.pl/home.html

C++, C#, Delphi, Pascal, PHP
http://kodzimy.net/

trójkąt 27 listopada 2011 / 22:53

Przez wcięcia też przechodziłem, ale ostatecznie "skończyłem poziomo". Co do szukania selektorów to z wyszukiwania wygodnie się korzysta, jak wiemy czego szukamy. Chociaż przechodzenie do każdego selektora przez wyszukiwanie jest trochę niewygodne. Dlatego ja preferuję mieć poukładany plik i robić szybki scroll w górę czy dół lub na początek czy koniec pliku. Wystarczy trzymać się kolejności deklaracji sektorów jak rozdziałów w książce.

  • reset
  • style bazowe
  • podstawowa struktura strony
  • elementy wspólne - style tekstu, formularze itp
  • style dla modułów CMS-a - każdy ma swoją sekcję
  • stopka

Często nie pamiętam dokładnie jak nazwałem grupę selektorów dla nowego modułu ale wiem doskonale w jakim miejscu w pliku jest ta sekcja więc scrollowanie jest szybsze niż wyszukiwanie.

Yano 28 listopada 2011 / 09:44

Czytelność takiego pliku CSS jest dość subiektywna. Zapewniam, że przy dużych projektach (obecnie mamy w pliku CSS po konkatenacji jakieś 6 tys. linii) ani jeden ani drugi nie będzie dostatecznie czytelny. Poza tym obawiam się, że przy pełnym wsparciu dla CSS3 (vendor prefixes included) czytelność "poziomego" pliku spada do zera.
Generalnie do szukania czegokolwiek selektorów/własności w pliku używam CTRL+F, do szukania błędów i szybkiego poprawiania - Firebuga. Poza tym po pewnym czasie wyrabiasz w sobie zdolność parsowania nawet najbardziej zagmatwanego CSS. :)

Tak, wiem - jest LESS, SASS, SCSS. Ale te techniki wymagają stosowania ich od samego początku przez wszystkich devów.

pawkow 29 listopada 2011 / 17:02

cleancss.com - polecam, świetnie formatuje, pozwala szybko zmieniać itp. ale - wrzucanie gradentów, zaokrągleń itp. do jednej linii to jakaś masakra.

Lokalnie oczywiście używam zapisu mieszanego - pionowy/poziomy, kwestia przyzwyczajenia, czym to skutkuje? A no tym:

.tabContainer > .tab {
background: red;
border: 1px solid #fff;
padding: 15px;
}
.tab-01 {width: 100px;}
.tab-02 {width: 150px; color: #fff;}
.tab-03 {width: 400px;}

A na produkcji wszystko jest skompresowane i tylko FireBug może pomóc ;)

Każdy powinien pisać tak jak mu jest wygodniej, jak komuś przeszkadza zapis w jednym wierszu, są formattery :)

css3.pl 30 listopada 2011 / 08:39

Właściwie to jest sprawa indywidualna i nie ma znaczenia kto jak pisze, najlepiej jak komu wygodniej.

Osobiście preferuje pionowe formatowanie z fragmentami formatowanymi poziomo. Poziomo kiedy mam np. kilkadziesiąt wpisów pod rząd z właściwością background-position albo początkowy reset. Większość kodu jest jednak pionowa, ponieważ jest to czytelniejsze.

Tak jak pisali przedmówcy, są elementy - głównie CSS3 - które w poziomie są bardzo niewygodne, np css3 gradienty.
Z wyszukiwaniem konkretnego fragmentu kodu nie ma problemu, ponieważ używam wyszukiwarki :) a skrolowanie no cóż, polecam zainwestowanie w myszkę której rolka ma dwa tryby, zwykły i bez oporu, czyli jak nią zakręcimy to się po prostu kręci, naprawdę świetna sprawa dla kodera, również przy przeglądaniu stron internetowych (taką rolkę ma np. myszka G9 od Microsoftu której używam).

Kiedyś jeszcze zagłębiałem kod, na zasadzie tworzenia większych wcięć elementom, które znajdują się w innych elementach, ale wadą jest to, że nie zawsze tworzy to logiczną strukturę i jest trudne w utrzymaniu.

Adriano 01 grudnia 2011 / 18:16

Właściwie to jest sprawa indywidualna
i nie ma znaczenia kto jak pisze,
najlepiej jak komu wygodniej.

To sprawdza się tylko wówczas, kiedy kodu CSS nie ruszy nikt poza nami.
Zawsze można kod sprowadzić do porządku po kimś, ale równoległa praca nad takimi tasiemcami będzie tylko udręką.

css3.pl 01 grudnia 2011 / 20:13

@Adriano - zgadzam się, jednak zamiast szukać złotego środka wystarczy użyć narzędzia do przeformatowania kodu (np. wbudowanego w edytor kodu), wtedy za każdym razem będziesz miał taki kod jaki lubisz, a inna osoba jaki ona lubi. Może nie da się przeformatować kodu do postaci z wieloma poziomami wcięć (niektórzy tak lubią pisać), ale podstawowe formatowanie takie jak pion lub poziom, umiejscowienie klamer, tabulacja, średniki, spacje i wiele innych, można spokojnie realizować.

Z kolei uważam że w pracy grupowej ważniejsze będzie komentowanie kodu, niż to jak on będzie sformatowany.



Komentarze