Tak zdechł XHTML i chuj mu na grób

03 Jul 2009

(ten grób pochodzi z piosenki Arkadiusz by Homo Twist)

I badzo dobrze, bo miejsce pięknych standardów jest w muzeach utrzymywanych z pieniędzy podatników zarabiających dzięki standardom, które wprawdzie piękne nie są, ale są za to (by sparafrazować profesora Bartoszewskiego) sympatyczne.

Gęba pełna frazesów

Kiedy byłem pięknym młodzieńcem zwykłem głosić z przekonaniem, że każdy problem da się rozwiązać w standardowy sposób. Jeśli rozwiązanie nie posiada szablonu rozwiązania to należy go stworzyć i ustandaryzować, bo przecież na wszystko da się znaleźć wystarczająco obszerny algorytm czy format. Ponadto dobre rozwiązanie powinno cechować się uniwersalnością, zatem wszystkie pośledniejsze rozwiązania powinny zostać uogólnione za pomocą dodatkowej warstwy abstrakcji. I te pe, i te de, kosmiczna harmonia i zen.

Szybki reality check

Teraz pobawimy się w grę fabularną i ja będę twoim mistrzem gry. Możesz sobie stworzyć avatara, ale nie musisz, bo wynik rozgrywki mogę ci zdradzić już teraz – będąc wielbicielem XHTMLa wielkiego sukcesu nie odniesiesz. I nie myśl, że poniższa gra nie ma wiele wspólnego z developersko-biznesową rzeczywistością. Ma całkiem sporo – straciłem już dawno nadzieję, że życie zacznie mnie nagle rozpieszczać bardziej sensownymi wyborami.

Dołączasz do zespołu tworzącego aplikację WWW. Jest już napisane trochę kodu, który raczej słabo się waliduje. Poziom wiedzy pozostałych członków zespołu jest zróżnicowany: kilku gości świeżo po studiach, jeden nadęty mastahaka, dwójka całkiem sensownych develi. Co robisz?
Zaczynasz tworzyć brakującą funkcjonalność pozostawiając kod niezgodnym z żadnych ze standardów byle tylko działał w FF i IE
Przepisujesz aplikacją na zgodną z XHTML

42

Odpowiedzią na większość problemów, z którymi miałem szansę się zmierzyć była dziwna mieszanka solidnej inżynierii, doświadczenia, dystansu do technologii, szczęścia, paniki, braku czasu oraz jasna konieczność indywidualnego podejścia do zagadnienia. Wszelkie automaty, uniwersalne formaty i metasilniki okazywały się niewłaściwe, w najgorszym przypadku uniemożliwiały wykonanie zadania. Architektoniczni astronauci budują piękne cacka, których nikt nie potrafi poprawnie używać. Dokładnie takie samo zdanie mam o XHTMLu. Jest to przeteoretyzowany gniot, produkt myśli obsesyjnego purysty, który w zamierzeniu ma łączyć cechy XMLa i HTMLa. Byłoby fantastycznie gdyby łączył ich zalety, ale niestety łączy również ich wady. I jest to bardzo zła wiadomość, bo o ile zalety obu formatów czasami bywają przydatne, to ich połączone wady zawsze stanowią przeszkodę. Gdyby było inaczej to wszyscy z uśmiechem na twarzy używalibyśmy takich pereł architektury jak XHTML, SOAP czy CORBA, tym czasem wszystkie wymienione chętnie widziałbym w tym samym miejscu, w którym obecnie znajduje się Betamax.

Digg del.icio.us StumbleUpon Wykop Reddit Folksr

permalink | trackback | rss

 
 
Michał Górny

Polecam ortografię oraz stosowanie <EXCERPT> (takie piękne, zupełnie niepodobne do XML-a, na pewno ci się spodoba!). Gwoli ścisłości, możesz obejrzeć jak teraz notka wygląda na głównej.

Ja wiem, że niektórzy lubią fapować do swojego document.write() i document.cookie, a potem grozić usunięciem konta tym, którzy z tego document.cookie sobie pożyczą czyjeś ciacho z sesją; ale rzeczywistość nie jest czarno-biała i taka „zgodność” wiąże się z faktycznymi problemami.

No i ostatecznie — co ma porzucenie rozwoju XHTML2 do „zdechnięcia XHTML-a”? Przecież W3C wyraźnie zaznacza, że w „jedynce” jeszcze bugi poprawi. XHTML2 to może faktycznie nie miał racji bytu ze względu na trudności z kompatybilnością; XHTML1 może jest nie do końca przemyślany, ale pewną zgodność ma — a tym sensowniejszą oferować będzie X/HTML5.

Swoją drogą, wskaż mi takie genialne komercyjne narzędzie, które poradzi sobie z zupą i anarchią HTML-opodobną, a umrze na widok xmlns.

stronger

Michał, nie widziałeś nigdy "parsera" XML/HTML opartego o ręczne wyszukiwanie znaczników w ciągu tekstowym? Nie miałeś do czynienia z dokumentem XML, który z poprawnym XML-em miał tylko wspólne rozszerzenie pliku? Nie przetwarzałeś nigdy danych z jakiegoś rich-text editora? Jeśli rzeczywiście nigdy Ci się nic takiego nie przytrafiło, to gdzie Ty pracujesz? I czy mogę wysłać tam swoje CV?
Co do narzędzi - tydzień temu (poprzednia notka) musiałem ręcznie rozwalać wiadomość SOAP by dodać do niej WS-Security, bo PHP nie wspiera WSSE. Za pierwszym razem zrobiłem to źle pomijając zadeklarowanie odpowiedniego xmlns. Czy myślisz, że na serwerze, do którego wysyłałem tego SOAPa zrobiło to wrażenie? Ani trochę. I to tyle w temacie trzymania się standardów przez developerów.
(Gdzie te orty?)

a

s/swierzo/swieżo/

> Czy myślisz, że na serwerze, do którego wysyłałem tego
> SOAPa zrobiło to wrażenie?

Zacytuję: "Be liberal in what you accept, and conservative in what you send"

Michał Górny

> Michał, nie widziałeś nigdy "parsera" XML/HTML opartego o ręczne wyszukiwanie znaczników w ciągu tekstowym?

No i czym takiemu parserowi poprawny XML zaszkodzi? Fragmenty typowo XML-owe IMO ominie. Chyba że jest skrajnie beznadziejny, to ewentualnie na /> może głupieć.

> Nie miałeś do czynienia z dokumentem XML, który z poprawnym XML-em miał tylko wspólne rozszerzenie pliku?

No dobra, ale co to ma do tematu? Weź mi wytłumacz, w jaki sposób istnienie XHTML-a koliduje z możliwością parsowania dokumentów jako HTML. Ba, są całkiem inteligentne parsery (aczkolwiek raczej nie w PHP), które potrafią z tagzupy zrobić całkiem ładny XHTML.

(a orta już nie widzę, więc albo poprawiłeś, albo oślepłem, gdzie obie opcje są równie prawdopodobne)

stronger

"Be liberal in what you accept, and conservative in what you send"

Czy to właśnie nie takie podejście owocuje zupą tagów w HTMLu? (ort poprawiony, dzięki)

stronger

Całkiem inteligentne parsery są również i w PHP, problem leży gdzie indziej. Gdy patrzysz na super-wykoncypowany format to zapewne nie możesz mu nic zarzućić i tak właśnie jest z XHTML. Problem jest jak zwykle z bezpośrednimi konsumentami tej technologii - developerami. Beznadziejny kod napisany przez jakiegoś gościa, z którym przyszło ci pracować to chleb powszedni. Parsowanie za pomocą strpos() bez uwzględnienia ns wyłoży się na łopatki.
Natomiast, skoro twierdzisz, że inteligentne parsery potrafią poprawić chwasty w HTML, to dlaczego nie można ich użyć w przeglądarce zamiast powoływać nowy, lepszy standard, którego i tak spora rzesza klepaczy kodu nie będzie przestrzegać?

Michał Górny

> Parsowanie za pomocą strpos() bez uwzględnienia ns wyłoży się na łopatki.

Po raz kolejny pytam — w którym miejscu? No chyba, że nie zamierzasz w XHTML-u dawać elementów HTML-a w główny NS, ale to już twój strzał w stopę.

> Natomiast, skoro twierdzisz, że inteligentne parsery potrafią poprawić chwasty w HTML, to dlaczego nie można ich użyć w przeglądarce zamiast powoływać nowy, lepszy standard, którego i tak spora rzesza klepaczy kodu nie będzie przestrzegać?

Równie dobrze możesz pytać po co było wymyślać CSS, skoro <font/> działało. CSS zapewnił znaczącą separację treści od wyglądu, XHTML1 ograniczył możliwość ustalania wyglądu w kodzie HTML-a — ale to w dalszym ciągu jest ten sam, zabytkowy HTML.

Policz sobie liczbę <div/> na stronie — to jest doskonały przykład, że coś z nim jest nie tak. HTML semantycznie jest wyjątkowo biedny, są niby akapity, listy, nagłówki — i to właściwie wszystko. Spójrz sobie na HTML5, na dodane tam elementy. Tego właśnie brakuje staremu HTML-owi, i po to się pracuje nad czymś nowym.

Jajcuś

XHTML 1.0 jest całkiem ok: HTML 4.01 zapakowany w ładną składnię XML. Połączone zalety obu. Niestety ktoś sobie wymyślił, że w dalszych wersjach XHTML należy zerwać z kompatybilnością z HTML. To nie mogło się udać, więc projekt padł.
Byłbym za tym, żeby XML był standardem dla przyszłych HTMLi, ale bez tej zbędnej ideologii i zrywaniem kompatybilności bardziej niż XHTML 1.0. I pewnie jakieś „X/HTML5” powstanie (jeśli sam HTML5 nie przewiduje jakoś zapisu w XML). Bo to ma sens.

lukasz

A czy w HTML5 będzie już można wstawić coś innego niż tekst w <noscript> ? Jak na razie jest to jedyna możliwość przekierowania (z meta) gdy brak JS... A to już zgodne ze standardami nie jest ;)

A tak do tematu, cały wywód o relacjach ja-inni pracownicy jest bardzo życiowy... Jednak czasami robi się też coś samemu. Firmy mają to do siebie że robią wszytko byle jak gdy pracownicy znają tylko podstawy "pajączka". Chyba że coś się przez ostatnie lata zmieniło i jest nagłe oświecenie, nie wiem, nie pracowałem.

stronger - chciałbyś montować paser konwertera, takiego dokładnego? Toby wydłużyło znaczeni wczytywanie stron.

Michał Górny - co widzisz złego w dużej ilości <div>?

Dodek

lukasz: Górnemu chodzi o to, że div jest tak semantyczne jak napis "pudło z przedmiotami" na pudle z przedmiotami.

szym0n

@Jajcuś, "[...]że w dalszych wersjach XHTML należy zerwać z kompatybilnością z HTML[...]" mógłbyś rozwinąć ? rozumiem że chodzi Ci wyłącznie o nazwy znaczników i części atrybutów tychże ? bo składnia przecież się przy przejściu z html do xhtmla zmieniła... a jeśli chodzi Ci właśnie o te nazwy (znaczników) to przecież htmle nie były wstecznie kompatybilne :> historycznie nie zachowywano ani składni ani "semantyki".

Nie rozumiem autora wpisu, co z tego że uwalono xhtml 2.0, przecież html 5 też będzie standardem do którego trzeba będzie się stosować... i tak dalej wstecz, XML&XHTML zrobiono właśnie dlatego że poprzednie rozwiązania były dla ludu zbyt trudne, więc jak zrezygnujemy z XHTMLa w ogóle (pomijam html5 który jest bytem samym w sobie ;) a nie "aplikacją" sgmlową czy xmlową) to tylko sobie pogarszamy sytuację. W zasadzie trzeba by się cofnąć przed html 2.0. Imho nie zanosi się na to. Ogólnie ten wpis wydaje mi się idiotyczny, ale jako operator taczki i wideł nie czuję się na dość mocnej pozycji żeby tego stwierdzenia bronić.

Szymon

no zapomniałem o XHTML-u 5 ;F

Szymon

The second concrete syntax uses XML, and is known as "XHTML5". When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an "XHTML5" document. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent an XML document from being rendered fully, whereas they would be ignored in the "HTML5" syntax.


Umarł Król, Niech Żyje Król ^^

stronger

Michał, z tym CSSem to grubo przesadziłeś. Wprowadzenie CSS rozwiązywało konkretne problemy. Jakie problemy HTMLa rozwiązuje XHTML?

strpos($html, '<jakis-tag>') się wyłoży gdy jakis-tag opakujesz w namespace - moj-ns:jakis-tag.

Co złego jest w div-ach? Jakie korzyści płyną dla odbiorcy strony z tego, że programista zamieni <div> na <section>?

Szymon

"Jakie problemy HTMLa rozwiązuje XHTML?"

html będąc aplikacja sgmlową odziedziczył po nim różne fintifluszki. Mi tam nie przeszkadzały (mogę nawet powiedzieć że je lubię), ale dla większości były nie do przyjęcia (tak jak cały SGML). Ponieważ XHTML nie jest aplikacją SGMLową tylko XMLową (a SGML jest znacznie bogatszym językiem niż XML) więc odpadło bardzo dużo złożoności która się ludziom nie podobała (o twórcach przeglądarek nie wspminając). Prostsze parsery. XSLT zamiast DSSSL, i tak dalej. Krótko mówiąc mniej rzeczy do groknięcia. A że biednie to trudno.

tdudkowski

"pozostawiając kod niezgodnym z żadnych ze standardów byle tylko działał w FF i IE"

W aktualnych wersjach FF i IE. Co kiedy wychodza nastepne, czesciowo zgodne? Co z Safari, Chrome i Opera? Standaryzacja to dobra rzecz, przydaje sie nie tylko hydraulikom.

stronger

W dalszym ciągu nie wiem jakie konkrente problemy adresuje XHTML. Co ma z tego odbiorca strony? Czy obchodzi go, że kod na naszej klasie jest semantycznym spełnieniem developera? Albo że onet waliduje się jako poprawny 1.0 Strict?

Nic z tych rzeczy. XHTML to mentalny wank. Standard powstały po to, by niektórzy devele mogli sobie powiedzieć "ale jestem zajebisty".

Tak to już jest w IT, że nic nie działa, wszystko okazuje się bublem i prowizorką, a twoi współpracownicy to techniczni ignoranci. W tych warunkach XHTML jest po prostu nieżyciowy. Piękny i dopracowany, ale nie do użycia w rzeczywistości.

stronger

tdudkowski, ze standaryzacją jest jak z przestrzeganiem prawa. Wszyscy wiemy, że jest to raczej dobre, co nie powstrzymuje nas przed mocniejszym przyciśnięciem pedału gazu, czy przejściem przez ulicę w niedozwolonym miejscu.

W rzeczywistości nie piszesz nigdy kodu pod konkretny standard, a pod konkretne przeglądarki. Gdybyś pisał pod standard, większość stron nie działałaby pod IE.

A gdy wychodzą nowe przeglądarki - poprawiasz. Wiem, to koszmar, ale tak to się właśnie kręci i niewiele możesz na to poradzić gdy główny gracz na rynku przeglądarek sika ci na głowę.

lukasz

To Ty piszesz strony pod IE? A poprawiasz dla innych? ROTFL

stronger

A rotflaj się tylko się za bardzo nie poobijaj. Piszę pod FF mając na uwadze ograniczenia IE. Kontakt z tym wyrobem przeglądarkopodobnym ograniczam do minimum.

Paweł Ciupak

„Jakie problemy HTMLa rozwiązuje XHTML?”

XHTML2? Wiele. Przykładowo, pozwala na nadanie każdemu elementowi atrybutu czyniącego z niego link (mozna nawet np. zamienić w link cały <div>, co często jest przydatne np. w nagłówkach); rozwiązuje problem z tekstami zastępczymi dla obrazków i koniecznością stosowanie technik FIR; zwiększa semantykę elementów poprzez możliwość nadania każdemu elementowi atrybutu `role' określającego pełnioną w dokumencie funkcję – w przeciwieństwie do HTML5, bez konieczności wprowadzania dodatkowych znaczników i z możliwością rozszerzalności; usuwa wreszcie znaczniki prezentacyjne; rozwiązuje problemy z wątpliwościami podczas wstawiania tekstów podzielonych na linie, takich jak np. poezja; upraszcza wstawianie elementów osdzonych takich jak np. filmy wideo czy aplety Javy z możliwością bezproblemowego fallbacku. Wreszcie sam XHTML pozwala na bezproblemowe wstawianie do dokumentu grafiki SVG czy wzorów w MathML.

Szymon

Paweł Ciupak, "wzorów w MathML" a po co komu wzory w onecie ? albo poezja ? ;)

Szymon

Paweł Ciupak, nawiasem mówiąc w htmlu 5 także usunięto elementy prezentacyjne, i też można używać SVG i mathML (afair).

Dodek

Szymon, ale wiesz, onet to nie jest cały internet :) Na przykład nam na Wikipedii to by się bardzo przydało, teraz jest renderowanie LaTeXowych wzorów do png, które jest wolne i czasami zawodne.

A SVG to moim zdaniem przyszłość internetu.

tdudkowski

@Stronger: pod konkretne przegladarki, ale zgodny ze standardami, co ulatwia dostosowanie do innych przegladarek i pozniejsze poprawki; wiekszosc zalecen xml-ujacych kod jest dobra dla latwosci i kosztow utrzymania kodu; nie pracuje w systemie korporacyjnym, ale czasem mam cos na szybko dodac lub naprawic i koszmarki architektoniczne z jakimi mozna sie spotkac przyprawiaja o bol glowy.

Szymon

Paweł Ciupak, o prosze: http://dev.w3.org/html5/spec/Overview.html#namespaces

Dodek, "Szymon, ale wiesz, onet to nie jest cały internet :)" staram się przyswoić sobie punkt widzenia Strongera. Mam nadzieję że dobrze mi idzie.

Michał Górny

@stronger: Zapytam po raz kolejny — kto podaje w XHTML-u elementy HTML-owe z prefiksem? XML daje ci taką możliwość, ale czy i jak z niej skorzystasz, to jest twoja sprawa. Jak rozbijesz sobie samochód, też będziesz miał pretensje do prawodawców, że pozwolili ci prowadzić?

@Jajcus: Usuwanie elementów nie jest złe — decydując się na konkretny standard, sam decydujesz, że nie chcesz ich używać. Jeśli chcesz je, używasz starszego standardu — proste. Złe jest wprowadzanie nowych w takich sposób, że stare przeglądarki sobie z nimi nie radzą.

@Dodek: Na Wiki możesz wybrać, w jakim formacie chcesz wzory.

stronger

Michał, konsekwentnie odmawiasz przyjęcia do wiadomości, że przytłaczająca większość kodu na tym świecie to źle sformatowane i niewalidujące się ścierwo, a większość developerów to kretyni, którym wystarczy, że u nic i u ich szefa działa. Znacznik <jakis-tag> nie jest częścią HTMLa, ale w dokumencie HTML nie sprawiał kłopotu. W XHTML musisz przenieść go do ns. Ale to tylko przykład pierwszy z brzegu i na pewno tysiące develi z całego świata mają własne pomysły jak spieprzyć sprawę. Jeśli nagle zaczniesz być bardziej restrykcyjny to coś na pewno się posypie, a wtedy będziesz się musiał po prostu wycofać. Sorry stary, robię to od 10 lat i za każdym razem jest tak samo.

stronger

Paweł, z listy imponujących usprawnień, które wymieniłeś tylko MathML i SVG wydaje mi się rzeczywistym usprawnieniem wynikającym z potrzeb końcowego odbiorcy. Pozostałe punkty to jaranie się własnym klimatem. Wyobrażasz sobie newsa na onecie "Nasza strona jest teraz 65% bardziej semantyczna"?

Nie zrozum mnie źle, nie twierdzę, że XHTML jest złym standardem. On jest po prostu niecelowy. I nie ma szans na adopcję, bo większość programistów to baraniei łby, które nie chcą żadnych zmian, a ci, którzy są w miarę kumaci są ograniczani przez istniejące technologie.

Udało nam się wprowadzić CSS i odejść od layoutu tabelkowego tylko dlatego, że mieliśmy znaczącą przewagę na starymi metodami. XHTML nie ma żadnej powalającej cechy, która mogłaby przekonać malkontentów, nie wspominając o twórcach przeglądarek.

Dodek

MGórny: 1) niezalogowani nie mogą, ale 2) to żadna różnica, bo i tak nie działa.

Michał Górny

@stronger: A ty cały czas przeczysz sam sobie. Naraz mówisz o „źle sformatowanym i nie walidującym się ścierwie”, które przecież definitywnie nie będzie miało przestrzeni nazw za pomocą prefiksów. A potem nie wiadomo jakim cudem, nagle wszystkie elementy dostają przestrzeń nazw z prefiksem.

Your turn:

nick:
and?:
www (if any):
Wpisz kod:code
 
 
Tak zdechł XHTML i chuj mu na grób html5 xhtml