WebForms, WebApps, WebControls

Gdy większość grzecznie czeka na XHTML2, są tacy, którzy twierdzą, że choć następna wersja XHTML zawiera doskonałe rozwiązania dla hyperlinków, multimediów czy semantyki utworów literackich i dokumentów naukowych, nie oferuje niczego co może przydać się w przypadku zwykłych stron WWW (np: na forach dyskusyjnych, w sklepach internetowych) czy aplikacji webowych.

Grupa ta nazywa się Web Hypertext Application Technology Working Group(WhatWG) i skupia osoby prywatne, producentów przeglądarek (m.in. Apple, Mozilla i Opera) oraz grupy ściśle zainteresowane rozwojem technologii sieciowych. W chwili obecnej pracuje nad trzema specyfikacjami – Web Forms, Web Applications (zwany również HTML5), Web Controls.

Web Forms zawiera nowe elementy i rozszerzenia już istniejących elementów (znanych z HTML) użyteczne na typowej stronie internetowej. Web Applications ułatwia tworzenie aplikacji webowych (np obsługa kontrolek RTF, menu, pasków narzędziowych). Web Controls w zamierzeniu rozszerza funkcjonalność Javascript i CSS.

Najbardziej zaawansowana i najbliższa realizacji, na tę chwilę, jest specyfikacja Web Forms 2.0.

Zgodnie z tym, co powiedział CEO Opery, Opera implementuje aktualnie obsługę Web Forms 2.0, a Firefox 1.1 powinien zawierać obsługę canvas.

HTML5 na tę chwilę nazwany jest WebApps i jego specyfikację można zobaczyć tutaj.

HTML5

XHTML był dobry dla Sieci. Bez wątpienia. Jego pojawienie się wywołało w niej pozytywny ruch – ludzie zaczęli przebudowywać swoje strony. Wszystko spowijała mgła haseł takich jak “dostępność”, “użyteczność” czy “kompatybilność”.
Dowiedzieliśmy się, że meta tagi są złe, że <font> jest passe, a za budowanie szablonów na tabelach będziemy smażyć się w piekle. Wiele osób próbowało stosować <div> i CSS, nieudolnie zastępując swoje tabelowe szablony nową technologią – w imię “semantic markup”, którego na dobrą sprawę nikt, poza garstką oświeconych, nie rozumiał i bzdury numer jeden: strony walidujące się w XHTML wyglądają wszędzie tak samo. Ci, którzy chcieli zrozumieć, bądź robić po swojemu, byli odsyłani do Google, AListApart czy HTML Dog i zapraszani ponownie gdy przyswoją sobie ten zakres wiedzy.

Część się czegoś nauczyła. Reszta dalej nie wie dlaczego <div> jest lepsze, dlaczego nie może umieścić <p> w <p> i jak należy korzystać z sekcji i klas – co w prostej linii doprowadziło do kolejnej choroby Sieci – divitis i classitis. Ba, spora część ludzi wciąż sądzi, że &nbsp; służy do tworzenia odstępów i nie rozumie semantyki (na dobrą sprawę sam się często zastanawiam co faktycznie jest lepsze z semantycznego punktu widzenia).

Nieszczęsny text/html

Chociaż po wydaniu XHTML1 i planach wydania XHTML2 oraz XForms, nikt nie przypuszczał, że dla text/html istnieje jakaś przyszłość – jednak istnieje!
WHATWG dostrzega fakt, że pozostanie kompatybilnym wstecz jest wciąż ważne, nawet w nowoczesnej Sieci. Jedną z głównych idei przyświecających grupie jest dodanie do HTML obsługi błędów. Jako, że domyślnie, HTML był językiem nie zawierającym żadnej metody obsługi błędów, należało stworzyć metodę radzącą sobie z nieprawidłową składnią – nazywaną czasem tag-zupą (tag-soup). Jako, że przeglądarki zaimplementowały tę koncepcję na swoje sposoby, strony były wyświetlane na różne sposoby, ponieważ drzewo DOM po sparsowaniu dokumentu, nie wyglądało w żadnej z nich tak samo.

W czasie, gdy tworzono XML ten problem ponownie wyszedł na światło dzienne. Rozwiązanie zastosowane w XML można nazwać drakońskim – w przypadku napotkania błędu, parser po prostu przestaje renderować dokument i wyrzuca komunikat o błędzie, pozostawiając użytkownika z niczym. Co gorsza, problem ten rozszerzył się także na RSS, oraz Atom Feed, który również nie zawiera żadnego, sensownego, rozwiązania tego problemu. Językiem, w którym udało się umieścić bardzo przyjemną formę obsługi błędów jest CSS. Oczywiście, w początkach implementacji zdarzały się “potknięcia”, jednak obecnie w przypadku popełnienia błędu w CSS, pozostałe elementy arkusza i tak zostaną poprawnie wyświetlone. Można to nazwać “user-friendly”.

Jak zostało już wspomniane – HTML 5 zapewni metodę parsowania dokumentów kompatybilną w przód jak i wstecz. Oprócz tego, HTML5 oczyszcza i rozwija specyfikację HTML4, definiuje zależności względem drzewa DOM oraz, w miarę możliwości, wprowadza nowe obiekty i elementy do specyfikacji. HTML5 będzie zawierał także specyfikację Web Forms 2, która jakiś czas temu została zgłoszona do W3C. HTML5 to także element CANVAS.

Pikselami po płótnie czyli czym jest CANVAS

CANVAS to bardzo sprytny element strony – jego wymiary są zależne od rozdzielczości strony i służy on z grubsza do prezentowania grafik, wykresów, paneli gier, w czasie rzeczywistym.

HTML5 vs XHTML

Jako, że HTML5 i XHTML korzystają z innego namespace nie ma obaw, że pojawią się problemy z korzystaniem z obu. Co więcej – elementy HTML5 prawie na pewno znajdą się w kolejnych wcieleniach XHTML. Co na pewno się zmieni, to fakt, że Załącznik C specyfikacji XHTML (Appendix C, informacje o media type) stanie się przestarzały i niepotrzebny.

Powiązane wpisy:

  1. W3C skupi się na HTML5
  2. Przegląd edytorów (X)HTML, część 1 – wprowadzenie
  3. Opera dla komórek – bug?
  4. HOWTO: Wannabe Web Standards Advocate
  5. Hell i on czyli rzut oka na Projektowanie serwisów WWW