To jak, widzimy się na Front-Trends 2010?

Nie jeździsz na konferencje – tracisz!

Przede wszystkim, zastałem w stolicy Wielkopolski mnóstwo nieprzypadowych gości. Byli tam managerowie, programiści, designerzy, blogerzy, internetowi celebryci, Czytelnicy tego bloga, uczestnicy moich szkoleń i masa innych specjalistów, którzy na co dzień tworzą nasz polski internet. Motywowały zasłyszane przeze mnie kuluarowe rozmowy, zainspirowane zapewne obejrzanymi wcześniej wystąpieniami. Wiesz, zamiast trzech buttonów dajemy jeden, a to to w ogóle porażka, nie wiem czemu tak zrobiliśmy… – spierał się siedzący za mną zespół developerów. Tym ludziom po prostu zależało, a strzelam, że takich dyskusji było tego dnia więcej.

Powiedzmy sobie głośno, jeśli jeszcze tego nie wiesz – nie bywasz na konferencjach – przegrywasz. Przegrywasz wiedzę, kontakty biznesowe, potencjalnie wartościowych, nowych znajomych. A w ogólnym rozrachunku – pieniądze, które mógłbyś zdobyć dzięki powyższym. Na sali kręciły się osoby, związane z takimi markami jak Microsoft, Opera, Nokia, Roche, czy Allegro. Pytanie “szukasz pracy?” zdecydowanie nie było tematem tabu.

Przeglądarka Twoim domem

Następna dekada to czas nowoczesnego, zgodnego ze standardami front-endu. JavaScript jest już dostępny na większości zaawansowanych urządzeń mobilnych, świat podbija niesamowity HTML5 (i krążące wokół niego nowinki), a Flash umiera. W dużych korporacjach “J2ME” zaczyna być ustawiany w parze z takimi słowami jak skansen czy muzeum, a zaawansowane, webowe aplikacje sprawiają wrażenie software’u desktopowego – są szybkie, lekkie, wygodne i działają w przeglądarce. Jest rzeczą niezwykle ważną, abyśmy nie przegapili pewnego skoku jakościowo – technologicznego, który niedługo się dokona. Tym bardziej cieszy fakt, że na horyzoncie pojawiły się wydarzenia, dzięki którym możemy poczuć się jak np. Brytyjczycy, którzy mają u siebie co roku kilkanaście (o ile nie więcej) takich konferencji.

SparkUp – jestem na tak

Nie chciałbym oceniać poszczególnych elementów konferencji SparkUp. Jak na każdej, były rzeczy, które należałoby poprawić, jak i te, za które należą się oklaski. Ogólne wrażenie było bardzo dobre. Nie będzie więc tutaj szyderczej i bratobójczej krytyki, którą z pewnością wielu blogerów by podniosło. Zresztą, najlepiej konferencję ocenią/ocenili jej uczestnicy na Blipie czy Twitterze. Jest to wręcz idealny kanał komunikacji dla takich eventów, czego kiedyś nie doceniałem.

Miałem też okazję porozmawiać dłuższą chwilę z jednym z organizatorów – Piotrem Czekałą. Wielkie gratulacje za chęci i sprawienie, że konferencja się odbyła! Miejcie świadomość, że SparkUp organizują sympatyczni ludzie z głową na karku. Przy okazji dowiedzieliśmy się kilku ciekawych rzeczy, co z pewnością przemyślimy w kontekście Front Trends.

Front Trends

No właśnie, Front Trends. Pojawiło się ostatnio mnóstwo pytań, co do konferencji, która odbędzie się w Warszawie 21 i 22 października. Wiedzcie, że pracujemy bardzo ciężko nad pełną wersją strony internetowej, a także nad cenami i ścieżkami tematycznymi. Nie chcę składać żadnych obietnic czasowych, ponieważ mamy zamiar zaoferować Wam jak najlepszą konferencję i dbamy o dopracowanie każdego szczegółu. Zbliża się najwyższy moment na podanie wszystkich, wiążących informacji, więc proszę o odrobinę cierpliwości!

Konferencji czas

Muszę przyznać, że jestem wielkim optymistą, jeśli chodzi o przyszłość konferencyjną w Polsce. Po tym, co usłyszałem i zobaczyłem we wtorek, jestem pewien, że Polska pragnie takich wydarzeń. I będzie je miała, bo taki potencjał nie może zostać zmarnowany.

Można powiedzieć, że marzenia się spełniają. Długo zapowiadana niespodzianka stała się faktem. Szykuje się największe w tej części Europy święto dla wszystkich ludzi odpowiedzialnych za kształt Internetu.

Niniejszym zapraszam na stronę informacyjną konferencji – Front-Trends.com. Jak dotąd, udało się nam zebrać samą śmietankę w postaci naukowców, ewangelizatorów i twórców popularnych frameworków. Ludzi, którzy kreują światowy web. Już wkrótce kolejne, równie gorące nazwiska!

Oficjalna strona wydarzenia ma obecnie charakter wyłącznie informacyjny. Identyfikacja wizualna wraz logo i pełną wersją strony (w tym płatnościami) pojawią się już niedługo. Jednocześnie zapraszamy na Twittera oraz Blip po najnowsze wiadomości.

Naszym celem jest stworzenie przypisów dolnych tak, aby wyglądały jako boczne, zupełnie jak na tym blogu. Jeśli w jakimś akapicie znajdzie się odnośnik do przypisu, jego treść powinnna pojawić się z prawej strony akapitu (tagu <p />). Zacznijmy od semantycznego szablonu:

<div class="article">
	<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus massa. Fusce sed erat. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse auctor neque id purus. Ut dignissim felis et velit suscipit fringilla. Aenean et est et lacus interdum rutrum.<a href="#przypis-1" class="hint"><sup>1</sup></a> Nam iaculis ipsum vel neque blandit placerat. Cras dui elit, varius at, gravida a, consectetur ut, elit. Donec turpis. Fusce quis sapien ac nisl lobortis eleifend. Morbi posuere, massa vel fermentum commodo, arcu quam fermentum turpis, vel tincidunt ante odio at arcu. Sed vitae purus.</p>
	<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus massa. Fusce sed erat. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse auctor neque id purus. Ut dignissim felis et velit suscipit fringilla. Aenean et est et lacus interdum rutrum. Nam iaculis ipsum vel neque blandit placerat. Cras dui elit, varius at, gravida a, consectetur ut, elit. Donec turpis. Fusce quis sapien ac nisl<a href="#przypis-2" class="hint"><sup>2</sup></a>lobortis eleifend. Morbi posuere, massa vel fermentum commodo, arcu quam fermentum turpis, vel tincidunt ante odio at arcu. Sed vitae purus.</p>
	<hr />
	<ol id="notes">
		<li id="przypis-1">First note</li>
		<li id="przypis-2">Second note</li>
	</ol>
</div>

Jak widać, kontenerem dla artykułu jest .article, odnośnikami do przypisów są linki .hint. Domyślne przypisy dolne tworzy lista #notes.

Pora na trochę podstawowych CSSów. Wypozycjonujmy treść, nadajmy odpowiednie typy fontów i tak dalej:

* {
	padding: 0;
	margin: 0;
}
a {
	text-decoration:none;
	color: #7EBB1F;
	font-weight: bold;
}
a:hover {
	background-color: #7EBB1F;
	color: #fff;
}
.article {
	width: 960px;
	margin: auto;
	font: normal 14px 'Lucida Sans Unicode', Arial, Helvetica, sans-serif;
}
.article p {
	margin-bottom: 20px;
	line-height: 20px;
	width: 680px;
}

Generalnie, cel jest następujący – jeśli mamy włączony JavaScript usuwamy listę numerowaną <ol#notes />, a jej elementy zmieniamy na <p /> i umieszczamy pomiędzy stosownymi akapitami artykułu. To teoretyczny opis. W praktyce będzie to zrobione nieco inaczej.

Poszukamy akapitów, które linkują do określonych przypisów. Jeśli dany akapit zawiera link .hint to dodajemy zaraz po nim stosowny przypis. Treść przypisu pobierzemy na podstawie identyfikatora, który znajduje się po hashu (#) w linku-odnośniku.

Najpierw jednak zajmijmy się sytuacją, kiedy mamy wyłączony JavaScript:

.article hr {
	border: none;
	border-top: 1px solid #7EBB1F;
	width: 680px;
	float: left;
	margin-bottom: 10px;
}
.article #notes {
	clear: left;
}
#notes li {
	font-size: 11px;
	width: 680px;
	margin-bottom: 3px;
	line-height: 15px;
	font-style: italic;
}

Powyższym ostylowaliśmy przypisy dolne – w końcu jeśli JavaScript będzie wyłączony, to będzie trzeba jakoś je zaprezentować. Warto sprawdzić efekt.

Fajnie jednak byłoby, gdyby jakiś aktywny przypis (tzn. ten, w który kliknęliśmy) został nieco wyróżniony. Zrobić możemy to dzięki selektorowi :target:

#notes li:target {
	font-weight: bold;
}

Oznacza to, że jeśli w linku pojawi się identyfikator jakiegoś tagu <li /> np. przypis1.html#przypis-2 to treść tego tagu (tutaj: < li id=”przypis-2″ />) zostanie wyboldowana. Wynika na to, że załatwiliśmy problem wyłączonego JavaScriptu.

Zajmijmy się teraz odpowiednimi skryptami, które przeniosą elementy z listy #notes pod stosowne akapity. Skorzystamy w tym celu z jQuery.

Najpierw należy poszukać wszystkich linków .hint w obrębie artykułu .article:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

Dzięki funkcji each przeiterujemy się przez wszystkie znalezione odnośniki do przypisów. Pierwsze, co powinniśmy zrobić, to znaleźć akapit, który jest rodzicem danego linku:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');

Następnie pobieramy adres linku, by uzyskać identyfikator przypisu, do którego się on odnosi:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

Tym sposobem pod zmienną id będą następujące wartości:

• #przypis-1
• #przypis-2
• itd.

Pora pobrać treść przypisu na podstawie jego ID i uformować nowy akapit z przypisem:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+'</sup>'+note+'</p>');

Szczególnie istotna jest tutaj 8. linijka:

var newNote = $('<p class="note"><sup id="'+id+'">'+(i+1)+'</sup>'+note+'</p>');

Otóż dzięki niej tworzymy nowy tag drzewa DOM jakim jest <p />. Oczywiście ubieramy go w stosowne wdzianko - nadajmy class="note" - tak, by potem można było ostylować przypis boczny. W nowym przypisie umieszczamy również indeks w <sup />, korzystając ze zmiennej i z pętli each - jej wartość zaczyna się standardowo od zera, więc należy dodać jeden, by otrzymać zwykłe odliczanie od 1. Znacznik sup musi mieć dobry identyfikator bez hasha na początku. Wyrzucamy więc "#" przez id.replace(/#/g, '').

Trzeba jeszcze zająć się pozycjonowaniem przypisu tak, by był wertykalnie nieco bliżej jego odnośnika .hint. Spróbujemy ustawić tak dobrany, ujemny margin-top, by nie było zbytnich przerw pomiędzy wspomnianym linkiem i akapitem z przypisem.

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+</sup>'+note+'</p>');

		newNote.css('margin-top', (parseInt($(parent).css('margin-bottom')) + ($(parent).height() + $(parent).offset().top) - $(element).offset().top) * -1);

Stosowny margines górny ustawiamy na podstawie prostego wyliczenia. Sumujemy wysokość i odległość od początku strony całego akapitu, a następnie od tej sumy odejmujemy odległość linku od początku strony. Odległość od początku strony możemy pobrać przez jQuery'owe offset().top, a wysokość przez height(). Do wszystkiego dodajemy jeszcze margines dolny akapitu, w którym mieści się link. Wszystko mnożymy razy minus jeden, by uzyskać ujemny margines dla naszego przypisu. Oto rysunek poglądowy, jak wyliczamy margines:

Pora dodać nowy przypis pod stosowny akapit i zakończyć pętlę each:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+'</sup>'+note+'</p>');

		newNote.css('margin-top', (parseInt($(parent).css('margin-bottom')) + ($(parent).height() + $(parent).offset().top) - $(element).offset().top) * -1);

		newNote.insertAfter(parent);

});

Na koniec musimy jeszcze usunąć przypisy dolne, które nie są już nam potrzebne:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+</sup>'+note+'</p>');

		newNote.css('margin-top', (parseInt($(parent).css('margin-bottom')) + ($(parent).height() + $(parent).offset().top) - $(element).offset().top) * -1);

		newNote.insertAfter(parent);

	});

	$('#notes').prev('hr').remove();
	$('#notes').remove();
});

Wynik naszej zabawy nie wygląda jednak zbyt atrakcyjnie.

Pora dodać stosowne style dla .note:

.article .note {
	float: right;
	background-color: #FBF1AB;
	border: 1px solid #ECD42B;
	width: 162px;
	padding: 4px;
	overflow: hidden;
	font-size: 12px;
}
.article .note sup {
	float:left;
	font-size:20px;
	vertical-align: bottom;
	margin-right: 5px;
	text-align: center;
	width: 30px;
}
.article .note sup:target {
	background: #FBEA71;
}

Jest całkiem nieźle!

Można by co prawda zwiększyć widoczność odnośników do przypisów:

.article .hint {
	margin-right: 10px;
}
.article .hint sup {
	font-size: 14px;
}

Działa wyśmienicie!

Zastosowane tutaj rozwiązanie ma w zasadzie tylko jedną wadę - nie należy nadużywać przypisów w jednym akapicie, ponieważ mogą one na siebie nachodzić, tworząc dość nieprzyjemny efekt. Oczywiście możemy nie stosować pozycjonowania względem odnośnika, usuwając linijkę odpowiedzialną za ustawianie górnego marginesu. Wtedy możemy stawiać przypisy gdziekolwiek i w jakiej ilości chcemy.

Postanowiłem stworzyć ankietę, w której zadaję Wam 30 pytań na różne, branżowe tematy. Najważniejsze dla mnie informacje są wymagane, jednak kilka pytań możecie z czystym sumieniem opuścić. Oczywiście ankieta jest w pełni anonimowa, tak więc im więcej respondentów, tym lepiej! Apeluję też o poważne odpowiedzi, ponieważ zależy mi na tym, by jak najlepiej dopasować ofertę bloga do Waszych preferencji. Na wynikach ankiety planuję również oprzeć wygląd paru projektów, związanych z tematyką blogów i front-endem jako takim.

Oczywiście wyniki ankiety omówię i przedstawię w jakiejś przystępnej formie. Bez obaw!

Zapraszam więc gorąco do wypełnienia ankiety na Ankietka.pl.

javascript: void();

Widziałem w swoim życiu wiele kombinacji. Raz treść ładowana była AJAXem bez żadnego komunikatu, drugi raz pojawiał się pasek postępu. Czasem zakładki otwierały się natychmiast, choć byłem pewien, że sobie poczekam (wszakże na stronie, z której przyszedłem, wszystko odbywało się przez zapytania asynchroniczne). Często też jestem świadkiem sytuacji, że zostaję przekierowany na inną stronę, mimo że zakładka sprawiała wrażenie dynamicznej. O niedostępnych tabach nie wspomnę – mało kto zwraca uwagę, że w przypadku wyłączonego JavaScriptu bądź uruchomienia zakładki w nowym oknie powinienem zostać przeniesiony do strony, która pokaże mi mniej więcej to, o czym była mowa w etykiecie karty. Niestety, nadal pokutuje (nie)słynne javascript:void – przykład pierwszy z brzegu – gry-online.pl:

A to Polska właśnie

Najlepiej przykład wkurzających zakładek prezentują polskie, czołowe portale. Zacznijmy od Onetu (używając tzw. skórki eleganckiej).

Po pierwsze, link więcej powoduje przeładowanie strony, mimo że wygląda on jak pozostałe zakładki. Po drugie, kontrast między zakładką a treścią jest tak mały, że można ulec dezorientacji. Tym bardziej, że treść jest dość długa i znacznie wykracza poza widzialny obszar monitora (1280×800). Nie wspomnę też o tym, że zakładki ładowane są AJAXem, używając bardzo mało przejrzystego komunikatu:

Na szczęście bez problemów mogłem otworzyć daną zakładkę w nowym oknie przeglądarki.

Na Onecie jesteśmy zaskakiwani niejeden raz. Trochę niżej widnieje zupełnie inny, horyzontalny dodajmy, system zakładkowy.

Oprócz braku konsekwencji, wyróżnienie aktywnego elementu jest dość mało sugestywne (o ile kolor pomarańczowy załatwia sprawę dość skutecznie, tak jasne obramowanie i wszędobylski biały niwelują pozytywne uczucie).

Na Wirtualnej Polsce nie lepiej. Powtórzony błąd z linkiem więcej. W dodatku bliskość dwóch systemów zakładek obok siebie sprawia wrażenie niezłego miszmaszu. Nie lubię powoływać się, jak już pisałem, na gadające głowy, ale jest to podręcznikowy przykład na tezy Jacoba Nielsena (które zresztą przetłumaczyłem poniżej). Na WP spróbowano też pobić rekord świata w upchnięciu jak największej treści na jak najmniejszym obszarze. Udało się to nieźle.

Poza tym, znowu zostałem zmylony brakiem AJAXa – tym razem interesująca mnie prognoza pogody została załadowana natychmiast. Zdziwiłem się także tym, że pod tabem reprezentującym pogodę nie ma oferty żarówek – tutejsza ikonka za nic nie przypomina słońca, o co, jak mniemam po głębszym zastanowieniu, zapewne chodziło autorom.

Nie lepsze są zakładki wyszukiwarek – tym razem aktywny element został wyróżniony pogrubieniem, co w połączeniu z klaustrofobiczną wręcz ilością miejsca tworzy duży chaos.

Z dziennikarskiego obowiązku wszedłem też na Interię i Gazetę.pl. W pierwszym przypadku było prawie idealnie – zachowana konsekwencja w używaniu zakładek, spójna kolorystyka i layout oraz natychmiastowe ładowanie bez AJAXa. Razić może jedynie dość niski kontrast między aktywnymi i nieaktywnymi zakładkami.

Na Gazecie jak to na Gazecie – o ile kontrast pomiędzy głównymi zakładkami jest stosunkowo mały, tak sytuację ratują duże odstępy pomiędzy nimi.

Dalej jest już mniej przejrzyście i dostępnie (najlepiej to widac w kontekście całego portalu, a nie konkretnego wycinka obrazu):

Paradoksalnie, najbardziej dostępnymi zakładkami na stronie są te:

Choć urodą i przestrzenią nie grzeszą.

Podsumowując – zakładki są skuteczne w realizacji założeń (upchanie treści w danym obszarze, czego wręcz developerzy nadużywają), jednak dobrze wykonanych tabów ze świecą szukać. Z reguły są one wręcz rozmyte z innymi elementami strony, nieprzewidywalne, mają mały kontrast, a zamieszczonej w nich treści jest o wiele za dużo.

Trzynaście przykazań

Swego czasu Jacob Nielsen popełnił 13 wskazówek co do budowania zakładek. Pozwolę sobie je przytoczyć:

• Używaj zakładek do rozróżnienia widoków tyczących się tego samego kontekstu (nie do nawigacji pomiędzy zupełnie innymi obszarami).
• Zakładki powinny logicznie dzielić treść tak, aby użytkownik z łatwością mógł się domyślić, co znajdzie pod każdą z nich.
• Zazwyczaj użytkownicy nie chcą widzieć jednocześnie treści z wielu zakładek. Jeśli ktoś chce porównać dane, przełącza się pomiędzy kartami, zapamiętując treść jednej z nich, by potem dopasować ją do danych z aktywnej zakładki.
• Zakładki nie powinny być od siebie tematycznie oderwane.
• Podświetlanie aktywnej zakładki poprzez jej rozjaśnienie jest ok, jeśli zakładek jest poniżej czterech (dla tylko dwóch tabów ciężko jest natomiast wtedy stwierdzić, która jest aktywna). Dodatkowo, możesz wyróżnić aktywną kartę poprzez zmianę jej wielkości, pogrubienie, ikonkę. Możesz ją również zaprojektować tak, by sprawiała wrażenie mieszczącej przed innymi zakładkami.
• Niewybrane zakładki powinny być czytelne i dobrze widoczne, przypominając użytkownikowi, że ma do wyboru także inne opcje. Jeśli nieaktywne karty są za bardzo “zlane” z tłem, pozostaje ryzyko, że użytkownik nigdy ich nie dojrzy, tym samym pozbawiając sie odkrycia dodatkowych opcji na Twojej stronie.
• Aktywna zakładka powinna być ściśle połączona z panelem jej contentu, sprawiając wrażenie przyklejonej. Podkreśla to, który box jest pokazywany i wskazuje użytkownikowi, która zakładka jest aktywna.

  Co więcej, ten sam kolor tła dla boxu i zakładki do niego prowadzącej wzmacnia także relację między nimi i wymusza używanie różnych kolorów tła dla nieaktywnych i aktywnych zakładek.

• Etykiety (labelki) powinny być krótkie i jasne. Ich długość powinna przeważnie wynosić od jednego do dwóch wyrazów. Krótkie nagłówki są bardziej widoczne i wpadają po prostu w oko. Jeśli potrzebujesz dłuższych jest to znak, że system zakładek to nie do końca to, czego potrzebujesz.
• Każde słowo etykiety powinno zaczynać się od dużej litery np. Biało-Czerwony Orzeł (choć biorąc pod uwagę specyfikę języka polskiego nie jest to do końca trafne założenie- przyp. ferrante). Unikaj kapitałek, które są mniej czytelne.
• Umieszczaj zakładki tylko w jednym rzędzie. Wielorzędowe zakładki wymagają “skakania” po elementach interfejsu, wprowadzając użytkownika w dezorientację. Jeśli masz aż tyle zakładek, że nie mieszczą się one w jednym rzędzie, pomyśl nad uproszczeniem designu.
• Zakładki powinny być nad boxem, nigdy pod lub z boku, ponieważ użytkownik może je przeoczyć.
• Powinno być oczywiste, jaki obszar strony jest objęty systemem zakładek.
• Pomiędzy kliknięciem w zakładkę a pojawieniem się stosownej treści nie powinno być dłuższych odstępów niż jedna sekunda (idealny czas to poniżej < 0,1s). W przeciwnym razie użytkownik nie czuje naturalnej zależności między jego ruchami myszką, a zmianą wyglądu poszczególnych tabów i paneli z treścią.

Jak widać, Jacoba Nielsena opłaca się czytać. Co więcej, ponoć większość go czyta (sic!). Szkoda jednak, że nikt przy tym nie myśli. Sam mam na swoim blogu zakładki i zaręczam Wam, to była zła decyzja. Na szczęście już wkrótce nadarzy się okazja, by to zmienić.

Pokora to jedna z największych cnót

Szafowanie szeroką gamą branżowych terminów nie czyni z Ciebie specjalisty. Spotykałem osoby, które twierdziły, że wiedzą, co to dostępność, użyteczność i inne takie… No, zresztą, sami dobrze wiecie… Większość z nich, zapytana o szczegóły, rzucała jednak podstawowymi określeniami, które można bez trudu znaleźć po 30 sekundach wyszukiwania w sieci.

Bardzo często ktoś, coś tam słyszał, jednak nie przypomina sobie szczegółów. Nielsen, Don’t let me think. A! I o niepełnosprawnych coś było! Prawie jak na lekcji biologii… Problem w tym, że tak jak lekarz podczas operacji nie sięga po podręczniki, by dowiedzieć się, gdzie mieści się serce, tak programista front-end nie myśli dwie godziny nad tym, jak działa, dajmy na to, hierarchia nagłówków.

Dlatego też o wiele bardziej cenię ludzi pokornych, którzy owszem, w trakcie boomu na użyteczność słyszeli kilka podstawowych haseł, aczkolwiek otwarcie przyznają, że nie wiedzą zbyt wiele i chcieliby poszerzyć horyzonty.

Poza tym, gro osób spod znaku doskonała znajomość HTML, XHTML, CSS oraz standardów W3C, WAI tak naprawdę, co komiczne, ma w swoim portfolio strony, które przeczą współczesnym standardom. Co więcej, pewnikiem wszyscy zrobiliśmy kiedyś jakiegoś potworka. W związku z tym, sto razy bardziej docenię osobę, która jest świadoma tego faktu, niż tę, która stwierdzi, że wszystko jest w porządku, a jej kwalifikacjami powinna zająć się najlepiej komisja złożona ze Spolsky’ego, Meyer’a, Zeldmana i innych.

To nadal jest programowanie!

Jeśli chodzi o JavaScript, zważ, że to nie tylko jQuery. Wielu programistów uważa czysty JavaScript za zupełnie zbędny, kiedy jest to podejście pozbawione sensu. Chciałbym wiedzieć, ile do powiedzenia na temat optymalizacji, closures czy programowania obiektowego mają osoby, które w swoim portfolio oceniają JavaScript na “doskonały”. Sam łapałem się na tym wielokrotnie – udało mi się napisać to i owo, dlatego myślałem, że jestem w danej dziedzinie ekspertem. Nic bardziej mylnego, języki programowania to żywy twór, który z każdym dniem odsłania nowe obszary.

Kiedyś o eventach w JavaScript wiedziałem tylko tyle, że trzeba pobrać odnośnik do DOM i przypiąć stosowną funkcję. Dziś o ból głowy (z zachwytu nad rozwiązaniami) przyprawiają mnie problemy wycieków pamięci lub zdarzeń bąbelkowych.

A gdzie mi tu Panie do zaawansowanego użycia Canvas, w którym zrobiłem bardzo mało rzeczy, aczkolwiek mam świadomość, jak to działa i wiem, że gdybym poświęcił swój czas na konkretny projekt, na pewno bym go zrobił. O ile z czystym sumieniem mogę więc stwierdzić, że nie jestem specjalistą z tej dziedziny, tak wiele osób napisałoby na Goldenline czy gdziekolwiek indziej, że Canvas wciąga uchem, kiedy tak naprawdę używała jedynie jakiegoś widgetu z Ajaxian.com.

Poznawanie zagadnień od podstaw jest bardzo ważne. Prędzej czy później trafimy na problem, któremu nie będziemy mogli podołać przez nasze zaniedbania. Pierwszy przykład z brzegu – miałem swego czasu zoptymalizować system walidacji formularzy faktur. Pozycji było ponad 30, każda z nich miała po pięć sprawdzanych informacji. Pętli były dziesiątki (setki?) tysięcy, a czas wykonywania skryptu oscylował wokół 15 sekund. Wszystko oparte było o jQuery i jQuery Validation. Dla każdego walidowanego pola frywolnie używano selektorów jak poniżej:

$('input[name^=xxx][name$=xxx]');

Przyjmując, że jQuery musi sprytnie przefiltrować wszystkie inputy, dopasowując je do podanych dwóch wyrażeń regularnych, mamy 30*5*2*600 iteracji (w dokumencie było około 600 inputów). Ciekaw jestem, co powiedziałaby osoba bez jakiejkolwiek wiedzy analityczno-algorytmicznej (choćby jak działają selektory w jQuery). Że o podstawach JavaScript nie wspomnę.

Pomyśl też, co stałoby się, gdybyś musiał napisać coś w MooTools lub Prototype?

Staranność

Nie rób w kodzie bałaganu, pod żadnym pozorem. Nieważne, czy zaczynasz duży czy mały projekt. Nazywaj klasy i identyfikatory zgodnie z przyjętą przez Ciebie konwencją. Żadnych test3, somethingExampleHehe i innych potworków. Nie pisz skryptów na szybko, bez dobrego formatowania i logicznego nazewnictwa zmiennych. Utrzymuj porządek w sekcji head dokumentów, jak i w folderach z plikami źródłowymi. Przyjmij konwencje nazw katalogów, w których trzymasz pliki css, js i obrazki.

Otaczaj skrypty JS anonimowymi funkcjami, tak, by nikt nie nadpisał Twojego kodu:

(function() {
// Twoj kod...
})();

Niestety, programowanie stron niesie ze sobą wiele pułapek, a jedną z nich jest skłonność do powstawania bałaganu. Wielokrotnie widziałem zdublowany kod, puste deklaracje w CSSach i wiele innych niedoróbek. Znając życie, większość pochodzi z czystego pośpiechu. Osobiście, często robiłem coś na szybko, dodawałem style inline, by sprawdzić, jak coś się zachowa, mimo że miałem do dyspozycji debugger. CSS i JS są bardzo czułe na fuszerkę, dlatego unikaj kompromitacji, nawet, gdyby praca miała potrwać 10 minut dłużej.

Zdarza się również, że mozolnie szukamy rozwiązania, dajmy na to pod IE, dopisując coś i skreślając w kodzie, a także pisząc na szybko różne nazwy zmiennych, typu some, x, aaa itd. Gdy dochodzimy do celu, zapominamy o sprawie, skoro “jest zrobione“. W efekcie w kodzie pozostaje bubel, który będzie nielogiczny dla programistów edytujących kod w przyszłości. Zmusi ich to prawdopodobnie do kontynuowania złej konwencji i dalszego brudzenia, bo przecież nie będę się doczytywał, o co temu kolesiowi chodziło.. Nie zostawiaj po sobie kodu, którego sam nie zrozumiesz za miesiąc.

Debugger i dobre narzędzia wspomagające to świętość! Dowiedz się, co to Firebug, WebDeveloper, Live Headers, Pixel Perfect, IE Tab, HTML Validator, czy Firecookie. Przeglądaj często stronę z rozszerzeniami do Firefoxa. A nuż wyjdzie coś interesującego!

Frameworki CSS to nie do końca trafiony pomysł, jednak przydatny w pewnych okolicznościach. Przeanalizuj dokładnie wady i zalety takiego rozwiązania, zainteresuj się resetami CSS czy też projektami typu 960 grid system.

Typografia potrafi być ciekawa, a XHTML ma wady, więc bądź ostrożny.

Rozwój osobisty

Nikt nie jest alfą i omegą. Nie zniechęcaj się tym, że wielokrotnie podczas pracy używasz Google. Zapamiętywanie hacków, czy też bugów przeglądarek jest pomocne, lecz nie jest to najważniejsze. Wystarczy, że znasz i kojarzysz problem. Rozwiązanie to tylko kwestia doboru środków.

Czytaj książki. O sieci pisze się tyle ciekawych rzeczy! Nie przeczytasz ich na żadnej stronie internetowej. Luke Wroblewski, Joel Spolsky, Eric Meyer, Jakob Nielsen, Louis Rosenfeld, Dean Clarke to tylko czubek góry lodowej nazwisk, które szanujący się developer powinien znać. Czytanie zagranicznych pozycji to nie moda, lans czy cokolwiek innego – to polepszanie swoich kwalifikacji. Biorąc pod uwagę, że w sieci są prawdopodobnie tysiące koderów z szablonu (CSS, HTML, JS), zatrudniłbym kogoś, kto po prostu wie więcej.

Jeśli nie znasz z kolei jakiejś pozycji, przyznaj to otwarcie, zamiast szukać okrężnej drogi w swoich tłumaczeniach. Nie znać “X” czy “Y” to nie wstyd, acz argument do dalszej nauki i sztuki poznania. Osobę, która próbuje podjąć dyskusję na temat, o którym nie ma żadnego pojęcia, z reguły można rozpoznać po kilku sekundach. Pamiętaj o tym.

Staraj się czytać blogi, choć zważ na to, że nie jest to żaden wyznacznik Twojej wiedzy, o czym nieliczni próbują przekonywać. Jeśli blogi, to nie tylko polskie (tym bardziej, że bardzo mało jest tych wartościowych). O JavaScript absolutnie fantastyczne rzeczy tworzy John Resig (twórca jQuery), jest genialny Dean Edwards, Paul Bakaus, Valerio Proietti. To tylko kilka nazwisk, bo o JS i CSS piszą tysiące osób. Bardzo pomocne są też serwisy typu A List Apart czy też Ajaxian.com, gdzie zgromadzone są najnowsze wiadomości i projekty z branży.

Zauważ, że posiadanie sprzętu Apple lub pisanie Twittera/Blipa nie czyni Cię specjalistą. Wiedz, że na Macu nie zobaczysz 64-bitowej palety kolorów, a to że Zeldman twitteruje nie robi Cię jego kumplem od wódki. Jeśli mimo wszystko stawiasz powyższy fakt za swoje ewidentne zalety, powinieneś zaznajomić się ze znaczeniami ekshibicjonizmu i jego pochodnymi.

Ucz się języka obcego, najlepiej angielskiego. Większość ważnych rzeczy mówi się tutaj w języku Szekspira. W prestiżowych firmach komunikacja z klientem bardzo często odbywa się po angielsku. Z kolei, jeśli Twoje aspiracje sięgają naprawdę wysoko, raczej nie dosięgniesz nieba w Polsce. Niestety, pierwsza liga front-endu gra za granicą. Sam fakt, jak mało mają tam do powiedzenia Polacy, świadczy o tym, że możemy traktować nasz kraj jako branżowy zaścianek.

Bądź krytyczny i szczery w swoich osądach, nie bój się wyrażać własnych opinii. Jeśli projekt dyskutowany jest pod kątem dziedziny, w której jesteś ekspertem, narzuć swoje zdanie i przede wszystkim przedstaw stosowne argumenty. Broń swojej wiedzy! Kto ma wiedzieć cokolwiek o dostępności, jak nie specjalista front-end? Oczywiście, sugestie innych osób są cenne, jednak ostateczne zdanie powinno należeć do Ciebie.

Fajne rzeczy o rozwoju osobistym pisze Alex Barszczewski.

Użyteczność

Sądzę też przekornie, że użyteczność to jedna z największych pułapek, jakie wyprodukował webdevelopment w ostatnich latach. Podstawowe terminy użyteczności stron www są jak najbardziej zasadne, jednak im dalej w las, tym więcej drzew. Tak naprawdę, wiele aspektów użyteczności jest sprawą dyskusyjną i to, dlaczego, przyjmijmy umownie, link jest czerwony, a nie niebieski, w gruncie rzeczy determinuje kontekst, zamierzony cel i dziesięć innych czynników, których nie znajdziemy w szablonowych książkach o usability.

Jest to działka, w której najwięcej mają do powiedzenia krzykacze. Ubzdurało im się, że znają się na użyteczności, bo przeczytali kilka mądrych książek. Większość sporów o usability danego elementu na stronie można podważyć “pierwszą lepszą” publikacją książkową. Dlatego też najgorsze argumenty, jakie możesz użyć w dyskusji o usability, tyczą się fanatycznego powoływania na konkretnego autora i rzekomego specjalisty od użyteczności. Nikt jeszcze nie wymyślił złotego środka, a książki o usability wskazują jedynie na najpopularniejsze problemy!

Przede wszystkim radzę myśleć! Użyteczność to nie proste regułki. To nie wersety z książek, które często powielają banały lub które są po prostu słabe (vide publikacje Kasperskiego). Nie idź na łatwiznę. Dopatruj się kontekstu, przeprowadzaj testy z użytkownikami, dyskutuj z kolegami po fachu! Nie ma nic bardziej zbawiennego, niż solidna burza mózgów, poparta konkretnymi argumentami merytorycznymi. Wiele publikacji aspiruje do bycia tak uniwersalnym, jak tylko sie da. Nie daj się nabrać, tym bardziej, że jest to ostatnio niezwykle chwytliwy temat. Specjalistów od użyteczności przybywa niczym cinkciarzy pod Pewexem, dlatego powtórzę jeszcze raz – myśl!

Prototypowanie

Doceń prototypy i testy z użytkownikami. Muszę stwierdzić, że wcześniej rzadko korzystałem z papierowych bądź elektronicznych prototypów. Designy od początku do końca projektował dla mnie grafik, zgodnie ze słownymi wytycznymi. Jakież to amatorskie podejście! Profesjonalny projekt powstaje stopniowo. Najpierw pracuje się nad wymaganiami, potem wkracza front-endowiec, który ma za zadanie przedstawić prototyp funkcjonalności strony. Nie projektuje on designu, ale ustala layout, rozmieszczenie buttonów, warstw, menu i wszystkiego, co tyczy się www. Przy okazji projektuje on większość aspektów użyteczności strony. Prototyp ułatwia pracę wszystkim – klientowi, designerowi, back-endowi i Tobie oczywiście. To na etapie prototypu powinny być wyjaśniane wszystkie wątpliwości. Tutaj ustalany jest ostateczny, podkreślmy to, kształt aplikacji. Wszystko po to, by potem zająć się tylko i wyłącznie kodowaniem oraz testowaniem.

Profesjonalne prototypy można tworzyć np. w Axure.

Prawdopodobnie to nie wszystko, co można by napisać na ten temat. Uczymy się jednak na błędach, a kolejne akapity dopisze życie, z pewnością…

Jawa czy sen?

By podejść do tematu z lepszej strony, zobaczmy, jak (w dużym uproszczeniu) wygląda development w JAVA. Mamy kompilator. Mawia się, że najpierw był kompilator, a dopiero potem wszystko inne. Tak naprawdę jednak jest to wręcz niebagatelne przyspieszenie pracy. Większość błędów programisty wykrywa właśnie on, dlatego na ewentualny debug kodu poświęca się naprawdę mało czasu. Aplikacje po prostu działają.

Z kolei system wyjątków pomoże nam w tym, czego nie zrobi kompilator Możemy z łatwością wyłapać niestandardowe zachowania programu i stosownie je obsłużyć. Całość dopełnia fakt, że JAVA jest w pełni obiektowym językiem – rzadko zdarza się (wcale?), że kod napisany w jednym miejscu, nadpisuje inny. Hermetyzacja robi swoje.

Do skutecznego i łatwego deploymentu, szybkiego uruchamiania projektów, czy po prostu utrzymywania ich mamy takie narzędzia, jak choćby Maven, Ant , czy Log4J.

Domek z kart

Jeśli chodzi o CSS i XHTML, wspierane przez JavaScript, można odnieść wrażenie, że to klocki, z których możemy coś poskładać, aczkolwiek nie możemy być pewni, czy w przyszłości nie trafi się element, który zburzy nam mozolnie tworzoną budowlę.

O ile CSS i XHTML współpracują ze sobą dość dobrze, tak JavaScript sprawia wrażenie przyszywanego wujka. Przede wszystkim, w JS pokutuje prawie to samo, co w PHP – naciągana obiektowość. Teoretycznie JavaScript jest obiektowy, ale by osiągnąć dziedziczenie, czy też ścisłą kontrolę dostępu trzeba postarać się o naprawdę wymyślny kawałek kodu, który w znacznej mierze trąci zawodami w hakowaniu, bądź konkursem na długość przyrodzenia. Dość powiedzieć, że dziedziczenie można uzyskać niejedną metodą, a każda różni się dość znacznie od poprzedniczki. Mawiają, że z gówna bata nie ukręcisz, jednak w JavaScript udaje się to bez problemów. Nie będę nawet wspominał o tym, że deklaracja klasy odbywa się poprzez function.

„Skopaną” konstrukcję poznajemy po tym, że wystarczy uszkodzić jeden element, by całość legła w gruzach w mgnieniu oka. Podobnie jest z JS. Niedostatki obiektowości powodują, że nie mamy choćby kontroli typów, przez co mnożą się instrukcje warunkowe, wspomagane przez typeof.

Kompilator

Za kompilator robią tutaj z reguły konsola błędów oraz narzędzia typu Firebug. Co to jednak za pomoc, skoro w gruncie rzeczy sami musimy analizować kod i czaić się na potencjalne błędy, używając call stacków (polskie „czujki”).

Pierwszy z brzegu przykład:

• JAVA:

  String foo = "string";
  int bar = 0;
  bar = foo+10;

• JavaScript:

  var foo = "string";
  var bar = 0;
  bar = foo+10;
  alert(bar); // daje "string10"

W pierwszym wypadku kompilator JAVA zgłosi niezgodność typów. Natomiast JavaScript z łatwością przepuści taką operację. To tylko wierzchołek góry lodowej problemów, z którymi stykamy się na co dzień. Zapewne większość z Was nieraz wyrywała sobie włosy z głowy, przytłoczona poszukiwaniami pod tytułem “gdzie to cholerstwo schowało się w IE” lub “dlaczego pod Fx jest null, a gdzie indziej, powiedzmy, 31137“. Można rzec, że taka jest już cecha języków skryptowych – ewentualne błędy wychwycić można dopiero po uruchomieniu całego programu. Programiści najbardziej chwalą je ze względu na szybkość. W przypadku JavaScript nie jest to najtrafniejszy argument – już 300 tysięcy iteracji potrafi zawiesić przeglądarkę.

Istotną wadą JS jest jego permanentna zależność od czynników zewnętrznych. Jesteśmy narażeni na skutki niepoprawnej implementacji ECMAScript (i DOM) przez przeglądarki, a następnie na przydział zasobów systemowych dla nich.

Mimo że w JavaScript można zrobić naprawdę wielkie rzeczy, to język przypomina raczej prototyp niż finalną wersję. Razi też jego mała integracja z HTML (XML) jako takim. W końcu JavaScript to interpretacja ECMAScriptu w założeniach ściśle związana z webem. Dlaczego przeglądarka dopuszcza document.getElementById(‘foobar’), kiedy w dokumencie nie ma żadnego elementu o takim identyfikatorze? W gruncie rzeczy, powinniśmy być ostrzegani przed taką ewentualnością. W jaki sposób?

Kłania się potrzeba kompilatora lub czegoś w tym rodzaju. Najlepiej byłoby, gdyby tłumaczył on kod JS na inny, ściśle znany tylko przeglądarce. Tylko skompilowany program mógłby zostać użyty na stronach internetowych. W innym wypadku, dołączenie plików “przypominających” poprawny JS byłoby niemożliwe.

Na pewno uniknęlibyśmy wielu błędów. Z pewnością devlopment zostałby również przyspieszony. Podejrzewam też, że szybkość wykonania programów w JS (bo już nie skryptów) byłaby o wiele większa, niż jest ona obecnie. Z drugiej strony, kod zostałby zamknięty na zewnątrz.

Standaryzacja!

By sen się ziścił, potrzeba klarownych reguł języka. JavaScript musi stać się w pełni obiektowy. Również relacje z HTML powinny być o wiele bardziej zacieśnione. Nie ukrywajmy tego, skoro w JavaScript istnieje obsługa DOM, dlaczego jeszcze bardziej nie popchnąć języka w tę stronę? Przecież większość skryptów odnosi się do struktury dokumentów HTML!

Pisałem to już jakiś czas temu, napiszę jeszcze raz:

Ta jedyna w swoim rodzaju zależność języka od czynników zewnętrznych (przeglądarki) skazuje JavaScript na dość powolny i niejednostajny rozwój. Pozornie specyfikacja jest taka sama dla wszystkich, jednak szybkość działania diametralnie różna

JavaScript 2

Sytuację próbuje ratować JavaScript 2, bazujący na ECMAScript 4. Pojawiają się deklaracje klas, typizacja, specyfikatory dostępu i wszystko inne, czego dobry programista mógłby sobie zażyczyć. Niestety, i tutaj musiała znaleźć się łyżka dziegciu. JavaScript 2 ze względu na taką, a nie inną obiektowość, jest praktycznie niekompatybilny wstecz. Biorąc pod uwagę miażdżącą popularność JS 1.* w internecie, nie wyobrażam sobie wejścia na rynek JS 2 bez zgodności wstecznej. Na to z kolei dość krzywym okiem spoglądają producenci przeglądarek.

Mamy tutaj dwa wyjścia – wprowadzić JS2 ze wsteczną kompatybilnością lub bez niej. Pierwsze wyjście może przypominać analogiczną sytuację z PHP4 i PHP5 – było niby świeżutkie i piękne PHP5, jednak proces migracji na nową platformę trwał latami. Boje się, że w przypadku JavaScriptu będzie podobnie – po co uczyć się nowej składni (a propos składni, wkrótce postaram się omówić nowe elementy JavaScript 2), skoro stara jest prosta i, co najważniejsze, działa?

Rewolucja pożera własne dzieci

Powyższa sytuacja obrazuje tak naprawdę, gdzie stoi dziś programowanie front-endu, a gdzie może być w przyszłości. Prawdopodobnie pomiędzy drugą a trzecią literką słowa web 2.0 zatraciliśmy, nie ukrywajmy, zdroworozsądkowy krytycyzm. Tworzymy standardy, propagujemy semantyczną sieć, jednak wydaje się, że reformować system powinniśmy od korzeni. Po co tworzyć 100 standardów, z których każdy mówi o zupełnie innym zagadnieniu. Robimy strony, używając w większości tych samych technologii – dlaczego z każdym rokiem nie konsolidujemy ich ze sobą, a wymyślamy ich nowe, niezależne definicje, które powodują 100 razy więcej problemów?

Już na samym wstępnie trzeba zaznaczyć, że rewolucji nie ma. Postanowiono podeprzeć się chwytliwymi terminami, które ze stanem rzeczywistym mają naprawdę mało wspólnego. Otóż Pani Sullivan oparła swój manifest OOCSS na dwóch tezach:

• Oddzielmy strukturę od wyglądu
• Oddzielmy layout (kontenery) od treści

Pozwolę sobie przetłumaczyć część pobudek, którymi kierowała się autorka, wymyślając OOCSS:

By zobrazować moją tezę piszę odpowiedniego frameworka, przede wszystkim jednak OOCSS jest zupełnie innym podejściem do CSS i kaskadowości. Bazuje na tradycyjnych dogmatach programowania, takich jak rozszerzalność obiektów, modułowość i przewidywalność kodu. Zaproponowane rozwiązania ocenione zostały przez pryzmat ich złożoności, innymi słowy: „co stanie się z wielkością Twojego CSS po dodaniu nowych stron i modułów?”.

Odpowiedzią na to pytanie jest dla wielu stron wymykający się spod kontroli rozrost kodu (spaghetti code), powodujący problemy z jego utrzymaniem. Ludzie często narzekają na CSS i słusznie – mimo że często jest to zwykłe pieniactwo, rozumiem ich frustracje.

Obecne metody pisania CSS wymagają od developera dużej wiedzy. By mianować się ekspertem CSS, trzeba spędzić wiele lat na kodowaniu. Nim nasz kod stanie się użyteczny, musimy okupić to nauką na własnych błędach. Proces developmentu we front-endzie skupia w sobie specjalistów na wielu poziomach wiedzy i obowiązków, mimo to nasze strony są niczym kolos na glinianych nogach. Możesz mieć świetnie dopracowaną dostępność, czy bezbłędny kod, ale kiedy dosiada się do niego ktoś zupełnie z zewnątrz, wszystko pada na łeb i szyję. Kod powinien być na tyle solidny, by nawet osoba nie znająca tajników CSS mogła w nim odnaleźć się bez problemów i złowieszczego wpływu na standardy kodowania, które przyjęliśmy wcześniej.

I tak, powstało 10 dobrych praktyk:

• twórz reużywalne komponenty
• używaj konsekwentnie stylów w zależności od semantyki – nie rób na jednej stronie nagłówka pierwszego stopnia, który raz jest zielony i 12-pikselowy, a raz niebieski i 15-pikselowy
• używaj zrozumiałych nazw dla innych
• bądź elastyczny
• naucz sie kochać siatki
• nie nadużywaj zbędnych selektorów
• oddziel wygląd od struktury kodu
• oddziel layout od treści
• rozszerzaj style elementów poprzez nadawanie im kolejnych klas
• Używaj resetów CSS z Yahoo UI

Mamy również 9 zagrożeń, których powinniśmy unikać jak ognia:

• style zależne od lokalizacji
• łączenie stylów z konkretnymi tagami np. div.someClass {}
• łączenie stylów z konkretnymi identyfikatorami np. #someID {}
• umieszczanie cieni i zaokrąglonych rogów na różnorodnych tłach
• nadużywanie metody sprite dla obrazków (chyba ze mamy bardzo mało stron w projekcie)
• dostosowywanie wysokości
• używanie obrazków zamiast tekstów
• nadmierna ilość kodu
• pochopna optymalizacja

Bazując m.in. na nich, Nicole opublikowała framework CSS, opierający się na rozszerzalnych gridach oraz rozdzieleniu layoutu od treści i wyglądu od struktury kodu. Mamy więc stosowne grids.css, content.css i libraries.css (reset). Według frameworka OOCSS można stworzyć np. taki kod:

<div class=”line”>
	<div class=”unit size1of2 rss”> </div>
	<div class=”unit size1of2 gmail lastUnit”> </div>
</div>

który da nam jeden poziomy kontener (class=”line”),a w nim dwie sąsiadujące kolumny, mające 50% całej szerokości rodzica (size1of2). Mniej więcej na tej podstawie, autorka zaleca budowanie naszych stron – dzięki reużywalnym komponentom, takim jak choćby te zaprezentowane wyżej, powinniśmy budować wszystkie kontenery – w imię zasady, że większość z nich ma wspólne cechy. Zaleca się więc, by to kontenery (grids) definiowały szerokość, a zawarte w nich elementy contentu – wysokość (paddingi, marginesy, heighty). Do tego dochodzi customizacja przez dodawanie nowych klas do tagów, jeśli standardowy package jest niewystarczający. W gruncie rzeczy dobry pomysł – nie musimy przecież sugerować się zaproponowanymi przez autorkę szerokościami, wyglądem i czymkolwiek innym – framework ten ma ukazać, jak można wdrożyć w życie koncept OOCSS.

Trzeba uczciwie przyznać, że większość powyższych tez istnieje w świadomości koderów od kilku dobrych lat. Mimo to tylko nieliczni developerzy używają łatwych w utrzymaniu technik CSS. O ile więc nazywanie czegoś mianem „OOCSS” jest raczej żartobliwe w kontekście tego, co ten termin definiuje (przerost formy nad treścią!), tak nazwa ta swoimi gabarytami niepokojąco sugeruje, że należałoby rozważyć problemy, którym OOCSS stara się postawić.