Kilka zasad projektowania w HTML5

HTML5 staje się już standardem obsługiwanym w dużym stopniu przez wszystkie nowe przeglądarki. Zgodnie z założeniem, że każdy standard powinien mieć swoje zasady projektowe. Oto sześć najważniejszych z nich: Unikanie zbędnej złożoności – czyli kończymy z wypisywaniem długich DOCTYPE czy charsetów. <!DOCTYPE html> i <meta charset=”utf-8″> to wszystko, czego nam potrzeba. Obsługa istniejących już treści [...]

html_mini

HTML5 staje się już standardem obsługiwanym w dużym stopniu przez wszystkie nowe przeglądarki. Zgodnie z założeniem, że każdy standard powinien mieć swoje zasady projektowe. Oto sześć najważniejszych z nich:

  1. Unikanie zbędnej złożoności – czyli kończymy z wypisywaniem długich DOCTYPE czy charsetów. <!DOCTYPE html> i <meta charset=”utf-8″> to wszystko, czego nam potrzeba.
  2. Obsługa istniejących już treści – w rzeczywistym świecie każdy deweloper pisze HTML trochę inaczej. Nie można powtarzać błędów XHTML-a, przeglądarki powinny przetwarzać różne formy języka i zachowywać się przy tym spójnie.
  3. Rozwiązywanie rzeczywistych problemów – nie obchodzą nas abstrakcyjne architektury, chcemy pragmatycznych rozwiązań dla problemów, które stoją dziś przed WWW. Według Keitha wielu ludzi chce, by można było umieszczać wiele akapitów <p> czy <h2> wewnątrz hipertekstowej kotwicy <a>. Czemu tego nie ma w specyfikacji?
  4. Podążanie utartymi ścieżkami – jeśli jakaś praktyka jest powszechnie akceptowana, to specyfikacja powinna ją przyjąć, zamiast wymyślać nową. Tak było z wprowadzeniem tagów <nav>, <section>, <article> czy <aside>, a przecież już w 1991 roku Tim Berners-Lee pisał, że wolałby zamiast hierarchii <h1>…<h6> zagnieżdżalny element <section> i ogólny element <h>, który na dowolnym poziomie w sekcji dawałby oczekiwany nagłówek.
  5. Eleganckie cofanie się – trzeba myśleć też o starszych przeglądarkach. Po wprowadzeniu nowych wartości typów do <input>, przeglądarki traktują te, których nie mogą rozpoznać, jako tekst – i to jest eleganckie. Ale już w wypadku wojny o wideo HTML5 kontra Flash, tak ładnie nie jest. Spór ten w praktyce to wojna <video> kontra <object>. Można by go rozwiązać, wracając do <object>, gdy <video> nie będzie rozpoznane. A jeśli nie działa ani jedno, ani drugie, zejść do <a>, by udostępnić link do treści.
  6. Hierarchia priorytetów – czyje potrzeby są ważniejsze? Keith głosi, że właściwy porządek rzeczy to użytkownicy > autorzy > twórcy implementacji > twórcy specyfikacji > teoretyczna czystość. Użytkownicy i programiści są zawsze ważniejsi, niż specyfikacje i teorie.