Z zamiłowania tworzę strony internetowe. Moje teksty mają na celu opisanie
niektórych fragmentów internetu, którego ta strona jest częścią.
Konserwatywny, pewny siebie, niekonwencjonalny - to wady czy zalety? Sprawdź!
maciej łebkowski
Poniższa lista jest listą błędów, które bardzo często można napotkać na stronach internetowych, wraz z krótkim opisem, dlaczego uważam te rzeczy za błędy. W miarę możliwości staram się również pokazać, jak ustrzec się przed popełnianiem takich błędów oraz podać pokrewną literaturę.
Całkowity brak, błędny albo niewłaściwie umieszczony doctype. Widziałem deklaracje HTML 4.0 Transitional w dokumentach zawierających kod XHTML, czasami nawet w dokumentach <frameset>. Zdarzały się również wstawiane po otwarciu znacznika <html> czy też niekompletne deklaracje.
Czemu? Dwa powody. Po pierwsze, poprawny doctype jest wymagany, począwszy od specyfikacji HTML 4.01 aż po dzisiejsze XHTML 1.0. Po drugie, nowoczesne przeglądarki na podstawie doctype decydują, który tryb renderowania strony wybrać. Mówi się na to "DOCTYPE switching". Aby osiągnąć jak najbardziej podobne efekty w różnych przeglądarkach, szczególnie jeśli chodzi o CSS, pomocnym będzie używanie tzw. "trybu zgodności ze standardami". Więcej informacji na ten temat na anglojęzycznych stronach: napraw swoją stronę używając odpowiedniego doctype oraz używanie odpowiedniego stylu wyświetlania przez deklarację doctype.
Popularną metodą zmiany wyglądu danej części strony jest wrzucenie tego w element <span>, nadanie mu klasy i zdefiniowanie odpowiednich stylów w CSS. Jestem pewien, że każdy widział rzeczy typu: <span class="naglowek"> czy też <span class="tekstglowny">
Czemu? Bo to w większości przypadków jest zupełnie niepotrzebne; nie ma żadnego znaczenia semantycznego i gmatwa kod. Używaj nagłówków dla nagłówków, znacznika <p> dla akapitów oraz odpowiedniego taga dla list. Używaj CSS-a do stylowania tych właśnie elementów, a jeśli to potrzebne, nadaj im klasy lub id.
Traktowanie internetu jako WYSWIG - niepotrzebne skupianie się na tym, jak element ma wyglądać zamiast zastanowić się najpierw nad strukturą, a prezentacje zostawić na później.
Czemu? O ile możemy powiedzieć, że większość internautów posługuje się wzrokiem, to nie możemy powiedzieć, że wszyscy tak robą. I nie ma sposobu, żeby uczynić z internetu WYSWIG. Tak długo będą istnieć różnice, jak długo ludzie będą używać różnych przeglądarek, systemów operacyjnych, monitorów, rozdzielczości, rozmiarów okien, ustawień kolorów czy wielkości czcionek. Internet to nie druk lub telewizja. Twój design musi być bardziej elastyczny.
Niesemantyczny kod. Wybieranie elementu HTML opierając się na tym, jak większość graficznych przeglądarek go domyślnie wyświetli, zamiast na znaczeniu tego elementu.
Czemu? To bardzo podobne do "<span> manii", czyli nie nadawanie konkretnego znaczenia zawartości przez używanie określonych znaczników HTML. Bez semantyki HTML-a nie graficznym agentom jest dużo trudniej wyłapać znaczenie treści. Zwykle nie ma problemu ze stylowaniem w CSS semantycznego kodu.
Deklarowanie jednego kodowania w nagłówkach HTTP wysyłanych przez serwer, jednocześnie korzystając z innego w dokumencie. To może wprowadzić w błąd przeglądarki, co spowoduje niewłaściwe wyświetlanie treści dokumentu.
Czemu? Dlatego, że chcesz mieć pewność, że internauci nie będą mieli problemów z odczytaniem zawartości twojej strony.
Zarówno brakujące jak i bezużyteczne. Elementy <img> bez atrybutu alt goszczą na milionach stron internetowych. Nie aż tak popularne są wartości typu "GIF, który tworzy layout", "duży niebieski przycisk z cieniowaniem" lub "obrazek JPG, rozmiar: 123KB", które są zupełnie nieprzydatne. Trzeba pamiętać, że atrybut alt jest wymagany dla elementów <img> i <area>
Czemu? Jest wymagany, poza tym bez niego informacje zawarte w obrazku są nieosiągalne dla screenreaderów, przeglądarek tekstowych, robotów sieciowych i użytkowników, którzy wyłączyli wyświetlanie obrazków. Należy zauważyć, że tekst alternatywny ma być związany z elementem. Dla obrazków dekoracyjnych i tworzących layout bezpiecznie jest użyć pustej wartości, alt="".
Wielokrotne używanie tej samej wartości dla atrybutów id; niewłaściwe znaki używane w nazwach id lub klas.
Dla CSS (CSS 2.1. Składnia i podstawowe typy danych)
In CSS 2.1, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [A-Za-z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit.
Dla HTML (Podstawowe typy danych w HTML)
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
Czemu? Przeglądarki, które trzymają się specyfikacji nie wyświetlą takiej strony w sposób, jaki zakładasz. Jeśli w dokumencie kilka elementów ma tą samą wartość ID, JavaScript, który się do nich odnosi nie zadziała lub efekty jego działania będą nie do przewidzenia.
Używanie skryptów, po stronie serwera lub klienta, mających na celu rozpoznanie przeglądarki użytkownika i w rezultacie wysyłanie różnego kodu. Zwykle zawodzi z powodów takich jak: nowe przeglądarki, ulepszone przeglądarki czy podszywanie się (Opera robi to domyślnie).
Czemu? To niepotrzebna komplikacja, która i tak kiedyś nie zadziała.
Długości (poziome i pionowe) wymagają jednostek w CSS, pod warunkiem że wartość jest różna od zera. Tym się różni CSS od HTML-a, że nie wystarczy podać width="10". W CSS to musi być width: 10px; (czy jakich tam jednostek sobie użyjesz)
Czemu? Bo bez tego nie zadziała w przeglądarkach trzymających się specyfikacji.
Stylowanie pasków przewijania, wyrażenia, filtry itp. CSS, który działa wyłącznie w Internet Explorerze.
Czemu? Działa tylko w określonej przeglądarce. Jeśli koniecznie chcesz użyć osobnego kodu dla IE, umieść go w osobnym arkuszu u załącz używając komentarzy warunkowych lub innych metod w taki sposób, aby tylko IE interpretował "niepoprawny" kod.
Uzależnianie strony od JavaScriptu. Zbyt wiele osób używa przeglądarek bez obsługi JS lub wyłączyła ją w swojej przeglądarce. Statystyki (te na W3Schools albo na TheCounter.com) wskazują, że jest to mniej więcej 8-10 procent internautów. Roboty wyszukiwarek obecnie również nie interpretują JS, pomimo to, że pojawiły się plotki o dodaniu takiej funkcjonalności do Googlebota. Jeśli nawigacja twojej strony jest oparta o JavaScript, nie oczekuj wysokich pozycji w wyszukiwarkach.
Czemu? Cierpi na tym dostępność i pozycja w wyszukiwarkach.
Zakładanie, że każdy ma zainstalowany plugin Flasha. Nie, nie każdy ma. I większość robotów internetowych też nie ma (Google eksperymentuje z indeksowaniem plików flashowych, ale nadal zalecają wstawienie tekstowej nawigacji i treści), więc jeśli cała twoja strona, albo jej nawigacja jest zbudowana wyłącznie we flashu, to nie zajdziesz wysoko w wynikach wyszukiwania.
Czemu? Cierpi na tym dostępność i pozycja w wyszukiwarkach. Nie mówię, że nie można w ogóle używać Flasha, tylko że trzeba to robić z głową.
Robienie obrazków z tekstu, nie zapewniając jednocześnie alternatywy. Nie tylko to, że ściąganie obrazka zajmuje więcej czasu niż ściąganie tekstu, ale również uniemożliwia to skopiowanie tekstu oraz w większości przypadków jego powiększanie.
Czemu? Cierpi na tym dostępność, dłużej się ładuje, spada pozycja w wyszukiwarkach.
Mało dostępne, trudne w użyciu formularze. Naucz się korzystać z takich elementów jak <label>, <fieldset>, <legend> i nie używaj przycisku reset.
Czemu? Mało dostępne, mało użyteczne. Przeczytaj artykuły tworzenie dostępnych formularzy, bardziej dostępne formularze i przyciski "reset" i "anuluj", żeby nauczyć się więcej o projektowaniu dostępnych i użytecznych formularzy.
Wiele zagnieżdżonych tabelek, GIFy "odsuwające", tagi <font>, elementy prezentacji w kodzie. To tak często spotykane, że nie muszę tu o tym wspominać.
Czemu? Bardziej zagmatwane, wolniejsze, mało dostępne, kiepskie dla wyników wyszukiwania strony.
Kodowanie najpierw pod Internet Explorera, a potem optymalizacja pod resztę, jeśli starczy czasu.
Czemu? Zabiera więcej czasu, promuje kiepskie nawyki. IE bardzo często akceptuje nieładny, niewłaściwy kod HTML, na którym wysypuje się większość przeglądarek. IE przetwarza również poprawny, dobrze zaprojektowany kod HTML, który działa we wszystkich przeglądarkach, więc używając go na co dzień robisz przysługę wszystkim przeglądarkom i nie kosztuje to ani więcej czasu, ani więcej pieniędzy. Zobacz również: czynnik IE.
Używanie odradzanych, wycofanych albo charakterystycznych dla jednej przeglądarki atrybutów, takich jak np: marginwidth, leftmargin, language, height dla tabelek, border dla elementów <img> itd.
Czemu? Niepoprawne i niepotrzebne. Używaj CSS zamiast nich. Dla <script> użyj type a nie language w celu określenia języka skryptowego (prawie zawsze jest to JavaScript).
Wiele odnośników zawiera długie adresy z niezakodowanymi znakami &. To jest błędne i może stwarzać problemy. Te znaki trzeba zapisywać jako &.
Czemu? Wytłumaczenie i przykład tego, co może się stać można znaleźć w artykule znaki & i walidacja.
Używanie ramek w celu podzielenia okienka przeglądarki pomiędzy kilka niezależnych dokumentów.
Czemu? Po pierwsze chcę powiedzieć, że ramki mogą być przydatne, jeśli używane we właściwy sposób; w intranecie i niektórych aplikacjach webowych. Na stronie publicznej ramki sprawiają zbyt wiele problemów z użytecznością i dostępnością. Problem z dodawaniem do zakładek, drukowaniem, linkowaniem i konieczność robienia obejść dla wyszukiwarek internetowych to tylko niektóre z niedogodności ramek.
Tabelki zawierające dane tabelaryczne, ale zakodowane w taki sposób, jakby miały służyć do tworzenia layoutu; nie korzystając z żadnego z wielu elementów i atrybutów, które mogą polepszyć ich strukturę i uczynić je bardziej funkcjonalnymi.
Czemu? Screen readery i tym podobne oprogramowanie nie są w stanie wyczytać sensu z tabelki, jeśli nie jest ona prawidłowo zaprojektowana. Można znaleźć całą masę artykułów o tym, jak należy projektować tabelki na stronie Tabelka, proszę bardzo, na witrynie Web Standards Project.
Podobnie jak <span> mania. Dodawanie niepotrzebnych divów i atrybutów class
Czemu? Zobacz "<span> mania" i "brak semantyki".
Jeśli szerokość twojej strony jest określona z góry, nie rób jej zbyt szerokiej. Nie zamierzam tu dyskutować na temat tego, który z layoutów, elastyczny czy stały, jest lepszy.
Czemu? Jeśli szerokość jest szersza niż okienko internauty odwiedzającego twoją stronę zmusza go to do przewijania w poziomie, a to nie najlepiej wpływa na użyteczność.
Nazywanie klas na podstawie tego, jak element będzie wyglądał zamiast na podstawie jego przeznaczenia.
Czemu? To spowoduje zamieszanie podczas tworzenia nowego designu. Klasa nazwana duzeniebieskie może w efekcie stylować tekst na mały i czerwony. Element o id lewakolumna może nagle znaleźć się po prawej stronie.
Brak deklaracji koloru tła dla elementu body.
Czemu? Wielu użytkowników nie ma takiego samego tła okienka przeglądarki jak twój.
Używanie XHTML-a, który nie jest dobrze sformatowany.
Czemu? Jeśli XHTML jest podawany jako application/xhtml+xml, a tak powinno być, to przeglądarki trzymające się specyfikacji, jak na przykład te bazowane na Mozilli, nie wyświetlą źle sformatowanego XHTML-a.
Określanie wyłącznie koloru tła lub koloru tekstu dla pól w formularzu, przede wszystkim jedno i wielo linijkowych (input type="text" oraz textarea).
Czemu? Niektórzy internauci ustawiają swoje systemy tak, aby używały odwróconych kolorów. Domyslnie pole tekstowe miałoby biały tekst na czarnym tle, zamiast czarnych literek na białym. Jeśli określisz czcionkę jako ciemnoszarą, bez podawania koloru tła, osoby z odwróconymi kolorami w swoich przeglądarkach zobaczą ciemnoszary tekst na czarnym tle, a tego nie da się rozczytać. Przeciwna sytuacja również sprawi problem - używanie jasnoszarego tła bez określania koloru tekstu spowoduje wyświetlanie białego tekstu na jasnoszarym tle. Należy zawsze określać zarówno kolor czcionki jak i tła, albo żadnego z nich.
To dość długa lista rzeczy, na które trzeba uważać. Jeśli wystrzegasz się ich wszystkich, to nieźle sobie radzisz. Jeśli obecnie popełniasz niektóre z nich, cóż, jeśli to jakieś pocieszenie, ja też kiedyś podpadałem pod wiele z tych punktów. Miejmy nadzieje, że to pozwoli zmniejszyć ilość tych błędów w przyszłości.
Ten artykuł jest tłumaczeniem artykułu Rogera Johanssona pt. web development mistakes. Tłumaczenia dokonał Maciej Łebkowski na licencji Creative Commons.
