Poza kursem, tłumaczeniami i artykułami cierpię na niemoc twórczą. Och, weno, weno - kreacjo (kreaturo) - where art thou!

Tylko pięć encji jest “bezpiecznych”.

Tylko pięć encji (<, >, &, " i ') jest na pewno obsługiwane przez wszystkie przeglądarki. Inne mogą zostać całkowicie pominięte, bądź wypisane bez zamiany na symbol (& nie zamieni się w “&” tylko zostanie wyświetlone jako “&”). Dla przykładu, jeśli Twoja strona zawiera   bądź ”, zostanie to po prostu “wypisane” przez Safari. Opera omija nieznane encje, podczas gdy rodzina Gecko rozpozna encje i wyrenderuje je poprawnie jeśli “the document references a public identifier for which there is a mapping in the browser’s pseudo-DTD catalog and the document has not been declared standalone” (Mozilla FAQ).

Korzystając z UTF-8, stosowanie którego jest zalecane, możemy skorzystać ze wszystkich (prawie) znaków jakie tylko chcemy, po prostu wpisując je z klawiatury (bez potrzeby korzystania z encji bądź innych, podobnych, odniesień. W przypadku w którym nie chcesz, bądź nie możesz skorzystać z UTF-8, encje numeryczne są obsługiwane i uznane za bezpieczne w każdych warunkach.

Zawartość komentarzy SGML może zostać zignorowana

Komentarze SGML (komentarze HTML są w istocie komentarzami SGML, <!– komentarz –>) mogą i są traktowane jako komentarze, nawet jeśli są umieszczone wewnątrz skryptów czy arkuszy stylów.

W HTML powszechną praktyką było umieszczanie zawartości skryptu w tego typu komentarzach by ukryć je przed przeglądarkami nie obsługującymi znaczników script bądź style, tym samym unikając sytuacji, w której zawartość takiego znacznika byłaby po prostu wyświetlona jako tekst na stronie WWW.

W XHTML stosowanie tej metody sprawi, że wszystko wewnątrz komentarza zostanie zignorowane przez przeglądarkę.

Przeglądarki, które nie obsługują elementów script czy style, są tak rzadkie, że można je spokojnie zlekceważyć, nawet tworząc stronę w zwykłym HTML.

Zawartość tagów script oraz style jest traktowana jako XML.

Elementy te traktowane są jako PCDATA (parsed character data), nie zaś jako CDATA (character data). Z tego powodu, wszystko co jest w nich zawarte i wygląda jak XML zostanie tak właśnie potraktowane, i “wyrzuci” błąd jeśli nie będzie zapisane poprawnie.

Jeśli chcesz w elementach script oraz style wykorzystać takie znaki, musisz umieścić je w bloku CDATA:

<script type="text/javascript">
<![CDATA[
...
]]>
</script>

Wewnątrz sekcji CDATA możesz używać dowolnych znaków i ich sekwencji bez obawy, że zostaną potraktowane jako XML.

W dokumentach wysyłanych jako text/html, otwieranie i zamykanie znaczników sekcji CDATA musi zostać wykomentowane, by ukryć je przed przeglądarkami nie obsługującymi CDATA:

<script type="text/javascript">
// <![CDATA[
...
// ]]>
</script>
<style type="text/css">
/* <![CDATA[ */
...
/* ]]> */
</style>

Jeśli jesteś BARDZO uparty i chcesz ukryć znaczniki CDATA przed BARDZO starymi przeglądarkami, powinieneś skorzystać z metody opisanej przez Iana Hicksona w Sending XHTML as text/html Considered Harmful:

<script type="text/javascript">
<!--//--><![CDATA[//><!--
...
//--><!]]>
</script>
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
...
/*]]>*/-->
</style>

Jest jeszcze jedna, być może lepsza metoda - skrypt negocjujący mime-type, który usuwa/dodaje bloki CDATA w zależności od tego jak wysyłany jest dokument.