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.

Podobne wpisy:

1. Zen Coding – snippety do kosza

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.

Wpis ten opublikowałem też na swoim prywatnym blogu.

Podobne wpisy:

1. Dlaczego frameworki CSS ssą?

Dust-Me Selectors robi właściwie „tylko” jedną rzecz — znajduje nieużywane selektory CSS. Jednak właśnie jest to jedna z najtrudniejszych rzeczy do wykonania manualnie, szczególnie w przypadku dużych, długo rozwijanych projektów.

Rozszerzenie może działać na dwa sposoby:

• przeszukiwanie jednej strony (przydatne raczej w niewielu przypadkach),
• tzw. Spider Search, czyli przeszukiwanie wszystkich linków z mapy strony.

Mapa strony może być stroną HTML lub sitemapą w XML zgodną ze standardem. W tym pierwszym przypadku są pewne ograniczenia. Otóż domyślnie potrafi on wyskoczyć na inne, zewnętrzne domeny i je sprawdzać. Nie udało nam się znaleźć opcji zabraniającej tego, jedynie da się ograniczyć omijanie odnośników z rel=”external” i/lub rel=”nofollow”. Problem jest, gdy nasz serwis na to nie jest przygotowany. Wtedy pozostaje wygenerowanie lub napisanie sitemapy (która przecież i tak się przyda).

Samo działanie programu już jest bardzo proste. Wybieramy „Automation → Spider Search”, podajemy adres sitemapy lub strony HTML i czekamy na wyniki, które wyglądają na przykład tak:

Okno wyników Dust-me Selectors

Oczywiście znalezione selektory nie powinny trafiać od razu do kosza, bo narzędzie nie potrafi (i raczej wątpliwe żeby kiedykolwiek potrafiło) wziąć pod uwagę manipulacji dokonywanych przez JavaScript. Ponadto mogą istnieć specyficzne widoki, które nie będą mogły się znaleźć w mapie strony. Dlatego też wyniki należy traktować tylko jako listę podejrzanych. Warto dodać, że narzędzie pomogło nam szybko pozbyć się prawie dwustu linii z arkuszy CSS (przy kolejnych do dokładniejszego sprawdzenia).

Podobne wpisy:

1. Jak przycinać i skalować obrazki?