Wyrzucanie tabel przez okno

Informacja

Poniższy tekst to przekład artykułu Douglasa Bowmana "Throwing Tables Out the Window", opublikowanego w serwisie Stopdesign.

Fallowing text is a translation of Douglas Bowmans article "Throwing Tables Out the Window" published at Stopdesign.

Zobacz mamo, nie ma tabel!

Ci, którzy byli na konferencji Digital Design World w Seattle w tym roku, widzieli moją prelekcję zatytułowaną "No More Tables, CSS Layout Techniques" ("Nigdy więcej tabel, techniki tworzenia layoutu przy użyciu CSS"). Podczas tej sesji przeglądnęliśmy prawidłowe zastosowania tabel w projektowaniu stron www. Było też kilka wskazówek na temat tworzenia ich w CSS. Następnie przeszliśmy do modelu beztabelarycznego, zagłębiając się w przykłady i prezentując zarys dwóch podstawowych podejść do tego zagadnienia (pozycjonowania - ang. positioning i osadzania - ang. floats).

W połowie prezentacji, ogłosiłem, ze teraz przystąpimy do konwersji z życia wziętego przykładu. Witrynę opartą na tabelach, wykorzystującą do tworzenia odstępów GIF-y, zamienimy w całkowicie czysty wystrój graficzny oparty o CSS. Oczywiście mogłem stworzyć fikcyjny przykład do użycia podczas tej prezentacji. Lecz pomysł ten byłby zbyt sztuczny. Gdybym stworzyłbym własny przykład, byłby on najpewniej ładny i schludny. Wszystkie przekształcenia dokonałyby się, tak, jakbym tego chciał. Uniknąłbym stawiania czoła problemom, którym już wcześniej wiedziałbym jak podołać.

Miałem ochotę na prawdziwe wyzwanie. Wybrałem witrynę małej, lokalnej firmy mieszczącej się w pobliżu Seattle i pomyślałem, że kilku moich słuchaczy może być dobrze obeznana z:

W porządku. Może więcej niż kilku słuchaczy dobrze zna tą niezbyt małą firmę. Wielu użytkowników odwiedza witrynę domową Microsoftu każdego dnia. Prozaiczna strona domowa Microsoftu może nie jest z pewnością najlepiej znaną i najczęściej używaną witryną, jak wyszukiwarka Google, czy Yahoo!, lecz przez microsoft.com przepływają ogromne ilości ruchu. Ludzi, którzy odwiedzają strony Microsoftu można liczyć w milionach.

Hańbą jest, że witryna Microsoftu nie jest tak zoptymalizowana jak być powinna. Widocznie nie podjęto jeszcze decyzji o dokonaniu porządnej optymalizacji. Użytkownicy pobierają więc większe strony, a serwery marnują dodatkowe pasmo. Pomimo, że strona główna zajmuje ok. 40KB, nie jest ona jeszcze tragicznie opasła. Jest jednak obciążona niezrozumiałym, kiepskim kodem, bazującymi na tabelach i na znacznikach opartych w prawnie zastrzeżone atrybuty. Są tu też jakieś dziwne JavaScripty. Zwróć uwagę, że nie wspomniałem czy jest to zgodne ze standardami, czy nie. Pomimo, że Microsoft używa XHTML, zwyczajnie opuszcza deklarację doctype na swojej stronie głównej.

Dlaczego Microsoft?

Czy jest to kolejna "zmowa na Microsoft"?

Mówiąc szczerze i bez ogródek... nie.

Nie wybrałem Microsoftu, by zrobić przedstawienie, czy podrzucić kilka negatywnych uwag o firmie, którą niektórzy ludzie uwielbiają nienawidzić. (Nie przepuściłem żadnej okazji by poddać w wątpliwość pewne decyzje, lecz unikałem osądzania).

Przyznaję, że celowo skierowałem swoją uwagę na firmę o wysokim profilu. Taka już moja natura. Lecz niewątpliwie jest to przykład, z którym każdy jest obeznany. Microsoft.com był (i jest) doskonałym kandydatem do przeróbki standardowo stworzonych dokumentów CSS.

A oto powody dlaczego...

Powód #1

Nieskuteczne użycie mnóstwa tabel i oddzielających GIFów w layoucie witryny. Kod strony jest przez to bardzo trudny do modyfikacji, a wyjściowy tekst cechuje się słabą dostępnością. Microsoft nie jest w tej kwestii osamotniony. Przytłaczająca większość witryn w sieci wciąż używa wielu tabel do stworzenia layoutu witryny, jak i do innych celów - stricte wizualnych. Ja wybrałem Microsoft, by mógł on służyć jako dobrze znany przykład (i ewentualnie jako model), który odwołuje się do tych samych kwestii, na których wiele witryn powinno się skupić.

Powód #2

Wystrój graficzny witryny Microsftu to struktura, gdzie jest tysiące podstron, a każda z nich korzysta z szablonu: Nagówek + 3 kolumny + Stopka. Nagłówek obejmuje całą górną część witryny wszerz, Lewa kolumna zawiera głównie nawigację, Główna kolumna to treść, a Prawa kolumna to dodatkowe "bajery". Pozostaje jeszcze Stopka, która znajduje się pod trzema kolumnami i również zajmuje całą dolną część witryny wszerz. Jeżeli nie mamy do czynienia z układem trójkolumnowym, to wiele witryn używa wariacji z dwoma kolumnami. W takim przypadku, albo po prawej, albo po lewej stronie znajduje się pasek nawigacji.

Powód #3

Strona główna Microsoftu używa CSS w nieco większym stopniu, niż tylko stosując fonty i kolory. Bardzo chciałbym zobaczyć firmę, która wymyśliła koncepcję, by arkusze stylu znajdowały się w środowisku aplikacji, bardziej w strone CSS, niż metod starej daty.

Powód #4

W zależności od tego, z jakiej przeglądarki korzystamy, Microsoft serwuje różne strony główne. Jedna wersja przeznaczona jest dla Internet Explorer dla Windows (v5.5 i nowsza). Druga wersja, uproszczona dla wszystkich innych przeglądarek (włączając w to IE/Mac), które opuszczają pewne elementy graficzne i logo produktów. Wersja nie pod IE opuszcza pewną część funkcjonalności (np. rozwijalne menu) i tworzy elementy witryny przy wykorzystaniu innych technik. Jeżeli masz IE/Wind 5.5 lub wyższą, możesz sprawdzić to na własną rękę. Jeżeli nie, poniżej znajdują się screeny dwóch wersji, z zaznaczonymi czerwonymi okręgami różnicami.

Wersja nie-IE/Win z pewnością jest bardziej anemiczna, aniżeli wersja prezentowana dla IE/Win. Wszyscy wiemy, że nie musi tak być. To nie jest to sprawa niechlujnego kodowania, które pracuje tylko z wybranymi przeglądarkami. Microsoft umyślnie dokonuje sprawdzenia przeglądarki przy użyciu skryptu JavaScript i przekierowuje przeglądarkę do innego pliku, jeżeli ma do czynienia z IE5.5+. Zamiast tego, Microsoft mógłby stworzyć witrynę, która współpracowałaby ze wszystkimi przeglądarkami.

Na szczęście Microsoft w ogóle serwuje witrynę dla nie korzystających z przeglądarki IE. Niektórzy developerzy mogą nawet nie posunąć się tak daleko. Najczęstszą wersją, którą słyszymy odnośnie rezygnacji ze wsparcia dla innych przeglądarek jest fakt, że IE jest przeglądarką używaną przez WIĘKSZOŚĆ ludzi i zbyt długo trwałoby wyprodukowanie działających wersji pod pozostałe przeglądarki. Inni narzekają, że rozwój oprogramowania dla innych przeglądarek niż IE byłby zbyt kosztowny. Obie wersje są nieprawdziwe.

Wielu programistów wierzy w te problemy, bo rozpoczynają pracę i sprawdzają ją w IE. Następnie spoglądają do innej przeglądarki i denerwują się, gdy widzą wiele problemów, które musieliby rozwiązać.

IE interpretuje CSS bardziej luźno, niż inne przeglądarki, które bardzo często zmieniały wersje przez ostatnie parę lat (Mozilla, Firefox, Safari, Opera...). Programowanie dla IE, a później dostosowywanie oprogramowania, by działało z innymi przeglądarkami (w końcowym rozrachunku) na pewno wydłuży czas i zwiększy koszty.

Rozpocznij od bardziej wymagającej przeglądarki, która (zazwyczaj) renderuje rzeczy, tak jak powinny one być zrenderowane. Spraw, by wszystko działało w niej, jak należy. Następnie, powróć do IE i wprowadź niezbędne poprawki. Programowanie jest wtenczas znacznie szybsze. Pomijanie najpopularniejszej przeglądarki na początku procesu tworzenia może wydawać się złym pomysłem, lecz w rezultacie łatwiej jest stworzyć stronę, którą dostosujemy do IE, niż odwrotnie. Pisząc kod pod IE rozpoczynasz od razu pisanie złego kodu, a co z tym idzie trudniej jest dostosować się do bardziej restrykcyjnych przeglądarek.

Idąc to ścieżką, wciąż musimy współzawodniczyć z Czynnikiem IE. Tym niemniej wraz z nabywaniem doświadczenia ze złymi zachowaniami CSS w IE, czynnik IE zaczyna odgrywać coraz mniejszą rolę. Pozostaje nadzieja.

Tylko fakty proszę!

Podczas drugiej części prezentacji, wkroczyliśmy w proces konwersji witryny Microsoftu bazującej na zagnieżdżonych tabelach, na bardziej purystyczną, opartą na CSS i działającą we wszystkich przeglądarkach. To żadna nowość. Inni już próbowali tego samego z witryną micorosft.com. Wielu stałych czytelników tej witryny tworzy bez użycia tabel zapewne już rok a nawet i więcej. Lecz nie widać, by w środowisku wszyscy rzucali się na tą głęboką wodę, pomimo, że wiadomo, co ich tam czeka. Z tą myślą powstałą prezentacja na Digital Design World i prezentowany artykuł.

Kontynuując prezentację, przełamaliśmy mity wszystkich etapów procesu, w łatwe w organizacji porcje. Zwróciłem uwagę na każdy z głównych kroków procesu, włączając w to wyrzucanie tabel, konwersję do bardziej semantycznej składni i technik CSS używanych do reprodukcji każdej z części witryny głównej Microsoftu.

Przez całą prezentację, przeanalizowaliśmy wiele diagramów, zrzutów i piktogramów, które pomogły nam zrozumieć techniki używane do renderowania każdej z sekcji. Miałem także przygotowany zawczasu gotowy kod, tak, bym mógł łatwo odwoływać się do kolejnych etapów procesu konwersji.

Jednym z powodów, dla których powstał ten artykuł, był zamiar opublikowania wyników konwersji witryny Microsoft.com, która jest jedną z tych, którą nie można ot tak sobie zignorować:

  Bieżący design
(IE/Win)		 Bieżący design (inny) Zoptymalizowany
Użytych tabel 40 36 0
Użytych GIFów odstępowych 35 76 0
Całkowita ilość tagów <img> 43 122 6
Ilość obrazów CSS 1 1 11
Obsługa przeglądarek 2 najnowsze najnowsze
Rozmiar pliku HTML 40 KB 39 KB 15 KB
Redukcja rozmiaru pliku - 3% 62%

Idąc dalej

Liczby stają się jeszcze bardziej interesujące, gdy zaczniemy tworzyć witryny w stylu ESPN Meyera/Davidsona. Zgodnie z publiczną witryną Microsoftu zatytułowaną "Wewnątrz Microsoftu", Microsoft publikuje statystyki ruchu dla domeny mictosoft, które wynoszą 1,2 miliarda odsłon w samym maju 2004. W tej prezentacji, pokazałem jak zmniejszyć ilość znaczników o 62% do 25KB. Przewidziałem jednocześnie, że ok. 25 KB byłoby rozsądną oszczędnością, gdyby Microsoft zdecydował się na szersze zastosowanie CSS. Jeżeli przemnożymy te 25KB, które oszczędzamy na każdej podstronie przez 38,7 miliona odsłon dziennie, otrzymujemy 924 GB oszczędności w transferze dziennie. To daje 329 terabajtów rocznie!

Te liczby powinny mówić same za siebie.

Firmy, takie jak Microsft mogą, lecz nie chcą utrzymywać tylko jednej wersji swojej strony domowej, która współpracuje z większą ilością przeglądarek, gdzie podstrony ładują się szybciej, a witryna dostępna jest dla wszystkich typów użytkowników i urządzeń. Bez względu na to, uważam, że warto było zwrócić na problem i zademonstrować, iż firmy mogłyby tworzyć jedną wersję witryny, która składałaby się z czystszego zestawu znaczników, pracowała w większej ilości przeglądarek i byłaby bardziej dostępna. Wszystko to udało się zademonstrować w przeciągu godziny lub dwóch...

Dodatkowe punkty i warunku

Copyright © 2024 by Paweł Grzesiak. Wszelkie Prawa Zastrzeżone.