Ramki#
Wstęp#
Ramki zrewolucjonizowały swego czasu pojęcie serwisu internetowego, kończąc erę luźno powiązanych, odmiennych stylistycznie stron podrzędnych składających się na serwis internetowy. Były szczególnie popularne od połowy lat 90, gdy ich obsługa wprowadzona została po raz pierwszy przez firmę Netscape w jej przeglądarce Navigator (później także w innych przeglądarkach). Była to technologia wprowadzona "na dziko", ale jej popularność sprawiła wdrożenie całości do specyfikacji HTML 4 (1998 rok). W tych okrutnych czasach strony robiło się zazwyczaj w „gołym HTML”, bez pomocy technologii po stronie serwera. Autorzy stron, nie zdając sobie sprawy z istnienia preprocesorów HTML, zmagali się z aktualizowaniem wspólnych elementów stron (menu) na wszystkich podstronach serwisu. W późniejszym czasie ramki zaczęły być sukcesywnie wypierane przez tzw. portalowe układy stron oparte na tabelach.
Mechanizm ramkowy pozwala podzielić plik na odrębne sekcje (ramki), w których wczytywane są osobne pliki (strony). Podział taki umożliwia np. wyodrębnienie menu, nagłówka lub stopkę, które zazwyczaj się nie zmieniają, oraz pozostałą treść umieszczaną w osobnych plikach. Dzięki temu możliwe jest wprowadzanie drobnych korekt w pliku menu, które będą widoczne w całym serwisie - bez konieczności wprowadzania zmian w każdym pliku osobno. Swego czasu było to bardzo duże udogodnienie - wystarczy wyobrazić sobie konieczność wprowadzenia dodatkowej pozycji menu w 1000 plikach serwisu. Dzięki ramkom cały problem sprowadzał się do korekty przeprowadzanej w jednym miejscu.
Dzisiaj z ramek praktycznie się nie korzysta. Nowoczesne narzędzia umożliwiające dynamiczne komponowanie kodu xHTML na podstawie szablonów ograniczyły potrzebę wydzielania fragmentu strony w oddzielnej ramce, a języki dynamicznego komponowania strony - takie jak PHP, Python lub ASP - umożliwiły tworzenie serwisów, których każda strona zawiera aktualizowane na bieżąco sekcje strony.
Opis techniki umieszczam tutaj ze względu na fakt, że jest ciągle jeszcze stosowana przez niektórych webmasterów.
DTD dla ramek#
Technika z użyciem ramek jest uznana w HTML 4.01 i XHTML 1.0 za schyłkową (pozostaje w obrębie wersji DTD Frameset), zaś w XHTML 1.1 została zaniechana (podobnie jak ramki pływające). Mimo upływu lat mechanizm ramek wciąż jest obecny w każdej nowoczesnej przeglądarce.
Dla pliku bazowego (tworzącego strukturę podziału) poniższa deklaracja będzie właściwa:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
Co istotne, ramka, w której znajdują się odsyłacze wczytujące dokumenty do innej ramki nie może mieć deklaracji Strict, gdyż nie przewiduje ona atrybutu target. Dlatego w takim wypadku konieczne jest użycie deklaracji Transitional.
Wszystkie strony, które ładowane są do konkretnej ramki, a które nie wczytują dokumentów do innej ramki (brak atrybutu target) mogą mieć deklarację DTD odpowiadającą wersji Strict.
Ramki lokalne (pływające) można używać deklarując DTD w wersji Transitional.
Wady#
Podstawowe wady wynikające ze stosowania ramek to:
- Zwykłe dodanie do zakładek (Ulubione) podstron serwisu z ramkami jest utrudnione lub nawet niemożliwe. Podobny problem występuje w przypadku chęci skopiowania adresu konkretnej podstrony, np. w celu przekazania koledze.
- Odświeżenie serwisu w ramkach, np. w przypadku problemów z transferem, zawsze powoduje powrót na stronę główną.
- Ramki są przeznaczone do budowy raczej prostszych struktur serwisu. Jeśli wstawimy na stronie dużo ramek - szczególnie w mniejszych rozdzielczościach ekranu - "okienko" z właściwą treścią strony może okazać się stanowczo za małe.
- Otworzenie linku w nowym oknie (lub karcie/tabie) najczęściej psuje całkowicie układ na ramkach i uniemożliwia nawigację.
- Strony otworzone z wyników wyszukiwania (np. za pomocą wyszukiwarki Google) są niekompletne i przez to nierzadko bezużyteczne.
- Trudno zapisać stronę na dysk. To jest zwykłe utrudnienie, a nie żadne zabezpieczenie antypirackie.
- Część webmasterów uważa, że jest to technika przestarzała i w żadnym wypadku nie należy jej stosować.
- Błędny lub całkowity brak indeksowania przez roboty sieciowe.
- Gorsza dostępność dla osób niewidomych (niegraficzne przeglądarki obsługują ramki słabo bądź nie obsługują wcale).
Oczywiście ramki nie są złem całego świata, czasami warto z nich korzystać. Przykładem może być strona Erica Meyera prezentująca wszystkie polecenia CSS 2.1 w menu po lewej stronie, po prawej stronie otrzymujemy bezpośredni opis umieszczony w specyfikacji W3C. Bardzo wygodne rozwiązanie, które oczywiście można wykonać za pomocą nowoczesnych technik (DHTML i AJAX), aczkolwiek najszybsze będzie zastosowanie ramek.
Ogólnie można powiedzieć, że na zwykłych stronach WWW ramki są zbędne. Niewidoczne ramki mogą być przydatnym hackiem przy robieniu webowych aplikacji dla starszych przeglądarek bez obsługi XMLHTTPRequest. Mogą też znaleźć zastosowanie w aplikacjach intranetowych, gdzie nie jest ważna szeroka dostępność i kompatybilność.
Mechanizm ramek ma swoje specyficzne problemy. Bardzo dobre zobrazowanie całości zaprezentował porneL w artykule "Dlaczego ramki są złym pomysłem".