W kolejnym spotkaniu z semantyką języka XHTML skupię się na podaniu praktycznych rozwiązań kilku często spotykanych problemów oraz przedstawię złożenia XHTML – technikę łączenia elementów XHTML w celu nadania bardziej szczegółowego znaczenia większemu fragmentowi tekstu.

XHTML – powrót do korzeni

Język HTML w ciągu ostatnich 15 lat zatoczył pełne koło. Pierwsze specyfikacje HTML podane przez Tima Bernersa-Lee określały HTML jako język opisu struktury dokumentu. W okresie wojny przeglądarek, czyli w drugiej połowie lat 90. ubiegłego stulecia, wypaczenie początkowej idei HTML-a sięgnęło apogeum. Witryny z tego okresu przeładowane były wszelkiego rodzaju rozwiązaniami, których jedynym celem było modyfikowanie wyglądu. W ten sposób prezentacyjne cechy witryn z okresu 1995-2000 przesunęły na dalszy plan strukturę dokumentu, nie wspominając o semantyce.

Wraz z pojawieniem się przeglądarek, które dość spójnie implementowały CSS, nastąpił nawrót do początkowych koncepcji. Cechy wizualne witryny zostały w znacznym stopniu oddzielone od struktury dokumentu. Obecnie strony WWW ponownie stały się krótkimi zwięzłymi dokumentami, w których główny nacisk jest kładziony na strukturę. Wygląd dokumentów jest opisany przez arkusze stylów.

Semantyka przez małe s

Równolegle z HTML/XHTML/CSS rozwijana jest koncepcja sieci semantycznej. Jednak w kontekście opisu relacji łączących poszczególne dane zawarte na stronie język XHTML nie jest semantyczny. Dlaczego? Jak pisałem w poprzedniej części, nie ma możliwości wskazania na stronie WWW przedstawiającej rozkład jazdy autobusów relacji pomiędzy numerem linii, godziną odjazdu oraz adresem przystanku.

Do tego konieczny jest XML. (Nawiasem mówiąc, gdyby było to możliwe, stworzyłoby to dodatkowy problem. Odwiedzenie wszystkich podstron witryny, która oprócz danych będzie zawierała komplet łączących je relacji, pozwoliłoby odwiedzającemu przekopiować całą bazę danych: informacje wraz z łączącymi je relacjami. W takiej sytuacji zapisy w rodzaju: \”zabrania się automatycznego parsingu oraz dekompilacji zawartości\” – patrz strona domowa nagród akademii filmowej http://www.oscars.org/legal/index.html – straciłyby jakikolwiek sens, gdyż samo odwiedzanie witryny byłoby swoistym parsingiem.)

Spór o użycie terminu semantyczny w odniesieniu do niesemantycznego języka XHTML najlepiej podsumowuje w swoim quizie Dan Cederholm pisząc: \”Call it semantics, call it preferred methods, call it advantages and disadvantages etc. The bottom line is that talking about this stuff can be beneficial\”.

W istocie chodzi o znalezienie takich konstrukcji XHTML (czyli: zagnieżdżenia znaczników), które mają – w sensie semantyki lub w dowolnym innym kontekście – przewagę nad innymi rozwiązaniami.

Z powodu niedostatków pod względem semantycznym języka XHTML Tantek Çelik i Kevin Marks wprowadzili terminy: semantyka przez duże S oraz semantyka przez małe s (patrz: Tantek Çelik i Kevin Marks, \”Real World Semantics\”). Pierwszy określa semantykę definiowaną językami RDF/OWL. Drugi termin odnosi się do dokumentów HTML/XHTML.

Wprawdzie terminy te nie zyskały powszechnej akceptacji, jednak podział, jaki definiują, jest jasny i znajduje zastosowanie w wielu publikacjach dotyczących semantyki XHTML. Określenie semantyka przez małe s oznacza zgodność użycia znaczników z pewnymi regułami. Termin ten pokrywa się więc z rozważaniami prowadzonymi przez Cederholma w swoim quizie.

Kto ma rację, czyli o braku specyfikacji semantyki XHTML

Semantyka kodu XHTML nie jest unormowana przez żadną specyfikację, poza opisem samego języka. O ile w odniesieniu do składni HTML oraz XHTML specyfikacje W3C są zwięzłe, jasne i dokładne, to opis semantyki poszczególnych elementów sprowadza się do ich podstawowego użycia. Nie są wymienione żadne złożone konstrukcje, np. akapity umieszczone wewnątrz listy wypunktowanej. Z jednej strony pozwala to na dużą dowolność w użyciu elementów, z drugiej – wprowadza ryzyko błędnego (tj. niesemantycznego) użycia. Brak jest punktu odniesienia, który służyłby weryfikacji czy podany kod jest, czy nie jest semantyczny.

Nie ma również oficjalnych dokumentów, na podstawie których moglibyśmy klasyfikować różne rozwiązania jako mniej lub bardziej semantyczne. Głównymi kryteriami oceny są zdrowy rozsądek, własne doświadczenia i przyzwyczajenia oraz ewentualne dodatkowe wymagania dotyczące konkretnej witryny WWW. O tym jak różne zdania na temat rozwiązań powszechnych problemów mają osoby zawodowo związane z webmasteringiem można się przekonać śledząc dyskusje Simple Quiz na witrynie Dana Cederholma (http://www.simplebits.com/bits/simplequiz/).

Cechy semantycznego XHTML

Klasyfikując różne metody kodowania XHTML należy rozważać następujące kryteria:

• kod HTML/XHTML może być nazywany semantycznym wyłącznie pod warunkiem poprawności składniowej (omawiane przykłady dotyczą języka XHTML 1.0 strict),
• semantyczny kod HTML/XHTML nie powinien zawierać elementów odpowiedzialnych za modyfikację wyłącznie cech prezentacyjnych,
• liczba użytych elementów powinna być zminimalizowana; rezygnacja z minimalizacji może być wymuszona przez stosowanie złożeń XHTML lub specyficzne wymagania,
• nazwy klas i identyfikatorów powinny odnosić się do roli elementów, a nie do ich wyglądu.

Oczywistym niepoprawnym rozwiązaniem jest stosowanie znaczników odpowiedzialnych za wizualne cechy:

Tytuł dokumentu

Powyższy przykład nie tylko nie jest semantyczny. Podany kod nie jest poprawny składniowo (w sensie XHTML 1.0 strict). Przykładem poprawnym składniowo jest:

Tytuł dokumentu

Jednak rozwiązanie to nie wskazuje roli, jaką pełni tekst Tytuł dokumentu. W tym przypadku najlepszym wyjściem będzie:

Tytuł dokumentu

Podany problem jest bardzo uproszczony. W faktycznych dokumentach XHTML decyzja dotycząca stosowania konkretnych znaczników i zagnieżdżeń będzie znacznie trudniejsza. Na przykład stwierdzenie, czy kod stopki zawierający zagnieżdżenie:

   
Lorem ipsum...

jest semantyczny czy nie, już takie oczywiste nie jest i może zależeć od kontekstu oraz dodatkowych wymagań dotyczących witryny.

Praktyczne rozwiązania popularnych problemów

Struktura dokumentu: powiązania tytułu, nagłówków i logo

Rozważmy witrynę firmy ABC SA i jej podstronę Oferta. Jak powinien wyglądać kod XHTML witryny, zakładając że na stronie ma się pojawić graficzne logo firmy?

Z punktu widzenia zagadnień SEO, słowa kluczowe powinny wystąpić zarówno w tytule strony, jak i nagłówkach. To nakłada wymagania na elementy title, h1 oraz h2. Logo witryny możemy wykonać umieszczając je w tle elementu div za pomocą odpowiednich arkuszy stylów:

ABC SA
ABC SA
Oferta
...

Pewnym wariantem powyższego rozwiązania będzie kod, w którym logo jest umieszczone jako obraz tła elementu h1:

ABC SA
Oferta
...

Warto pamiętać, że W3C zaleca, by h1 był identyczny jak tytuł strony.

Menu

Menu witryny wykonywane jest w postaci list ul oraz ol. Zdaniem Molly Holzschlag (por. \”Integrated Web Design. The Meaning of Semantics\”) lista ol lepiej oddaje semantykę menu, ponieważ opcje menu są w istocie uporządkowane:

   
opcja 1
   
opcja 2
   
opcja 3

Pozostanie kwestia umieszczenia powyższego menu w kodzie strony. Tutaj argumentem, jaki należy wziąć pod uwagę jest fakt, że w przypadku przeglądarek czytających zawartość strony lepiej, gdy menu pojawia się – w kodzie XHTML – po treści wszystkich kolumn (por. Matthew Levine: \”In Search of the Holy Grail\”):

   
   
   

   
ABC SA
   
ABC SA
   
Oferta
   

      ...
   
   

      
opcja 1
      
opcja 2
      
opcja 3
   

Stopka

W odniesieniu do stopki należy rozważyć użycie elementów div oraz p wraz z ewentualnym zagnieżdżeniem. Jeśli tekst stopki stanowi jeden akapit (lub jedną linię), wówczas dostępnymi rozwiązaniami są:

Lorem ipsum...

oraz

Lorem ipsum...

Jeśli jednak w stopce pojawia się kilka akapitów, wówczas rozsądnym jest użycie zagnieżdżonych elementów div i p:

   
Lorem ipsum...
   
Dolor sit...

W przypadku stopki jednoakapitowej dopuszczalnymi rozwiązaniami są:

Lorem...
Lorem...
Lorem...

Nawigacja: jesteś tutaj

Panel nawigacyjny pokazujący bieżącą pozycję jest znacznie trudniejszy do sklasyfikowania pod względem semantyki. Zazwyczaj element ten wykonuję w postaci pojedynczego akapitu:

 Jesteś w link 1 > link 2 

lub elementu div:

 Jesteś w link 1 > link 2 

jednak równie dobrze element ten można wykonać w postaci listy:

Jesteś w 

   
link 1
   
link 2

czy nawet listy zagnieżdżonej.

Łącząc opisane do tej pory rozwiązania, otrzymamy witrynę z listingu 1. Oczywiście w przypadku takiej witryny trudno mówić o jedynym słusznym i semantycznym rozwiązaniu. Kod z listingu 1 można poddać licznym modyfikacjom i zmianom, zachowując jego semantyczność.

   
      
   

   
ABC SA
   
ABC SA
   
Oferta
   

      Jesteś w link 1 > link 2
   
   

      ...
   
   

      
opcja 1
      
opcja 2
      
opcja 3
   
   
Lorem ipsum...

Ilustracja

W jaki sposób w artykule osadzić ilustrację opatrzoną tytułem? Ja do tego celu stosuję element div w połączeniu z img oraz p:

   
   
Rys. 1. Podpis rysunku...

Ewentualnie numer rysunku możemy dodatkowo oznaczyć elementem span czy innym tekstowym, co pozwoli na oddzielenie podpisu od oznaczenia Rys. 1.:

   
   
Rys. 1. Podpis rysunku...

lub

   
   Rys. 1.
   
Podpis rysunku...

Listing

Podobnie jak obraz możemy sformatować listing:

$a = $b + $c;
echo $a;

Listing 1. Podpis listingu...

Wstawka kodu
Wstawki kodu nie mające statusu listingu, jednak wymagające umieszczenia w osobnej linii, wykonuję przy użyciu standardowego elementu pre:
foreach ($t as $v) {
   echo $v;
}

Fragmenty tekstu
Elementy tekstowe, które są umieszczane wewnątrz akapitu, takie jak nazwy plików, zmiennych, wyrażenia matematyczne, nazwy programów, nazwy opcji, skróty klawiszowe czy tytuły książek można oznaczyć:
php.ini
file _ get _ contents()
2x + y = 5
Apache
File → New
Ctrl+C
„Ogniem i mieczem”
Oczywiście w miejsce kilku spośród powyżej podanych rozwiązań można użyć elementów frazowych dostępnych w XHTML-u (specyfikacja HTML, punkt 9.2.1). Jednak ta lista jest zamknięta i wcześniej czy później konieczne będzie rozszerzanie stosowanego zestawu znaczników. Dlatego wolę wszystkie wstawki tekstowe oznaczać jednolicie elementami span z odpowiednią klasą.
Konieczność takiego oznaczania wynika nie tyle z potrzeby odrębnego formatowania, ile z potrzeby przetworzenia dokumentu. Przykładem przetwarzania jest sprawdzanie pisowni. Wykonując korektę artykułu nie sprawdzam pisowni nazw plików, zmiennych czy skrótów klawiszowych. W ten sposób sprawdzanie pisowni przebiega znacznie sprawniej.
Złożenia
Termin złożenie XHTML (ang. XHTML compaund) został zaproponowany przez Tanteka Çelika w pracy pt. \”The Elements of Meaningful XHTML\”. Złożenie HTML to dwa lub więcej elementów XHTML użytych wspólnie w celu zwiększenia semantyki. W oryginalnej pracy Çelika jako przykłady pojawiają się trzy złożenia: kod, konwersacje oraz bibliografia.
Złożenie: kod
Do oznaczania kodu komputerowego Çelik proponuje złożenie elementów pre i code:

{html}
{/html}
$a = $b * $c;

Złożenie: konwersacje
Konwersacje, zdaniem Çelika, mogą być oznaczane jako złożenie listy numerowanej, cytatów cite i blockquote oraz akapitów p:

   

   Costello
   
Well then who\'s on first?
   
   

   Abbott
   
Yes.
   

Bibliografia
Natomiast do oznaczenia bibliografii odpowiednim złożeniem jest:

   

   \"Colorimetry, Second Edition\", CIE Publication 15.2-1986, ISBN 3-900-734-00-3
   
   

   \"Casscading Style Sheets, level 1\", H. W. Lie, B. Bos, 17 December 1996.
   

Złożenie: ilustracja
Poprzez analogię do powyższych rozwiązań złożeniami możemy nazwać także podane wcześniej metody formatowania ilustracji z podpisami czy listingów:

   
   Rys. 1.
   
Podpis rysunku...

Dodając nazwę klasy elementu, np. compaundImg:

   
   Rys. 1.
   
Podpis rysunku...

zyskamy nową, jednoznaczną strukturę XHTML, która formatuje rysunek posiadający następujące cechy:
obraz - img.jpg
tekst alternatywny - Lorem ipsum...
rodzaj podpisu - Rys. 1.
podpis - Podpis rysunku...
W razie potrzeby format ten możemy wzbogacić o dodatkowy oddzielny atrybut: numer rysunku. Zmieniając nazwę klasy na compaundImgNo zyskamy kolejne złożenie, którego semantyka nieco różni się od złożenia klasy compaundImg:

   
   Rys.
   1.
   
Podpis rysunku...

lub

   
   
      Rys.
      1.
   
   
Podpis rysunku...

Podsumowanie
Granica pomiędzy złożeniami a redundancją oraz semantycznym i niesemantycznym kodem XHTML jest bardzo wąska. Kod o tej samej strukturze może - w zależności od kontekstu - być nazwany semantycznym lub nie. Na przykład użycie dodatkowego elementu niekiedy powoduje, że dokument przestaje być semantyczny, a innym razem nie.
W przypadku pojemnika:

   
Lorem ipsum...
   
...

użytego w celach prezentacyjnych możemy powiedzieć, że powyższy kod nie jest semantyczny. Jednak powyższy kod nie musi wcale zawierać arkusza stylów. A w takiej sytuacji, czy jest sens mówić, że pojemnik #wrapper służy do modyfikacji cech prezentacyjnych? Czy sam brak stylów może powodować, że powyższy kod czasami nazwiemy semantycznym (wówczas gdy nie ma stylów), a czasami niesemantycznym (gdy ma style)?
To samo zagadnienie, czyli użycie jednego dodatkowego elementu w odniesieniu do stopki nastręcza jeszcze więcej trudności:

   
Lorem...

Czy użycie dodatkowego elementu p powoduje, że powyższy kod jest niesemantyczny? A może mamy do czynienia ze złożeniem?
Nie będę się silił na udzielanie odpowiedzi na powyższe pytania. To kwestie, które większość webmasterów rozstrzygnie po swojemu, dostosowując je do konkretnych realiów. Dla mnie istotny jest raczej ogólny kierunek rozwoju. Wychodząc od witryn poprawnych składniowo (w sensie XHTML 1.0 strict), należy dążyć z jednej strony do minimalizacji kodu XHTML (czyli rezygnacji z divitis, spanitis, classitis oraz iditis) w połączeniu ze stosowaniem stylów oraz odpowiednim nazewnictwem klas i identyfikatorów, a drugiej - do rozbudowywania arsenału własnych złożeń.