Sesja się już dla mnie skończyła, można więc coś napisać. Dzisiaj będzie jednak krótko, bo i temat prosty.
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.
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 :).
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.
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ę?
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.
Odniosę się do tego, co wypunktowałeś:
1. Że... co? Przepraszam, ale jak wyobrażasz sobie zagnieździć elementy, które faktycznie muszą być zagnieżdżone bez... ich zagnieżdżania? Chętnie zobaczyłbym jakikolwiek kod HTML napisany przez Ciebie, w którym wystarczy zmienić tylko CSS by nagle z szablonu portalowego zrobić liniowy, dostosowany do np. telefonu komórkowego.
2. Wybierz proszę ja ciebie odpowiednią nazwę, tak żeby nie kolidowała ewentualnie z naszym wewnętrznym nazewnictwem, które chcemy użyć. IMHO yui-* to dobry wybór, można tylko mieć pretensje do Blueprinta, że używa nazewnictwa "span-*".
3. Skomentuję tylko resetowanie. Wyobraź sobie, że ktoś w przeglądarce ustawił jako domyślne tło czarne, marginesy z dupy i tekst na żółto. Spróbuj teraz bez resetowania ustawień do domyślnych, takich jakie nam pasują, wykorzystać domyślny margines czy domyślny kolor tła/tekstu.
4. Tutaj może faktycznie zdarzyć się tak, że nawigacja będzie w kodzie "bliżej" niż właściwy content. Ale z tego co wiem, to można to obejść.
5. Aplikację też możesz bez frameworka napisać. Wystarczy zlepić ze sobą kilka bibliotek/projektów (np. w PHP) typu Doctrine/Propel, Smarty etc. I można pisać.
Zwykły bezkonstruktywny bełkot. I wybacz, ale opinia jest subiektywna jak cholera, a tytuł flejmogenny.
tiraeth: 1. Prawdą jest że często trzeba zmieniać HTML przy zmianach wyglądu, ale nie zawsze. Im więcej kodu jak w przykładowym yui, tym częściej trzeba zmieniać. Kwestia ilości tych zmian.
2. Po co Reinmar miałby coś wybierać, skoro jego twierdzeniem jest, że frameworki są złe i ich nie używa? To co piszesz jest nielogiczne.
3. Skomentuję resetowanie. Resetowanie jest OK, o ile nie niszczy się w ten sposób elementów formularzy. Chyba, że te elementy szanowny resetujący też zamierza ostylować co do jednego. Wtedy jest ok.
BTW, Yui to całkiem ładne japońskie imię. ;-)
Ja się natomiast z autorem zgadzam. Jeśli mam przyspieszać tworzenie kodu HTML+CSS, to akurat wolę mieć dobrze przygotowane środowisko pracy, a szczególnie edytor, który powtarzające się czynności wykonuje za mnie.
Jeśli chodzi o resetowanie, to faktycznie, możesz się kiedyś przejechać. Chociaż za resetowaniem to bardziej przemawia to, że nie trzeba przy każdym elemencie samemu poprawiać a to marginesu dla tego silnika, a to dopełnienia dla innego, bo to jest uciążliwe (trudno mi sobie wyobrazić, żeby akurat tę czynność zautomatyzować) i często po prostu zaciemnia kod.
@tiraeth:
1. patrz to co napisał mcv - jest drobna różnica w przeniesieniu kilku divów w kodzie, a zmianie dodatkowych 20 klas.
2. znowu patrz co napisał mcv - nie używam frameworków, więc ten problem mnie po prostu nie dotyczy.
3. jeśli ktoś zmienił sobie tło na czarne i padding w inputach, to pewnie wie co robił i zrobił to z jakiegoś powodu. Na dodatek nie pisałem, że nic nie resetuję - resetuję to co potrzebuję mieć dokładnie ostylowane, żeby właśnie mieć jak najmniej takich niespodzianek.
Na dodatek2 - jeśli zresetujesz wszystko tak jak w YUI (po tagach), to później musisz odresetewać style dla treści, albo zostawiasz taki goły biedny tekst.
4. słowo klucz "obejść".
5. lekko inny wymiar - framework CSS można zastąpić w kilka minut, a symfony to jest kilkanaście(dziesiąt) tysięcy linii kodu.
Bełkot może, bez konstruktywny może. Opinia jest subiektywna, bo to blog, a nie artykuł w gazecie, a tytuł flejmogenny, bo lubię patrzeć jak rosną mi statystyki i pojawia się dużo jeżdżących po mnie komciów :)
Osobiście też frameworków css nie używam. Więcej z tym problemu niż pożytku. Z czasem jednak każdy z nas sobie taki framework tworzy i warto sobie te gotowe czasem przejrzeć i może wykorzystać kilka pomysłów (np. reset.css by E. Meyer)
Jeśli już widzę w czymś framework css to rapid prototyping (zakładając, że jest dobry i dobrze znany przez użytkownika)
Do testów wybrałeś najgorszy framework. Polecam 960gs lub Baseline.
Co do rozdzielenia prezentacji od semantyki to też są na to słuszne sposoby już.
Polecam obejrzeć http://vimeo.com/7530607
@rad: Zgadzam się z tym, że z czasem każdy sobie taki framework tworzy. Ja też mam kilka (naście?) reguł, które pojawiają mi się w praktycznie każdym projekcie, choć też nie zawsze :)
Mógłbyś coś więcej powiedzieć o rapid prototypingu, bo nic konkretnego pod tą nazwą nie mogę znaleźć.
@DrLex: 960gs (http://www.spry-soft.com/grids/grid.css?column_width=60&column_amount=12&gutter_width=20) daje to samo co np. YUI, tylko bez resetów i czyściej. Główne wady jednak współdzieli.
W Baseline'ie podoba mi się trochę typografia, ale używają tam pikseli. Ja ostatnio mocno polubiłem się z emami, w szczególności, że wielokrotnie uratowały mi skórę (ostatnio musiałem dorobić skalowanie całej strony - z marginesami, wszystkimi szerokościami, wysokościami, itd, do dawno już skończonej strony, w której nie było mowy o takich cudach wcześniej). Formularze też są w miarę spoko - ale znowu - ja inaczej koduję je HTMLem.
Po wielu rozmowach jakie dzisiaj odbyłem i kilku rzeczach, które mi podesłaliście myślę, że jest spora szansa, że postaram się wydzielić trochę szablonów z mojego kodu i stworzyć własny framework. Tak jak napisałem pod koniec notki - ostylowałbym formularze i typografię (albo "stworzył typografię" - czuję się analfabetą ;). Musiałbym co prawda stworzyć klasy nie na zasadzie "co opisują", tylko "co robią", ale w kilku miejscach mogę coś takiego przeboleć.
Nie mam jednak na myśli tego, że przyznaję się do pomyłki :P. Jestem pewien jednego - taki framework będzie używalny tylko dla mnie, ewentualnie dla kolegów z pracy, którzy przywykli do mojego stylu (inaczej mówiąc - zostali zmuszeni do pisania tak jak ja :D). W moim świecie pedantycznego kodu jedynie takiego typu frameworki mają prawo bytu.
Tak mi przyszło do głowy, że zmuszanie programistę, który już ma jakiś styl do używania czyjegoś frameworku, to jak zmuszenie grafika żeby z czyichś clipartów zmontował jakieś dzieło :P Rzecz jasna mam na myśli tylko HTML i CSS. Nie wiem czy można mieć jakiś styl programując np. w PHP :>
W ogóle "styl" to takie piękne słowo.
Również dla mnie fw css to nieudany pomysł. Reset, predefiniowane typo - ok.
Ale cała reszta to... nadużycie semantyczne przede wszystkim :)
Lepiej poznać LESS CSS http://lesscss.org/ - to jest cos czego w css`ie dla mnie zawsze brakowalo...
@DrLex: Obejrzałem jeszcze prezentację, do której podałeś link - w 95% zgadzam się z autorem. W zasadzie, o ile o czymś nie zapomniałem, tylko w kwestii resetu mam odmienne zdanie :)
Compass (meta-framework CSS) umożliwia korzystanie z wymienionych we wpisie frameworków, omijając przedstawione wady - na przykład korzystać z Blueprint samemu nadając nazwy klasom i identyfikatorom.
960gs - Gdy nie wiem od czego zaczac projekt.. stawiam siatke, zapominam o niej juz po 20 warstwie, a po 100 nie ma wiele wspolnego z projektem jak wspomnial Reinmar.
Porownanie FWorkow do pracy grafika z clipartami troche nietrafione.
Blizej im do aplikacji wspierajacych dobor palet kolorow, paternow i typografii, a i to jest nietrafione. Pozwala jednak nimi zarzadzac i ulatwia dostep, stad sugestia.
Mimo to, sam z nich nie korzystam.
Jakos tak mam wrazenie, ze mnie ograniczaja ale coz.. jedni wola kolorowanki, a sa i tacy co swiadomie, z premedytacja wykraczaja poza linie, schematy.. i wiedza, ze to dobre jest. ajj, chyba poplynalem;-)
waldo!
@Łukasz: Spojrzałem na szybko na Compassa, ale mnie trochę przeraził poziomem skomplikowania/rozbudowania. Będę mu musiał poświęcić dłuższą chwilę.
@Palto: Na basen miałeś chodzić ;P
~tiraeth: jeśli chodzi o zmianę samego CSS - zapomniałeś już o CSS Zen Garden? ;)
Frameworki CSS są dla ludzi, którzy nie chcą się nauczyć CSS.
@Reinmar: rapid prototyping w znaczeniu szybkie stworzenie działającego rozwiązania. Szybkie stworzenie prototypu, szkicu. Spotkałem się z tym gdzieś w elektronice.
Często zdarza się, że chcemy wypróbować jakieś rozwiązanie i tworzymy sobie taki prototyp. Przy wdrożeniu "do produkcji" oczywiście przepisujemy go na nowo.
Nie wiem jak wy, ale ja jakoś nie mogę od razu napisać idealnego rozwiązania ;)
@riddle: czy ja wiem, to tak jakby powiedzieć, że frameworki np. Pythona są dla ludzi, którzy nie chcą się nauczyć pythona :P
fw css może i nie są idealne (i pewnie nigdy nie będą), ale ja widzę ich rolę nieco inaczej.
- automatyzować powtarzalną część zaawansowanych użytkowników css
- ułatwić start osobom uczącym się css
- szybkie tworzenie prototypów
może w chwili obecnej taki framework nie istnieje, ale nie zakładajmy, ze taki zbiór reguł nigdy nie powstanie. Powiedz jakiemuś dobremu programiście, że używa frameworka bo nie umie programować ;)
Po co tak defensywnie? CSS to nie język programowania. Dla każdego projektu tworzy się pewnego rodzaju „framework”, dlatego te uniwersalne są dla tych, którzy nie chcą się CSS nauczyć i mieć od razu gotowe. Tak jak napisano w poście – Less to nie framework, to automatyzacja (której nie lubię, ale jak kto woli). Jedyny framework CSS którego warto używać to ten: http://unobtrusivecss.com/unobtrusive.css
Albo inaczej, bo wyjdzie że trolluję. :-)
Duże projekty wymagają określonego poziomu zaawansowania w tworzeniu CSS – szablony bywają skomplikowane. Dlatego żeby nie napisać 20.000 linijek dla każdego elementu, należy to wszystko poukładać w bloki i odpowiednio odzwierciedlić w CSS. Bez umiejętności i pewnej wprawy się tego nie zrobi, dlatego powstało zapotrzebowanie na frameworki HTML/CSS – takie jak Blueprint czy YUI 2 Grid. One są dla ludzi, którzy wolą nauczyć się kilkunastu zasad tychże frameworków (bądź użyć gotowca / wygenerować z builderów, których też jest dostatek) i przestać się przejmować układem i zasadami, które wywalają layout na IE.
I można tak, ale mój oryginalny komentarz nadal podtrzymuję: „frameworki CSS są dla ludzi, którzy nie chcą się nauczyć CSS” (w stopniu pozwalającym na swodobodne pisanie zorganizowanego i lekkiego kodu). Ot, coś jak z PHP – amatorów klecących skrypty jest multum, a prawdziwych koderów szukać ze świecą.
riddle ja się z tobą w pełni zgadzam, ja też za frameworkami CSS (w obecnej formie) nie przepadam. Bez rewelacji. Ale nie odrzucam koncepcji frameworka css jako takiego. I uważam, że jeśli już to skierowany jest do osób bardziej zaawansowanych lub właśnie chcących się uczyć (coś podpatrzeć) początkujących.
z tym, że dla mnie idealny framework to prosty zbiór kilku reguł powtarzających się w każdym projekcie. Podobny do tego, który podlinkowałeś ;)
http://img.riddle.pl/_handshake-20100131-142511.jpg :]
:)
Wspaniale. Mój blog łączy ludzi :)
>Frameworki CSS są dla ludzi, którzy nie chcą się nauczyć CSS.
W 100% się zgadzam - tak jak napisałem pod koniec wpisu - korzystając z frameworków trudniej się nauczyć czystego CSSa. I chyba w ogóle tak jest, że korzystając w jakimkolwiek języku z jakiegokolwiek frameworka jest trudniej nauczyć się czystego języka. Na moim przykładzie - piszę sporo w symfony, ale PHP nie znam. Pisałem w jQuery, ale JSa się dzięki temu nie uczyłem. Trochę lepiej dopiero zaczęło być jak przerzuciłem się na prototype'a.
> z tym, że dla mnie idealny framework to prosty zbiór kilku reguł powtarzających się w każdym projekcie. Podobny do tego, który podlinkowałeś ;)
Dodałbym do tego, że taki framework powinien być jak najbardziej prywatny/firmowy. Nawet w HTMLu/CSSie jest tyle stylów kodowania, że użycie czyjegoś rozwiązania się po prostu nie sprawdza.
A ja z JS miałem akurat odwrotnie :P Nigdy jakoś nie mogłem się przekonać do JavaScript, ale jak zobaczyłem jQuery to się po prostu zakochałem. Zacząłem używać jQ i z czasem uczyć się JS.
Kiedyś na początku mojej nauki wiele bym dał, żeby zobaczyć takie czyjeś rozwiązania. Żeby nie zaczynać od zera.
Z jednej strony odrzucam wszystkie prawdy objawione i jedyne słuszne rozwiązania, ale chętnie patrze jak robią pewne rzeczy inni ludzie bo to pomaga mi wypracować moje własne rozwiązania.
Jeszcze o Compass http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters/
Witam serdecznie wszystkich, przeczytałem Waszą dyskusje, z częścią zdań się nie zgadzam z częścią zgadzam - bez znaczenia.
Chciałbym jednak wtrącić jedną uwagę - obserowowałem paru koderów zaczynających prawie od zera swoją przygodę z kodowaniem backendu do bycia absolutnym 'wymiataczem', sam również przeszedłem pełną ścieżkę od zafukanego kodera css'a do dumnego z siebie programisty obiektowych języków. Jedna cecha wspólna, którą widziałem wszędzie u wszystkich, to fakt że odruchowo każdy koder tworzy sobie coś w rodzaju własnego framework'a - pare pseudoklas, pare 'trików' które są wspólne dla wszystkich projektów które tworzy. W tym kontekście mimo iż sam uważam że korzystanie z frameworka css powoduje znaczny overhead kodu, to nie odrzucam samej idei silnej konwencji w danym projekcie, która pozwala na opanowanie css'a i html'a, które jak wszyscy przecież wiemy mają tendencje do wyrywania się z pod kontroli i hasania radośnie po polach sentencji 'później się to poprawi' i 'ja to teraz na szybko tylko sfixuje' oraz 'to ja to tylko tu skopiuje'
Silna konwencja jest dobra.
Polecam również szczerze wspomnianego tutaj compass'a jak i nie wspomnianego HAML'a i SASS'a (wg mnie sass jest zdecydowanie lepszym rozwiązaniem niż np less ale to osobista opinia i nie radze na niej polegać bez próbowania). Natomiast życia i kodowania bez HAML'a sobie już nie wyobrażam. W naprawde rzadkich okazjach kiedy musze coś napisać w zwykłym HTML'u dostaje lekkich drgawek powieki i musze szybko uzupełniać magnez :)
Pozdrawiam wszystkich, mam nadzieje że nie zatrollowałem.
Madsheep
@masheep: W sumie po części zgodziłeś się z tym co padło w komentarzach - framework jest fajny jak jest prywatny == każdy programista tworzy sobie coś w rodzaju własnego frameworka :)
Co do SASSa i Lessa - wypróbowałem ostatnio tego drugiego przy dosyć sporym projekcie i muszę powiedzieć, że dałem radę przez kilka dni. Później, kiedy na każdą kompilację musiałem czekać 2-3s zaczął mnie szlag trafiać. Do tego kod zamiast ładniejszy, zaczął się robić coraz bardziej zagmatwany, rozwijanie tego trudniejsze, więc całość wywaliłem.
Co do SASSa (jak i HAMLa) to nigdy nie ufałem narzędziom, które mają zupełnie odmienną składnię od języków bazowych. Ale skoro odrzuciłem już Lessa, to może spróbuję coś tego typu. Chociaż brałbym wersję na Pythona, bo powinna być szybsza. Jednak najbardziej irytowało mnie czekanie.
Nie używam frameworków CSS, bo mnie ograniczają i narzucają własny styl pisania, słowem - odbierają całą przyjemność tworzenia kodu.
Odnośnie LESS-ów, HAML-ów i innych SASS-ów, to jestem tutaj staroświecki i wolę się 'męczyć' w czystym CSS i HTML, ponieważ na szybkości pisania mi specjalnie nie zależy (nie pracuję w fabryce na taśmie, ani z nikim się nie ścigam), a na podobne rozwiązania wolę poczekać aż zostaną zaimplementowane w CSS, np. mamy wyrażenia arytmetyczne, a w przyszłości prawdopodobnie pojawią się też zmienne.
Jeśli chodzi o temat resetowania CSS, staram się od tego odchodzić. Resetowanie jest na pewno wygodne i szybkie, ale daje w tyłek silnikowi (szczególnie selektor uniwersalny) i w wielu miejscach niepotrzebne, wystarczy włączyć konsolę Firebuga i zakładkę HTML, żeby się przekonać jak wiele deklaracji nadpisujemy stosując reset.
@css3: dlatego spece od CSS odradzają używania selektora uniwersalnego, a resetowanie tylko zachowań odbiegających od normy. [potrzebne źródło ;) ]
Jeśli znasz lepszy sposób niż reset css, czyli przez sprowadzenie ustawień css do jednej postaci na wszystkich przeglądarkach i tworzenie na bazie tego, to bardzo chętnie go poznam :)
@rad - lepszy sposób? zależy co rozumiesz przez "lepszy".
Ja (w tej chwili, bo może się to zmieniać :)) wyznaję zasadę, że użycie resetów zależy od tego jaki layout kodujemy.
Bo zdarzają się layouty mega zgrafikowane, gdzie każdy px się liczy i wtedy wygodnie jest zresetować praktycznie wszystkie właściwości. Ja długo używałem tak niepolecanego * {...}, a ostatnio przerzuciłem się na mocno zmodyfikowany przeze mnie reset od Meyera.
Zdarzają się też takie gdzie jest dużo typografii, CSSowych efektów, a mniej grafiki. Wtedy nie ma co resetować wszystkich marginesów, paddingów i czego tam jeszcze, bo później trzeba to odzyskiwać z powrotem. Dlatego spokojnie można się obejść ustawiając tylko kilka porządkujących właściwości.
@css3.pl: przez lepszy rozumiem taki, który posiadałby więcej zalet niż używany przeze mnie obecnie reset.css Meyera ;)
IMO zalety stosowania reset.css są nieporównywalnie większe, niż te kilka dodatkowych regułek, które musi przemielić przeglądarka zwłaszcza na obecnych komputerach :P
@rad to chyba zależy od projektu, zgodzę się tutaj z Reinmarem, czasami po prostu reset nie jest potrzebny, bo albo połowa resetu jest bezużyteczna (resetujemy elementy, których w projekcie nie wykorzystujemy), albo nadpisujemy reset.
Z drugiej strony nie wiem w jakim stopniu nadmiarowy kod i selektor gwiazdki spowalnia renderowanie, nigdzie jeszcze nie wiedziałem testów, które pokazywałyby wyższość CSS wydajnego nad niewydajnym, więc możesz mieć racje, że to jest bez znaczenia.
@css3.pl: Ja też testów nie widziałem, ale dużo fajnych ludzi tak mówi :) No chyba, że zrobił nam się zabobon.