Autor przekładu: Robert Błaut
Lokalizacja dokumentu: http://standards.blaut.biz/xhtml-faq/
Dokument ten jest tłumaczeniem oryginalnego HTML and XHTML Frequently Answered Questions.
Przekład jest nienormatywny i może zawierać błędy powstałe w czasie tłumaczenia. Status normatywny posiada jedynie oryginalna wersja w języku angielskim dostępna pod adresem http://www.w3.org/MarkUp/2004/xhtml-faq.
Redaktor: Steven Pemberton, W3C/CWI
Data wersji: 21 lipca 2004
Inne pokrewne FAQ:
Wszelkie komentarze, sugestie dotyczące treści tego dokumentu prosimy przesyłać na adres www-html-editor@w3.org. Do tematu listu prosimy dopisać słowo FAQ.
HTML jest najprawdopodobniej najpopularniejszym językiem znaczników na świecie. W momencie wprowadzenia standardu XML, zorganizowano dwudniowe warsztaty mające podjąć decyzję, czy nowa wersja HTML napisana w języku XML jest rzeczywiście potrzebna. Końcowy wniosek był jasny 'Tak, jest potrzebna': korzystając z HTML opartego na XML inne języki XML będą mogły zawierać kod XHTML, jak również dokumenty XHTML będą mogły zawierać osadzony kod innych języków znacznikowych. Przy okazji tworzenia nowego standardu będzie można oczyścić fragmenty istniejącej specyfikacji HTML oraz dodać nowe funkcjonalności, jak np. lepsza obsługa formularzy.
Jeśli twoje dokumenty są napisane w czystym języku XHTML 1.0 (nie zawierają innych języków znaczników) możesz nie zauważyć wielkiej różnicy. Ale wraz z pojawianiem się coraz większej liczby narzędzi XML, takich jak na przykład XSLT do przekształcania dokumentów, zaczniesz zauważać przewagę stosowania XHTML. Na przykład XForms pozwoli Ci na proste edytowanie dokumentów XHTML(lub innych dokumentów XML). Aplikacje semantycznej sieci www będą mogły w pełni korzystać z zalet dokumentów XHTML.
Jeśli Twój dokument jest czymś więcej niż tylko czystym dokumentem XHTML 1.0, np. zawiera kod języka MathML, SMIL, czy SVG, w takim przypadku zalety tego języka widzisz od razu: nie możesz wykonać takiego zadania korzystając z języka HTML.
Nie. Język HTML nie przestrzega zasad języka XML. Musisz dokonać niezbędnych zmian, aby Twoje dokumenty były zgodne z regułami składni XML.
HTML Tidy ma możliwość konwersji dokumentów HTML do XHTML. Przeglądarka Amaya jest w stanie zapisać dokument HTML jako XHTML.
Takie działanie jest w pełni zamierzone. Przeglądarki HTML akceptują każdy dokument, poprawny lub nie i próbują zrobić z tym coś pożytecznego. Konieczność korygowania błędów popełnionych przez autorów stron www powoduje, że przeglądarki są bardzo skomplikowanymi aplikacjami, zwłaszcza, jeśli oczekuje się, że wszystkie przeglądarki powinny zachowywać się identycznie. To również przyczyniło się do tego, że ogromna liczba dokumentów HTML jest nieprawidłowa, ponieważ skoro dobrze wyświetlają się w przeglądarce, autor nie zdaje sobie sprawy z błędów. To czyni zadanie tworzenia nowych agentów użytkownika ogromnie trudnym, gdyż dokumenty deklarowane jako HTML są często niskiej jakości.
Wszystkie przeglądarki wiedzą jak renderować poprawne dokumenty HTML. Jakkolwiek, jeśli są one niepoprawne, przeglądarka musi poprawić taki dokument, a ponieważ nie wszystkie przeglądarki poprawiają nieprawidłowe dokumenty w identyczny sposób, Twoje dokumenty mogą wyglądać i działać odmiennie w różnych przeglądarkach. Ponieważ na rynku obecnych jest kilkadziesiąt różnych przeglądarek i z każdym dniem pojawiają się nowe (nie tylko dla komputerów PC, ale również PDA, telefonów komórkowych, telewizorów, drukarek, a nawet lodówek), nie jest możliwe przetestowanie Twoich dokumentów na każdej z tych przeglądarek. Jeśli stworzysz niepoprawny dokument HTML i taki dokument nie będzie poprawnie działał w danej przeglądarce, to będzie Twój błąd; jeśli z kolei napiszesz poprawny dokument HTML i on dalej nie będzie prawidłowo działał w wybranej przeglądarce, będzie to oznaczać, że przeglądarka ta posiada błędy.
W3C prowadzi serwis: http://validator.w3.org/. Przeglądarka Amaya jest również w stanie przetestować dany dokument pod kątem poprawności kodu HTML.
Chociaż przeglądarki są w rzeczy samej ważnymi użytkownikami języka HTML oraz XHTML, istnieją również inne aplikacje i systemy, które mogą czytać dokumenty stworzone w tych językach. Na przykład silniki wyszukiwarek czytają takie dokumenty, a przecież przeglądarkami nie są. Poprzez użycie terminu "agent użytkownika" staramy się zwracać uwagę na te różnice.
Na przykład, gdy szukasz czegoś w wyszukiwarce Google często będziesz mógł ujrzeć w wynikach poszukiwań coś takiego: "Ta strona korzysta z ramek, a Twoja przeglądarka niestety nie obsługuje ich." Tekst taki może odstraszać potencjalnych użytkowników. Autor takiej strony nie zdaje sobie sprawy, że istnieją inne niż przeglądarki programy, które mogą czytać jego strony. Powinien on w sekcji <noframes>
zamieścić bardziej sensowny tekst, który nie prezentowałby się co najmniej dziwnie w wynikach wyszukiwarek.
We wczesnych latach rozwoju języka HTML różne organizacje i firmy dodawały wg własnego widzimisię nowe elementy i nowe atrybuty do tego języka. Zagroziło to powstaniem wielu różnych wzajemnie niekompatybilnych wersji języka HTML. XML (X oznacza rozszerzalny (ang. Extensible)) pozwala każdemu na użycie własnych nowych elementów, bądź elementów z innych języków. Jednak, aby przeglądarka lub inny agent użytkownika wiedziały, które elementy należą do którego języka, musisz je o tym poinformować. Do tego właśnie celu służą deklaracje przestrzeni nazw.
XHTML jest aplikacją formatu XML, a to oznacza, że powinien być przesyłany z odpowiednim typem MIME (application/xhtml+xml
, application/xml
lub text/xml
). Jakkolwiek XHTML 1.0 został zaprojektowany tak, aby przestarzałe agenty użytkownika nie miałby problemu z przetwarzaniem dokumentów napisanych w tym języku. Jeśli zastosujesz się do kilku prostych zasad, wiele Twoich dokumentów XHTML 1.0 będzie bez problemów obsługiwanych w przestarzałych przeglądarkach. Jednak ponieważ takie przeglądarki rozumieją tylko typ MIME text/html
, dlatego musisz użyć tego właśnie typu do przesyłania dokumentów XHTML 1.0 do tych przeglądarek. Lecz musisz zdawać sobie sprawę, że przesyłanie dokumentów XHTML do przeglądarek jako text/html
oznacza, że te przeglądarki widzą takie dokumenty jako zwykłe dokumenty HTML, a nie XHTML.
Takimi przeglądarkami są wszystkie oparte o kod projektu Mozilla (Mozilla, Netscape 5 i wyższe, Galeon i Firefox, Camino, Chimera, DocZilla), Opera, Amaya, iCab, Safari, wszystkie przeglądarki w telefonach komórkowych, które obsługują WAP2. W zasadzie, każda nowoczesna przeglądarka akceptuje typ MIME application/xhtml+xml. Większość tych przeglądarek również nie ma problemu z application/xml
. Zobacz szczegóły na stronie: Test obsługi typu MIME XHTML.
Nie. Jakkolwiek istnieje trik, który pozwala serwować dokumenty XHTML Internet Explorerowi jako application/xml
.
Dopisz na początku Twojego dokumentu poniższe linie:
<?xml version="1.0" encoding="iso-8859-1"?> <?xml-stylesheet type="text/xsl" href="copy.xsl"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>
gdzie plik copy.xsl
ma następującą zawartość:
<stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"> <template match="/"> <copy-of select="."/> </template> </stylesheet>
Zauważ, że ten plik musi się znajdować w tym samym katalogu, w którym znajduje się dokument zawierający odniesienie do niego.
Mimo, że plik jest serwowany jako XML i jest również parsowany jako XML, przeglądarka myśli, że otrzymała dokument o typie text/html
i dlatego ten dokument XHTML 1.0 powinien być napisany zgodnie ze wskazówkami dotyczącymi dostosowywania takich dokumentów dla przestarzałych przeglądarek.
Twój dokument XHTML wciąż będzie dobrze działał w przeglądarkach, które akceptują XHTML 1.0 jako application/xml
.
Nie. Reguły CSS, które mają odniesienie tylko do HTML, mają zastosowanie tylko do dokumentów przesyłanych text/html
.
Nie. Z uwagi na sposób w jaki definiowany jest XML nie są możliwe triki takie jak, generowanie kodu html przez skrypty podczas przetwarzania przez parsera XML kod dokumentu.
W dalszym ciągu możesz osiągnąć identyczne efekty, ale musisz w tym celu skorzystać z modelu DOM, aby mieć możliwość dodawania i usuwania elementów
XHTML 1.1 jest czystą aplikacją XML i taką powinien w zamierzeniach twórców specyfikacji pozostać. Kompatybilność wstecz z przestarzałymi przeglądarkami została zarzucona. Dlatego dokumenty XHTML 1.1 muszą być przesyłane z typem MIME application/xhtml+xml.
Nie został usunięty. XHTML 1.0 definiuje trzy wersje: strict (ścisłą), transitional (przejściową) oraz frameset (ramkową). We wszystkich trzech wersjach celowo zachowano tak duże podobieństwo z HTML 4.01, na ile pozwalał na to XML. XHTML 1.1 jest zaktualizowaną wersją odmiany XHTML 1.0 strict. W żadnej wersji HTML strict nie ma zawartego atrybutu target
. Pozostałe dwie wersje transitional i frameset nie zostały zaktualizowane, ponieważ nie było takiej potrzeby. Jeśli chcesz korzystać z atrybutu target
powinieneś wykorzystać wersję XHTML 1.0 transitional.
Modularyzacja XHTML nie została opracowana dla zwykłych użytkowników języka XHTML, ale dla projektantów języków opartych na standardzie XHTML. Zaobserwowano, że różne firmy i organizacje mają tendencję do projektowania własnych wersji HTML i XHTML, które są wzajemnie niekompatybilne na podstawowym poziomie. Modularyzacja XHTML dzieli specyfikację XHTML na kilkanaście modułów, które mogą być pojedynczo wybierane podczas definiowania nowego języka. W ten sposób mamy gwarancję, że każdy język oparty na XHTML, który korzysta z tabel, używa tej samej definicji tabel jak inne języki korzystające z tego samego modułu. Modularyzacja również dokładnie określa, gdzie można dodawać nowe elementy, a gdzie nie.
HTML i XHTML dobrze wypełniają swoją rolę, jednak jest wiele obszarów, które mogą być zdecydowanie bardziej udoskonalone. Obszary, które wymagają takich rozwiązań to przede wszystkim lepsze możliwości strukturalizacji, usunięcie funkcjonalności, które są zdublowane w XML, lepsza dostępność, internacjonalizacja, niezależność od platformy sprzętowej, rozbudowane formularze oraz ograniczenie potrzeby korzystania z języków skryptowych.
Nie. Element <img>
zostanie zastąpiony w XHTML2 czymś zupełnie innym (jeśli chcesz, możesz jednak wykorzystać <object>
).
Sposób działania elementu <img>
stwarza wiele problemów w HTML:
alt
. Taki stan rzeczy przyczynił się m.in. do słabej popularyzacji standardu PNG, który jest zdecydowanie lepszy od GIF i JPG, ponieważ autorzy stron korzystają powszechnie zaadaptowanych typów obrazków, aby mieć pewność, że każdy je zobaczy.alt
nie może być formatowany, dlatego jest wyświetlany jako czysty tekst.longdesc
- odnośnika do szczegółowego opisu obrazka, jako ułatwienia dla niewidomych osób, ale w praktyce jest rzadko implementowany.Standard XHTML2 mówi, że wszystkie obrazki są ekwiwalentne do niektórych części treści, dlatego pozwala na korzystanie z atrybutu src
z każdym elementem. Standard mówi: jeśli obrazek jest dostępny i przeglądarka może go przetworzyć, należy wyświetlić obrazek, w przeciwnym razie należy wyświetlić zawartość elementu. Na przykład:
<p src="map.png">Exit from the station, turn left, go straight on to <strong>High Street</strong>, and turn right</p>
Podstawową zaletą tej metody jest pełna funkcjonalność dokumentu w przypadku niedostępności obrazka z różnych powodów (na przykład uszkodzenie sieci) lub w przypadku braku obsługi przez przeglądarkę danego typu obrazka. Jeśli chcesz udostępnić kilka rodzajów obrazków, możesz to osiągnąć poprzez:
<p src="map.png"><span src="map.gif">Exit from station...</span></p>
jednak lepiej jest wykorzystać negocjację rodzaju treści, jeśli twój serwer daje takie możliwości (większość daje):
<p src="map">Exit from station...</p>
W tym przypadku negocjowany jest typ przesyłanego obrazka obsługiwanego przez daną przeglądarkę. Jeśli nie jest dostępny obrazek, wtedy zostanie wyświetlona zawartość elementu. Dodatkową zaletą tej metody jest to, że możesz w każdej chwili udostępnić na serwerze obrazek innego typu i nie będziesz musiał zmieniać kodu strony.
XLink i XHTML mają wzajemnie niezgodne wymagania w zakresie linkowania.
Jest wstecznie zgodny, ale inaczej niż poprzednie wersje języka HTML.
Ponieważ wcześniejsze wersje HTML były językami specjalizowanego przeznaczenia, bardzo ważne było zapewnienie wstecznej zgodności w nowych wersjach, aby nowe dokumenty mogły być bez problemu obsługiwane przez starsze przeglądarki. Z tego właśnie powodu na przykład element <meta>
posiada treść wewnątrz atrybutu, zamiast wewnątrz elementu. Gdyby było inaczej, stare przeglądarki wyświetlałyby tę treść.
Dziś, dzięki językowi XML i arkuszom stylów, takie ścisłe zachowanie wstecznej zgodności nie jest już konieczne, ponieważ obecne przeglądarki oparte na języku XML, czyli praktycznie 95% wszystkich przeglądarek na rynku, mogą przetwarzać nowe języki znaczników bez konieczności aktualizacji do nowszej wersji. Większość elementów XHTML 2 działa już teraz w istniejących przeglądarkach, czyli aplikacjach jeszcze nieprzygotowanych do obsługi XHTML2. Większość działa, ale nie wszystko: podobnie jak w czasach, gdy dodano do standardu HTML formularze i tabele, użytkownicy musieli czekać na nową wersję przeglądarek, tak teraz takie nowe funkcjonalności jak XForms oraz XML Events, będą wymagały, aby agenty użytkownika rozumiały te elementy.
Atrybut xml:space
dotyczy danych wejściowych: jakby to powiedzieć, określa on czy spacje będą obecne w drzewie DOM (np. w wewnętrznie przetwarzanym przez przeglądarkę dokumencie), nie określa on w jaki sposób będą wyświetlane spacje na ekranie wynikowym. Spacje wynikowe są kontrolowane przez własność 'whitespace
' z CSS. Ustawienie jej na 'pre
' oznacza, że spacje z drzewa DOM będą również obecne w wynikach, ustawienie jej na 'normal
' oznacza, że spacje będą składane (Standard CSS3 daje więcej możliwości w tym zakresie).
Z tego właśnie powodu wszystkie elementy w XHTML2 mają ustawione xml:space="preserve"
. W innym przypadku właściwość 'whitespace
' z CSS nie dawałaby żadnego efektu i nie miałbyś możliwości kontroli spacji. Domyślny arkusz stylów ma ustawione 'whitespace
' na 'normal
' z wyjątkiem elementu <pre>
, ale oczywiście masz możliwość zmiany tych ustawień.
Copyright ©2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.