Za Jens Meiert

To, że tabelki są be, powinna wiedzieć każda osoba zajmująca się tworzeniem kodu HTML… Element table jest prawdopodobnie jednym z najczęściej źle używanych elementów HTML. Podobnie jak pozostałe elementy, table może być użyty źle (czyli do budowania układu strony, tak zwanego „layoutu”), lub dobrze. Tabelka sama w sobie nie jest zła, jeśli użyta jest zgodnie z jej przeznaczeniem. Specyfikacja W3C wyraźnie mówi, że tabelka służy do organizowania różnych danych: tekstu, obrazków, linków, formularzy a nawet innych tabel. Tabelka służy zatem do przedstawienia danych tabelarycznych.

Zgodnie z tytułem skupię się na XHTMLowej wersji tabelki. Tabelę tworzy się używając do tego celu znacznika <table>. Aby była ona tabelą, trzeba zdefiniować rząd komórek (ang. table row) <tr>, a w nim musi znaleźć się przynajmniej jedna komórka nagłówka (ang. table header cell) <th> lub komórka danych (ang. table data cell) <td>.

<table>
	<tr>
		<th>treść komórki nagłówka</th>
		<td>treść komórki danych</td>
	</tr>
</table>

No i mamy pierwszą, prostą tabelkę… Tabela może zawierać w sobie (np. przed definicją pierwszego rzędu komórek) znacznik <caption>. Służy on do przedstawienia krótkiego opisu tabeli. Opis ten domyślnie widoczny jest na stronie (w zależności od potrzeb można go ukryć za pomocą CSSa). Do dłuższego opisania tabelki służy atrybut summary dodawany do znacznika <table>. O ile dla samego wyglądu strony atrybut summary nie ma znaczenia (jego zawartość NIE jest wyświetlana), o tyle ma on znaczenie w kwestii dostępności - zawartość atrybutu odczytywana jest przez czytnik ekranowy (screenreader). Wspomina o tym Mark Pilgrim w swojej książce Dive Into Accessibility. Kod tak opisanej tabeli będzie wyglądał następująco:

<table summary="Długi opis tabeli">
	<caption>Krótki opis tabeli</caption>
	<tr>
		<td>treść komórki danych</td>
	</tr>
</table>

Poza opisem tabeli, „jawnym” (znacznik <caption>), lub „ukrytym” (atrybut summary), tabela ma jeszcze inną ciekawą możliwość: grupowanie rzędów. Rzędy mogą być pogrupowane w nagłówek, stopkę i sekcję główną (tzw. „ciało” tabeli). Służą do tego odpowiednio znaczniki <thead>, <tfoot> oraz <tbody>, które definiujemy dokładnie w takiej właśnie kolejności (<tbody> PO <tfoot>, a nie jak można by się spodziewać, PRZED). Taka tabela wyświetla się już w normalnej, spodziewanej kolejności (sekcje <thead>, <tbody> i <tfoot>). Kod tak pogrupowanej tabelki może wyglądać tak:

<table summary="Długi opis tabeli">
	<caption>Krótki opis</caption>
	<thead>
		<tr>
			<th>treść komórki nagłówka w sekcji thead</th>
		</tr>
	</thead>
	<tfoot>
		<tr>
			<td>treść komórki danych w sekcji tfoot</td>
		</tr>
	</tfoot>
	<tbody>
		<tr>
			<td>treść komórki danych w sekcji tbody</td>
		</tr>
	</tbody>
</table>

Tak mniej więcej wygląda semantyczna tabelka w wersji XHTML. Tabelkę taką można oczywiście jeszcze odpowiednio ostylować (Smashing Magazine podaje kilka ciekawych propozycji) lub/i dodać jakieś ciekawe zachowania za pomocą JavaScriptu (np. Table Sorter). Jeżeli chcielibyście bardziej zgłębić temat tabel polecam artykuł Semantic (X)HTML Markup: Using Tables Appropriately…

Małe info: od jutra (01.09.2008) wyjeżdzam na miesiąc do Niemiec (takie tam małe zlecenie) - w tym czasie blog oczywiście będzie dostępny. Niestety nie jestem pewien, czy będę miał na tyle dużo swobody, żeby móc zajmować się blogiem… Zresztą i tak przy takiej częstotliwości pisania to chyba byłby jakiś rekord…

Idea BarCampu przyjęła się również w Polsce. Od imprez zagranicznych różni się czasem trwania - polskie imprezy to spotkania kilkugodzinne, zagraniczne natomiast trwają kilka dni. Pierwszy BarCamp odbył we Wrocławiu pod nazwą Grill IT z inicjatywy firmy Janmedia (o ile dobrze pamiętam).

Z tego co mi wiadomo, w Elblagu, moim rodzinnym mieście, póki co nikt niestetny nie wpadł na pomysł zorganizowania takiej imprezy. Najbliższy znany mi BarCamp to organizowany w Trójmieście 3camp. Kolejnym miastem, które zapragnęło własnego BarCampu jest Olsztyn, gdzie w poniedziałek, 5 maja o godzinie 17:00 w pubie Sowa pod nazwą Olcamp odbędzie się pierwsze BarCampowe spotkanie. Ja co prawda na Olcampie niestety nie będę, ale osoby z Olsztyna i okolic (Elbląg?) serdecznie zapraszam. Jak zapewniają organizatorzy dobra zabawa zapewniona…

Na koniec dla informacji podaje linki (wraz z miastem w którym odbywa się spotkanie) do wszystkich znanych mi BarCampowych spotkań organizowanych w Polsce. Lista może być niekompletna, dlatego jeżeli znacie jeszcze inne spotkania, których nie wymieniłem, to proszę o komentarz lub e-maila…

• 3camp - Gdańsk
• Aula Polska - Warszawa
• Bachanalia IT - Zielona Góra
• Barcamp - Poznań
• Boatcamp - Łódź
• Bootstrap - Warszawa
• Grill IT - Kraków
• Grill IT - Wrocław
• Innowatorium - Warszawa
• Netcamp - Szczecin
• Olcamp - Olsztyn
• Spodek 2.0 - Katowice
• Yulbiz - Warszawa

Pragnę podziękować Michałowi za wspólną pracę (mam nadzieję, że czyta jeszcze tego bloga) i życzyć mu, a także pozostałym pracownikom i współpracownikom firmy ARK Elit dalszych sukcesów. Kto wie - życie bywa zaskakujące i może zdarzyć się tak, że nasze drogi zawodowe jeszcze się skrzyżują…

Co teraz? Cóż, na pewno nastąpią duże zmiany (na lepsze rzecz jasna) i wiosenne porządki. W końcu będę miał czas zająć się projektami, których nie udało mi się zrealizować w trakcie pracy w ARK Elit, popracować nad własnym rozwojem, zrobić porządek z zaległymi sprawami. Co dalej? Nowa praca? A może własna działalność gospodarcza? To, przynajmniej na razie, pozostanie moją tajemnicą…

Techniczne

1. Czy sprawdzasz poprawność kodu HTML używając walidatora HTML?
2. Czy sprawdzasz poprawność stylów CSS używając walidatora CSS?
3. Czy sprawdzasz swoją stronę przynajmniej w przeglądarkach IE, Firefoksie, Operze i Safari?

Obrazki

4. Czy dodajesz atrybuty ALT i TITLE do wszystkich ważnych obrazków?
5. Czy dodajesz atrybutu LONGDESC do wszystkich obrazków, które potrzebują opisu?
6. Czy piszesz efektywne teksty w atrybucie ALT?
7. Czy tworzysz strony o rozmiarach mniejszych niż 50 kilobajtów?
8. Czy wybrałeś poprawny typ plików do grafiki?
9. Czy dodajesz opis do obrazków, które są ważne dla treści?
10. Czy używasz tekstu zamiast obrazka do przedstawienia ważnej treści?

Treść

11. Czy używasz fontów bezszeryfowych (sans-serif) w odpowiednim rozmiarze do głównego tekstu?
12. Czy ustawiłeś odpowiednio interlinię i odstępy między znakami, aby poprawić czytelność tekstu?
13. Czy wyrównałeś tekst do lewej strony? (zależy od języka)
14. Czy używasz jednostek EM albo procentów zamiast PX?
15. Czy upewniłeś się, że nie ma całych zdań pisanych wersalikami (dużymi literami)?
16. Czy używasz mniej niż 78 znaków (włączając spacje) na linię?
17. Czy tworzysz krótkie i precyzyjne akapity z wyjaśniającymi tytułami?
18. Czy używasz list do podsumowań?
19. Czy najpierw piszesz wniosek, a dopiero potem jego wytłumaczenie?
20. Czy tworzysz odpowiedni kontrast pomiędzy tekstem a tłem?
21. Czy strona dostępna jest także dla przeglądarek tekstowych?
22. Czy upewniłeś się, że nie ma żadnych stron „w trakcie tworzenia”?
23. Czy uwzględniłeś funkcję drukowania dużych ilości tekstu?
24. Czy stworzyłeś arkusz stylów do druku?
25. Czy zamieniłeś wszystkie specjalne znaki na odpowiednie kody ISO-Latin?
26. Czy sprawdziłeś, czy tekst nie posiada żadnych błędów gramatycznych i innych?

Nawigacja

27. Czy upewniłeś się, że wszystkie linki działają?
28. Czy umieściłeś linki do wszystkich podstron na stronie głównej?
29. Czy umieściłeś główną nawigację na każdej podstronie?
30. Czy użyłeś nie więcej jak 8 elementów w głównej nawigacji?
31. Czy utworzyłeś rozróżnienie strony aktywny od nieaktywnej w menu?
32. Czy używasz wyjaśniającego tekstu w linkach zamiast „kliknij tutaj”?
33. Czy używasz wyjaśniającego tekstu w linkach zamiast terminów biznesowych?
34. Czy utworzyłeś rozróżnienie linków już odwiedzonych od tych jeszcze nie odwiedzonych?
35. Czy utworzyłeś rozróżnienie linków od zwykłego tekstu?
36. Czy dodałeś atrybut TITLE do wszystkich linków?
37. Czy używasz ścieżki dostępu, gdy liczba podstron jest duża?
38. Czy uwzględniasz opcję szukania, gdy liczba podstron jest duża?
39. Czy logo jest linkiem do strony głównej?
40. Czy utworzyłeś link „przejdź do treści” na górze strony?
41. Czy utworzyłeś link „przejdź do menu” na górze strony?
42. Czy umożliwiłeś przeglądanie strony za pomocą klawiszy SHIFT-TAB i RETURN?
43. Czy upewniłeś się, że nie używasz żadnych linków JavaScript?

Struktura

44. Czy stworzyłeś spójną strukturę strony?
45. Czy umieściłeś logo w lewym górnym rogu?
46. Czy umieściłeś wyjaśniającą sentencję (slogan) w pobliżu loga?
47. Czy umieściłeś okienko wyszukiwania w prawym górnym rogu?
48. Czy umieściłeś ważną treść w obszarze above the fold?
49. Czy design strony oparty jest na systemie siatki?
50. Czy stworzyłeś płynny design używając wartości procentowych?
51. Czy stworzyłeś stronę dającą obejrzeć się również w niskich rozdzielczościach?
52. Czy stworzyłeś odpowiednie tytuły (w tagu TITLE) do wszystkich podstron?

Formularze

53. Czy upewniłeś się, że użytkownicy nie powracają do zmienionego formularza po błędzie?
54. Czy stworzyłeś przyjazną i informującą stronę błędu?
55. Czy stworzyłeś przyjazną stronę z podziękowaniem z e-mailem potwierdzającym?
56. Czy dodałeś tylko przycisk „wyślij” bez przycisku „resetuj”?
57. Czy poinformowałeś użytkownika, czego może oczekiwać po kliknięciu przycisku „wyślij”?
58. Czy podzieliłeś długi formularz na wiele stron?
59. Czy dałeś użytkownikowi odpowiednią ilość miejsca do pisania?
60. Czy umieściłeś gwiazdkę (*) przy obowiązującym polu?
61. Czy zachowałeś standardowy wygląd pól formularza jakie generuje przeglądarka?
62. Czy stworzyłeś logiczny porządek zapytań?
63. Czy użyłeś podwójnego pola dla hasła?
64. Czy pozwoliłeś by komputer, nie użytkownik zajął się formatowaniem informacji?
65. Czy upewniłeś się, że użytkownicy mogą wypełnić cały formularz używając klawisza TAB?
66. Czy wyjaśniłeś użytkownikowi po co pytałeś o określone informacje?
67. Czy wyjaśniłeś użytkownikowi co zamierzasz zrobić z tymi informacjami?
68. Czy użyłeś AJAXowej (po stronie klienta) walidacji formularza?
69. Czy użyłeś tagu LABEL w formularzu?
70. Czy umieściłeś LABEL nad polem INPUT, a nie za nim?
71. Czy wybrałeś właściwy typ pól INPUT dla różnych danych?
72. Czy sprawiłeś, że pierwsze pole INPUT jest automatycznie aktywne?
73. Czy rozróżniłeś aktywne pole od pola nieaktywnego używając input:focus?
74. Czy użyłeś tagów FIELDSET i LEGEND we właściwy sposób?

(o ile jest to wymagane)

75. Czy sprawdziłeś, czy formularz działa również z wyłączoną obsługą JavaScript?

Multimedia

76. Czy upewniłeś się, że ważne informacje lub nawigacja nie są wykonane we Flashu?
77. Czy upewniłeś się, że muzyka i klipy wideo nie starują automatycznie?
78. Czy upewniłeś się, że muzyka i klipy wideo mogą być w każdej chwili wyłączone?
79. Czy poinformowałeś użytkownika o rozmiarze i długości muzyki i klipów wideo?

Ekstra dodatki

80. Czy stworzyłeś stronę błędu 404?
81. Czy stworzyłeś mapę strony?
82. Czy stworzyłeś kanał RSS? (jeżeli dodajesz treść regularnie)
83. Czy stworzyłeś wersję strony o wysokim kontraście?
84. Czy stworzyłeś dobrze wyglądające adresy URL (jak ten)?
85. Czy upewniłeś się, że twoja strona nie korzysta z ramek (FRAMES)?
86. Czy upewniłeś się, że nie ma żadnych okienek pop-up na stronie?
87. Czy stworzyłeś formularz kontaktowy zamiast zwykłego linka do e-maila?

Tłumaczenie jest oczywiście dosyć swobodne, ale mam nadzieję, że udało mi się zachować sens pytań z oryginalnej listy… Oczywiście wszelkie sugestie, komentarze i/lub poprawki mile widziane…

W firmie, w której obecnie pracuję (o samej firmie napiszę więcej już wkrótce) bardzo przywiązujemy wagę do tego, aby atmosfera pracy była ciekawa… Staramy się aby praca nie kojarzyła się z „pańszczyzną”… Nie ma u nas typowych dla większych firm relacji typu „pracodawca - pracownik” - partnerskie relacje między nami to codzienność… Praca dla nas, to nie jest konieczność, którą należy „odwalić” od godziny 8 rano do 16 po południu… To, co nas łączy, to wspólna pasja do komputerów, a przede wszystkim do internetu… Po prostu kochamy to, co robimy…

Co prawda nasza firma (piszę „nasza”, bo bardzo się z firmą identyfikuje) to nie Google (aktualna ilość pracowników i współpracowników w naszej firmie: 6), ale i tutaj zdarzają się rzeczy wykraczające poza obowiązki pracownika i pracodawcy :D Dwugodzinne pogaduszki (niekoniecznie o rzeczach związanych z pracą) przy porannej kawie, przerwa na pizze, a ostatnio nawet seanse „kinowe” - kilka tygodniu temu skusiliśmy się na film z naszego dzieciństwa - The Goonies (a co, wszyscy byliśmy dzieciakami), a ostatnio Star Wars - Episode I: The Phantom Menace (w planach obejrzenie całej sagi Star Wars). Takie dwugodzinne oderwanie się od pracy pozwala zapomnieć o stresie, oczyszcza umysł (gdy na przykład po kilku godzinach walki z jakimś skryptem nie możemy wpaść na poprawne rozwiązanie), umożliwia integrację pracowników i szefostwa… Myślę, że taka dwugodzinna przerwa raz na kilka tygodni firmie nie zaszkodzi (pod warunkiem, że nie stanie się to codziennością) - wręcz przeciwnie - pracownicy będą zadowoleni, że firma nie jest nastawiona na wyciskanie z nich ostatniej kropli krwi, ale stawia na pracowników, ich pomysły i na przyjazne relacje między kadrą…

Oczywiście w tym wszystkich nie chodzi o to, aby pracodawca organizował regularne seanse filmowe - to jedynie przykład z mojej firmy… Chodzi tu przede wszystkim o normalne relacje międzyludzkie i stosunek jednej i drugiej strony do siebie nawzajem - a najlepszą sytuacją jest, gdy podział na strony nie istnieje (tak jak ma to miejsce u nas)…

Czy Wy też pracujecie w takich firmach? A może prowadzicie takie firmy?

Polski Związek Niewidomych Okręg Śląski wraz z Agencją IArt stworzył projekt Widzialni, którego zadaniem jest zwrócenie uwagi opinii publicznej na problem dostępu do informacji w Internecie dla osób niewidomych i niedowidzących.

Taką informację możemy przeczytać na stronie widzialni.eu. Można tam też przeczytać o nowej, innowacyjnej technologii Eyescreener, która to, zgodnie z zapewnieniami na stronie „jest zgodna ze specyfikacjami W3C, WAI: AAA (zgodna ze wszystkimi trzema poziomami WCAG - dokumentu o dostępności).”. Nie byłoby w tym nic dziwnego, gdyby nie fakt, iż Agencja IArt, która jest „sprawcą” całego zamieszania, pod przykrywką promowania dostępności (a w zasadzie jej małego wycinka) nie promowała tak naprawdę siebie… Skąd takie przypuszczenia? To proste - wystarczy wczytać się w teksty umieszczone na stronie widzialni.eu:

opracowaliśmy unikatową w skali kraju a być może Europy technologię

Projekt Widzialni jako jedyny w Polsce posiada rekomendację Polskiego Związku Niewidomych o. śląski

Widzialni są prawdziwym prekursorem na polskim rynku idei dostępności i użyteczności stron internetowych

„unikatową w skali kraju, jedyny w Polsce, prawdziwym prekursorem na polskim rynku” - tymi jakże skromnymi słowami IArt promuje proponowane przez siebie rozwiązanie. Pytania nasuwają się same: dlaczego śląski PZN rekomenduje akurat ten projekt, dlaczego tylko jeden taki projekt jest polecany, skąd PZN wie, czy to jest dobre, czy złe? I na jakiej podstawie IArt twierdzi, że Widzialni są prekursorem idei dostępności i użyteczności??

Taki sposób promowania dostępności jest zły - w zasadzie jest to zaprzeczenie zasad dostępności. Dostosowanie strony tylko dla jednej dysfunkcji może spowoduje większe szkody niż strona niedostosowana - co widać chociażby na stronie widzialni.eu - niby dostępna dla niewidomych, za to dyskryminuje się osoby widzące i niedowidzące prezentując tekst ze zbyt małym rozmiarem fonta… Zamiast promować polecaną przez W3C inicjatywę WAI czy wytyczne WCAG (które to powinien znać każdy szanujący się webmaster), tworzy się „nowe”, nikomu niepotrzebne rozwiązania… Tymczasem dobrze zaprojektowana, z semantycznym, poprawnym kodem (x)HTML strona www jest jak najbardziej dostępna bez stosowania żadnych dodatkowych zabiegów czy narzędzi - i to nie tylko dla screenreaderów. Zatem po co wyważać otwarte już drzwi?

Taki sposób promowania w pewnym stopniu przypomina mi sytuacje z firmą IVO, która wmawiała internautom, że ich oprogramowania IWR (Intelligent Web Reader) jest jedynym słusznym i poprawnym rozwiązaniem na niedostępność w sieci (chociaż w rzeczywistości tak nie jest). Po za tym, czyż nie powinno być tak, że firma, która chce promować dostępność sama powinna zadbać o dostępność swojej strony?? Tymczasem „na dzień dobry” dostajemy wykonaną w technologii Flash opartą na tabelkach stronę…

Czy wam też zdarzają się tacy „wszystkowiedzącylepiej” klienci??

Co prawda nie obyło się bez drobnych problemów z kodowaniem znaków w bazie danych (nie ja pierwszy zresztą miałem taki problem), ale udało mi się jakoś przebrnąć przez te trudności. Trochę z tym było roboty, bo aktualizowałem z dosyć starej wersji 2.0.7, dlatego, aby upgrade był niezauważalny wszystko odbyło się w nocy…

No to został wykonany jeden z kilku punktów mojego planu dotyczącego tego bloga… Ciąg dalszy zmian nastąpi…

Cóż, czasem plany, nawet te najlepsze, przegrywają w konfrontacji z życiem codziennym… Nie oznacza to, że należy się poddawać… Ktoś, kto przeczytał tytuł tego posta mógł pomyśleć, że zamierzam się poddać, zamknąć bloga… Wręcz przeciwnie - po tak długich „wakacjach” postanowiłem „wybudzić” bloga z długiego, zimowego snu… Nie obiecuje, że będę pisał często (no, na pewno częściej niż raz na osiem, dziewięć miesięcy), ale zawsze uważałem, ze lepiej pisać rzadziej, a bardziej interesująco niż pisać codziennie o „dupie maryny”. Tak, wiem - w sieci dzieje się tak wiele ciekawego, że bez najmniejszego problemu mógłbym pisać codziennie… Jednak zakładając tego bloga, nigdy nie chciałem, aby powielał on informacje zawarte gdzie indziej… Oczywiście zawsze jestem otwarty na Wasze propozycje (o ile jeszcze ktoś czyta tego bloga) i jeżeli macie jakieś ciekawe tematy, to proszę o maila…

Koniec gadania… czas wziąć się do roboty…

Celem Identity 2.0 jest pomoc w zarządzaniu tożsamością w sieci. Więcej na ten temat możecie przeczytać na angielskojęzycznym blogu Identity 2.0, który niewątpliwie był inspiracją dla twórcy (twórców) polskiej wersji…

W „wyszukiwarce” wykorzystano AJAXowy skrypt AutoComplete, co pozwala na wpisanie jedynie kilku pierwszych liter poszuwanej właściwości. Skrypt pokaże wszystkie właściwości z wpisanym przez nas ciągiem znaków.

Przekierowanie do szukanej przez nas właściwości CSS możemy też szybko uzyskać wpisując w okno przeglądarki z której korzystamy nazwę właściwości po adresie, np.: cssdocs.org/font.

Istnieje też możliwość dodania „wyszukiwarki” do okna wyszukiwania w przeglądarce Firefox.

Via SitePoint.

Kiedy rozmawia się o różnego rodzaju standardach sieciowych, często wspominany jest XHTML. Wiele osób wierzy, że jest on przyszłością sieci. Jestem innego zdania i ten artykuł wyjaśnia moje rozumowanie.

• Trochę historii HTMLa
• XML wkracza na scenę
• „Sprawmy, by HTML działał jak XML”
• Problem z używaniem XMLa w sieci
• Nie możemy oczekiwać by początkujący używali XHTMLa

Trochę historii HTMLa

Dawno temu, w 1990 roku, pierwsze części HTML weszły w użycie. Został stworzony specjalnie do dokumentów naukowych i nie zawierał żadnych elementów strukturalnych. Pomysł był taki, aby to właśnie użytkownik decydował jak powinien wyglądać dokument; ostatecznie raporty czyta się dla ich zawartości, nie dla ich wyglądu. Docelową „publicznością” dla HTMLa byli oczywiście naukowcy i inni obeznani z komputerami ludzie: w jakimś sensie programiści.

Wkrótce sieć wkroczyła do głównego nurtu. Wszyscy surfowali w sieci i wiele ludzi posiadało swoje strony WWW. Ale nikt nie dbał o jakość kodu i większość stron zawierała poważne błędy. Pomimo tych błędów większość stron „jakoś działała”, to znaczy, wyświetlało się to, co autor chciał pokazać. Wszystko dzięki obsłudze błędów w aktualnych przeglądarkach.

Rozgniewana społeczność programistów/webmasterów od początku narzekała na zły kod i domagała się, byśmy zmuszali ludzi to tworzenia kodu poprawnego. W przeszłości byłem częścią tej grupy.

XML wkracza na scenę

Około roku 1998 ukazała się specyfikacja języka XML. XML jest językiem, który ułatwia konstruowanie własnych języków. Pomyśl o nim jak HTMLu, gdzie tworzysz swoje własne tagi, ale nie dopuszcza się tworzenia błędów. Programiści bardzo go polubili i szybko rozpowszechnili.

XML ma bardzo precyzyjnie zdefiniowaną obsługę błędów (w przeciwieństwie do HTMLa): kiedy parser znajdzie coś niespodziewanego zatrzymuje się i wyświetla błąd. Daje to przede wszystkim dwie rzeczy. Pierwsza z nich sprawia, że edytowanie XMLa bliskie jest „prawdziwemu programowaniu” - jeśli popełnisz mały błąd program nie kompiluje się. Druga: ponieważ nie ma potrzeby programowania obsługi błędów, parser staje się szybszy i łatwiejszy do napisania. Programiści czuli się jak we własnym domu.

„Sprawmy, by HTML działał jak XML”

Założono konsorcjum W3C i programiści z rozgniewanej społeczności HTMLa wywarła na konsorcjum wrażenie. W3C postanowiło zrobić coś w sprawie nędznego kodu pisanego przez ludzi i ustandaryzowała nowy język dla sieci. XHTML wziął tagi z HTMLa ale dostosowano język tak, by był zgodny z XMLem. Wynikiem jest język który może być (i powinien) parsowany jako XML.

Zatem wszystko jest dobrze? Nie. Gdy rozejrzeć się dookoła można zauważyć, że cholernie ciężko jest uzyskać aby XHTML parsował się przy użyciu tego samego parsera co XML w aktualnych przeglądarkach. Pozwólcie, że to wytłumaczę: aby zadecydować, którego parsera użyć, trzeba wysłać poprawy typ MIME ze swojego serwera. Jeżeli korzysta się z PHP można to zrobić tak:

<?php
if ( stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml") ) {
   header("Content-type: application/xhtml+xml");
}
else {
   header("Content-type: text/html");
}
?>

Ten krótki skrypt pyta przeglądarkę, czy poradzi sobie z XMLem i jeśli tak, to wysyła XMLowy typ MIME “application/xhtml+xml”. Jeśli przeglądarka nie poradzi sobie (Internet Explorer 6 i 7 nie dają rady) to wysyłany jest typ MIME “text/html” (gdzie błędy są tolerowane i poprawiane).

Ale to nie jedyna zmiana jakiej potrzebujemy. Pod koniec roku 2004 Ian Hixie napisał Sending XHTML as text/html Considered Harmful (uwaga: techniczne :D). Wczytując się w ten tekst można zobaczyć, że trzeba zmienić dużo więcej niż tylko typ MIME, jeśli chce się, żeby XHTML pracował zgodnie z zamierzeniem. Krótko rzecz biorąc: zrobienie tego poprawnie jest trudne.

Problem z używaniem XML w sieci

XHTML trudno jest parsować w sposób zgodny z zamierzonym w aktualnych przeglądarkach. Zamiast tego ludzie używający go decydują się (albo nie wiedzą że można inaczej) na parsowanie go tak, jakby był to HTML. Ale czyż nie pozbawia nas to największego powodu do używania XHTMLa? Jedyna różnica pomiędzy HTML 4.01 a XHTML jest taka, że XHTML może być parsowany jak XML! Tak długo jak będziesz parsować swój kod jak HTML nie ma powodu, żeby używać XHTML.

Jeżeli spojrzymy na specyfikację XHTMLa jest tam mała tabelka przedstawiająca które wersje XHTMLa powinny być wysyłane z jakim typem MIME. Widać tam, że można wysyłać XHTML 1.0 jako „text/xhtml” (MAY - czyli MOŻNA). Ale patrząc dalej do późniejszych wersji widać, że NIE POWINNY (”SHOULD NOT” - zaznaczone na czerwono) być one wysyłane jako „text/html”. Tak więc już wkrótce parsowanie XHTMLa jako HTML nie będzie dozwolone jeśli chce się podążać za standardami. Pozostaje parsowanie go (XHTMLa) jako XML.

Wyobraźmy sobie jakąś dynamiczną stronę która pozwala jej użytkownikom na dodawanie treści. Dobrym przykładem są komentarze tej strony. Jeśli ja używam XHTMLa (i parsuje go poprawnie) i ktoś użyje niewłaściwego kodu w komentarzu strona powinna przestać działać. Kolejny użytkownik wchodząc na stronę otrzyma brzydki komunikat błędu z numerem linii i jakimś kodem. Totalnie nie do zaakceptowania. Zatem powinienem znaleźć sposób na parsowanie HTML w moich komentarzach i naprawić błędy, które mogą zepsuć stronę. Ok.

Następnie kopiuje-wklejam (copy-paste) jakiś tekst ze strony i chcę go wam zacytować. Kiedy publikuję artykuł otrzymuję obrzydliwy komunikat błędu, ponieważ strona, z której wkleiłem tekst używa innego kodowania znaków i to „rozwala” mój XHTML. Po zbadaniu problemu okazuje się, że można to naprawić parsując cały tekst z panelu administratora i upewnić się że jest on poprawnie zakodowany w UTF-8 zanim zostanie zapisany w bazie danych. Ok.

Następnie ściągam trochę JavaScriptu i próbuję użyć go na stronie. Ponownie ludzie otrzymują okropny komunikat błędu prosto w twarz w momencie wejścia na stronę. Wydaje się, że JavaScript obsługiwany jest bardziej ściśle w XHTMLu i wymaga to używania takich dziwnych znaczków CDATA na początku i końcu skryptu. Ok, to też naprawiłem.

I tak kontynuując, małe błędy w kodzie sprawiają, że strona co chwila się „wywala”; również błędy w parserach którzy pozwalają ludziom na psucie mojej strony poprzez komentarze. Mam wykształcenie informatyczne, więc prawdopodobnie mógłbym naprawić błędy i ciągle łatać stronę dopóki wszystko nie będzie działać. Ale czy tego chcę? Co złego jest w obecnych metodach naprawy błędów, które zauważam w trakcie walidacji? A co z wszystkimi nieprogramistami?

Nie możemy oczekiwać by początkujący używali XHTML

Jak przeczytaliście powyżej, cholernie ciężko jest uzyskać poprawny XHTML. Jednak W3C przepycha XHTML jako nowy standard sieciowy. Pomimo tego, że ciężko będzię początkującym uzyskać stan poprawny. Pomimo tego, że trzeba bedzie przenieść obsługę błędów na każdą ze stron, zamiast na przeglądarki. Pomimo tego, że XHTML nie ma prawie żadnej kompatybilności wstecz, więc niemalże wszystkie strony w sieci będą musiały zaktualizować swój kod.

Nie, nie będę parsował wszystkiego jako XML na stronach, które tworzę. XHTML był od początku złym pomysłem i prędzej skłaniałbym się do rozwoju nowej wersji HTML pod nazwą Web Applications 1.0 (znanym też jako HTML 5).

Mam nadzieję, że ten artykuł wyjaśnia, dlaczego tak wiele blogów webdeveloperskich używa HTML (wliczając Friendly Bit). Którego języka używacie?

Od siebie dodam tylko tyle, że ciągle jeszcze wielu łepmajstrów nie jest w stanie nadążyć nawet za HTMLem…

Via Paweł Wimmer.