Wczoraj (czwartek, 2 lipca) organizacja W3C odpowiedzialna za publikację standardów sieciowych ogłosiła zakończenie prac nad XHTML.
Z końcem bieżącego roku grupa pracująca nad standardem XHTML 2.0 zostanie rozwiązana, a obecnie obowiązujące specyfikacje XHTML 1.0 i 1.1 zamrożone w aktualnej postaci. Celem organizacji jest przyśpieszenie prac nad HTML 5, aby jak najszybciej wdrożyć standard w życie.
Przy okazji warto również przypomnieć, że mimo obsługi przez coraz więcej przeglądarek, w tym niedawno wydanego Firefoksa 3.5, obowiązkowe kodeki obsługujące znaczniki <audio> i <video> nie będą częścią standardu HTML 5. Wpływ na to miały głównie firmy takie jak Apple i Nokia, które od początku sprzeciwiały się idei natywnej obsługi multimediów (a konkretnie postawienia na Ogg/Theora) w przeglądarkach.
Więcej informacji: http://www.w3.org/News/2009#item119
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
OSnews.pl jest społecznościowym serwisem informacyjnym poświęconym oprogramowaniu, systemom operacyjnym i światowi IT. więcej »
Trochę wkurzające bo nagle mamy zwrot o 180 stopni i coś co miało być przyszłością ginie, a lekko gnijący trup zmartwychwstał. Dobrze że przynajmniej nie wszystkie projekty zamknęli z automatu i chociażby prace nad XForms będą kontynuowane.
Przeredagowałem trochę. Z tym końcem to bym się zastanowił. To, że zależy im na szybszym wydaniu HTML5 i skupiają się tylko na nim, nie oznacza że już nie powrócą do prac nad XHTML
To możesz wrócić do poprzedniego bo jest wyraźnie napisane: “…after discussion with the participants, W3C management has decided to allow the Working Group’s charter to expire at the end of 2009 and not to renew it“.
I jeszcze chciałbym dodać że z HTML 5 wyleciały kilka dni temu zapisy dotyczące kodeków w audio/video bo przeważyły interesy poszczególnych korporacji (np Apple powiedziało że nie ma zamiaru wspierać ogg skoro ma quicktime). To tylko pokazuje czym obecnie jest W3C.
FUD!
cytat:
” Apple refuses to implement Ogg Theora in Quicktime by default (as used
by Safari), citing lack of hardware support and an uncertain patent
landscape”
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020620.html
Ich argumenty sa dosyc konkretne, w polowie techniczne w polowie prawne. Byc moze gdyby ktos przeprowadzil dokladnal analize Theory pod katem patentow Apple moglo by zmienic zdanie, a wtedy bedziemy miec juz 3 firmy wspierajace Theore. Takiej analizy nigdy nie bylo. Bardzo wazne jest tez to co tak naprawde oznacza ze Theora jest wolna od patentow, i jakie to niesie za soba konsekwencje, czy to dobrze ze jest wolna od patentow ? A co jesli ktos dostanie patent na kluczowy element Theory ? Jakie to bedzie nioslo za soba konsekwnecje ? I dla apple i dla opery i dla kazdego innego producenta przegladarek ?
To wszystko są wymówki korporacji starającej się stać jak najdalej od otwartych standardów, co więcej: nie jest to zaskoczeniem, jeśli wziąć pod uwagę że jest to firma specjalizująca się w dostarczaniu zamkniętych rozwiązań hardware’owo-software’owych, szukająca przewagi nad konkurencją poprzez ograniczanie dostępu do wykorzystywanej przez siebie technologii.
@maciek: rozumiem:
- FOSS mówi “wywalić Mono z powodu niejasnej sytuacji patentowej” — dobrze
- Apple mówi “wywalić Theorę z powodu niejasnej sytuacji patentowej” — źle
Mono to rzecz podejrzana i niebezpieczna z wielu powodów wymienionych w komentarzach pod niusem odnośnie takiego a nie innego (i IMO uzasadnionego) Stallmanowego poglądu.
Theora to oprogramowanie od podstaw stworzone jako otwarte, które – o zgrozo – stanowi konkurencję dla apple’owego quicktime. Zaś Apple nie pierwszy i nie ostatni raz pokazuje, że woli rozwiązywać problemy tworząc i rozwijając własne, zamknięte, rozwiązania, nie zaś opierać się na rozwiązaniach otwartych. Z pewnego punktu widzenia jest to nawet zrozumiałe: dzięki temu zachowują kontrolę nad tą technologią.
Theora to oprogramowanie stworzone od podstaw, korzystające z rozwiązań, które prawdopodobnie podpadają pod istniejące patenty.
http://lists.xiph.org/pipermail/theora/2005-March/000804.html
w3c widze probuje o sobie przypomniec ostatnimi czasy. Taka proba zaistnienia w “mediach”… szkoda tylko ze w taki sposob.
@occulkot: Cos jak Stallman?
Raczej coś jak t.r.a.s.z. Byle nasmrodzić.
kurde – raz juz pisalem ale jakos nie dodalo.
Stallman imo w przeciwienstwie do w3c swoimi popisami robi troche pozytecznej roboty. Naglasnia potencjalne problemy (przy okazji robiac z siebie fantyka
) – ale dzieki temu wiele osob ma watpliwosci.
Aktualnie w3c natomiast podejmuje kontrowersyjne decyzje (wiadomo – mozna ich nie sluchac), ktore tylko robia zamieszanie.
No dobra… Dobrze, że przynajmniej chwilowo. Rozumiem ten krok, ale IMHO html5 jest sporym krokiem wstecz.
@Sławek: Nie jest. XHTML byl ciekawym eksperymentem, ale zakonczonym kompletna porazka, glownie na skutek YSOD.
IMO to, co czasem skutkowało YSOD (tj. wymóg ścicłej poprawności) to akurat najlepsza część XHTMLa. brakowało tylko opcji, aby kopać prądem autorów aplikacji webowych za każdym razem, kiedy aplikacja ta wygeneruje niepoprawną stronę.
Bardzo mi się podoba jak tutejsi mali Jasiowie wyobrażają sobie rzeczywistość…
@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.
@stronger: właśnie to sobie wyobraziłem.
“Szefie, napracujemy się nad tym ze trzy razy więcej niż nad HTML, jak zrobimy jakikolwiek minimalny choćby błąd w XHTML to klienci zobaczą YSOD zamiast strony, oczywiście ci klienci którzy w ogóle będą w stanie stronę oglądać, bo najpopularniejszy IE nie obsługuje XHTML, ale będziemy działać w duchu zgodności ze standardami, wolności informacji i otwartości rozwiązań.”
Domyślenie się odpowiedzi szefa zostawiam jako ćwiczenie dla czytelników i moderatora.
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.
Czy to tak trudno zamykać każdy znacznik, nie wpisywać pokemonów do środka znaczników, itd. ?
Nie rozumiem w czym problem – wszystko jest ustandaryzowane. Przejście z dobrze napisanej stronki to tylko doklejenie DTD, przestrzeni nazw, jak również prologu XML. W czym problem? Nawet nie wiesz, jak później jest trudno modyfikować stronkę nie napisanej zgodnie z tymi standardami. Możesz więc:
a) Podpisać umowę z klientem, która zakaże mu zmiany zdania
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.
W dodatku HTML jest trudniejszy w nauczeniu się. Dla każdego znacznika jest zdefiniowana inna polityka, co do zamknięcia. Jeden znacznik możesz zamknąć, inny musisz w niektórych okolicznościach, inny musisz zawsze, a jeszcze innego w ogóle nie możesz zamknąć. Nie wspominając już o braku możliwości łączenia z innymi elementami, w tym stworzonymi przy użyciu jeszcze nie powstałych językach.
Dlaczego siejesz FUD? Może jesteś bardziej prawnikiem lub kierownikiem niż webmasterem?
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”
@maciek: Świetne podsumowanie. W dodatku nikt nie potrzebowałby antywirusa, a programy działałyby szybciej
.
Jaki jest jednak tego sens?
“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ś.
On raczej myślał ogólnie o ochronie pamięci.
Właśnie problem polega na tym, że nie jesteś webmasterem. Co w tym złego, by dla IE wysłać dokument w XHTML z niewłaściwym content-type, a reszcie z poprawnym. Z tego powodu napisałem wniosek, że przejście z dobrze napisanej strony na XHTML, to nic trudnego.
Problem w tym, że HTML utrudnia pewne rzeczy dla programów komputerowych. 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?
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 jest taka możliwość? Które CMS-y to obsługują?
@groszek: a przerzucasz niefiltrowany tekst pochodzący od użytkownika bezpośrednio na stronę? Bezpieczeństwo twoich danych musi być porażające.
Fajnie popatrzeć, na słowną walkę między kimś przyznającym się do nie bycia webmasterem a ludźmi webmasterów udającymmi
Szczególnie fajnie jest widzieć, jak ZU bije ich argumentami po łbie a do nich nie dociera. Widać to tacy co webmaster to maja na koszulce, a z rynkiem i zapewnianiem klientowi rozwiązań nie mieli nigdy do czynienia.
cutugno – szkoda twojego czasu – oni i tak nie zrozumieją. są podobni do maniaków próbujących wymusić nie używanie HTML w listach e-mail. Ślepota połączona z czystą formą zaślepienia pochodzącą chyba od zbytniego zapatrzenia w oop.
“Co w tym złego, by dla IE wysłać dokument w XHTML z niewłaściwym content-type, a reszcie z poprawnym.” – no trzeba mieć na prawdę nierówno pod sufitem, by takie rzeczy proponować tylko po to, by użyć xhtml (a niektóre eventy DOM, które są tylko w html transitional to pewnie będzie stał i emulował ręcznie pani Basi). O tym, że niektórzy tutaj pewnie o technologii Midas i o tym jak się jej używa w ogóle nie słyszeli a się odzywają nie wspomnę.
PS – tak mam dzisiaj obniżony poziom ignorowania głupoty u innych ;-p
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.
Przeglądarka internetowa wysyłając żądanie do serwera, umieszcza w nim nagłówek “Accept”, a z niego można wyczytać czy obsługuje ona XHTML czy nie.
Jeden jedyny warunek w kodzie aplikacji, aby określić czy odesłać “Content-type: text/html”, czy może “application/xml”… Polski projekt systemu szablonów OPT robi to od ręki.
Jeżeli ktoś używa notatnika do pisania stron, nie ma się co dziwić, że dla niego wielkim problemem jest domykanie każdego tagu.
Serwis, do którego posiadam link w profilu w całości jest napisany w XHTML 1.0. Nie było żadnych problemów przy zastosowaniu standardu, który nie każda przeglądarka w ogóle obsługuje.
Jeżeli chodzi o wstawianie kodu przez użytkownika, błędnie napisany HTML rozsypie cały szablon strony, więc tak czy inaczej musi być przetworzony. Zaznaczam, że HTML jest znacznie trudniej przetworzyć niż XHTML, a choćby dlatego, że można napisać takie coś:
Istnieje cała masa narzędzi do przetwarzania kodu XHTML i te narzędzia potrafią bardzo dobrze sobie poradzić z niepoprawnie napisanym kodem, na dodatek mamy gwarancję, że każdy tag zostanie poprawnie domknięty i tym samym pewność, że nikt nie popsuje nam layoutu.
Każdy, kto chce aby jego strona działała poprawnie na 100% przeglądarek niech całkowicie zrezygnuje z CSS i tych innych “pierdół” jak JS. Niech jeszcze najlepiej pisze czysty tekst, bo nawet HTML 4.01 w tak popularnych przeglądarkach jakim był kiedyś IE 6 nie obsługuje w pełni poprawnie tego standardu.
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.
@likemandrake i wszyscy inni fani XHTML:
Kod
Nie jest poprawny w HTML. Znaczniki należy poprawnie zagnieżdżać.
@el.pescado
Napisanie takiego kodu owszem nie jest poprawne, ale jest możliwe. Dopóki nie wykryjesz samemu tego błędu lub nie przepuścisz przez walidator, błąd będzie sobie istniał, a przeglądarka nawet nie jąknie, że coś jest nie tak.
Jak w tym samym dokumencie wstawisz DOCTYPE XHTML i nawet prolog xml, to przeglądarce też będzie bez znaczenia, chyba że ustawisz odpowiedni Content-Type, czego nie zrobisz, bo wtedy strona nie wyświetli się u ~50% użytkowników.
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.
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ć.
Dokładnie jest tak jak piszesz. Kiedyś tu na osnews.pl wspominałem nawet, że DOCTYPE nie jest priorytetem do określenia jak przeglądarka ma potraktować dokument. Priorytetem jest właśnie nagłówek “Content-Type”.
Wyjątkiem jest tu jednak seria IE w wersji < 8, które olewają w wielu przypadkach ten nagłówek, a treść dokumentu starają się rozpoznać po rozszerzeniu pliku (w przypadku np. obrazów graficznych). W IE to właśnie DOCTYPE zapewnia czy IE 6 i 7 będą działały w trybie zgodności wstecznej, czy "zgodnej ze standardami", a mam tu na myśli w dużej mierze Box Model CSS, który jest inny w obu przypadkach.
Na dodatek w IE 6 żaden, ale to żaden znak nie może pojawić się przed deklaracją <!DOCTYPE, ponieważ w takim wypadku IE 6 automatycznie wraca do zgodności wstecznej. W takim wypadku stosowanie prologu XML mija się z celem...
@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ć.
Czyli w takim razie w IE 7 i 8 ten błąd nadal występuje
Ja byłem pewien tego problemu dla wersji 6, dlatego nie pisałem o pozostałych.
@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.
Przypomnę, że oczywiście HTML2.0 początkowo miał wycofywać pewne tagi, ale z tego powodu, iż każdy znacznik powinien móc mieć jego atrybuty. Dla mnie byłoby to o wiele lepszym podejściem niż obecnie się to robi. Projektowanie stron byłoby szybsze, prostsze, a kod byłby czytelniejszy. HTML5 jest powrotem do starych praktyk, gdyż
<html>
<body>
<p>AAAA
<p>BBBB
</body>
</html>
Będzie znowu poprawne
a parsery znowu będą się rozjebywać na prostych stronkach… nie no, po prostu super pomysł…
nie siej fuda. można spokojnie stosować parsery XML dla dokumentów “staroświeckiego HTMLa”: trzeba je po prostu najpierw przepuścić przez n.p.
tidy(1)Mam na myśli, że standard będzie to dopuszczać. W html-u 5 będzie można zaserwować dokument dosyć zgodny z XML-em, jak to jest teraz. Jednak sam pomysł na dopuszczenie czegoś takiego jest, IMHO poroniony. Na pewno jest krokiem wstecz.
oczywiśce. Ja tylko zwracam uwagę, że taki dokument html niezgodny z XMLem możesz po stronie klienckiej ziksemelować przy pomocy na przykład polecenia
cat plik.zupatagów | tidy -asxhtml i pracować z nim używając wszelkich narzędzi XMLowych.... bo zamknie niedomknięte tagi, poprawi "case" znaków a nawet doda namespace.kolejny super pomysł. pozwólmy “webmasterowi” robić sieczkę z kodu i potem zatrudnijmy kogoś kto napisze skrypt czyszczący ten syf. jasne, taki skrypt już jest napisany. tylko po cholerę go w ogóle używać, skoro można napisać stronę w poprawnym x(ht)ml? niech “webmaster” przed wypuszczeniem takiego gniota w świat przepuści go przez oczyszczacz. zaoszczędzi to na pewno kilku watów energii…
Nie będą. Obsługa automatycznie zamykanych tagów *jest* opisana *bardzo dokładnie* w specyfikacji i jest obecnie zaimplementowana przez wszystkie przeglądarki.
Ponieważ składnia HTML 5 jest opisana całkowicie, włącznie z obsługą błędów, nie będzie istniał żaden ciąg znaków, który by mógł dać różną interpretację w różnych przeglądarkach implementujących parser HTML 5.
<html>
<body>
<p>AAAA
<p>BBBB
</body>
</html>
nie będzie poprawne, ponieważ każda strona musi mieć title
Nie pamiętam specyfikacji, ale w którejś odnośnie X(HYML) – chyba html 4.x – było o tym napisane. Ma rację – każda strona powinna posiadać title.
Dla ścisłości to musi mieć head a w nim title
Co to? czyżby antyspam odsiał moją odpowiedź z tego powodu, że zawierała 3 linki? To napiszę jeszcze raz w skrócie:
BoBsoN: dla ścisłości: jedynym znacznikiem, który dokument html mieć musi jest TITLE. znacznik HEAD (podobnie jak BODY i HTML) jest opcjonalny, ponieważ zbiory elementów zawierających się w (odpowiednio) HEAD i BODY są rozłączne, i przeglądarka i tak rozróżni co się gdzie należy. Co więcej: zasady takie obowiązują od 2.0 aż do 4.01 Strict włącznie.
Wielu ludzi nawet pomija head i body. Mamy tylko html, jako główny korzeń, style i inne na samej górze, a potem jest już treść.
jak mnie pamięć nie myli W3C nie tyle wyznacza standardy a zalecenia
A są jeszcze jakieś inne, konkurencyjne “zalecenia” odnośnie opisu treści na WWW z którymi się liczą producenci przeglądarek? To że coś nie jest isoIleśTysięcy nie znaczy, że nie jest standardem.
jest – WHATWG
Stary nius. Pamietam notke o tym na blogu Tima Bernersa-Lee sprzed, bodajze, dwoch lat.
Szkoda, że decydenci w W3 powariowali – XHTML 1.1 to dobry standard. XH2 mógł być równie udanym projektem.
Jeśli jednak chcą się cofnąć do internetowej epoki kamienia łupanego, to ich sprawa. Przecież ludzie nie muszą podążać za ich widziemisie i nadal używać XH1.
Ja proponuję abyśmy – my niezadowoleni – przepisali nasze strony webowe na draftowe XHTML 2.0
No ja w tym widzę jeden problem – czy przeglądarki rozumieją ten draftowy XH? Ostatnio sprawdzałem kilka lat temu i wtedy nie fungało.
Nie. I co z tego?
Tak, ale XHTML 2 miał być naprawdę genialną sprawą. A oni wszystko rozp…. :/ Smutne i to bardzo
Xlink też powinien wejść. Przynajmniej pozwalało określać link, jako osadzony. Coś co dzisiaj robi brzydki iframe lub serwer, mogła dokonać przeglądarka. Już nie wspominając, że xlink dzięki temu mógł zastępować w małej liczbie przypadków object, jak to miało wyglądać w xhtml2 w sprawie anchorów i linków.
HTML 5 ma .
Grrr!
kto pisał filtr do tych komentarzy!
iframe seamless
Przypomina mi się anegdota związana z pewnym malarzem – hiperrealistą, który namalował swój ogródek, ale nie uwzględnił jednego drzewa, które psuło mu kompozycję. Gdy spotkał się z zarzutem sprzeniewierzenia hiperrealistycznej idei dokładnego odwzorowywania rzeczywistości, malarz ów, zgadzając się z zarzutem, natychmiast naprawił całą sytuację… ścinając drzewo.
Omawiany problem wydaje mi się podobny; producenci pewnej pseudoprzeglądarki nie potrafią sprostać założeniom standardu, więc usiłują wybrnąć z tej sytuacji zmieniając standard – zatrzymują rozwój istniejących, zaawansowanych technicznie projektów i wprowadzają “nowy”, bazujący na własnej, przestarzałej i wynikającej częściowo z niedostatków (patrz: itp.) specyfikacji formatu.
Niestety okazuje się, że jest to firma bardzo wpływowa, o czym świadczy nie tylko jej zdolność do przeforsowania własnych idei w W3C, ale również cała rzesza stron przestrzegających _jej standardu_.
Ponoć to ta firma, jako pierwsza podała rękę innym producentom przeglądarek na polecenie webmasterów. Teraz się okazuje, że nici ze współpracy.
HTML 5 został stworzony przez Operę i Mozillę. To te dwie organizacje wywarły nacisk na W3C.
Ich motywacją nie jest pomaganie Microsoftowi. Celem jest kompatybilność ze stronami w sieci.
Specyfikacje W3C do tej pory nijak się miały do realiów. Żadna ze specyfikacji W3C nie obejmowała nawet 5% tego, co potrzeba do otworzenia GMail.
Implementacja science-fiction jak XForms i XHTML 2 kompletnie na nic się nie zdają, gdy użytkownicy porzucają Firefoksa/Operę/Chrome, bo im strona banku, intranet czy inny osiołek nie działa.
Tak samo CSS nadaje się do użytku dopiero w wersji 2.1. Wiesz czym jest 2.1? To jest CSS 2 + bugi IE + bugi Firefoksa. Głupi hack używany w GMail też został dodany do CSS 2.1. I teraz CSS 2.1 działa wszędzie.
To samo W3C robi z HTML 5. Będzie on tym, co robią przeglądarki od lat. Do tej pory udawano, że tego nie robią, ale to było ściemnianie.
a zechcialbys przeprowadzic maly eksperyment? Pojdz na W3C, znajdz dokumentacje draftowa XHTML2.0 i wklej tu jakis trywialny przyklad strony zgodnej z XHTML2.0… Moze dzieki temu latwiej bedzie zauwazyc czemu xhtml2.0 zostal uznany za malo przyszlosciowy…
http://w3future.com/weblog/gems/xhtml2.xml
Dobry przyklad, najciekawsza jest data Tuesday, August 06, 2002. Porownaj sobie to teraz z poziomem na jakim jest obecnie HTML 5 nie tylko jako draft, sprawdz tez jakie juz elementy HTML 5 zostaly zaadoptowane w przegladarkach… i ktory rok mamy obecnie ;]
Czyżby 2009? To ja poproszę HTML 5 + SVG + IE8. Albo dowolną bazę danych ze wsparciem XML która eksportuje dane do XHTML (ups, IE8 nie ma application/xhtml+xml w związku z czym z XHTML 5 nici). Albo porządny parser dokumentów gdzie nie muszę tracić czasu procesora na czyszczenie śmieci które nie wiadomo jaki da efekt końcowy. Ja tu nie widzę żadnego postępu. Listy nawigacyjne, sekcje, xforms. To wszystko było w XHTML 2.0 – 7 lat temu.
Dokładnie. W HTML-u wprowadzono sprawdzanie poprawności danych wprowadzonych do formularza. Do cztery/pięć lat temu było już w XForms. Sekcje i listy nawigacyjne miały zostać wprowadzone do XHTML-a 2.0. W dodatku XHTML 2.0 miał dać webmasterowi większą wolność w zapisie, itd. Nie trzeba już było tworzyć kwiatków typu:
<a href=”….”><img scr=”…”></a>
Możliwe miało też być zdefiniowane następnej i poprzedniej strony dokumentu, a także spisu treści, co miało uprościć nawigowanie po serwisie, a także umożliwić to, np. czytnikom ebooków(lub przeglądarkom specjalnie zaprojektowanymi do potrzeb czytania). Z tego powodu uznaję, że HTML5 jest krokiem wstecz. Nie rozumiem po co porzucać specyfikację, która właściwie mogłaby już ujrzeć światło dzienne. Zamiast tego wprowadzają jakieś dziwactwo.
@Marek: HTML 5 + SVG jest złe, bo nie działa w IE8, a XHMTL 2 …działa w IE8? XForms działa w IE8? Gdzie tu logika?
Parser HTML 5 dokładnie defniuje obsługę błędów, więc dowolny ciąg bajtów (nawet kompletnie losowy) będzie dawał zawsze identyczny wynik we wszystkich przeglądarkach HTML 5 – będziesz mieć gwarancję jaki będzie efekt końcowy.
Parsowanie HTML 5 nie jest trudniejsze od niewalidującego (stand-alone) parsera XML. Jest łatwiejsze i szybsze od walidującego parsera XML (który musi zawierać drugi parser DTD). XHTML 1 wymaga walidującego parsera XML.
@Zbigniew Braniecki: A nie uważasz, że teraz W3C może mieć problem? Wycofanie się ze standaryzowania kodeków w HTML5, wycofanie się z XHTML2. Jest to jakby nie patrzeć kilka kroków wstecz.
Jeszcze dopisek
Fakt, faktem Mozilla ostatnio gdzieś pokazała, jak zachować wsteczną kompatybilność tagu
videoz np. flashem, czy innymi formatami wideo.Tomek: Trudno nie uznac, ze W3C samo w sobie jest w dzisiejszych realiach jednym wielkim problemem.
Ja chcialem tylko powiedziec, ze XHTML2 jest swietny, ale dla maszyn, nie dla ludzi. Jest slabo “hackowalny”, bo trudno go dotknac “notatnikiem”.
HTML5 jest imho znacznie ciekawszym rozwiazaniem, poniewaz jest wlasnie “hackowalny”, a z cala pewnoscia jest krokiem do przodu i aktualizacja tagow do realiow swiata (page, section, side itp.)
A co do Ogg? Heh… zbieram sie zeby napisac o tym posta, ale podejscie roznych vendorow do kwestii jest moim zdaniem ladnym zobrazowaniem roznic w podejsciu do celow i dobrym przykladem dlaczego Mozilla jest wazna. Samo to, ze wdrozylismy z Ogg to jedno. Ale to, ze od roku wspieramy rozwoj Ogg aby mogl konkurowac z H.264 jest moim zdaniem jeszcze wazniejsze.
ehh… zapomnialem o tym, ze to lapie tagi (poproooosze dostep do edycji wlasnych komentarzy).
Chodzi mi o to, ze podejscie do tego tagu video jest dobrym przykladem roznic miedzy celami roznych vendorow i dla mnie dowodem dlaczego jestesmy potrzebni (jako Mozilla) w swiecie WWW.
Nie rozumiem. Ideą XMLa było właśnie to aby był również dla ludzi czytelny (i jest). Otwierasz w notatniku i masz to samo (elementy, atrybuty).
Aktualizacja tagów do realiów świata. Przykład: tworzę nowy dokument XHTML 2.0, definiuję przestrzeń nazw xmlns:html5=”http://www.w3.org/costamhtml5″, używam <html5:video>, <html5:page, section, side, whatever≶. Teraz tylko zadaniem maszyny (bota, przeglądarki) jest wyłuskać to co rozumie (przeglądarka przez wbudowane definicje jak obecnie). To się nazywa rozszerzalność i swoboda której na chwilę obecną nie ma i na razie nie ma nawet koncepcji jak miałaby wyglądać w HTML5. To niby nazywasz krokiem naprzód? Chcę poprawić semantyczność – RDF jest XMLem – przestrzeń nazw, microformaty – co to za bzdura żeby wciskać do klasy (class)? <p mf:date=”costam”> Tak powinna wyglądać sieć przyszłości.
@Zbigniew Braniecki: Owszem, jesteście potrzebni, ale całkowicie w inną stronę, niż do tej pory był kierowany “mainstreem” Mozillowy. Fakt, że przy FF 3.5 było wiele problemów i tak na prawdę odbiór ogólny był tego taki, że w Mozilli jest zastój. Dopiero później zaczęły wychodzić ciekawe projekty z Mozilli Labs. Ale myślę, że teraz Mozilla, poza rozwijaniem FF powinna naprawiać MSIE. Co jakiś czas pojawiają się informacje pojedynczych deweloperów związanych z Mozillą czy Google, że mają zamiar zrobić coś z obsługą standardów pod MSIE. I dopóki to skrzydło Mozilli nie rozwinie się w pełni to o obsłudze HTML 5 w MSIE możemy zapomnieć. Microsoft wyraźnie jest niechętny tej rekomendacji, blokując wprowadzenie Ogg.
Jak Oni chcą pomóc MSIE? Co mogą zrobić? Poprowadzić Microsoft za rączkę? Oni zwyczajnie nie chcą! Podaj link do wpisów na blogu
.
> Otwierasz w notatniku i masz to samo
Tylko, ze to nie jest czytelne. Tak samo jak nie jest czytelny XSLT, mimo, ze semantycznie jest piekny, ani RDF.
> Owszem, jesteście potrzebni, ale całkowicie w inną stronę, niż do tej pory był kierowany “mainstreem” Mozillowy.
A zastanow sie jakie mielibysmy mozliwosci operowania bez takiego “tarana” jakim jest Firefox? Kto by nas sluchal i kto by nas uwazal za partnera do dyskusji bez takiego sukcesu jak Firefox?
Zgadzam sie z Toba, ze zwlaszcza w krajach takich jak Polska mozemy zaczac skupiac sie na innych celach. Ale wciaz sa kraje gdzie MS ma 90% rynku i upewnienie sie, ze mamy stabilna pozycje na rynku swiata jest nadal bardzo wazne.
> Fakt, że przy FF 3.5 było wiele problemów i tak na prawdę odbiór ogólny był tego taki, że w Mozilli jest zastój.
Pewnie po czesci dlatego, ze np. samo stworzenie Mozilli Messaging nie jest dla uzytkownikow “przelomem”. Dopiero to co ona zrobi za kilka lat bedzie.
Nawet sam Fennec nie jest, dopiero to co ma on szanse zrobic z rynkiem mobilnym (otworzyc go) bedzie.
Dla MS mamy kilka projektow, np. ScreamingMonkey czy Canvas3D. Ale na sile nie da sie nikogo zmusic do zajecia sie rynkiem ktory nie tylko nie zarabiaja, ale na dodatek ktory rozwija sie w strone konkurowania z ich flagowym SilverLightem.
No właśnie uważam wprost przeciwnie – Microsoft można zmusić. A raczej nie zmusić, a obejść ich barykadę. Przecież to Google implementuje w MSIE Canvas
Z tego co wiem to taki plugin w postaci skryptu JS działa w maps.google.com. Czytałem wiadomości, że są plany, aby Mozilla wydawała plugin do MSIE, który by sprawiał, że będzie on pięknie renderował strony zgodne ze standardami. I to jest pomysł na naprawienie sieci. Z resztą z drugiej strony Microsoft potrzebuje czasu, bo o ile produkty ze stajni Live Labs są zgodne z najnowszymi standardami, to niestety MSIE nie. Może trzeba poczekać na wymianę zespołu, jak MS zauważy znaczący spadek popularności swojego dziecka.
Przełomowa moim zdaniem będzie wersja 3.6, w której przygotowane w wersji 3.5 podłoże w postaci szybkiego silnika JavaScript zostanie zagospodarowane projektami z Mozilla Labs. Dawno nie było tak przełomowego Firefoksa.
Akurat rynek urządzeń mobilnych jest dobrze zagospodarowany przez Operę Mini, która nie ma problemów ze stronami www. Więc Fennect może być co najwyżej miłym zamiennikiem Opery Mini, a nie kluczowym produktem walki o uregulowaną przez W3C strukturę stron www. Fennec nie będzie Firefoksem. Nie pełni tego zadania.
Szczerze?
Dla mnie utworzenie Mozilli Messaging było pogrzebaniem Thunderbirda, który nadal nie może wyjść ze swojej “bety” 
@Sławek – poszukaj w Google nazw, które wymienił Zbigniew Braniecki: ScreamingMonkey oraz Canvas3D
To jest chore, by wspomagać konkurencję, aby osiągnąć coś na rynku, lecz chyba jedyna właściwa droga. Jeżeli webmaster będzie mógł napisać: zainstaluje wtyczkę do przeglądarki; zamiast zmień przeglądarkę; to użytkownik go posłucha. Potem będzie większe prawdopodobieństwo, że taki użytkownik faktycznie zmieni przeglądarkę. Jest to jednak paranoja jakaś dziwna.
Dobry standard? Spróbuj użyć własnej przestrzeni nazw XML. Albo prefixu. Abbr, czy acronym? Językoznawcy nie mają pojęcia. Co oznacza alt=”"? Specyfikacja nie mówi. Wszystkie te rzeczy poprawił XHTML 5.
http://pornel.net/html5
Krok do przodu dwa kroki do tyłu…
Po komentarzach wnioskuje ze wiekszosc nie ma bladego pojecia czym byl XHTML 2.0 i czym bedzie HTML 5. XHTML 2 byl martwym tworem juz prawie od samego poczatku, zrywal wstecznal kompatybilnosc i nie mial poparcia wsrod producentow przegladarek. HTML 5 ma poparcie, przedewszystkim jest tworzony przez WHATWG, warto pamietac o tym ze whatwg != w3c, grupy ze soba wspolpracowaly od dawna. Smierc XHTML 2 byla oczywista jeszcze przed jego narodzinami, w momencie gdy powolano WHATWG i postawiono krzyzyk nad XHTML 2.0 rozwijajac HTML 5 Web Applications (ktory ma byc kolejna wersja HTML i XHTML)
Sam nie czuje sie odpowiednia osoba to pisania na temat obu projektow, ale staram sie pamietac o jednym jesli mam sie juz wypowiadac krytycznie to wolal bym najpierw poznac temat, a temat jest BARDZO szeroki. Pamietajcie ze HTML jest jezykiem wzglednie prostym, ale wykorzystywanym i adopowanym przez miliony, jego rozwoj jest prowadzony przez garstke ludzi, dla milionow, same przegladarki internetowe staly sie tworem bardzo skomplikowanym, w tej grze nic nie jest proste, latwe i przyjemne, napewno takie nie bedzie, trzeba sie cieszyc ze jest chec dzialania na rzecz rozwoju i wspolpracy.
HTML potrafił być dwuznaczny. Nie piszę o samej specyfikacji, lecz pozwalał na tworzenie dwuznacznych stron, np. przez brak konieczności domykania tagów. Z tego powodu jest wielkim krokiem wstecz. Coś, co mi się bardzo podobało w XHTML-u – czytelność – tutaj nie będzie mieć miejsca.
Mógłbyś mi wytłumaczyć (nie jestem specjalistą), bo wydaje mi się, że specyfikacja HTML pozwala na niezamykanie tagów, ale przed dwuznacznością chroni ustalenie, że każdy otwierający tag “automatycznie zamyka” ten poprzedni niezamknięty. Takie coś mi się kojarzy, ale nie wiem czy tak jest…
Może ja też się nie znam. Zbuduj mi z tego drzewo dokumentu, gdzie elementem root jest body:
<body><font face=”tahoma”>aaa<p>bbb</font>ccc<p>ddd</body>
Podpowiadam: to NIE jest poprawny dokument HTML 4. NAWET jak dodać DOCTYPE i title. Trzeba jeszcze wyrzucić pierwsze p.
@maciek: Całkowicie zrozumiałe. Font raczej jest elementem liniowym, więc nie powinno się go dzielić na linie(;-) – taka gra słowna). Nie spodziewałem się jednak, że jest to zakazane przez standard. Rozumiesz chyba jednak o co chodzi? Równie dobrze zamiast p moglibyśmy wstawić b(nie trzeba go chyba zamykać).
ja generalnie popieram Twoją myśl przedstawianą na wszystkie sposoby w tym wątku, że zupa tagów jest be, a tolerancja dla błędów to ohydztwo… ale po raz kolejny proszę o weryfikowanie swoich twierdzeń choćby i walidatorem.
Problemem nie jest “nieparsowalność” tradycyjnego HTMLa, bo (a) istnieją jego parsery i (b) można go nawet wprost przełożyć na xml i używać dowolnych narzędzi XMLowych.
Problemem IMO największym jest mylne przekonanie, jakoby stworzenie poprawnego dokumentu HTML było znacznie łatwiejsze od stworzenia poprawnego dokumentu XHTML, i wynikający z tego wysyp dokumentów podających się za HTMLowe a HTMLowymi nie będących.
Potwierdzam twoje przekonanie. IMHO, powodem wydaje się to, że html-a do tej pory uczą w wielu szkołach. W przypadku XHTML-a webmaster ma pod górkę(nauczyć się, jak ładnie pisać, nauczyć się DTD niekiedy na pamięć, jak również przestrzeni nazw), ale potem ma już z górki. Nauczyciele wolą uczyć na HTML-u, bo pokazują same przykłady, które są często błędne. Co najgorsze, to wyświetlane jest to w przeglądarce, która nie sprawdza poprawności dokumentów, bo ważne jest, by klientowi się wyświetlało.
Ogólnie pisząc:
a) XHTML zawiera w sobie mniej elementów(znaczników), przez co można go się szybciej nauczyć
b) W XHTML-u możemy zamykać elementy na dwa sposoby
c) W XHTML-u nie musimy się zastanawiać czy możemy zamknąć/domknąć znacznik
d) Musimy się jedynie nauczyć DTD(co nie jest trudne) i przestrzeni nazw(też nie jest trudne)
e) Kod jest bardziej przejrzysty
Widać, że niedoczytałeś nawet do podtytułu specyfikacji HTML 5!
http://pornel.net/html5
http://www.w3.org/TR/html5/the-canvas-element.html#the-map-element
4.8.12 The map element
Ręce opadają
Tytuł newsa sugeruje, że zamrożone zostają wszystkie wersje a to nie do końca prawda. Specyfikacja HTML5 rozwija XHTML (zwany XHTML 5), który bezpośrednio wywodzi się z rodziny XHTML 1.
Nie rozumiem za bardzo zamieszania – na przykład Fiat Uno jest dopuszczany do jazdy po drogach, a mimo to ludzie kupują jednak Mercedesy za 80000 z pełną świadomością, że nie muszą wydawać aż tyle pieniędzy na samochód.
.
Tak samo będzie, mniejsze / większe, zapotrzebowanie na porządny kod HTML. Chociażby ze względu na zwiększający się udział telefonów z przeglądarkami oraz coraz większą ilość popularnych przeglądarek na komputerach PC.
Nie porównywałbym Mercedesa i Fiata …
Tytuł newsa jest błędny. W3C nie porzuca XHTML jako takiego, tylko konkretną wersję tej specyfikacji – XHTML 2.0. XHTML będzie rozwijany dalej.
Poza tym mam wrażenie, że ogromna ilość komentujących tutaj nie ma zielonego pojęcia o różnicach między HTML a XHTML. HTML 4.01 i XHTML 1.0 są semantycznie równoważne. Oferują dokładnie takie same znaczniki i z grubsza takie same atrybuty. Nie ma tu co gloryfikować XHTML – zupę tagów można tak samo zrobić w XHTML jak HTML (ponadto wiele z przykładów rzekomo poprawnego HTML wcale takimi nie jest). Różnica jest jedynie w składni – HTML wywodzi się z SGML, natomiast XHTML opiera się na XML. Tak samo będzie z HTML 5 – można będzie go sobie zapisać jako HTML, jak również jako XHTML – do woli.
Swoją drogą śmieszne w powszechnym zachwycie XHTML jest to, że nawet przeglądarki go obsługujące w 90% przypadków i tak parsują go jako zwykły HTML;)
Wiem, że większość znaczników się pokrywa, jednak z XHTML wyrzucili parę. Nie oznacza to jednak, że:
a) Zupy tagów w XHTML-u nie da się zrobić, bo tu każdy znacznik musi być zamknięty w porządku FILO. Powinna sprawdzić to przeglądarka lub dowolny parser.
b) Rzeczy, które miały zostać wprowadzone w XHTML2.0 miały być naprawdę fajnie. Część z nich zostało oczywiście wprowadzonych w HTML5, jednak nie to miałem na myśli. W XHTML2 mogliśmy wreszcie normalnie napisać <img src=”….” type=”…” href=”…” /> . Eliminowało to mnóstwo problemów z przeglądarką, było czytelniejsze i logiczniejsze(jak obrazek może być częścią odnośnika, gdy mamy na myśli odnośnik do jego powiększenia?).
c) Różnica między SGML-em, a XML-em jest spora, mimo iż nie wymagało to od webmastera specjalnego/wielkiego nakładu, by to pojąć/dostosować się.
“Tak samo będzie z HTML 5 – można będzie go sobie zapisać jako HTML, jak również jako XHTML – do woli.”
O tym ja wiedziałem, jednak dla przeglądarki, jak i odbiorcy stron nie jest to takie różowe. Szczególnie na zastosowaniu HTML-a ucierpią wszystkie roboty, które starają się zrozumieć treść strony. Może praca z HTML-em jest wciąż możliwa, jednak trudniejsza, wymaga większego nakładu pracy.
Nie, nie wyrzucili żadnych. Tak HTML 4.01 jak i XHTML 1.0 występują w dwóch odmianach: Strict i Transitional. Wyrzucono znaczniki, owszem, z HTML 4.01 Strict i XHTML 1.0 Strict, ale zostały one zarówno w HTML 4.01 Transitional i XHTML 1.0 Transitional. Sam XHTML nie ma tu nic do rzeczy.
W HTMLu znaczniki też muszą być zamykane w takiej właśnie kolejności. Różnica jest taka, że przeglądarki w przypadku źle podomykanych tagów w HTML starają się domyślić o co chodzi, a w przypadku XHTML powinny wyrzucić YSOD (czego, i tak nie robią, o ile nie dostaną ospowiedniego Content-Type, więc w 90% przypadków wychodzi na jedno).
Musiałbym zajrzeć do specyfikacji, ale chyba w transitional nie ma frameset(oczywiście to jest lekkie naciągnięcie).
W każdym razie w transitional chyba nie spotkamy się z tt czy font.
Sławek mówił o wyrzuceniu znaczników z XHTML 2 w XHTML 5, a nie z HTML 4.01 w XHTML 1…
Żeby nie pozostać gołosłownym – DTD XHTML 1.0 Transitional znajdziemy tutaj: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
Element tt jest zdefiniowany w wierszu 717, font w 749, center w 607.
Ehhh. Ta drobna różnica sprawia że w xhtml można używać choćby mathml, w html 4 nie. Dla większości osób oczywiście nieprzydatne ale nikt nigdy nie starał się przedstawiać sprawy inaczej (włącznie z w3c, dokument http://www.w3.org/TR/xhtml1/ zawiera opis różnic i tekst “The semantics of the elements and their attributes are defined in the W3C Recommendation for HTML 4″).
Niektórzy zdają się zapominać (albo nigdy nie zajmowali się stronami wcześniej) jak wyglądała sytuacja ~2002 roku. Teraz z perspektywy czasu łatwo jest krytykować. Wtedy to była rewolucja ideologiczna. Prasa, blogi, znane postaci – wszyscy mówili o xhtml, powstały książki choćby Zeldmana czy Meyera (do Polski moda dotarła trochę później). Nagle zaczęto wymyślać hacki dzięki czemu css działał w każdej przeglądarce, powstały takie pojęcia jak faux columns, css sprites etc. I co najważniejsze – tak jak ikona e na pulpicie oznaczała internet tak ten magiczny X nawiązywał do semanatyki, walidacji, css. Ludzie się tym zachłysnęli – mieć na swojej stronie znaczek “xhtml valid” to nagle było jakby wyróżnienie. Jak el.pescado zauważył – były równoznaczne – tylko nikt jakoś wcześniej (oprócz w3c które jasno zawarło w specyfikacji tekst “nie należy używać tabel bo nie dają przenośności”) nie myślał o tych pojęciach. Choćby ten blog (wordpress) jest przykładem jak wiele się zmieniło. A kto wie jakby potoczyły się losy gdyby nie zaczęto tyle o sprawie mówić. Może dalej IE miałby 98% rynku, może opera i firefox w ogóle by nie istniały bo nie byłoby zapotrzebowania dla zacofanych stron opartych o tabele, font, center, activex i inne wynalazki. Więc polecam trochę refleksji przed napisaniem kolejnego komentarza.
Fakt – i to jest rzeczywista różnica, a nie wyimaginowana w stylu “w HTML można używać i a w XHTML trzeba em”, “w HTML robi się layouty na tabelkach a w XHTML na divach” czy “w XHTML trzeba poprawnie zamykać tagi a w HTML nie”.
Jest w tym trochę prawdy, ale jak sam piszesz, xhtml niejako przez przypadek “podczepił się” pod te wszystkie przemiany – po prostu nadał etykietkę całemu ruchowi, mimo, że ruch ten nie miał w zasadzie z xhtml nic wspólnego.
Na koniec trzeba pamiętać, że dziś są inne czasy, natomiast znajdujemy się na portalu dla ludzi obeznanych z tematem, gdzie nie wypada stosować takich uogólnień;)
Miał trochę wspólnego. XHTML został tak zaprojektowany, by umożliwić izolację formy od treści – wyrzucenie znaczników do formatowania(w wersji strict na pewno), itd.
Niedokładnie. Izolacja formy od treści była, owszem, celem, ale już samego HTML 4.0. Stąd wyrzucenie z HTML 4.0 Strict (“właściwej” wersji HTML) znaczników prezentacyjnych.
XHTML 1.0 nie idzie ani krok dalej – stanowi dokładne odbicie semantyki HTML 4.0 w składnię pochodną XML.
W XHTML 1.0 w ogóle nie można korzystać z przestrzeni nazw XML, więc MathML odpada. W XHTML 1.1 można bodajże użyć tylko MathML, SVG i RDF. Natomiast opierając się na artykule porneLa (http://pornel.net/html5) HTML5 pozwala na użycie tych wynalazków, co więcej, serwując go jako application/xhtml+xml możesz używać wszystkich przestrzeni XML!
Wszystkich zdefiniowanych (czyli wrzuconych przez WHATWG do jednego wora). Co zrobić z rozszerzalnością jeszcze nie wymyślili (FAQ, punkt 6).
HTML5 pozwala? kłamstwo. Przepisałem stronę XHTMLową na HTML5, i inline’owy SVG przestał działać w przeglądarkach Firefox, Opera i Arora. No chyba, że “specyfikacja pozwala” – jeśli tak, to ze “powszechnym wsparciem dla html5″ jest gorzej niż z XHTML2.
XHTML5 + inline SVG: http://intertwingly.net/blog/
HTML5 + SVG działa w Firefox 3.6+ jak włączysz parser html5 w about:config (oczywiście, gdy to zostanie ukończone będzie działało normalnie).
W3C cechuje bizantyjska wręcz biurokracja, powolność, brak elastyczności przy jednoczesnym braku konsekwencji. Ta organizacja to po prostu moloch zupełnie nie przystający do szybkości z jaką rozwija się Internet. No ale czego się spodziewać, skoro W3C wyrosło z ludzi zatrudnionych w państwowych instytucjach naukowych…
Wszystkim krytykom HTML 5 polecam krótki artykuł autorstwa Kornela Lesińskiego na ten temat: http://pornel.net/html5
Część “Wsparcie przez IE” opisuje _wady_ specyfikacji HTML5
No właśnie. W tym rozdziale czytamy:
“Składnia HTML 5 powstała przez reverse-engineering IE, a wiele z nowych elementów HTML bazuje na dotychczas niestandardowych rozszerzeniach IE.“,
i już mamy odpowiedź, dlaczego HTML5 będzie mógł być serwowany jako text/html, dlaczego cofamy się do zupy znaczników, zapomnianego wytrycha EMBED i innych dziwactw rodem z zeszłego stulecia – wszystko po to aby o IE można znowu mówić jako o przeglądarce internetowej.
Pisanie serwisów internetowych “pod przeglądarkę” zawsze piętnowałem jako kompletny brak profesjonalizmu i jedną z największych plag sieci www i cieszyłem się, że wraz z upowszechnianiem się standardów sieciowych i rozwoju przeglądarek, praktyka ta traci na popularności. Nawet w najgorszych przewidywaniach nie sądziłem, że odnosząca sukcesy na polu walki z tym szkodliwym procederem, dumna ze swej niezależności, uznana instytucja standaryzująca, kompletnie skapituluje sprzeniewierzając się swej misji i tworząc standard “pod przeglądarkę” skreśli dorobek ostatnich lat.
HTML 5 działa w Gecko, Webkit i Presto, więc używanie HTML 5 to nie jest pisanie pod IE.
Opera i Mozilla zapoczątkowały tworzenie HTML 5, bo “dorobek W3C” okazał się bezużyteczny w sieci.
10-kurwa-lat minęło i application/xhtml+xml nadal jest bezużyteczne z powodu IE.
IE jest i nie zniknie, więc albo można przez następne 10 lat udawać, że się robi krok na przód (serwując XHTML parserowi HTML w IE) albo pogodzić się z rzeczywistością i opracować coś, co będzie wreszcie działało normalnie, bez żadnych “ale”.
Jeśli chcesz coś niedziałającego w IE, HTML 5 pozwala ci używać składni XML (która nie otworzy się w IE w ogóle).