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>Tagu address możemy używać jedynie zgodnie ze specyfikacją HTMLa 4.01:
The
ADDRESSelement 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>
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ą :).
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ę :)
Żeby nie było za miło posprzeczaliśmy się także o niektóre rozwiązania w CSSie :)
padding:0.1px. Jeśli trzeba, czyli w przypadku braku obramowania, bądź paddingu,* {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,:last-child zerujemy margines ostatniemu dziecku (dzieci mają marginesy aby je od siebie odsunąć),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} :).
Co do <address/> to bym uważał — HTML5 doprecyzowuje jego zastosowanie (http://dev.w3.org/html5/spec/Overview.html#the-address-element).
Cyt. ‘The address element must not be used to represent arbitrary addresses (e.g. postal addresses), unless those addresses are contact information for the section.’
> aby odsunąć w pionie zawartość rodzica od dziecka używamy paddingów dla tego pierwszego.
A to już zupełna nieznajomość CSS-a się kłania.
> (i nie mieć zonka że coś się rozjeżdża bo zmieniłem wielkość czcionki)
Tak, na pewno nic się nie rozjedzie. A użytkownik będzie miał niezwykłą przyjemność czytania tekstu, który nie mieści się w przeznaczonym do niego polu, bo jakiś geniusz stwierdził, że poszerzenie strony zepsuje jego cenny (beznadziejnej jakości) layout.
Wlasnie dlatego wymyslono zoom calej strony a nie durne powiekszanie czcionki.
"o musiałem zmusić mcvała żeby pisać całe selektory i wszystkie właściwości w jednej linii"
Na stos LIFO z Tobą! Fucking hard to debug. U nas w firmie już byś herbatę wszystkim robił ;>
Nie widzę za to nic nadzwyczajnego w zaproponowanej przez Ciebie listy z dwoma definicjami i zgadzam się z używaniem px do odsuwania elementów.
Nigdy natomiast, ale to nigdy, nie używam css reset - jakoś nigdy nie mam z tym problemów. Mój największy IE6.css, przy dużych serwisach społecznościowo-portalowych, ma jakieś 50 linijek - większość to png fix / box model fix.
Marginesy warto podawać w emach jeśli dotyczą bezpośrednio tekstu albo boksów ze zmienną wielkością , ale kiedy chodzi o przesunięcie zawartości od brzegu sztywnego boksu, to zdecydowanie lepszym pomysłem jest użycie pikseli. W końcu bardzo dziwnie by to wyglądało gdyby dla 250px sidebara, tekst raz zaczynał się 20px od brzegu a innym razem 50...
Te style w jednej linii to duże zuo. Ani wszystkiego nie widać, ani nie da się łatwo jednej właściwości skopiować. Tak właściwie to nie ma plusów, poza tym, że jest mniej linii. Tyle, że mniej linii to właściwie niewiele daje.
Do trzeciej w nocy siedzisz, a rano Cię w pracy nie ma.
Pewnie jakieś freelancerskie nawyki ;-)
"pojedynczych cudzysłowów", "całe selektory i wszystkie właściwości w jednej linii" <- same herezje :P
Wow, to w końcu, w css_3_ pojawiła się taka właściwość - IE pewnie za 10 lat będzie to obsługiwał?
@lolek: jeżeli chodzi ci o box-sizing, to nie musi obługiwać. Dzięki temu selektorowi ustawiamy, żeby box-model działał na wszystkim innym niż IE dokładnie tak, jak działa teraz na IE ;]
@Michał Górny: może jakieś dowody? Bo ja też mogę napisać, że kompletnie nie znasz czegoś tam.
O zmianie wielkości czcionki w KODZIE pisałem. Nie chcę zmieniając font-size z 0.9em na 1.1em martwić się, że porozsuwał mi się nagłówek strony. Zresztą - co innego jest pisać elastyczny layout (i w dodatku dla siebie), a co innego sztywny, gdzie każdy px się liczy dla klienta.
@teamon: Zależy co kto woli :) Ale osobiście Cię popieram. Tylko nie wiem kogo Ty popierasz :D
@BTM: Herbaty nie pijam :). A formatowanie CSSa to temat na niezłego flame'a :P Choć wiem, że jestem w mniejszości.
To samo do resetów - tyle samo jest zwolenników co przeciwników. Ja myślę tylko że odejdę od zerowania na rzecz ustalania jakichś sensownych wartości w emach.
Co do hacków dla IE6 to mam dokładnie to samo :D W pewnym momencie człowiek tak dobrze się uczy unikać jej bugów, że nawet nie trzeba hacków pisać :)
@anoriell: Dokładnie tak. Dodatkowo jeszcze rozróżniam używanie jednostek w layoucie gdzie chodzi często o odsuwanie bloków, od używania jednostek już w treści, gdzie przechodzę na emy.
@BTM2: Szef mi powiedział żebym nie przychodził za wcześniej, bo będzie miał wyrzuty sumienia :D Ja chciałem na 8mą chodzić :P
@lolek: Pojedyncze cudzysłowy to dla mnie też herezja, ale mają jeden plus - nie trzeba shifta wciskać :D:D
Ojtam, przy tym to już odruch ;-) Tak jak u mnie wciskanie Esc jak chcę napisać "ń" (HTMLKit jako Alt+N miał skrót do "Nowy dokument" i trzeba było tak kombnować, teraz w Zend dalej mam taki odruch :P)
Ja też odruchowo wciskam ten shift, ale pamiętam, że zdarzało zdarzają się właśnie pomyłki, kiedy w tego shifta nie trafiałem. Ale i tak nie zamierzam się przyzwyczajać do pojedynczych cudzysłowów.
"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ę."
Zapłoniesz na stosie. I jeszcze za brak spacji między property:value.
Reszta:
1. Resetowanie przez * {} jest głupie, bo rozwalasz domyślne style dla formularzy, których już potem nie przywrócisz.
2. :last-child jest złym pomysłem, :first-child już lepszym (wszystko poza IE6)
Więcej o CSS w jednej linijce (wyróżnione moje komcie)
http://www.flickr.com/photos/jonathansnook/2800852816/#comment72157606970684105
http://www.flickr.com/photos/jonathansnook/2800852816/#comment72157606970797259
@Riddle: Wiedziałem, że będziecie mnie chcieli wszyscy spalić :D Cóż - znaczna większość z Was jednak łamie linie więc i ja będę musiał. Zobaczymy.
Ad1. Od resetowanie przez * {} też akurat zamierzam powoli odejść, ale wydaje mi się, że nie sprawiło mi problemów nigdy. Poza rzecz jasna paddingami w kontrolkach, ale istnieje box-sizing, tak jak pisałem :P
Ad2. A dlaczego first-child jest lepszym pomysłem? Wtedy trzeba górne marginesy ustawiać (w celu oddzielenia dzieci - o czym nie napisałem)
A tak BTW napisałem ten wpis głównie myśląc o HTMLu i interpretacji tagów, a wszyscy przyczepili się do CSSa :P
Ja nie chcę palić! Ja popieram jednolinijkowy CSS! Tylko z odstępami i wcześniej ustaloną kolejnością atrybutów, żeby było się łatwiej połapać.
A jak resetowanie to raczej IMO konkretnych elementów.
@zx: To też fajne rozwiązanie żeby właściwości np. alfabetycznie walić, albo na początek strukturalne, później fonty, a później coś tam. Ale to w obu przypadkach się przydaje.
Ano to fajna sprawa jest faktycznie w obu przypadkach. U mnie to coś w stylu: width, height, margin, padding, float, clear, position, border, background, font, color itd. Mam nawet chyba gdzieś wypisane wszystkie atrybuty i ładnie uporządkowane i w moim kodzie to takie prywatne standardy.
Jeśli pracujecie sami nad CSS-em, to myślę że jednolinijkowce są spoko jak się Wam tak podoba. Ale wystarczy że dojdzie druga osoba i są konflikty – bo usuwać właściwości i łączyć (optymalizacja. nie powtarzamy rulesetów jak nie trzeba) z takich dziwolągów jest nieziemsko ciężko.
Ale to działa też na odwrót - dla mnie ciężko jest pracować nad wielolinijkowym CSSem jak dostaję coś takiego w spadku. Dlatego dobry tool do konwersji to byłaby fajna sprawa.
s/;/;\t\n/ i przed sibie ;]
Ajć, odwrotnie. Ale wiecie o co biega ;]
No i jeszcze żeby takie cudo poustawiało własności w odpowiedniej kolejności. Jest coś takiego, ale pamiętam, że coś mi w tym nie pasowało, dlatego od jakiegoś czasu myślę, żeby sobie po prostu coś napisać.
Są narzędzia. I to nawet lepsze niż w/w regexp.
A edytowanie wielolinijkowca jest banalne – oczywiście jak się używa narzędzia tekstowego (typu vim, Notepad++, TextMate) a nie notepada. :P
http://img.riddle.pl/multiline-css-20090318-135309.png
teamon: To się nazywa inteligentna odpowiedź. Po co robić coś dobrze, skoro wymyślono workaround? Po co w ogóle robić stronę, można wrzucić gotowy obrazek z treścią — i będzie zero ryzyka, że layout się rozjedzie.
Reinmar: box model nie jest wystarczającym dowodem?
@Michał Górny: nie bój się - ja box model znam. Wyjaśnij mi tylko gdzie powiedziano, że to nie padding służy od odsuwania krawędzi boksa od jego zawartości.
@Reszta: przeformatowałem sobie teraz w gvimie cały plik ze stylami i nie potrafię nad nim pracować :P Nie mogę znaleźć selektorów. Przydałoby się ładne zwijanie kodu, ale niestety jeszcze nie udało mi się tego skonfigurować w gvimie.
Reinmar: Okurka, sry, nie dojrzałem rano „rodzica od dziecka” i myślałem, że dwa równorzędne elementy tak od siebie odsuwasz ;f.
Hehe :) Spoko. Pisałem to na szybko, więc się domyślałem, że nie do końca jasno :) Zresztą - o 3ciej w nocy nie chciało mi się przykładów tworzyć.
CSS jednolinjkowy? Noz sie w kieszeni otwiera...
A tam. Ja tam przez większość czasu na początku pisałem CSS-a na wiele linijek, a ostatnio doszłem do wniosku że to niewygodne i się przestawiłem na tryb jednolinijkowy. Nie wiem, jaka wygoda jest w edytowaniu pionowo rozlazłych plików.
@mg Jasne, utrudniajmy developerom prace. Zoom calosci daje takie same efekty a nie rozwala calego laya. Co do formatowania css i konwertowania za kazdym razem - scm (chyba nie trzeba nic dodawac)
teamon: Nie, lepiej niech dostają pieniądze za nicnierobienie i inwestują w Apple.
zieff