Lachlan Hunt: Migrated polish FAQ from blog

2007-09-09T14:10:05Z

Migrated polish FAQ from blog

New page

== Co to jest WHATWG i dlaczego zostało utworzone? ==

W 2004 po warsztatach W3C, firmy takie jak: Apple, Mozilla i Opera zaniepokoiły się kierunkiem obranym przez W3C w stosunku do XHTML, brakiem zainteresowania dotyczącym HTML i potrzeb autorów serwisów internetowych. W odpowiedzi, firmy te wyznaczyły sobie misję związaną z tymi zagadnieniami i w ten sposób powstała grupa robocza Web Hypertext Application Technology (skrót: WHATWG).

Obecnie WHATWG jest stale rosnącą grupą producentów przeglądarek, deweloperów i ludzi zainteresowanych rozwojem nowej generacji HTML oraz technologii pokrewnych, w szczególności takich, które pozwalają autorom pisać i umieszczać aplikacje w seci internetowej.
== Co to jest (X)HTML 5? ==

[Web Applications 1.0, Web Forms 2.0…]
== Co się dzieje z XHTML 2.0? ==

[Znaleść prosty i dyplomatyczny sposób na przedstawienie statusu XHTML 2.0. Zobacz [http://www.whatwg.org/specs/web-apps/current-work/#relationship0 Notatki Web Apps na temat XHTML2]]
== Co się dzieje z XForms? ==

[zobacz [http://www.whatwg.org/specs/web-forms/current-work/#r-to-xforms Notatki Web Forms na temat XForms]]
== Dlaczego potrzebne jest HTML 5 i XHTML 2.0? ==

[Nie jest! - Należy wyjaśnić dlaczego obie specyfikacje istnieją]
== Po co udoskonalać HTML? ==

[Ponieważ jest to język używany przez większość autorów stron i jest on obsługiwany przez wszystkie przeglądarki.]
== Dlaczego nie udoskonalić XHTML zamiast HTML? ==

[HTML 5 udoskonala zarówno HTML jak i XHTML…]
== Czy (X)HTML 5 w końcu położy kres debacie dotyczącej XHTML jako text/html? ==

Tak. W przeciwieństwie do HTML 4.01 i XHTML 1.0, wybór HTML czy XHTML zależy od typu MIME, a nie od DOCTYPE. Zobacz [http://blog.whatwg.org/html-vs-xhtml HTML vs. XHTML]
== Czy XHTML jest lepsze od HTML? ==

[Niektórzy mówią, że XHTML jest lepsze ponieważ… Zobacz następną odpowiedź.]
== Czy HTML jest lepsze od XHTML? ==

[Niektórzy mówią, że HTML jest lepsze ponieważ… Zobacz poprzednią odpowiedź.]
== Jaki będzie DOCTYPE? ==

W HTML: <!doctype html>. Jedynym powodem dla którego wstawia się DOCTYPE w HTML to uruchomienie trybu standardowego w przeglądarkach.

W XHTML nie wymaga się DOCTYPE. Można go umieścić jeśli się chce, ale nie jest to zalecane, ponieważ ma to jedynie znaczenie przy walidacji w parserach walidacyjnych, których przeglądarki i tak nie stosują.
== Jeśli nie ma DTD, jak można walidować stronę? ==

Używając [http://hsivonen.iki.fi/validator/html5/ testera zgodności ].
== Co to jest serializacja HTML? ==

Serializacja HTML odnosi się do syntaksu dokumentu HTML zdefiniowanego w HTML 5, który jest oparty na syntaksie SGML z wcześniejszych wersji HTML, ale jest on bardziej kompatybilny z tym jak przeglądarki obsługują HTML w rzeczywistości.

Każdy dokument, którego typ MIME jest określony jako text/html uważany jest za serializację HTML, nawet jeśli autor zastosował składnię XML.
== Co to jest serializacja XML (lub XHTML)? ==

Serializacja XML odnosi się do składni określonej przez XML 1.0 i Namespaces w XML 1.0. Źródło, które ma XML MIME type takie jak: application/xhtml+xml lub application/xml jest dokumentem XML i jeśli stosuje elementy w nazwach przestrzeni HTML, to zawiera XHTML. Jeśli głównym elementem jest “html” w nazwach przestrzeni HTML , to dokument nazywa sie dokumentem XHTML.
== Jakiego typu MIME używa HTML 5? ==

Serializacja HTML musi być serwowana przy użyciu text/html MIME type.

Serializacja XHTML musi być serwowana przy użyciu XML MIME type, np.: application/xhtml+xml lub application/xml. W przeciwieństwie do XHTML 1.0, XHTML 5 nie może być wysyłana jako text/html.

Stosowanie niewłaściwego MIME type (text/html) dla XHTML spowoduje, że dokument będzie parsowany według wymogów stawianych dla HTML. Innymi słowy, będzie traktowany jako "zupa znaczników" (tag soup). Zapewnienie XML MIME type jest jedynym sposobem na to aby przeglądarki obsługiwały dokument jako XML.
== Przeglądarki nawet nie obsługują w pełni HTML 4.01 i XHTML 1.0, więc po co tworzyć nową wersję? ==

[HTML 4.01 i XHTML 1.0 nie są dostatecznie precyzyjne. W obecnym stanie rzeczy, przeglądarki nie mogą w pełni implementować HTML 4.01 i dalej być kopatybilnymi.]
== HTML działa, więc dlaczego trzeba go naprawiać? ==

[HTML tak naprawdę nie działa. (wyjaśnić…)]
== Którzy producenci przeglądarek wspierają rozwój HTML 5? ==

Apple, Mozilla i Opera.
== Którzy producenci przeglądarek wspierają rozwój XHTML 2.0? ==

Ah… *chrząknięcie*…
== A Microsoft i Internet Explorer? ==

HTML 5 jest rozwijane z myślą o komptybilności z IE. Obsługa wielu funkcji może być zapewniona przy użyciu JavaScript.
== Kiedy będzie można zacząć stosować nowe funkcje? ==

Tak szybko jak przeglądarki zaczną je obsługiwać. Nie trzeba czekać aż HTML5 stanie się rekomendacją, ponieważ nie może się to wydarzyć do czasu kiedy implementacja zostanie kompletnie ukończona. [należy rozszerzyć tą odpowiedź ]
== Czy HTML 5 posida wsteczną kompatybilność? ==

Tak. (wyjaśnić)
== Jak mogę pomóc? ==

Jest wiele rzeczy, które możesz zrobić. Zobacz [[What_you_can_do|co mogę zrobić]]!
== Czy trzeba płacić składki członkowskie, aby uczestniczyć? ==

Nie, uczestnictwo jest otwarte dla wszystkich. Możesz zapisać się na [http://whatwg.org/mailing-list listy mailingowe WHATWG]. Można również [http://blog.whatwg.org/w3c-restarts-html-effort przyłączyć się do nowej grupy W3C - HTMLWG], co jest troszeczkę dłuższym procesem.
== Jak można śledzić zmiany w specyfikacji? ==

Specyfikacja jest dostępna w [http://svn.whatwg.org/ subversion repository]. Można używać dowolnego svn client do sprawdzenia najnowszej wersji i stosować narzędzia diff do porównania zmian. Można również używać [http://html5.org/tools/web-apps-tracker Web Applications 1.0 ((X)HTML5) Tracker Tool]. Narzędzie to pozwala na porównanie wersji specyfikacji.
== Jakiego typu klasy i identyfikatory stosuje się w elementach DIV? ==

[Link do badań na ten temat. Potrzebne jest przeszukanie archiwum odnośnie poprzednich dyskusji na ten temat.]
== Kiedy HTML 5 zostanie ukończone? ==

Około 15 lat lub więcej zanim stanie się rekomendacją W3C (załączyć przybliżony harmonogram)

Aby specyfikacja stała się rekomendacją, powinna być ona w pełni wdrożona i interoperacyjna, co jest poświadczone tysiącami testów (20.000 testów dla całej specyfikacji to najprawdopodobniej minimalna liczba). Jeśli rozważy się jak dużo czasu zajmie napisanie tylu testów i jak dużo czasu trzeba poświęcić na implementacje każdej funkcji, wtedy człowiek rozumie dlaczego cały proces jest taki długi.

Jednakże WHATWG uznaje i rozumie ten problem: różne części specyfikacji są na różnych etapach rozwoju. Niektóre sekcje są stosunkowo stabilne i ich implementacja jest na ukończeniu, co umożliwia stosowanie ich już teraz (np.: <canvas>). Ale istnieją również sekcje, które są ciągle zmieniane lub nie są jeszcze napisane.

Nadal opracowuje się szczegóły, ale w planie jest wskazywanie stopnia stabilności każdej sekcji. Sekcje takie jak np.: Link Types, które są stosunkowo proste, nie zabiorą dużo czasu na kompletną interoperatywną implementację. Faktem jest, że Mozilla już wprowadza nowe funkcje autodiscovery w Firefox 3.0, a nie powinno to zająć dużo czasu zanim np.: Technorati, Bloglines, itp. zaczną podążać tym samym śladem.

Kiedy dana sekcja jest interoperacyjna, jest ona całkiem stabilna i istnieje małe prawdopodobieństwo dużych zmian. Zmiany w takich sekcjach miałyby raczej charakter redakcyjny, szczególnie, gdy dana funkcja jest już w powszechnym zastosowaniu (tak jak obecnie autodiscovery).

Zasadniczo, nie powinno się przywiązywać dużej uwagi co do statusu całej specyfikacji. Powinno się raczej patrzeć na status poszczególnych sekcji.
== Czy powinienem zamykać puste elementy za pomocą /> czy >? ==

Void elements w HTML (nowa nazwa na puste elementy) nie wymagają ukośnika. Np.: zamiast pisać <br />, można jedynie napisać <br>. Stosuję się to dla wszystkich pustych elementów, w tym img, input, itp.

Jednakże, ze względu na szerokie zastosowanie XHTML 1.0, istnieje spora liczba stron używających końcowego ukośnika. Z tego powodu sładnia ta jest dozwolona (chociaż nie zalecana) po to, aby ułatwić przejście z XHTML 1.0 na HTML5.

Ważnym jest, aby zdawać sobie sprawę, że składnia ta jest zbędna w HTML i jest ona ignorowana przez przeglądarki. Chociaż jest to składnia XML, nie oznacza to, że dokument HTML będzie parsowany narzędziami XML. HTML i XHTML są oddzielnymi serializacjami i każda z nich musi być przetworzona narzędziami obsługującymi dany format.
== Jeśli stosuje się poprawną składnię w dokumentach HTML, czy można parsować je w parserze XML? ==

Nie, HTML i XML [http://html5.lachy.id.au/output#differences bardzo się różnią], w szczególności wymogami parsowania. Ale ponieważ HTML 5 jest zdefiniowany w kategoriach DOM, w większości przypadków istnieją zarówno serializacje HTML jak i XHTML representujące ten sam dokument. Istnieje natomiast kilka różnic, wyjaśnionych poniżej, które uniemożliwiają niektórym dokumentom HTML prezentację jako dokumentów XHTML i wice wersa.

Jeśli chce się przetwarzać dokument HTML jako XHTML, wymaga to konwersji na XHTML; i wice wersa jeśli chodzi o przetwarzanie XHTML jako HTML.
== Co to jest deklaracja nazw przestrzeni? ==

W XHTML wymagane jest określenie namespace. (należy znaleść proste wyjaśnienie do czego służy namespace)

<html xmlns="http://www.w3.org/1999/xhtml">

W HTML atrybut xmlns jest dozwolony jedynie na elemencie html tylko wtedy, gdy jego wartość wynosi “http://www.w3.org/1999/xhtml“. Nie robi on niczego innego, poza tym, że pozwala na ułatwienie przejścia z XHTML 1.0. Nie jest to deklaracja nazw przestrzeni w dokumencie HTML, ponieważ HTML nie obsługuje nazw przestrzeni.
== Czy w HTML będzie obsługa nazw przestrzeni? ==

HTML5 jest definiowany w kategoriach DOM i wszystkie elementy HTML będą istnieć w nazwach przestrzeni HTML: http://www.w3.org/1999/xhtml. Jednakże, w przeciwiństwie do serializacji XHTML, nie istnieje prawdziwa składnia nazw przestrzeni w serializacji HTML (zobacz poprzednie pytanie). Innymi słowy, nie trzeba deklarować nazw przestrzeni w znacznikach HTML w taki sam sposób jak to ma miejsce w XHTML.

[http://html5.lachy.id.au/output#namespace-decl XHTML wymaga by nazwy przestrzeni były deklarowane] przy użyciu atrybutu xmlns. Deklaracja namespace nie jest potrzebna w HTML, ponieważ przeglądarki na podstawie [http://html5.lachy.id.au/output#mime-type MIME type] (text/html) będą wiedziały, że jest to dokument HTML .

Proponowano wprowadzenie znaczników MathML do HTML, które istniałyby w nazwie przestrzeni MathML. Jeśli ta propozycja zostałaby zaakceptowana, będzie ona obsługiwana w taki sposób, który nie wymaga konkretnej deklaracji w znacznikach.
== Jak określić kodowanie znaków? ==

W przypadku HTML zaleca się sprecyzowanie kodowania przy użyciu nagłówka HTTP Content-Type. Jeśli nie można [http://www.w3.org/International/O-HTTP-charset skonfigurować serwera ] do wysyłania właściwego nagłówka, można zastosować element meta. Element meta użyty do tego celu powinien pojawić się jako pierwszy element w znaczniku head (nawet przed title) oraz w pierwszych 512 bajtach pliku.

<meta charset="UTF-8">

Proszę zauważyć, że element meta jest inny niż HTML 4, chociaż jest kompatybilny z wieloma przegladarkami z powodu w jaki wdrożono rozpoznawanie kodowania.

W XHTML, stosuje się reguły XML do określania kodowania znaków. Można zastosować nagłówek HTTP Content-Type lub deklarację XML.

<?xml version="1.0" encoding="UTF-8"?>

W przeciwnym razie, należy zastosować domyślne UTF-8 lub UTF-16. Zaleca się stosowanie UTF-8.
== Jakie są różnice pomiędzy HTML i XHTML? ==

Zobacz listę [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|różnic pomiędzy HTML i XHTML]] w wiki.
== Czy HTML 5 obsługuje href na każdym elemencie tak jak XHTML 2.0? ==

Nie, obsługa href we wszystkich elementach wiąże się z wieloma problemami, które utrudniają obsługę w HTML 5.

* Nie jest wstecznie kompatybilna z obecnymi przeglądarkami.
* Nie dodaje żadnej nowej funkcji, która nie byłaby możliwa przy zastosowaniu elementu a.
* Jest bezsensowna z niektórymi elementami takimi jak: input i button, gdzie zastosowanie href ingerowałoby w ich normalną funkcję.
* Producenci przeglądarek donoszą, że byłoby to bardzo kopleksowe zadanie.

Jedynym plusem jest to, że href redukuje czas zapisu w niektórych przypadkach, ale w świetle swoich minusów , nie jest to wystarczający powód do zapewnienia całkowitej obsługi.

FAQ/pl - Revision history

Lachlan Hunt: Migrated polish FAQ from blog