Semantyczna sieć a webdevelopment

Na początku powinienem się do czegoś przyznać. Moje oświadczenie idealnie mogą odzwierciedlać słowa utworu “Nie jestem punkiem” pana Dariusza Paraszczuka, co w moim wykonaniu zabrzmiałoby jakoś tak:

Nie jestem webdeveloperem i nigdy nie byłem,
i nigdy tego przed wami nie kryłem.
Nie jestem webdeveloperem, co nie oznacza,
że nie popieram lub mi uwłacza.

Nie jestem webdeveloperem i być nie chciałem,
bo się po prostu nie nadawałem.
Więc skojarzenia są bezpodstawne,
nie sprawiedliwe no i zabawne.

Nie jestem webdeveloperem i nigdy nie byłem,
chociaż go czuję i blisko z nim żyję.
Nie jestem webdeveloperem i być nie mogę,
bo inną w życiu obrałem drogę.

To tyle w kwestii wstępnego wyjaśnienia. Nie jestem webdevelperem i nigdy nim nie byłem, co nie oznacza, że nie miałem z nim do czynienia i nie znam wielu panujących w tym środowisku standardów oraz dobrych praktyk. Chciałbym się jednak podzielić swoimi odczuciami i uwagami, jakie mnie od jakiegoś czasu nachodzą, a momentami nawet dręczą.

Kiedy z jakiś powodów, głównie niezależnych ode mnie, wracam na krótką chwilę do “webowego developmentu”, staram się poznać trendy i zmiany, jakie zaszły w tym środowisku od ostatniej mojej styczności. A tych zmian zawsze jest dużo, sieć się szybko zmienia i ewoluuje. Powstaje dużo narzędzi ułatwiających prace - kiedyś nikt nawet nie śnił o takich inicjatywach jak HTML5 Boilerplate czy Twitter Bootstrap. Standardy i specyfikacje się rozszerzają, obecnie coraz więcej da się zrobić w przeglądarce za pomocą HTML5, CSS i JS. A kiedyś trzeba było stosować różne sztuczki i kruczki…

Za każdym razem jednak odczuwam, że w sieci nadal panuje wielki burdel. Od dawna próbowano zbudować lepszy web. XHTML miał pomóc zunifikować kontent pałętający się po sieci, ułatwiając jego przetwarzanie, a także rozdzielając widok od treści. Mimo, iż mamy obecnie HTML5, ludzie nadal nie potrafią dobrze z niego korzystać. Semantyczna sieć przyszłości chyba nadal jest naiwną mrzonką, gdyż ponad połowa sieci i developerów ma ją w głębokim poważaniu.

W latach 90-tych i na przełomie milenium borykaliśmy się z falą budowania stron i aplikacji z niepoprawnym wykorzystaniem elementów języka HTML i CSS. Głównie objawiało się to bazowaniem na tabelkowych layoutach. Wyrośliśmy z tego i przeszliśmy ku większemu rozdzieleniu treści od wyglądu oraz bardziej poprawnym wykorzystywaniu, zgodnie z ich przeznaczeniem, elementów HTML-owych. Poznaliśmy podstawy semantyki, a developerzy nauczyli się, że tabelka służy do prezentacji tabelarycznych danych, a nie traktowania jako fundament całej strony.

Mimo, iż obecnie aplikacje webowe i witryny budowane są z wykorzystaniem bardziej odpowiednich elementów - div + CSS, to tamten problem odrodził się w nieco innej odsłonie. Uwidacznia się on tym, że pomimo ładnego sklejania strony na divach, semantyka nadal kuleje. Ponad większość stron dostępnych w sieci zawiera niezłą papkę tagów. Tym razem treść opakowana jest nadmierną ilością kontenerów i CSS-owych klas - ot nowy wymiar sieci. Twory takie posiadają zerową użyteczność, pomimo tego, że całościowo i wizualnie prezentują się bardzo ładnie, a nawet oszałamiająco.

Używanie diva jako jedynego taga, którym emulujemy inne elementy jest chore. Wiele razy spotkałem się ze stronami, gdzie to właśnie kontenerami budowano wszystkie możliwe konstrukcje, często zbliżone do list, czy tabelek. Jeśli dane reprezentują listę powinno się wykorzystać dedykowane do tego elementy dostępne w HTML, przecież mamy od groma różnych typów list. Podobnie jest z tabelkami. Należy głośno powiedzieć: tabelki nie są złem, analogicznie jak konstrukcja goto w językach programowania. Trzeba tylko wiedzieć jak ją dobrze i poprawnie wykorzystać. Niestety, niektórzy chyba mają problem z rozróżnieniem typu danych i usilnie pakują je w kontenery przedstawiane w formie tabelki.

Braki w semantyce implikują problemy z użytecznością. Zupa tagowa, brak odpowiedniej struktury strony z nagłówkami i paragrafami… dla osób, które z różnych powód nie korzystają lub nie widzą efektu działania styli CSS (wyłączyli je, korzystają z odpowiednich czytników dla niewidomych) z takiej strony niczego się nie dowiedzą. Zawartość takich stron wygląda dla nich jak zlepek zdań, wyrazów, czasem nawet nie mających sensu (vide dane tabelaryczne prezentowane w tabelce zbudowanej na divach).

“Myślenie nie boli” - wystarczy się tylko zastanowić!

Weźmy sobie jako przykład logo firmy w nagłówku strony, które w większości przypadków jest odnośnikiem do głównej strony. O tym akurat wszyscy wiedzą i takie działanie przeszło już do kanonu. Podobnie jest z wpakowaniem tego obrazka do arkusza styli, a nie treści strony. To już jest plus, ale dlaczego od razy nie zawrzeć tego linka w nagłówku pierwszego stopnia, wskaże jest to elementem najwyższego poziomu w strukturze dokumentu? Idąc dalej, czemu nie dodać w tym linku lub nagłówku jakiejś treści - nazwy strony, firmy. Treść tą następnie za pomocą prostych zabiegów w CSS można “wyłączyć” lub ukryć. Co to da? Da to wiele - strona zachowa swoją strukturę dokumentu, trochę semantyki, zwiększy usability, i wszyscy będą zadowoleni.

To wszystko jest naprawdę proste!

Wszystkie elementy odpowiadające za wygląd powinny się znaleźć w arkuszu styli CSS. Strona z wyłączonymi stylami powinna ładnie odzwierciedlać logiczną strukturę dokumentu. Poprawna struktura strony jest jej podstawowym fundamentem. Należy wykorzystywać w niej odpowiednie do tego celu elementy języka HTML, takie jak header, h*, p, a article, section, footer, …

Dopiero po zbudowaniu struktury dokumentu przystępujemy do konstruowania i dostosowywania arkusza styli, aby taką prostą i przejrzystą stronę przedstawić według założonego projektu designu. Ingerując w stronę jedynie za pomocą pomocniczych elementów takich jak div i span, i to jedynie tam, gdzie jest to faktycznie konieczne. Nigdy na odwrót! Nie należy dostosowywać kontentu i struktury dokumentu pod wygląd.

Oczywiście w pewnych znikomych sytuacjach, czasem nie da się wszystkiego załatwić CSS-em i trzeba pewne elementy struktury strony odpowiednio ułożyć, ale takie sytuacje zdarzają się naprawdę rzadko.

Niestety w prawdziwym świecie, gdzie liczy się szybki zarobek i jak najmniejszy czas poświęcony na projekt, upłynie jeszcze wiele czasu zanim cokolwiek się zmieni. Czy doczekamy się kiedyś semantycznej sieci?

Pocieszeniem może być to, że niektórzy, w tym także wielkie firmy, dostrzegają ten problem i widzą potencjał w semantycznej sieci, a tym samym starają się tworzyć swoje dzieła zgodnie z tą ideą i sztuką. Oby takie posunięcia były coraz częstsze, a ludzie tworzący sieć starali się bardziej, ku lepszej przyszłości.

To tyle w tym temacie, który zaczął się od tego, że sam obecnie tymczasowo pracuję jako webdeveloper przy prostej aplikacji webowej. Zajmuję się takim tam prostym webowym panelem od strony klienta i administratora, wraz z infrastrukturą i serwisami/agentami nadzorującymi i zarządzającymi farmą serwerów, w jednym naszym start-up-owym projekcie. Przy okazji rozwijając mój stary, ale prosty micro-framework implementujący w jakimś stopniu MVC w PHP.

I tutaj też mnie zastanawia kilka kwestii, m.in. dlaczego nikt nie buduje modułów PHP w C/C++, które poprawiłyby wydajność wielu aplikacji webowych. Bo po co trzymać PHP-owy kod fundamentu (np. farmewroka, core, engine) i tracić na czasie i wydajności ciągłego jego przetwarzania, a nie zrobić tego natywnie. Przecież te fundamenty w danych projektach się prawie wcale nie zmieniają, są tylko wykorzystywane niczym zewnętrzne, trzecie elementy lub narzędzia. Ale to inna bajka, o której opowiem może następnym razem…