Gone to grave yards every one (Parafraza słów piosenki “Where have all those flowers gone”).

Zaczyna mnie to męczyć i nudzić. XHTML okazuje się być rozczarowaniem w dodatku wychodzi na to, że ci, którzy zarzucali standardom zabijanie kreatywności mieli rację. Z wyjątkiem kilku serwisów, takich jak csszengarden, które pokazują jak strony mogą wyglądać, wszystko co trafia na sieć jest, jak by to ujął mój były pracodawca - blant and unexciting.

Strona wycentrowana, 768px na szerokość, font ten sam, tylko minimalne różnice w rozmieszczeniu elementów.

Przypomina mi to moją rozmowę z koleżanką z ASP, której zadałem pytanie kiedy była bardziej twórcza - przed, czy po pójściu na ASP i poznaniu tych wszystkich zasad, nazw i definicji. Wiecie jaka jest odpowiedź?

Marudzenie mode ON

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.

Wiosna w końcu nadeszła, więc czas zabrać się za porządki.

Ze mną już tak jest - co jakiś czas potrzebuję zmian w swoim życiu. Nie należy się więc dziwić jeśli któregoś dnia powiem “a pier.. to wszystko” i ryzykując wydziedziczenie przez ojca, wyjadę gdzieś na koniec świata łowić ostrygi.

Czy coś podobnego.

Nim do tego jednak dojdzie, postanowiłem ponownie zmniejszyć ilość systemów operacyjnych w moim komputerze domowym. Kto chce pomóc mi wybrać dystrybucję Linuksa, która powinna pozostać na moich dyskach i cieszyć się moimi względami (przynajmniej do przyszłego miesiąca, aż znów nie zachce mi się zmian), niech podniesie rękę i wciśnie przyciski na klawiaturze.

A do wyboru sąąąąąą..:

1. Debian
2. Gentoo
3. PLD
4. Ubuntu

with three columns and two rows Link Graphic otwo .pl dash Portal internetowy Link Graphic slash nag underline forum.gif Table with seven columns and one row Link Graphic slash ikonka underline poczta.gif E dash mail one GB Link Graphic tlen.pl Komunikator Link Graphic www.Tlenofon.pl Tlenofon Table end Table end Table end Table with one column and forty-four rows Link Strona główna right double angle bracket forum Dla webmasterów Table with one column and one row Link Spis tematów vertical bar Link Nowy temat vertical bar Link Szukaj vertical bar Link Pokaż nagłówki vertical bar Link Preferencje Table end Table with four columns and forty-two rows Data Odp. Temat Autor left bracket thirteen point zero four right bracket sixteen colon five eleven

To nie żart. Mniej więcej tak brzmi jedna ze stron pewnego portalu czytana przez screen reader.

A czy Ty chcesz wiedzieć, jak screen reader przeczyta Twoją stronę?

Fangs to plugin do Firefoxa emulujący działanie screen readera.

Kolejny draft artykułu z kursu na browsehappy.

Nie pamiętam już dokładnie kiedy zacząłem korzystać z XHTML. Pisząc już w HTML przestrzegałem wielu reguł, które stały się standardem w XHTML. Ot, po prostu wydawały mi się logiczne. Ale dopiero niedawno zacząłem używać XHTML poprawnie - serwując dokumenty jako application/xhtml+xml.

Wiedziałem wtedy, że na mojej drodze pojawią się problemy. Nie myślałem jednak, że będzie ich aż tyle. Jest po prostu cała masa drobnych spraw, które skutecznie potrafią utrudnić życie.

Niniejszy artykuł nie jest argumentem “za” bądź “przeciw” XHTML. Jest to właściwie tylko krótki spis problemów na jakie możesz natrafić zmierzając w stronę standardów. Czy zdecydujesz się na HTML 4.01, XHTML 1.0 serwowany jako text/html dla wszystkich przeglądarek czy XHTML 1.0 serwowany jako application/xhtml+xml dla tych, które potrafią to obsłużyć i text/html dla które nie potrafią - pozostawiam w Twojej gestii.

Jeszcze jedno - wymienione “haczyki” dotyczą tylko przeglądarek, które obsługują application/xhtml+xml, tym samym traktując XHTML jako XML. Prawdopodobnie jest to powód, dla którego tak rzadko mówiło się o tych problemach we wczesnych dniach XHTML - mało kto używał przeglądarek potrafiących obsłużyć taki mime-type, zatem wszyscy słali pliki jako text/html.

Obecnie wysyłanie XHTML jako XML jest coraz powszechniejsze. Głównie ze względu na fakt, że coraz więcej osób korzysta z przeglądarek takich jak Firefox, Mozilla, Opera, Safari czy innych, potrafiących w pełni obsłużyć XHTML/XML.

Także webdeveloperzy stają się coraz bardziej wyczuleni na to, czym w rzeczywistości jest XHTML (a nie jest tylko HTML’em ze zmienionym doctype, jakimś tam prologiem XML i slashami na końcu tagów).

Co jakiś czas wybuchały dyskusje na temat zastosowania i sposobu użycia XHTML. Niektóre były całkiem “gorące”. Ci, którzy brali w nich udział - wiedzą.

Jeśli zamierzasz umieścić na swojej stronie system negocjacji mime-type i wysyłać poprawnie XHTML, będziesz musiał wiedzieć co może się stać (i się stanie) z dokumentami, które zamierzasz opublikować, oraz jak uniknąć potencjalnych problemów.
Na początek polecam lekturę Content Negotiation i Serving up XHTML with the correct MIME type.

Inne, bardziej oczywiste, różnice między HTML a XHTML są wymieniane w każdym, dobrym, kursie XHTML: pisz tagi i ich atrybuty małymi literami, wartości atrybutów zawsze ubieraj w cudzysłów, sprawdź czy wszystkie tagi są pozamykane, itd.

Niemniej jest tego więcej gdy chcemy przesyłać XHTML jako XML.

Poprawna struktura jest wymagana

Przesyłane dokumenty muszą być poprawnie sformatowanym XML’em (co niekoniecznie znaczy, że są walidującym się XHTML). Nie ma kompromisów, nie ma miejsca na błąd. Jeśli dokument nie jest poprawny, wszystkie “zgodne” przeglądarki jak jeden mąż (z wyjątkiem IE, rzecz jasna) poinformują o błędzie i zaprzestaną renderowania strony.

Deklaracja kodowania znaków w prologu XML może byc wymagana

Jeśli w swoich dokumentach używasz kodowania innego niż UTF-8 czy UTF-16, deklaracja XML jest wymagana. Chyba, że informacja o kodowaniu wysyłana jest przez serwer.

Czy informacja o kodowaniu powinna być zawarta w nagłówkach wysyłanych przez serwer jest niesprecyzowana. Architecture of the World Wide Web, Volume One: Media Types for XML mówi:

In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing.

Z drugiej jednak strony, XHTML 1.0, Second Edition: Character Encoding mówi nam:

In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers.

Tak czy inaczej, nie zaszkodzi zdefiniować poprawnego kodowania w prologu XML:

<?xml version="1.0" encoding="iso-8859-2"?>

Jak dostać się z Dworca Centralnego w Wszawie na ulicę Zabraniecką, korzystając ze środków komunikacji miejskiej

Wiem, że autobus 517, ale ostatni raz Warszawę widziałem miesiąc temu przesiadając się na pociąg do Kielc

Prawnik, znający się na prawie autorskim/własności, poszukiwany na gwałt

Poniższy opis wymaga przetestowania.

Wiemy już mniej więcej jak zrobić pseudo kategorie na joggu za pomocą selektorów, ale to rozwiązanie może mieć jeszcze jedno zastosowanie. Komentarze.

Chcielibyście by Wasze komentarze były wyświetlane inaczej niż reszty? A może chcielibyście oznaczyć inaczej swą sympatię komentującą Waszego joga (by wszyscy wiedzieli kto jest kto i z kim ;)?

W szablonie z komentarzami do div‘a (tudzież td) dodajemy tak jak poprzednio atrybut title="": <div class="&COMMENT_CLASS;" title="&COMMENT_NICK;">.

Tutaj pojawia się jeden z dwóch fragmentów, których jeszcze nie sprawdziłem gdyż jak dotąd było mi strasznie nie po drodze z szablonem komentarzy. Zgodnie z moimi domysłami w title powinien pojawić się nick, bez żadnych dodatków. Efekt powinien być zatem podobny do tego: <div class="comment1" title="nbw">.

Teraz przychodzi kolej na CSS.

Mając tak spreparowany kod HTML, możemy go spróbować ostylować.

div.comment1[title~="nbw"] {border: 3px ridge #000;}

div.comment1[title~="ktośtam"] {border: 1px dotted #f90;}

W takich przypadkach mógłbym skorzystać ze znaku “=”, ale może kiedyś zdecyduję się wpisać np: “nbw na urlopie”?

Na koniec przyznaję, że to rozwiązanie ma jeszcze więcej słabych punktów niż rozwiązanie z pseudo-kategoriami. Wystarczy, że wpiszę się jako nbw-cośtam i przestanie działać. Poza tym, nie jest to sposób zabezpieczony przed podszywaczami.

Zatem jest to właściwie tylko ciekawostka, która podobnie jak kategorie mogłaby kiedyś zostać uwzględniona w engine joggera.

Bo widzisz, są tu tacy którzy się kochają

i muszą się spotykać, aby się ominąć

bliscy i oddaleni, jakby stali w lustrze

piszą do siebie listy gorące i zimne

rozchodzą się jak w śmiechu porzucone kwiaty

by nie wiedzieć do końca czemu tak się stało

są inni co się nawet po ciemku odnajdą

lecz przejdą obok siebie bo nie śmią się spotkać

tak czyści i spokojni jakby śnieg się zaczął

byliby doskonali lecz wad im zabrakło

bliscy boją się być blisko żeby nie być dalej

niektórzy umierają - to znaczy już wiedzą

miłości się nie szuka - jest albo jej nie ma

nikt z nas nie jest samotny tylko przez przypadek

są i tacy co się na zawsze kochają

i dopiero dlatego nie mogą być razem

jak bażanty co nigdy nie chodzą parami

można nawet zabłądzić lecz po drugiej stronie

nasze drogi pocięte schodzą się z powrotem.

ks. Jan Twardowski

Zaletą nowoczesnych systemów blogowych jest podział na kategorie notek. Dla przykładu, u Molly E. Holzschlag można odnaleźć kategorie takie jak web design, professional, blogging itp. U Davea Shea mogą to być accessibility, css czy reflective.

Jogger takiej możliwości nie daje. Blog.pl także nie.

Początkowo myślałem o wpisywaniu w treść notki np.: <div class="klasa dla danej kategorii">. Z oczywistych względów nie zadowalało mnie to.

Później myślałem o dodawaniu jakiegoś prostego znacznika, który “informowałby” arkusz stylów i skrypt js (chciałem, by odwiedzający stronę mieli wybór jakiej kategorii notki chcą czytać), że notka należy do tej a nie innej kategorii. Na tę chwilę zarzuciłem pomysł pisania skryptów, skoncentrowałem się na stronie wizualnej.

Na początku pisania notek na joggu próbowałem stosować nazwy kategorii zawarte w nawiasach kwadratowych umieszczone w tytule notki. Ten pomysł wydał mi się całkiem słuszny i poprawny. Zwłaszcza, gdy postanowiłem go ostylować.

Dla każdej notki w moim arkuszu stylów znajduje się definicja klasy "note". Zatem do stylowania nie mogłem użyć klasy. Identyfikator też odpadał z kilku powodów. Ale pozostał atrybut "title=".

Zatem w szablonie strony, div class="note" wzbogaciło się o title="&ENTRY_SUBJECT;".

Pora zająć się CSS’em.

Do tego posłużył mi selektor. Po powyższych zabiegach atrybut title zawiera w sobie ciąg łancuchów oddzielonych spacjami. Ścisłe określenie selektora nie zadziała. Zatem trzeba skorzystać z selektora pasującego do tego typu ciągu:

div.note[title~="[XHTML]“] {color: #000;}

Voila.

Oczywiście, to tylko przykład. Elementy w title mogą mieć różne nazwy i sposób zapisu.

Od razu przyznam, że ten sposób nie zadziała w przeglądarce IE. Ale dzięki temu, że domyślną klasą jest “note”, żaden z użyszkodników IE nie poczuje różnicy.