@cutungo, daj spokój. Nie wytłumaczysz. Jak zaczną pracować to sami poczują jak to jest próbować przekonywać kierownictwo, że warto przepisać całą aplikację w XHTMLu zamiast spełnić wymagania klienta.

Szefie? A może w końcu przejdziemy na język szablonów który umożliwia parsowanie dokumentów XML i rzuci nam wyjątkiem gdy popełnimy błąd (PHPTAL, kid-templates)? Wiesz jak jesteśmy zagonieni.

Ja mam inny pomysł: pozbądźmy się z naszych systemów operacyjnych ochrony pamięci! Przecież same problemy z tym są: jak program odwołuje się do złych danych, wyraca się! a nie musi tak być… mógłby tylko dać nieco inny wynik, przynajmniej użytkownik widziałby, że "coś działa" 😛

"Przejście z dobrze napisanej stronki to tylko doklejenie DTD, przestrzeni nazw, jak również prologu XML"

Przecież to bzdura. IE w ogóle nie obsługuje XHTML chyba że poda mu się niewłaściwy content type, to dopiero wtedy sobie jakoś próbuje z nim radzić. To właściwie zamyka dyskusję, bo jeśli dla 65% userów i tak muszę to pisać i testować jak HTML to znacznie lepiej wyjdę na użyciu HTML.

"Możesz więc:
a) Podpisać umowę z klientem, która zakaże mu zmiany zdania"

Jeśli mam klienta na stronę to pierwsze o co pyta to ile % przeglądarek tą stronę będzie w stanie pokazać. Jeśli miałbym rzeczywiście używać XHTML to limituję sobie odpowiedź do 35% co gwarantuje kopa w dupę. I zdaje się IE8 dalej nie obsługuje, ale nawet nie chce mi się tego sprawdzać.

"c) Pocić się i męczyć nad pokemonami i zupą tagów w HTML-u, testując stronkę bez przerwy pod każdą przeglądarką, szukać niedomkniętego znacznika w gęstwinie."

Nikt nie powiedział, że będzie łatwo, ale ta opcja daje większe szanse pozostania w biznesie niż pokazanie z góry faka dwóm trzecim potencjalnych userów.

"Dlaczego siejesz FUD? Może jesteś bardziej prawnikiem lub kierownikiem niż webmasterem?"

Nie jestem webmasterem, ale jakie to ma znaczenie? Na WWW wygoda webmastera jest ważniejsza niż dostępność strony dla użytkowników?

maciek: "pozbądźmy się z naszych systemów operacyjnych ochrony pamięci! Przecież same problemy z tym są"

Bardzo dobry przykład. Poprawne zarządzanie pamięcią jest trudne, więc coraz częściej używa się rozwiązań z garbage collectorami, bounds checking i innymi bajerami, które te problemy usuwają w cień.

Ale doceniam, że się starałeś. 😉

A Pani Jadzia z księgowości przeklei nam do naszego 100% zgodnego ze standardami CMS tekst z worda i wszystkie przeglądarki poza IE (bo ten ma niewłaściwy content-type) odmówią współpracy.

@groszek: a przerzucasz niefiltrowany tekst pochodzący od użytkownika bezpośrednio na stronę? Bezpieczeństwo twoich danych musi być porażające.

XHTML jest znacznie bardziej przejrzysty od HTML-a. Zresztą rozumienie, że zapiszę dokument XHTML, który po zastosowaniu paru sztuczek zostanie poprawnie wyświetlony pod IE jest tak samo poprawne, jak próba napisania dokumentu w HTML-u i zastosowaniu tych samych sztuczek. W przypadku samego dokumentu XHTML musimy pamiętać o paru dodatkowych aspektach, jak wstawianie spacji przed /, jednak bez problemu sobie z tym poradzisz.
Ja wolę pisać strony w porządnym standardzie, by mieć mniej roboty. W przypadku IE będę mieć tyle samo roboty w "łataniu" tego czegoś, niezależnie czy użyję HTML-a czy XHTML-a. Przez dostosowanie się do XHTML-a mam jednak mniej pracy.

Ja właśnie, gdy muszę pisać w notatniku, wybieram XHTML-a. Przeglądarka sama mi wskaże, gdzie mam błąd. W dodatku korzystam z porządnego edytora tekstu, który mi koloruje składnie/podkreśla błędy. Raczej rzadko się zdarza, bym zapomniał domknąć jakiś tag. Może parę razu w mojej karierze.

Przejście z dobrze napisanej stronki to tylko doklejenie DTD, przestrzeni nazw, jak również prologu XML.

Odwołam się do takiego starocia, a co. Trzeba jeszcze przepisać połowę skryptów JS, bo w XHTML nie działa document.write, i w ogóle zmienić hosting, bo obecny dokleja na końcu strony jakiś skrypt, który powoduje YSOD.

b) Zastosować standardy, by wszystko móc w parę sekund zmienić
c) Pocić się i męczyć nad pokemonami i zupą tagów w HTML-u, testując stronkę bez przerwy pod każdą przeglądarką, szukać niedomkniętego znacznika w gęstwinie.

Piszesz jakby HTML wymuszał tworzenie zupy tagów a XHTML automatycznie sprawiał że kod jest piękny i w ogóle. A tu niespodzianka! W HTML można tak samo tworzyć poprawne dokumenty jak w XHTML. I na odwrót, kiepski webmaster może tak spartaczyć kod w XHTMLu, że aż przykro na to patrzyć.

@likemandrake: To trochę dziwne, bo w IE7/8 trafiłem na ten sam błąd. Po doklejeniu prologu XML-a na początek strona przestała się poprawnie wyświetlać.

@Sławek: "Co w tym złego, by dla IE wysłać dokument w XHTML z niewłaściwym content-type, a reszcie z poprawnym."

To, że niczemu to już wtedy nie służy, a tylko daje szansę zaliczenia YSODa. To po co miałby ktoś to robić?

"Problem w tym, że HTML utrudnia pewne rzeczy dla programów komputerowych."

Defekuję na wszelkie możliwe trudności jakie HTML może sprawić programom komputerowym dokąd nie ma praktycznej alternatywy (olewany przez praktycznie cały rynek XHTML praktyczną alternatywą nie jest).

" Utrudnia również wprowadzanie poprawek. Po co nam dalszy rozwój HTML-a, jak dla własnego dobra będziemy się starać, by dokumenty napisane przez nas były zgodne z jakąś aplikacją XML-a? Lepiej porzucić html-a i rozwijać XHTML-a. Sądzisz inaczej?"

Sądzę, że pełno jest technicznie fajnych inicjatyw, które szlag trafił bo ktoś nie przemyślał czegoś od strony biznesowej. XHTML można do takich zaliczyć, z tym, że "nie przemyślał" to mało powiedziane. To było od samego początku proszenie się o faila.

To, że XHTML sam w sobie nie był pomysłem biznesowym może wzbudzać pewne współczucie dla jego promotorów ale jest to też kolejny dowód, że aby stworzyć coś czego ludzie będą używać trzeba myśleć biznesowo bez względu na to czy na końcu chce się zarabiać pieniądze czy nie.

"Ja wolę pisać strony w porządnym standardzie, by mieć mniej roboty. W przypadku IE będę mieć tyle samo roboty w “łataniu” tego czegoś, niezależnie czy użyję HTML-a czy XHTML-a. "

Tylko że dla 65% userów i tak piszesz w HTML (albo nie pozwalasz im oglądać strony). Skądinąd słusznie, bo każdy inteligentny człowiek mając do wyboru pokazać faka standardowi albo pokazać faka dwóm trzecim potencjalnych userów wybierze to pierwsze.

"Przez dostosowanie się do XHTML-a mam jednak mniej pracy."

To jest kolejny dowód na to, że XHTML tak naprawdę nic nie wnosił. Można się dostosować do jego wymagań i dalej sprzedawać spory podzbiór tego, na co pozwalał jako HTML. Nawet trzeba, bo nikt nie kupi strony niewidocznej w IE. Tak więc mając wybór: sprzedawać stronę jako HTML dla wszystkich, albo sprzedawać dla nie-IE jako XML raczej wybiorę to pierwsze, bo to i tak już jest interpretowane jako HTML w IE a sprzedawanie reszcie jako XML nie daje mi NIC poza ryzykiem YSOD.

@el.pescado: "Trzeba jeszcze przepisać połowę skryptów JS, bo w XHTML nie działa document.write"

Panie, co Pan. Przecież skrypty używające document.write to ZUO.