Autor nie ukrywa też swoich preferencji co do dalszego rozwoju języka HTML:

HTML5 will be the future of the web, so my advice would be to pay close attention to it.

Pogląd ten jest poparty kilkoma dobrymi argumentami, więc sądzę że warto zapoznać się z całym tekstem, jeśli jeszcze nie wyrobiliście sobie zdania w tej kwestii.

The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.

Uważam, że komunikat błędu można jak najbardziej podciągnąć pod tą definicję. Jest przecież bezpośrednio powiązany z daną kontrolką. Pytanie brzmi – jakie są korzyści takiego rozwiązania? Rozpatrzmy następujący formularz:

<form method="post" action="index.html">
  <div id="errors">
    <h2>Błędy</h2>
    <ul>
      <li><label for="name"><em>Imię i nazwisko</em>: Proszę podać imię i nazwisko</label></li>
      <li><label for="email"><em>Email</em>: Podany adres e-mail jest nieprawidłowy</label></li>
    </ul>
  </div>
  <div><label for="name">Imię i nazwisko <em>(wymagane)</em></label> <input type="text" name="name" id="name" value=""> <strong class="error"><label for="name">Proszę podać imię i nazwisko</label></strong></div>
  <div><label for="email">Adres e-mail <em>(wymagany)</em></label> <input type="text" name="email" id="email" value="Lorem ipsum"> <strong class="error"><label for="email">Podany adres e-mail jest nieprawidłowy</label></strong></div>
  <div><input type="submit" value="Wyślij formularz"></div>
</form>

Powyższy przykład na żywo
Takie rozwiązanie przypisuje bezpośrednio informację o popełnionym błędzie do danego pola formularza. Według mnie może to być bardzo istotne zwłaszcza przy długich formularzach, występujących poniżej linii zgięcia. Po przeładowaniu strony nie widzimy bezpośrednio formularza ani komunikatów błędu z nim powiązanych. Świadczy to przeważnie o niewłaściwym projekcie strony, ale przykra rzeczywistość jest taka, że od czasu do czasu musimy borykać się z tego typu problemami.

Moje pytanie brzmi – czy takie rozwiązanie jest prawidłowe (nie spotkałem się z nim na innych stronach) i czy przynosi użytkownikom jakąkolwiek korzyść? Osobiście zauważyłem już jeden problem. Kliknięcie na label w górnej liście błędów przenosi do odpowiedniego pola, ustawiając na nim focus. Nie ma jednak powrotu do listy błędów, i efekt może być taki, że znajdziemy się gdzieś w połowie formularza nie będąc jednocześnie całkowicie świadomym położenia swojego i innych pól, w których wystąpiły błędy.

Czuję, że ta technika ma przyszłość, ale obecnie nie jestem do końca pewien, jak to rozwiązać przy pomocy czystego HTML. Będę wdzięczny za wszelkie uwagi.

Zgodnie ze specyfikacją znaczników META na stronie W3C atrybut id nie jest dla nich prawidłowy. Nie udało mi się też nigdzie znaleźć powodu ani nawet opisu takiego zachowania. Kliknięcie na przyciski powinno wyświetlać wartość SPAN. Inne zachowanie jest nieprawidłowe.

Jeśli macie jakieś informacje na ten temat – dajcie znać.

Aktualizacja. Praktycznie pięć minut po kliknięciu ”Publikuj“ znalazłem przyczynę problemu. Moje początkowe założenia były niewłaściwie – problem nie dotyczy wyłącznie znaczników meta. Zgodnie z tym Raportem błędów na stronie niezastąpionego PPK metoda document.getElementById(foo) zwraca w IE elementy z atrybutem name równym foo. Opera świadomie stosuje takie samo rozwiązanie w celu rozwiązania problemów z niektórymi ważnymi stronami, oczekującymi takiego właśnie podejścia. Dla porządku dodałem jeszcze jeden przykład ilustrujący problem.

Aktualizacja 2. Zaczynam podejrzewać międzynarodowy spisek, chociaż jednocześnie pewną ulgę. Kilka godzin po moim poście, Jeremy Keith opublikował wpis “Names and IDs” na ten sam temat. Pozostaje mi się cieszyć tylko, że nie tylko taki szary ludek jak ja miał z tym problem…

Artykuł opisuje dwie przeciwstawne metody tworzenia stron internetowych:

1. Podejście wizualne – budowę zaczyna się od stworzenia projektu graficznego, następnie tworzy się szablony HTML, a na koniec dodaje właściwą treść
2. Podejście strukturalne – treść strony przetwarza się na kod HTML, główny nacisk kładąc na sensowną kolejność i znaczenie tworzonych elementów, a dopiero później dodaje się do niego warstwę graficzną

Całym sercem opowiadam się za tym drugim rozwiązaniem z kilku powodów:

• Otrzymany kod HTML jest dużo bardziej przejrzysty i sensowny dzięki skupieniu się na strukturze, a nie na detalach graficznych. Oczywiście, wraz z budowaniem warstwy prezentacyjnej pojawia się konieczność dodania kolejnych elementów, jednak mogą one zostać lepiej rozmieszczone i ich ilość jest z zasady mniejsza. Ponadto łatwiej określać nazwy klas i identyfikatorów dla elementów (a to wcale nie taka oczywista kwestia), ponieważ widzimy, co konkretnie zawiera dany kontener.
• Część klientów, zamawiających stronę internetową ma bardzo mgliste pojęcie o jej zawartości. Przygotowanie szablonów na pierwszym etapie projektowania pozwala zapobiec przykrym niespodziankom, gdyż klienci w tym momencie widzą dokładnie, co znajdzie się na stronie. Dużo prościej wprowadzić poprawki w treści i funkcjonalności w kodzie HTML, niż przerabiać i ciąć od nowa sporą część projektu graficznego.
• Programiści są szczęśliwsi – od razu widać czy dana podstrona będzie wymagała osobnego modułu, czy też można wykorzystać któryś z obecnie istniejących. Wprowadzanie zmian w połowie projektu jest zawsze bardziej czasochłonne i kosztowe, niż gdyby były one uwzględnione od samego początku.

Niestety, w codziennej pracy napotykam wiele przeszkód, uniemożliwiających takie rozwiązanie:

• Przygotowanie treści jest zajęciem czasochłonnym i wymaga od klienta zaangażowania i świadomości rezultatu, który chce się osiągnąć. Z tym w 80% przypadków nie jest za dobrze.
• Dobrzy graficy, znający się na tworzeniu stron internetowych to skarb. Ci, potrafiący przygotować projekt uwzględniając gotową strukturę (opisaną w HTMLu) są prawdziwą rzadkością i przeważnie już pracują w wielkich agencjach.
• Najlepiej sprzedaje się projekt graficzny, bo on przemawia do klienta.
• Poza smutnym działem produkcyjnym nikogo to nie interesuje i ciężko wymusić całkowitą reorganizację sposobu pracy i kontaktów z klientem.

Jak można zauważyć – istnieją pewne problemy, które wynikają jednak nie z wad samej metody, a raczej z niedoskonałości rzeczywistości, w której musimy pracować. Mimo to mam nadzieję, że ten sposób szybko się przyjmie gdyż zdecydowanie ułatwia pracę zarówno kodera jak i programisty.