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.

Nie rzadko trzeba było [...]

"Nierzadko".

najpierw wyszukujemy obiektu

Najpierw wyszukujemy temu misiu.

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ę.

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

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

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.

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...

@ 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.

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.

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.

@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.

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.

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

less.watch();

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

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.

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/

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.

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.

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 :)

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.

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ą.

@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.