W dzisiejszej części kursu Twitter Bootstrap dowiemy się jakie elementy są wspierane przez ten framework oraz przekonamy się o mnogości klas CSS, które pomogą nam w szybkim tworzeniu witryny.
Na samym wstępie zaznaczę, że z uwagi na nową wersję Bootstrapa postanowiłem stworzyć ten artykuł właśnie pod ostatnią aktualizację. Na szczęście niewiele elementów uległo zmianie, jednakże jeżeli wystąpi różnica w nazewnictwie klas pomiędzy Boostrap 2.x a Bootstrap 3.0, oznaczę je kolorem zielonym.
Typografia czyli podstawowe elementy prezentacji treści w HTML
Zacznijmy od nagłówków. Bootstrap dostarcza nam ostylowanie nagłówków od <strong>h1</strong> do <strong>h6</strong> co sprawia, że nie musimy się martwić o zachowanie odpowiednich marginesów itd. Używamy ich jak w normalnym HTML czyli po prostu:
1 2 3 4 5 6 | <h1>Tutaj nagłówek</h1> <h2>Tutaj nagłówek</h2> <h3>Tutaj nagłówek</h3> <h4>Tutaj nagłówek</h4> <h5>Tutaj nagłówek</h5> <h6>Tutaj nagłówek</h6> |
Możemy dodać element <small> wewnątrz nagłówka. Da to nam efekt opisu tego nagłówka.
1 | <h1>Bla bla bla <small>Pomniejszony tekst nagłówka</small></h1> |
lub
1 | <h1>Bla bla bla <span class="small">Pomniejszony tekst nagłówka</span></h1> |
Skoro wiemy już jak wyglądają nagłówki w Bootstrap warto nadmienić, że domyślny rozmiar czcionki dla akapitu to <strong>14px</strong> a wysokość jej linii to <strong>1.42</strong>. Kiedy dodamy do paragrafu klasę lead otrzymamy tekst odznaczający się od pozostałych paragrafów wielkością oraz grubością czcionki.
Aby pomniejszyć tekst możemy użyć po prostu elementu <strong><small></strong> lub nadać innemu dowolnemu elementowi klasę <em>small</em>. Spowoduje to, że tekst zawarty w tych elementach będzie miał 85% rozmiaru czcionki rodzica tego elementu.
Inne klasy pozwalające na formatowanie akapitów
Klasa lead to nie jedyna klasa, która wpływa na prezentację akapitów. Otrzymujemy jeszcze kilka innych. Omówimy najpierw te, które wpływają na pozycjonowanie treści wewnątrz tych elementów. Aby wyrównać lub wyśrodkować tekst możemy użyć text-left, text-center lub text-right.
1 2 3 | <p class="text-left">Tekst wyrównany do lewej.</p> <p class="text-center">Tekst wyśrodkowany.</p> <p class="text-right">Tekst wyrównany do prawej.</p> |
Możemy również nadać różny charakter treści w akapicie. Otrzymujemy bowiem do tego takie klasy: <em>text-muted</em> (muted), text-primary, text-success, <em>text-info</em>, text-warning, text-danger (text-error).
Skoro wiemy już jak wygląda sprawa nagłówków i akapitów w Twitter Bootstrap, pokażemy sobie jak korzystać z innych dobrodziejstw HTML 5 (oczywiście wspieranych przez framework :-) ).
Aby utworzyć prosty blok z danymi kontaktowymi możemy użyć elementu <adress> w taki sposób:
1 2 3 4 5 6 | <address> <strong>Webroad.pl</strong><br> ul. Zamkowa 100<br> New York<br> <abbr title="Telefon">T:</abbr> (123) 456-7890 </address> |
Możemy także utworzyć sobie blok z cytatem ( blockquote) oraz nadać mu klasę pull-right. W ten sposób otrzymamy ładnie ostylowany element z naszym cytatem, gdzie tekst będzie wyrównany do prawej.
Na dzisiaj to koniec. W następnej lekcji zajmiemy się formularzami, tabelkami oraz przyciskami. Trzymajcie się i do zobaczenia w następnej części kursu Twitter Bootstrap!
nie lubię sposobu, w jaki Bootstrap domyślnie styluje subheadingi. zgodnie ze specką, element small nie powinien być do tego używany. z kolei klasa .small nie oddaje znaczenia tego elementu (to nie jest „mały tekst”, tylko po prostu podtytuł). http://www.w3.org/TR/html5/common-idioms.html#sub-head
nie lubię sposobu oznaczania podpisów w cytacie ;) znów – Bootstrap używa tutaj elementu small, który nijak ma się do znaczenia tego elementu. zgodnie z dotychczas obowiązującą wersją specki HTML, raczej powinien być to span (względnie b od autora) albo – co jest często przerostem formy nad treścią – cytat opatulić dodatkowo w figure a podpis w figcaption (co ma sens jedynie przy bardziej złożonych artykułach). obecnie podpis do cytatu można włożyć po prostu w cite (wreszcie ktoś w W3C otworzył oczy!) http://html5doctor.com/cite-and-blockquote-reloaded/
przykładów takich „smaczków” w Bootstrapie można mnożyć (pusty li.divider – serio? a co z border-bottom?) a w połączeniu ze „składnią do wszystkiego” z wersji 3.0, gdzie z nie-listy można zrobić listę (sic!), dostajemy po prostu tagzupę. z tego samego powodu niekoniecznie uważam BEM za dobrą praktykę (narąbmy divów, żeby moduł się nam dobrze wyświetlił a ten akapit musi mieć koniecznie klasę .nazwa-naszego-modulu–promocja__paragraph)
btw nie rozumiem też zmiany .text-error na .text-danger. IMO pierwszy był logiczniejszy i łatwiejszy do skojarzenia (można było pisać to w ciemno, nawet nie znając BS)
A co sądzisz o http://semantic-ui.com/ ? ;)
pewnie wyjdę na hejtera, ale co tam ;)
jak już mówiłem gdzie indziej – to nie „semantic UI” a „verbose UI”. choćby przykład z gridem – muszę oznaczyć, że to część UI (.ui), że to grid (.grid), z kolumnami (.column; btw z czym innym może być grid? jakoś „wierszowanego” sobie nie wyobrażam) i w końcu, że tych kolumn jest 3 (.three). mamy 4 klasy, z czego tak naprawdę potrzebna jest jedna (.grid). no i elastyczność leży (.ui.three.column.grid do 4 kolumn już nie posłuży).
fajnie, że mogę sobie „porozmawiać” z tagami i czytać kod jak książkę. tyle, że tworzę tym samym nadmiarowy kod a niespecjalnie to dużo wnosi (samo .grid tak samo wyjaśniłoby wszystko).
bardzo też podobają mi się tendencyjne przykłady na stronie głównej – semantyczne znaczniki + klasy z „semantic” ui vs divowate BS. szkoda, że BS też jest „HTML agnostic”.
i tu kolejny problem – czy jest sens tworzenia „HTML agnostic” CSS? czy koniecznie musimy mieć możliwość stylowania nienawigacji tak, jak nawigację? czy złożoną listę koniecznie trzeba móc odtworzyć na divach? itp itd. owszem, to oznacza hiper „elastyczność”, ale tym samym zachęca do totalnej olewki semantyczności kodu (zresztą semantyczny HTML i tak umiera, bo przecież „wystarczy tu dodać coś ze schema.org – Google to łyknie”…).
dalej – jeśli tworzymy modularny CSS, to czy każdy tag HTML powinien mieć odpowiednią klasę? a co np z tak trywialnym przykładem jak choćby podpis w cytacie? czemu obecnie nie wystarczy blockquote > cite, tylko potrzebujemy .ui.block.quote > .ui.quote.signature (o wersji BEM-owej nie wspomnę…)? specjalnie tworzymy sobie kolejne warstwy abstrakcji, zapominając, że CSS tylko określa prezentację HTML i bez niego istnieć nie może. najpierw powinien być fundament semantyki (tworzymy HTML bez CSS) a dopiero później martwimy się jak to ładnie wyświetlić (i dodajemy klasę tam, gdzie jest to koniecznie potrzebne). tutaj jest wręcz odwrotny proces: mamy super hiper klasę .quote i teraz „dorobimy” sobie kod HTML pod to. jak to się kończy, wszyscy dobrze wiemy.
przykład? http://semantic-ui.com/collections/breadcrumb.html nikt mi nie powie, że koniecznie każdy link musi mieć klasę .section… a .divider? niepotrzebny element – mamy :after. i zanim ktoś powie, że przecież może być potrzeba zrobienia różnych odstępników: kto na swojej stronie tworzy kilka różnych stylów breadcrumbs? a odstępnik można sobie zrobić na poziomie developingu (i tak obecnie wszystko jest kompilowane z SASS/LESS, więc to jest kwestia jednej zmiennej).
tak samo np checkboxy: http://semantic-ui.com/modules/checkbox.html serio potrzebujemy diva dla każdego checkboxa? co jak co, ale we wszystkich frameworkach CSS kod formularzy jest absolutnie, totalnie udziwniony.
http://semantic-ui.com/views/comment.html – to to mnie już totalnie rozwala :D nikt mi nie powie, że to nie jest przerost formy nad treścią. zwykle starcza coś typu .comment + kilka selektorów .comment p itd. nie przeginajmy i nie próbujmy totalnie oddzielić CSS od HTML. tzn – tak, CSS i HTML to dwie różne warstwy. ale to CSS nakładamy na HTML, a nie próbujemy przystosować HTML do CSS! bo później wychodzą potworki tego typu.
tak samo zawsze zastanawiam się nad ikonkami: czemu to jest pusty element? przecież mamy :after, :before a taki FontAwesome używa znaków spoza zakresu „czytelnych”, więc w czym problem? + w CSS3 Speech Module dostajemy speak:none, dzięki czemu wgl wyłączymy czytanie takiego elementu (i AFAIR w chrome jest to już rozpoznawane).
jedyne co mi się tak naprawdę w Semantic UI podoba, to sposób „dziedziczenia” w CSS, który jest najintuicyjniejszym z istniejących i de facto jest najczystszym wykorzystaniem CSS: .ui.grid, .four.wide.column itd. osobiście sam go stosuję i kod CSS jest cholernie czytelny (rzut oka i wiadomo co jest od czego i po czym dziedziczy). staje to okoniem w stosunku do BEM i – przynajmniej dla mnie – działa to lepiej. ponoć ma jakieś problemy z wydajnością, ale osobiście ich nie zauważyłem. jak ktoś ma linka do jakiegoś artykułu/benchmarku, to chętnie się temu przyjrzę ;)
uff, to by było tyle jeśli chodzi o Semantic UI ;)
Dzięki za treściwy komentarz! Czasami mam wrażenie, że Twoje uwagi zasługują na nadanie Ci tytułu honorowego redaktora! Zastanów się – może chciałbyś coś kiedyś na webroad.pl napisać?
Dokładnie. @Comandeer:disqus, możesz podesłać na [email protected] swój adres? Chcielibyśmy wysłać do Ciebie kubki do kawy WEBroad w nagrodę za super aktywność :-)
dzięki :D podeślę. od tej chwili będę komentował Was, pijąc colę z Waszego kubka ;)
a co do bycia redaktorem – zastanowię się nad tym. może coś stworzę :D
Super! Dzięki :D
Zapraszamy i smacznego!
PS: Kawa jest zdrowsza :P
@Comandeer:disqus przedstawił jedną stronę medalu, jest też druga, przynajmniej w moich oczach. Semantic UI i jemu podobne narzędzia cierpią na divitis i classitis i możemy w nieskończoność pisać jakie to złe i będziemy mieli rację. Jasne, że mogło by to wyglądać np. tak:
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Przez Michał
12/12/2013
kategoria1
kategoria2
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Consequuntur, maiores, velit, non, quasi voluptate voluptatem porro inventore hic magni possimus sequi explicabo adipisci ex cumque excepturi. Assumenda, voluptates porro tempore.
tag1
tag2
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Przez Michał
12/12/2013
kategoria1
kategoria2
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Consequuntur, maiores, velit, non, quasi voluptate voluptatem porro inventore hic magni possimus sequi explicabo adipisci ex cumque excepturi. Assumenda, voluptates porro tempore.
tag1
tag2
I byśmy się tym zachwycali, wszystko by było ładnie dziedziczone po .klasa-matka, bo proste, mało klas etc. Sprawdzi się to jednak tylko na niewielkich stronach, bo każde zmiany (np. chęć przeniesienia kategorii do stopki) wiążą się ze zmianami w CSS, a prezentacja kategorii się nie zmienia, tylko ich miejsce w artykule. Znam to z autopsji i wiem jak to wkurza. Gdybym wszystkiemu dodał klasy, tak jak jest w Semantic UI, to nie musiał bym wcale do CSS zaglądać.
Chodzi o to, że wybierając framework CSS musimy zdecydować czy chcemy mieć minimalistyczny kod czy dużą elastyczność. Ja osobiście coraz bardziej przekonuje się do takich rozwlekłych (trudno je określić mianem semantycznych) rozwiązań, ale trzeba zdawać sobie sprawę z przerostu formy nad treścią i szukać złotego środka :)
teraz z kolei przesadziłeś w drugą stronę i pokazałeś coś, z czym ja się również nie zgadzam ;) mianowicie pokazałeś „semantyczny CSS” (ok, ciut się wyłamałeś, bo dałeś klasę, ale reszta pozostała niezmienna): http://coding.smashingmagazine.com/2013/08/20/semantic-css-with-intelligent-selectors/
owszem, takie podejście sprawdza się tylko i wyłącznie na małych stronach i to nie podlega dyskusji. zresztą i tak przy jakimkolwiek bardziej skomplikowanym elemencie grzęźniemy w bagnie typu article > section > footer li a span… nie ma to większego sensu i właśnie od tego mamy klasy.
podejście, o którym mówię w bardzo ładny sposób zostało przedstawione w kursie HTML logeena. chodzi mi o jego implementację OOCSS. nie mówię o odrzuceniu klas i znakowaniu tylko najwyższego rodzica, bo wkrótce nas to zaboli. chodzi o sensowny podział na poszczególne moduły. np moduł menu raczej nie będzie dzielony na poszczególne linki, dlatego możemy sobie darować klasę typu .navigation-item czy podobną.
tak samo Twój przykład z kategoriami: nie wyobrażam sobie oznaczenia kategorii czymś w rodzaju article > header > ul:nth-child(3). w tym wypadku tak bardzo uzależniamy CSS od HTML, że każda najdrobniejsza zmiana pociągałaby za sobą potrzebę przepisania sporej ilości arkusza. kategorie w artykule są mniejszym, niezależnym (sub)modułem i jako taki może przecież dostać klasę. wówczas przeniesienie tego w inne miejsce kodu nie sprawia najmniejszych problemów.
owszem, modularyzacja w CSS jak najbardziej. z tym, że ja myślę raczej większymi częściami całości (poszczególne bloki a nie poszczególne elementy) – dzięki temu zarówno kod HTML, jak i kod CSS pozostają w miarę czyste i omijam rozwlekłość. oczywiście nie upieram się przy niestosowaniu klas i stosuję je zawsze, gdy jest to wygodniejsze/wymaga mniejszego nakładu pracy. nie walę jednak klas wszędzie, bo po prostu jest to niepotrzebne.
poza tym – powtórzę się – dla mnie możliwość odtworzenia listy na nie-liście może i jest elastycznością, ale nie prowadzi do niczego dobrego (rośnie nam rozmiar CSS i cierpi semantyka HTML).
nie zapominajmy, że podstawą Sieci jest właśnie HTML. CSS jest tylko warstwą prezentacji. ostatnio mam wrażenie, że się o tym zapomina i przystosowuje HTML do CSS. to tak jakby przystosować książkę do okładki i poprzestawiać wyrazy w kilku rozdziałach, bo lepiej się komponują z obwolutą.
no i zostaje jeszcze kwestia: czy aby na pewno tworząc konkretny projekt strony potrzebujemy absolutnie uniwersalnego frameworka? biorąc takiego BS i tak ok. 60% kodu nigdy nie wykorzystamy. więcej czasu spędzimy na próbie odchudzenia tej kobyły niźli na faktycznym developingu i czerpaniu korzyści płynących z niepisania CSS-a od podstaw.