Blogasek by Piotrek Reinmar Koszuliński

Myślałem, że dam radę prowadzić dwa blogi, jeden bardziej techniczny, drugi luźniejszy, czyli ten. Nic jednak z tego, dlatego zamykam tego bloga. Od roku wszystkie moje artykuły (głównie JavaScript) lądują na Code42.pl.

Dziękuję Joggerku, to były wspaniałe lata z Tobą :)

Artykuł został przeniesiony na mój nowy blog – code42.pl.

Artykuł został przeniesiony na mój nowy blog – code42.pl.

Sesja się już dla mnie skończyła, można więc coś napisać. Dzisiaj będzie jednak krótko, bo i temat prosty.

Cóż to takiego framework CSS?

No właśnie. Każdy wie co to są frameworki programistyczne, ale CSSowy? Według wiki:

A CSS framework, also known as a web design framework is a pre-prepared library that is meant to allow for easier, more standards-compliant styling of a webpage using the Cascading Style Sheets language. Just like programming and scripting language libraries, CSS frameworks (usually packaged as external .css sheets inserted into the header) package a number of ready-made options for designing and outlaying a webpage.

Czyli, tak jak w językach programowania, framework jest biblioteką (w tym wypadku grupą reguł CSS) która ułatwia implementowanie jakichś standardowych, często powtarzających się funkcjonalności (w tym wypadku pewnych schematów w layoutcie).

Co, według mnie, frameworkiem CSS nie jest? Pisałem w listopadzie o parserze/kompilatorze/procesorze CSS - LESS, który rozszerza składnię CSS o kilka świetnych rzeczy. Między innymi - zmienne, zagnieżdżone reguły, obliczenia, wielokrotne wykorzystywanie reguł. Jakby nie było - nie podchodzi to pod definicję z Wikipedii, ale niestety znajduje się w linkach do przykładowych frameworków. Dla ustalenia uwagi - LESS nie jest frameworkiem.

Czemuż ssie?

Pod mą lupę wziąłem pierwsze linki zwrócone przez Google. Przyjrzałem się chwilkę frameworkom: Blueprint, Elastic CSS, YUI 2 Grids. Prawdopodobnie są lepsze rozwiązania od tych i z chęcią się im przyjrzę jeśli linki pojawią się w komciach :).

Słówko o nieudanym porodzie

Wypada jeszcze wtrącić, dla niezorientowanych, co to za poroniony pomysł ten Grid system. Otóż wpadł ktoś na pomysł, że wygodnie będzie wszystkim (grafikom, programistom) jak ustalimy sobie, że strona składa się z X kolumn po Ypx szerokości każda, między którymi są marginesy po Zpx. Przyznam, że obaj z grafikiem byliśmy zachwyceni, aż do... pierwszego projektu. Życzę np. sporo zabawy z cieniami wychodzącymi poza granice kolumn, w przypadku kiedy nie możemy użyć box-shadow. Szlag trafia wszystkie piękne, okrągłe wartości.

Koniec wtrącenia

Najpierw kawałek kodu z YUI 2 Grids:

<div id="yui-main">
   <div class="yui-b">
      <div class="yui-g">
         <div class="yui-g first">
            <div class="yui-u first"></div>
            <div class="yui-u"></div>
         </div>
         <div class="yui-g">
            <div class="yui-u first"></div>
            <div class="yui-u"></div>
         </div>
      </div>
   </div>
</div>

Tyle się kiedyś mówiło o semantyce kodu i oddzieleniu wyglądu od treści. Ponad pięć lat temu, kiedy zaczynałem naukę HTMLa i CSSa, trwała walka o to aby programiści zaczęli pisać porządny kod. Wydawało mi się, że teraz już nie powinno być z tym problemów, a tu zonk. Patrzę na ten przykład i co widzę?

• Prezentacja zbita razem z HTMLem - żeby zmienić układ strony zmieniamy HTMLa, a nie CSS,
• Kompletnie bezznaczeniowe nazwy klas i identyfikatorów - jedno wielkie semantyczne szambo. Wybrałem akurat framework od YUI, bo jest w tym najgorszy (choć Blueprint mu nie ustępuje). Elastic CSS wygląda trochę lepiej,
• Divitis. W przypadku YUI można chyba akurat dowolnie zmieniać użyte tagi, bo framework resetuje marginesy i paddingi dla wszystkich elementów (co też, tak na marginesie, uważam za kiepską praktykę). Kiedy jednak używając Blueprinta postanowimy zawrzeć którąś kolumnę w listę, to wszystko szlag trafia, bo uwaga... niektóre selektory zawierają nazwę tagu :O
• Narzucona struktura i kolejność elementów w kodzie HTML. Ja akurat poświęcam sporo uwagi temu aby każdy element nawigacyjny był w sensownym miejscu, aby nie używać niepotrzebnych tagów, a wykorzystując framework nie mam tej elastyczności,
• I wreszcie - przecież to wszystko co oferuje framework można w czasie, który jest bez znaczenia w stosunku do całego projektu, napisać ręcznie. To jest kilka reguł, które doświadczona osoba pisze na raz i to od razu z ewentualnym hackiem dla IE6. Tak, wiem, że nie wszyscy mają taką wiedzę, ale wykorzystując framework nigdy jej nie pogłębią.

Tak więc w żadnym wypadku nie widzę sensu w używaniu frameworków do budowy układu strony. Żeby jednak nie było, że w ogóle nie umiem wykorzystywać zewnętrznego kodu - uważam, że przydatne są frameworki poprawiające typografię, bądź też pod niektórymi względami formularze. Muszą jednak bazować na selektorach używających tagów, a nie klas, czy nie daj Boże identyfikatorów.

Przez mój czytnik i mojego blipa przewija się masa linków. Część ze znalezionych informacji dodaję do swojego del.icio.us, jednak mimo to o tych najważniejszych / wartych najwięcej uwagi czasem zapominam. Pomyślałem więc, że będę publikował co jakiś czas najciekawsze moim zdaniem znaleziska z zakresu web developowania i usability. Raz, że samemu będzie mi łatwiej do tych informacji wrócić, dwa, że może komuś zaoszczędzę trochę czasu i podsunę coś czego jeszcze nie czytał.

Wiele z poniższych linków macie szansę znać, wiele to starsze informacje, ale to pierwszy wpis w tym cyklu (tak, jeśli będę miał o czym pisać, to może zacznę to robić regularnie :) - następne będą aktualniejsze i zgrabniejsze. Na dodatek aby znaleźć te linki niestety musiałem przeglądać historię i wiele ciekawych rzeczy mogłem pominąć.

Usability vel użyteczność

• AB Tests – strona zbiera wyniki testów A/B podsyłane przez czytelników. Nie zawsze są to wiarygodne testy (ze względu na zbyt małe próbki), ale jest też wiele wartościowych badań, z których można nauczyć się czegoś na przyszłość.
• 10 przydatnych wskazówek związanych z użytecznością – jak to w Smashing Magazine – krótko, treściwie, ładnie i z głową.
• Jak wygląda raport z audytu użyteczności – by Robert Drózd.
• UI Flow Shorthand Notation – prosty sposób na graficzne przedstawienie "flow" serwisu. Czyli podstrony, akcje użytkownika i ścieżki między nimi.
• Dlaczego zatrudnię do mojego startupu programistę gier – trochę mniej związane z usability, ale nadal.
• Google Analytics w kontekście użyteczności – prezentacja przeprowadzona przez Roberta Drózda na WUD Tour. O tym, że nie wystarczy odpalenie statystyk - trzeba jeszcze umieć ich użyć.
• Lista lektur o użyteczności – wrzucam ją chyba sam dla siebie, żeby się motywować do czytania :).

Łebowe i niełebowe programowanie

• Python - pomoce, kursy, ćwiczenia – zacząłem się ostatnio uczyć Pythona i tu znalazłem sporo ciekawych materiałów. Polecam Python Challenge – najbardziej praktyczna nauka języka :).
• O tym dlaczego chowanie elementów interfejsu przez display:none jest złe – Sam odpowiedzi nie znałem. Artykuł o tym jak to zrobić lepiej.
• Falsy values i operatory porównania w Javascriptcie – dla mnie same falsy values były oczywiste, gorzej jednak z operatorami porównania - warto zapamiętać.
• ECMA zatwierdza ECMAScript 5 jako standard – więcej informacji na ten temat.
• Słownik HTMLa 5 – bardzo wygodny i przejrzysty spis tagów. Do każdego elementu mamy opis i przykładowy kod (brakuje mi listy atrybutów). Warto do niego zaglądać (jak i na całego HTML5 Doctora).
• HTML5 WTF? – prezentacja w komiksowym stylu o HTMLu 5. W sam raz dla szefa :)
• Jak powinien wyglądać śliczny kod HTML – nie z każdym elementem się zgadzam, ale to temat na osobny wpis. W skrócie - HTML5 w praktyce.
• JS Ninja – kilka przykładów ataków XSS. Przydatne do samokontroli podczas pisania Javascriptu.

Inne

• Komiksy o świecie twórców stron – z humorem o naszej pracy i środowisku :)
• Klienci z piekła rodem – bez komentarza. Trzeba poczytać. W każdą z tych sytuacji jestem w stanie uwierzyć :P

Póki co na tym koniec. Od teraz co ciekawszy znaleziony link będę sobie odkładał, więc następne wydanie przeglądu prasy będzie aktualniejsze.

Uwaga: wyszedł mi "odrobinkę" przydługi wstęp. Zabieganych zapraszam od razu do konkretów.

CSS rady nie daje

Nie da się ukryć że frontend developerzy (czy inaczej "ci od cięcia grafiki" :) łatwego życia nie mają. Pierwsza sprawa to niedoskonałości samych języków (CSS, xHTML, Javascript+DOM), druga to różnice i bugi (zwane inaczej ficzerami) w obsłudze przez przeglądarki. Każdy z tych języków na szczęście się rozwija (CSS3, HTML5, ECMAScript 5), a implementacja standardów jest, nawet w Internet Explorerze, sukcesywnie polepszana. Trwa to jednak strasznie długo, dlatego warto pokombinować samemu.

Ostatnio opisałem plugin do edytorów tekstów dzięki któremu można przyspieszyć pisanie HTMLa. Dzisiaj pod lupę chciałbym wziąć CSS. Osobiście na tempo pisania listy właściwości nie narzekam - mam własny zestaw snippetów, który umila mi życie. Inaczej ma się sprawa w stosunku do selektorów. Już w niedużym projekcie potrafią się zrobić cuda typu:

#content .news_list .item .title {...}
#content .news_list .item .date {...}
#content .news_list .item .date .day {...}

Albo:

.s1 { width:120px; float:left; font-size:1.1em; margin-left:10px; color:#FA0; }
/*gdzieś kawałek dalej:*/
.s2 { width:120px; float:left; font-size:1.1em; margin-left:10px; color:#C14; }

Gdzie wypada to połączyć do pary selektorów i dla każdego z osobna jeszcze kolor ustawić. Niestety to najprostszy przypadek z tej rodziny, czasami trzeba znaleźć części wspólne dla kilku reguł po kilkunaście właściwości, albo olać wszystko.

Dalej można wymieniać:

• Powtarzające się wartości kolorów, rozmiarów, marginesów, itd. Zmiana jednej wymaga zmiany pozostałych, bo np. tekst ma mieć ten sam kolor w nagłówkach newsów co gdzieś w sidebarze i górnym menu. I jak pozapamiętywać te wszystkie kluczowe wartości, żeby później nie szukać co to był za kod tego pomarańczowego, który używam do podkreśleń?
• Obliczenia - dopełnianie się marginesów, paddingów i borderów, kolor lekko ciemniejszy, kolor lekko jaśniejszy. Ja zawsze do cięcia siadałem z kartką A4, która już po kilku godzinach była zapisana do pełna wartościami i obliczeniami.

• -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px;

Co więcej - to są problemy które pojawiają się już na etapie stron o średniej wielkości i kodowania w pojedynkę. W przypadku sporych serwisów (długo i wieloetapowo rozwijanych) i większego zespołu potrafią urosnąć do &*$#$%. To jest jak rzeźba w gównie. Trzeba przepisać cały ten bajzel. Sam ostatnio tak opisałem jeden commit do bazy.

Wysyp wspomagaczy

Jakiś czas temu dostałem od kogoś link do LESS CSS - parsera/kompilatora (nie wiem jak to nazwać) rozszerzającego możliwości CSSa o kilka interesujących rzeczy typu: zmienne, obliczenia, reguły zagnieżdżone, itd. O temacie jednak zapomniałem (mało ostatnio koduję) i przypomniał mi kilka dni temu o nim Occulkot, który podrzucił mi Sassa. Obydwa kompilatory napisane są w Rubym. Zrobiłem mały research i znalazłem jeszcze podobne cudo, tyle że w Pythonie - Clever CSS.

Po krótkim wczytywaniu się w przykłady zdecydowałem się na LESSa. Dodaje do CSSa trochę mniej ficzerów, ale przynajmniej nie zmienia jego składni (plik CSS jest poprawnym plikiem LESS) i nie wymusza na mnie jedynego, właściwego formatowania kodu (Sass i Clever CSS mają składnię czerpiącą z języków w jakich zostały napisane - odpowiednio Ruby i Python - wymagają więc wcięć).

Polecam przeczytać Haml-sass, czyli tragedia w dwóch aktach. Przy okazji tej lektury ja również odradzam Hamla, który jest w teorii cudownym (zen i te sprawy) systemem szablonów HTMLa. Tylko, że kompletnie to nieczytelne, brzydkie i bez sensu.

Instalacja

Po tym przydługim wstępie (chciałem usunąć, ale żal jak się już napisało) przejdźmy do konkretów.

Instalacja, dla posiadających gema (ci nieposiadający najlepiej niech go zainstalują), jest banalna:

$ sudo gem install less

Ewentualnie jeśli ktoś koduje w Railsach, to może go zainteresować ten plugin.Najprostszym sposobem skorzystania z LESSa jest jednak przy pomocy konsoli:

$ lessc style.less

Wykonanie tego polecenia spowoduje utworzenie pliku style.css zawierającego wynik działania kompilatora.

Ficzery

Zmienne

Kompilując taki kod:

@brand_color: #4D926F;
 
#header {
  color: @brand_color;
}
h2 {
  color: @brand_color;
}

Otrzymamy:

#header, h2 { color: #4d926f; }

Jak widać, poza podstawieniem zmiennej, LESS połączył też reguły o tej samej liście właściwości. To informacja dla miłośników oszczędzania na bajtach transferu :).

Wielokrotne wykorzystanie reguł

CSSowe DRY :).

.rounded_corners (@radius: 5px) {
  -moz-border-radius: @radius;
  -webkit-border-radius: @radius;
  border-radius: @radius;
}
 
h1 .stronger {
	font-weight:bold;
	font-size:1.1em;
}
 
#header {
  .rounded_corners;
  h1 .stronger;
}
 
#footer {
  .rounded_corners(10px);
}

Po kompilacji:

h1 .stronger {
  font-weight: bold;
  font-size: 1.1em;
}
#header {
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px;
  font-weight: bold;
  font-size: 1.1em;
}
#footer {
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;
  border-radius: 10px;
}
 

Przy czym definicja reguły musi wystąpić przed jej użyciem. Przykład z wykorzystaniem h1 .stronger nie ma uzasadnienia w praktyce (jest w zasadzie błędny), ale chciałem tylko pokazać, że można wykorzystywać ponownie dowolne reguły.

Zagnieżdżone reguły

To chyba mój ulubieniec. Dzięki temu rozszerzeniu unikniemy pisania co chwilę mega długich selektorów. Dziwię się w ogóle, że nie ma tego w oficjalnym CSSie.

#header {
  color: red;
  a {
    font-weight: bold;
    text-decoration: none;
  }
 
  > p {
	  color: blue;
  }
}

Po kompilacji:

#header { color: red; }
#header a {
  font-weight: bold;
  text-decoration: none;
}
#header > p { color: blue; }

Obliczenia

Chyba nie muszę tłumaczyć.

@the-border: 1px;
@base-color: #111;
 
#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}
 
#footer { 
  color: (@base-color + #111) * 2; 
}

Po kompilacji:

#header {
  color: #333333;
  border-left: 1px;
  border-right: 2px;
}
#footer { color: #444444; }

To by było na tyle. Jeśli kogoś temat zainteresował to zapraszam do specyfikacji, gdzie autor omawia jeszcze kilka dodatków.

W każdym razie - cztery małe ficzery, a jak cieszą, prawda? :)

Praca z LESSem

Zastanawiałem się tylko jak usprawnić kompilację po wprowadzeniu zmian do pliku LESS. Najfajniej gdyby udało mi się w moim VIMie podłączyć wykonanie $ lessc pod operację zapisania, ale to nie na moje umiejętności. Mcv zaproponował mi takiego Makefile'a:

%.css: %.less
	lessc $<

Wykonujemy go uruchamiając: $ make plik1.css plik2.css. To już powinno mi się udać podpiąć w VIMie pod zapis pliku. Ewentualnie można spróbować tak:

all: *.css
 
%.css: %.less
	lessc $<

Co zadziała automatycznie dla wszystkich istniejących już plików CSS po wykonaniu prostego $ make. Przy czym, jeśli się mylę, to proszę mnie poprawić, bo nigdy żadnego makefile'a sam nie napisałem.

EDIT: w komentarzach pojawiły się rozwiązania mojego problemu.

Snippety do htmla? Nieeee. Zobaczcie Zen Coding. W skrócie działa to tak. Wpisuję w edytorze CSSową składnią:

div#content>h1+p

Wciskam jakąś kombinację klawiszy i dostaję:

<div id="content">
<h1></h1>
<p></p>
</div>

Sprytne, nie? :) Ale to jeszcze mało. Spróbujcie tego:

div#top>h1>a[title=Do strony głównej]{Moja strona}<ul#menu>li.pos$*3>a

<div id="top">
    <h1>
        <a href="" title="Do strony głównej">Moja strona</a>
    </h1>
    <ul id="menu">
        <li class="pos1">
            <a href=""></a>
        </li>
        <li class="pos2">
            <a href=""></a>
        </li>
        <li class="pos3">
            <a href=""></a>
        </li>
    </ul>
</div>

Chyba nie muszę mówić jak bardzo taka pomoc przyspiesza pracę. Napisanie z palca kodu z drugiego przykładu zajęłoby mi przypuszczalnie więcej niż 2 minuty. Gdybym użył snippetów (do których przy HTMLu nie mogę się przyzwyczaić) może skróciłbym ten czas dwukrotnie. Zaś używając wynalazku Zen Coding całość naklepałem w 20s (i to nie mając wprawy). Tak więc gorąco polecam.

Gdyby ktoś szukał wtyczki do VIMa, to powstał plugin, którego twórca zainspirował się Zen Codingiem.

Nie, nie będzie to wpis o tym jak moim zdaniem powinien wyglądać HTML5 i CSS3 (a w zasadzie to 4 już). Popełnienie takiego tekstu mam w planach i jak trochę powrócę do żywych, to może mi się uda :).

Jak pewnie niektórzy wiedzą - zostałem zatrudniony na etacie w firmie, z którą od dłuższego czasu (~dwa lata) współpracowałem jako freelancer. Na pierwszy ogień poszedł mały, wewnętrzny projekt, przy którym współpracuję między innymi z mcvłem. Do tej pory obaj sporo tworzyliśmy HTMLa i CSSów, ale żaden z nas, a na pewno nie ja, nie musiał przy tym z nikim ściśle współpracować.

Każdy programista na pewno rozumie to, że w nowym zespole zawsze trzeba ustalić konwencje dotyczące stylu kodowania. My apropo HTMLa ustaliliśmy, że używamy pojedynczych cudzysłowów (do tej pory zawsze korzystałem z podwójnych i herezją było dla mnie używanie pojedynczych, ale w zasadzie nie jest źle :). Z CSSem było gorzej, bo musiałem zmusić mcvała żeby pisać całe selektory i wszystkie właściwości w jednej linii, ale dało radę.

I tak z pierwszymi ustaleniami zasiedliśmy do pracy. Popracowaliśmy całe 4 dni i okazało się, że te krótkie ustalenia to stanowczo za mało.

<address>

Interpretacja mcvała

Tagu address możemy używać jedynie zgodnie ze specyfikacją HTMLa 4.01:

The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form.

Czyli możemy w tym tagu zawrzeć informacje dotyczące kontaktu z autorem (prawdopodobnie jedynie drogą elektroniczną). Mogą to być linki, maile, ale co ciekawe - ulica i miasto już raczej nie. Wydaje się to potwierdzać dość dziwny przykład podany dalej w specyfikacji:

<ADDRESS>
<A href="../People/Raggett/">Dave Raggett</A>, 
<A href="../People/Arnaud/">Arnaud Le Hors</A>, 
contact persons for the <A href="Activity">W3C HTML Activity</A><BR> 
$Date: 1999/12/24 23:37:50 $
</ADDRESS>

Moja interpretacja

Nie ma potrzeby trzymać się co do słowa niedoskonałej specyfikacji HTMLa sprzed prawie 10 lat. Użyjmy taga address jako taga semantycznego nadającego znaczenie każdemu zawartemu w środku adresowi (czy to pocztowemu, czy mailowemu, czy też stronie firmowej). Dodatkowo - nie oznaczajamy nim jedynie danych kontaktowych z autorem strony, ale także z każdym innym podmiotem, który na stronie opisujemy (np. we wszelakich bazach miejsc).

Dodatkowo uważam, że nazwa address jest bardzo niefortunna, jeśli mamy tam umieszczać linki. Gdyby ktoś miał na myśli jedynie informacje o kontakcie, to tag nazywałby się contact.

I tutaj chciałbym wesprzeć się przetłumaczonym przez Łukasza Grabunia artykułem pt. Zapomniane znaczniki, który od lat służy mi pomocą w walce ze sklerozą :).

Inne moje nadinterpretacje

Istnieje jeszcze kilka innych tagów, przy których interpretacji nie uważam za sensowne ściśle trzymać się specyfikacji. Od razu podkreślam, że nie mam na myśli zupełnego oderwania się od niej. Nie chcę używać table jako tagu do opisu stołu w restauracji, albo tabelkowego layoutu. Uważam natomiast, że na przykład lista definicji to nie tylko stricte:

<dl>
	<dt>Kura</dt>
	<dd>Stworzenie boskie, o dwóch nogach i opierzonym ciele</dd>
</dl>

Ale także inne konstrukcje zawierające jakiś temat i jego zawartość. Na przykład lista użyta przeze mnie wcześniej trochę z premedytacją:

<dl>
	<dt>Interpretacja mcvała</dt>
	<dd>(...)</dd>
	<dt>Moja interpretacja</dt>
	<dd>(...)</dd>
</dl>

Oczywiście mogłaby też wyglądać tak:

<h3>Interpretacja mcvała</h3>
<div class='section'>(...)</div>
<h3>Moja interpretacja</h3>
<div class='section'>(...)</div>

I w pewnym przypadkach jest to zdecydowanie poprawniejsze rozwiązanie. Jednak kiedy nagłówki sekcji nie są wyraźne (mam tu na myśli rzecz jasna znaczenie wynikające z treści strony, a nie jej wyglądu :P) i są jedynie opisami tego co znajduje się niżej, to wolę użyć rozwiązania pierwszego. Ale akurat w specyfikacji listy definicji twórcy HTMLa podali więcej przykładów, które w pewnym sensie tłumaczą moją nadinterpretację.

Przypomina mi się także, że kiedyś był mały ruch przekonujący by całą stronę (poza treścią typowo akapitowo - nagłówkową) opisywać listami uporządkowanymi, nieuporządkowanymi i listami definicji. W pewnym sensie zgadzałem się z tym, że cała strona jest jakąś listą i sporą większość jej elementów da się zrozumieć jako jakąś część listy. Zdaje się jednak, że to już przesada w drugą stronę :)

Na HTMLu nie koniec

Żeby nie było za miło posprzeczaliśmy się także o niektóre rozwiązania w CSSie :)

Styl mcvała

• zostawiamy przeglądarkowe paddingi i marginesy, bądź ustalamy ich początkowe wartości (ale nie na zero),
• aby odsunąć w pionie zawartość rodzica od dziecka nadajemy dziecku marginesy pionowe i jeśli potrzeba rodzicowi padding:0.1px. Jeśli trzeba, czyli w przypadku braku obramowania, bądź paddingu,
• wszystkie marginesy i paddingi ustalamy według emów - aby zwiększona w kodzie wielkość czcionki miała wpływ na te wielkości.

Mój styl

• zerujemy za pomocą * {padding:0; margin:0} wszystkie niepotrzebne odstępy, aby móc nad nimi dokładnie zapanować. Nadajemy je z powrotem dopiero w treściach strony,
• aby odsunąć w pionie zawartość rodzica od dziecka używamy paddingów dla tego pierwszego. A poprzez :last-child zerujemy margines ostatniemu dziecku (dzieci mają marginesy aby je od siebie odsunąć),
• marginesy i paddingi w 90% przypadków podajemy w pikselach, by mieć większą kontrolę nad ich wartościami (i nie mieć zonka że coś się rozjeżdża bo zmieniłem wielkość czcionki)

Oczywiście żaden z nas nie był w stanie przekonać drugiego do swoich racji :). Niestety - obaj w swoim życiu już za dużo layoutów pocieliśmy i zbyt wyrobione mamy zdanie na niektóre tematy. Ale i tak uważam, że można się sporo ciekawych rzeczy dowiedzieć pracując z drugą osobą. Ja na przykład dowiedziałem się o własciwości box-sizing i wreszcie zapanuję nad {width:100%; padding:10px} :).