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.
]]>
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Przez Michał
12/12/2013
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.
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Przez Michał
12/12/2013
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.
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 :)
]]>PS: Kawa jest zdrowsza :P
]]>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 ;)
]]>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)
]]>