Pułapki wymieniam na: http://pornel.net/xhtml

BTW: void przy funkcji nick() jest mało przydatny :P

Jeżeli chodzi o probemy z XHTML to masz rację - dużo odpowiedzialność ponosi za to W3C - ale niemała w tym rola webdesignerów - zwłaszcza dużych agencji, firm, korporacji, które rzucają się na każdą nowość tylko po to, żeby wyciągnąć z tego kasę - podobnie jest z web2.0 i AJAXem i tak pewnie będzie z XHTML 2… Wciskaniu ludziom na siłę czegoś o czym ludzie nie mają pojęcia to kiepska droga do promowania standardów… A promować je trzeba - bo jak już wspomniałeś: przyszłość należy do XHTMLa… Czy tego chcemy czy nie :D Z tym tylko, że do promowania XHTMLa przydałyby się przykłady - a tych dobrych to ze świeczką szukać :D

fragment o składaniu długopisów (to w tym momencie „toczę pianę”?) w najmniejszym stopniu nie miał dotyczyć Ciebie - chodziło o ludzi, którzy mają problem z napisaniem validującego się dokumentu.
Poza tym uważam, że kolejną bzdurą jest stwierdzenie, że ludzie by sobie nie poradzili… składnia XML-a jest banalna, validator opart na XML Schema (bo raczej nie DTD) mógłby wskazywać błędy bardzo precyzyjnie łącznie z podpowiadaniem jak powinno być dobrze - każdy byłby w stanie napisać validujący się dokument - z pewnością nawet moja mama. Problem mogliby mieć dopiero np. z JavaScriptem.
Hmm.. i chyba dochodzę do wnoisku, że to w sporej części wina W3C, że tak to nie wygląda…

Moje wykrzykniki z początku to zabieg stylistyczny.. im większa bzdura padała w tym artykule tym mocniej ją autor akcentował - tym mocniej akcentowałem swą ripostę ja.

Jeśli to nie Twój artykuł, to tym bardziej nie powinieneś brać tego do siebie :)

Ad. tercio: No c’mon… ludzie, którzy wiedzą jak używać nie wiedzą jak go tak naprawdę używać? ;)

Ad. quarto: faktycznie ta technoogia wciaż wygląda na młodą… niby wszystkie narzędzia są, ale powinny być lepsze, czyt. łatwiejsze, podobnie materiały szkoleniowe itd..

Podsumowując: może i konkluzja artykułu jest w jakiś sposób prawdziwa (nie licząc tych (imo) bzdurnych stwierdzeń z początku), ale artykuł daje złe wyobrażenie o tej technologii, błędne, jest naciągany… to szkodliwe, bo teraz ludzie zaczną się tego bać, a naprawdę nie ma czego…

Dobry XHTML 1.0 to poprostu validujący się dokument, w tej wersji XHTML-a można sobie odpuścić application/xhtml+xml (może i tak nie miało być, ale na tym obecnie staneło). Większość ludzi i tak nie będzie potrzebowało rozszerzać tego języka, więc niech poprostu piszą validujące się dokumenty - to na początek wystarczy.

Hmm.. trzebaby się zabrać za promocję tego języka jakoć mocniej :)

// A zacząć by od siebie…

„Ale czyż nie pozbawia nas to największego powodu do używania XHTMLa?”
Nie.

„Jedyna różnica pomiędzy HTML 4.01 a XHTML jest taka, że XHTML może być parsowany jak XML!”
Bzdura!

XHTML od HTML różni się przede wszystkim X-em. Ten X to skrót od ‚eXtensible’. To ‚eXtensible’ sprowadza się do dodania atrybutu ‚xmlns’ w XHTML 1.0 i modularyzacji XHTML (w kolejnych wersjach/wariantach). To ‚xmlns’ oraz modularyzjacja to ogromna różnica w stosunku do HTML (i bynajmniej nie zanika ona jeśli parsujemy dokument jako HTML - to w niczym nie przeszkadza).

Ten ‚X’ pozwala nam tworzyć XHTML Host Lanuages (XHTML Basic, XHTML Print, nasze wlasne..), dodawać atrybuty których potrzebujemy (np. a aplikacjach), wplatać w kod XHTML zupełnie niezwiązane z nim języki, no i „last but not last” - pozwala(ł by) nam budować Sieć Semantyczną.

Parsowanie jako HTML to wręcz pomijalna w obecnych czasach zaleta.

XHTML2 to marzenie - naprawia prawie wszystko to, co tak drażni i nie pozwala pisać naprawdę logicznego kodu HTML.

To nieuzasadnione niczym poza ekonomią zachowawcze zachowanie Microsoftu w największym stopniu hamuje rozwój sieci.

„Wiele osób wierzy, że jest on przyszłością sieci. Jestem innego zdania i ten artykuł wyjaśnia moje rozumowanie.”

XHTML __JEST__ przyszłością sieci - nie można mieć innego zdania mając dobre wyobrażenie o tym czym XHTML jest i jakie możliwości daje.

Jak ktoś ma problem z napisaniem poprawnego syntaktycznie kodu XHTML, to powinien się zająć składaniem długopisów.

Co do nazwiska to przepraszam, bez okularów dzisiaj coś słabo widzę :D

A tak przy okazji Michale widzę, że zmieniłeś swoją stronę :D Ciekawy, ascetyczny design…

Mi jako twórcy nie zależy na tym żeby parsowany XML pokazywał błędy, XML (mam na myśli np źródła RSS) tworzą ludzie i to oni najcześciej zawodzą, w trakcie testów parsera przetestowałem około 1000 feedów napotykając co chwile na jakieś kwiatki, niezgodne ze specyfikacjami (można by o tym pisać godzinami).

W dzisiejszych czasach zalewa nas tak duża ilość informacji, że niemożliwością jest żeby choćby najlepszy i najszybszy admin jakiegoś tam portalu przetestowował każdą z nich w każdym miejscu do jakiego dociera.

Podsumowując XHTML, XML - TAK, ale na początku z mechanizmami idiotoodpornymi tak jak jest to w przypadku parserów HTML, + ewentualna możliwość włączenia raportowania błedów na żądanie. W innym wypadku bedzie to specyfikacja świetna i martwa. Wyłączenie raportowania błędów na pewno przyczyniło by się do popularyzacji XHTML’a, a umiejetności programistów z czasem osiągnęły by akceptowalny poziom.

Pozdrawiam Piotr Jóźwiak

Problem z XHTML wynika nie tylko dlatego, że ludzie do niego nie dorośli. Nie dorosły do niego przede wszystkim przeglądarki (chodzi tu głównie o IE), które nie potrafią poprawnie go (XHTMLa) parsować.

Problemem jest nie tylko to, że branża jak to powiedziałeś „zastygła” - nie dorośliśmy nie tylko do XHTMLa, ale nawet do HTMLa - wystarczy spojrzeć jak wiele jeszcze stron posiada błędy semantyczne, ramki, tabelki do layoutu… Czy do tego został stworzony HTML? Nie sądze…