Do tematu jakiś czas temu nawiązał już Riddle. Nowomodni webmasterzy dostrzegli w logo Valid XHTML
wartość samą w sobie. Coś, jak odznaka sprawności harcerskiej, kolejna pozbawiona sensu plakietka do zapchania stopki na stronie. Nikt nie rozumie, czym jest XHTML i czym różni się od swojego starszego kuzyna.
Najważniesze, żeby strona się walidowała,
mniejsza o to, czy walidacja dla samej walidacji ma jakąkolwiek wartość. Niewygodną treść wystarczy zepchnąć do zewnętrznych plików, a te nie podlegają już władzy wszechmocnego narzędzia W3C. Można spać spokojnie.
Dziś, za pośrednictwem pytania Andreasa z Web Graphics, trafiłem na inny wynalazek - FlashObject. Jak łatwo się domyślić, jest to kolejna uświęcona
metoda zagnieżdżania niepoprawnego kodu w poprawnym
dokumencie. Jak czytamy na stronie projektu, ma on na celu umożliwienie zagnieżdżenia obiektów Flash widocznych w starych i zepsutych wersjach Safari i Internet Explorera dla MacOS.
Główny problem polega na tym, że przeglądarki te wymagają niepoprawnego kodu, więc całość została zamknięta w niewielki skrypt JS i efektywnie ukryta przed walidatorem. Zgodzę się, że często wsparcie dla takich przeglądarek jest wskazane, ba, czasem wręcz nieodzowne. Jednak mówimy o starych przeglądarkach, które nie potrafią wykorzystać najmniejszego nawet kawałka nowych technologii. Nie wspierają też XHTML serwowanego jako application/xhtml+xml, jaki jest więc sens upierania się przy stosowaniu XHTML? Dużo prościej byłoby użyć typu dokumentu, który jest zaprojektowany dla wsparcia przestarzałych elementów i atrybutów. Używanie XHTML 1.0 Strict nie niesie ze sobą żadnych korzyści poza wymuszaniem stosowania brzydkich hacków, które mają naprawiać to, co zepsute jest gdzie indziej - w przeglądarce.
Na koniec podkreślę jeszcze raz, że walidator jest narzędziem dla osoby budującej witrynę, a nie dla odwiedzających. Oszukiwanie go to jak okłamywanie własnego doradcy i pomocnika, a wklejenie żółtego guziczka za wszelką cenę nie ma najmniejszego sensu, ale o tym szerzej w następnym numerze webesteem art & design magazine.
Po pierwsze do powyższych wniosków trzeba dorosnąć. Po drugie "valid XHTML 1.0 Strict!!!" to moda. A niestety moda i dorosłość niewiele mają ze sobą wspólnego…
Z drugiej strony to, co mówisz, też ma swoją dosyć mocną reprezentację w Sieci. Istnieje sporo stron/blogów ludzi "bardzo mocno świadomych", które są specjalnie kodowane w HTML — np. Anne (http://annevankesteren.nl/) z jego HTML 4.01 i ostetacyjnie wręcz niepozamykanymi paragrafami :-) Obawiam się, że czasami również to nie ma uzasadnienia i po prostu kiełkuje tutaj odwrotna moda - "HTML uber alles". A moda … patrz początek ;-)
Niestety do zrozumienia co to jest X w XHTML i kiedy być powinien, kiedy nie koniecznie, a kiedy jest wręcz szkodliwy, potrzeba trochę inteligencji. A to jak wiadomo towar bardzo deficytowy…
No cóż, Internet miał być medium "dla wszystkich" :/
I widać efekty.
1. "Nikt nie rozumie, czym jest XHTML i czym różni się od swojego starszego kuzyna." to dość autorytarne stwierdzenie. Co za różnica dla Ciebie, dla przeglądarki, dla usera, czy strona jest w XHTML czy HTML 4.01, jeśli nie używasz gdzieś po drodze XML?
2. Mało logiczne te Twoje wnioski. Stawiasz tezę, że duszenie kodu do XHTML Strict jest bez sensu… potem dziwisz się, a raczej marudzisz, że ludzie robią misz-masze i ukrywają niewygodne hacki poza widokiem walidatorów. A przecież i walidatory, jak zresztą napisałeś, są funkcjonalnym narzędziem, którego warto używać. I bez sensu byłoby, żeby wyłapywały hacki, które sam znasz. Nie patrzysz na to z tej strony?
I oczywiście disclaimer: ja się nie znam, nie zajmuję się kodowaniem stron internetowych, jeśli już to bardzo głębokim server-side. Więc pewnie się mylę…?
misia:
Rzecz w tym, że hacków się używać *nie powinno*.
Enleth: i Ty nie stosujesz hacków, tylko wypluwasz pure XHTML Strict ze swojego php, tak?
misia: a czemu nie?
Enleth: a po co? nie lepiej z dziewczyną do kina? na co Tobie albo userowi XHTML Strict, jeśli nie masz nigdzie po drodze XML/XSLT? wicie? bo ja nie wim.
:D
(Dla wyjaśnienia: enleth.jogger.pl)
Enleth: no i to jest jakiś argument:) Gratulacje, bo dobra robota!
btw, XSLT jest *silnie* wykorzystywany już od dłuższego czasu w aplikacjach webowych - najbardziej odjechanym przykładem jest Cocoon.
I teraz jedno ważne pytanie: stosuje się XML, żeby mieć XHTML Strict, czy raczej XHTML Strict, żeby mieć XML… Bezpodstawna pogoń za XHTML jest przemalowanie samochodu na różowo - rzuca się w oczy, choć brzydkie jak diabli.
Quote: Po drugie "valid XHTML 1.0 Strict!!!" to moda.
XHTML 1.0 Strict to bardzo ładna specyfikacja (w ogóle technologie oparte na XMLu wydają się ładne), gdyby wszystkie strony, działające we wszystkich przeglądarkach stosowały się do niej, na wszystkich stronach treść byłaby oddzielona od struktury, et caetera, świat byłby piękny. To o czym Patrys pisze, to stosowanie brzydkich hacków, *tylko* po to żeby strona się walidowała, dążenie do 0 błędów za wszelką cenę, bez patrzenia na założenia przyświecające twórcom standardu.
Oczywiście możliwe, że napisałem jakieś straszne bzdury, ostatnio robię wszystko byle nie zajmować się technologią.
@Kelner: XML nie jest łatwy, XML jest wymagający. Pliki XML nie są ładne. Ludzie nie są parserami XML. Moda na pliki konfiguracyjne XML jest zła. A oddzielenie treści od struktury… no nie wiem, czy to takie proste, jak piszą w kolorowych reklamówkach ;)
Oddzielenie wyglądu od treści jest bardzo proste i osiągalne, a jeśli *potrzebujesz* hacków, żeby strona działała we wszystkich przeglądarkach, to - zamiast hacków - powinieneś użyć innego DOCTYPE. Ot i cała sprawa. Proste?
@Patrys: true z jednym tylko zastrzeżeniem, że ekstrakcja konkretnych treści z XHTML bez kontekstowej schemy (gdzie mam szukać cukierków, a gdzie baloników) jest niemożliwa mimo, że to ładny XHTML ;)
misia:
ale wiadomo, że coś jest nagłówkiem, coś cytatem, coś skrótem, coś kolejnym paragrafem i tak dalej. Przeglądarce czytającej tekst niewidomemu to starczy dla poprawnego czytania. font size="22" nie bardzo.
Enleth: oczywiście. Ale odcedzenie treści ze stron takich, jak http://www.wp.pl/, nie stało wiele łatwiejsze ;)
Bo strony WP nie są poprawne. Może i walidator informuje o tym, ale tak nie jest.
Enleth: może i nie są, ale nie w tym rzecz - chcę, dla przykładu, pobrać z tej strony listę wiadomości dnia. I za diabła tego bez schemy opisującej treść (której nie ma, bo raczej się jej jeszcze nie robi) nie namierzę.
misia:
Od takich zabaw jest XMLRPC albo SOAP. (X)HTML jest dla agentów. A strona WP jest tragiczną zlepką divitis z hatemelus presentalis.
Patrys:
nie chcę już polemizować, bo temat mocno schodzi na aplikacje rozproszone, a ja mogę się łatwo rozgadać ;) Anyway, chyba jeszcze tego nie mówiłem: odwalasz dobrą robotę. Jakbym miał coś dodać: więcej kreatywności, mniej narzekania ;). No ale taka pora roku, że mi też się nie chce.
misia:
Z doświadczenia wiem, że ludzi najłatwiej przekonać przez antyprzykład ;]
no pff, ponarzekam sobie, Patrys, to juz bylo. Przychodzi Ci walczyc z demencją na stare lata. Weź porusz jakiś nowy temat, bo o "script kiddies html'a" juz pisałeś ;]
"Rzecz w tym, że hacków się używać *nie powinno*."
Kompletna bzdura. Już co najmniej kilka osób pisało, i ja się pod tym podpiszę, że "hack" to złe określenie poprawnej techniki. Lepszym słowem jest "obejście" - bo niestety, nie żyjemy w idealnym świecie, w którym wszystkie przeglądarki jak jeden mąż renderują strony zgodnie ze standardem, który w wielu kwestiach pozostawia zbyt szerokie możliwości interpretacji.
Nie wspominając o tym, że to, co dziś jest hackiem - jutro może być standardem. Przykład pierwszy z brzegu: IFR i sIFR.
Najbardziej dobijają mnie ludzie, którzy twierdzą, że XHTML serwowane jako text/html to istne zło, a sami je tak serwują… [o mime-type nie świadczy 1 wiersz kodu] Ehh, odechciało mi się komentować :/
A gdzie masz takich ludzi? Póki co, ledwo kilkanaście procent rynku jest w stanie parsować XHTML serwowany jako XML.