Dziś, drodzy zgromadzeni, profesor Pimpin pokaże wam, jak ważne jest rozdzielenie wyglądu i treści.

Profesor Pimpin
Profesor Pimpin przy pracy.

Jako, że od pewnego czasu mój pracodawca zleca cięcie części projektów webmasterom zewnętrznym (outsourcing jest jazzy), oszczędza nam to dużo czasu, który możemy poświęcić na programowanie silników PHP... albo na ponowne cięcie wyżej wspomnianych projektów.

Problem z outsourcingiem polega na tym, że wszyscy zarzekają się, że są istnymi geniuszami, a ich praca warta jest każdych pieniędzy. Dziesiątki, ba - nawet setki, lat w braży, tysiące projektów na karku, pełen profesjonalizm. Rzeczywiście, ostatnio dostałem do ręki projekt wykonany z pozoru bez zarzutu. Szybki rzut okiem do kodu źródłowego ujawnił tylko kilka usterek, ale szablony zostały przygotowane zgodnie z XHTML 1.1 i bez użycia tabel.

Później jednak zainteresował mnie jeden z formularzy, gdzie przycisk wysyłający dane niebezpiecznie nachodził na dolną krawędź fieldsetu. Nic to, pomyślałem, i zająłem się swoją pracą, czyli powoływaniem owego cuda do życia. Mniej-więcej w połowie podłączania szablonów do swojego systemu CMS zapragnąłem zmodyfikować podpis wspomnianego formularza, gdyż do granic eksploatowane przez nas lorem ipsum zdawało się niewiele mówić przeciętnemu odwiedzającemu serwis. Podmieniłem przeto tekst na nieco inny i w tym miejscu szczęki moje rozwarły się by tak pozostać na czas dłuższy. Tekst, owszem, wydłużył się, jednak ostatnie pola formularza znalazły się już daleko za nim, nie wspominając o przycisku, który już wcześniej leżał na dolnej krawędzi. Obecnie przebywał prawdopodobnie około 200 pikseli niżej, niestety nie mogłem tego zweryfikować, gdyż wylewająca się treść formularza była skrupulatnie przykrywana przez inny boks na stronie.

Webmaster tnąc szablony sugerował się projektem i konkretnymi tekstami zastępczymi, jakie zostały tam umieszczone. Cały boks formularza był tak naprawdę namalowany na jego tle, więc wydłużenie jego zawartości spowodowało wylanie się treści poza widoczne pod spodem ramki. Myślenie o designie w kontekście konkretnej treści jest jednym z największych błędów popełnianych przez niespecjalnie doświadczonych webmasterów. Robienie stron na własne potrzeby nie wymaga specjalnej elastyczności - gorzej, kiedy klient postanowi zastąpić proponowane treści własnymi. W końcu to jego serwis i po to właśnie kupił od nas system zarządzania treścią.

Drugi problem dotyczący wspomnianego serwisu to skrypty JS i ich przywiązanie do szablonu. Odpowiedzialne są one za podświetlanie przycisków i podpowiedzi w formularzach. Wszystko działało bez zarzutu do czasu, kiedy zostaliśmy zmuszeni dodać na jednej z podstron kolejny formularz i kiedy to okazało się, że jest to dość trudne. Skrypty, co prawda, znajdowały się w zewnętrzym pliku, ale uparcie wyszukiwały w nim konkretne przyciski i konkretne pola formularzy. Wymusiłoby to na nas dopisywanie obsługi każdego formularza, każdego jego pola i wszystkich nowych przycisków do pliku ze skryptami. W końcu zdecydowałem się zrezygnować z zaproponowanego przez autora rozwiązania (co było samo w sobie dość problematyczne ze względu na bliskie powiązanie ich z funkcjonalnością serwisu) i skorzystać ze sprawdzonych wielokrotnie skryptów własnego autorstwa, o których pisałem w lipcu.

Podsumowując - czas oszczędzony na traktowaniu layoutu dosłownie (z dokładnością do piksela) to czas, który trzeba - prędzej czy później - z nawiązką włożyć w ponowne przeprojektowanie szablonu, kiedy treść przestanie spełniać jego oczekiwania (choć powinno być odwrotnie, to szablon powinien być dla treści, a nie treść dla szablonu).

Na koniec drobna dygresja - bardzo kiepskim pomysłem jest tworzenie graficznych przycisków formularzy poprzez wymuszenie pustego napisu na przycisku i zastąpienie jego tła obrazkiem. Kiedy - podczas testów wspomnianych szablonów - na próbę zablokowałem arkusze CSS, moim oczom ukazały się niewiele mówiące szare kwadraciki. Nie muszę chyba pisać, że nie budziły skojarzeń ze słowami typu przelicz czy wyślij. Czasem pomysłowość w stosowaniu CSS mnie przeraża, zwłaszcza że istnieje <input type="image" />...