Home  |  Aktualności  |  e-Komunikacja  |  WWW  |  Bezpieczeństwo  |  Linux  |  Programy  |  GSM/UMTS  |  Rozrywka

HTML - znane pojęcie... ?

Na czym polega widzenie w sieci? WWW a tryb wysiwyg!

Tworzenie dokumentów polega dziś najczęściej na obsłudze oprogramowania, gdzie dokonuje się równoczesne zakodowanie "języka" i jego "wizualizacja" (WYSIWYG). Dany program gwarantuje nam, że "jedyna rzeczywistość" dokumentu, z jaką mamy do czynienia podczas interakcji na ekranie, znajdzie wierne odbicie w druku, zapisie, wyświetleniu się na ekranie monitora.

Z dokumentami WWW jest tak samo, z tą różnicą, że "rzeczywistość" naszego dokumentu dotyczy róznych komputerów podpiętych gdzieś... do węzłów sieci. Dlatego jedynym programem-interfejsem są standardy HTTP, URL, HTML, które muszą być uwzględnione w dokumencie. Znajdują one wyraz w postaci zapisów tekstowych obecnych w dokumencie. Dlatego tworzenie dokumentów HTML jest tworzeniem tekstu - nie obrazu na ekranie - obraz bywa przygotowanym załącznikiem.


Dla odbiorcy - nie istotne jest, jak taki tekst powstaje. Odbiorca nie wie czy został zapisany znak po znaku z klawiatury, zestawiony z kawałków czy wygenerowany przez jakiś program. Liczy się tylko to, jaki ciąg znaków, identyfikowany jako osobny dokument, dociera do odległego komputera. Tam jest on interpretowany w postaci "strony WWW".



Tworzenie dokumentów HTML

Jest sprawą autora i jego warsztatu, jak efektywnie tworzyć dokumenty sieciowe. Zrozumiałe, że autor chce widzieć interpretację tworzonego dokumentu w postaci strony WWW. Jednak dokumenty HTML często tworzone są zaocznie. Program pobiera dane z jakiejś bazy i tworzy dokumenty HTML "na żądanie". Autor programu i tej bazy nie widzi wtedy wszystkich możliwych stron WWW, jakie powstaną, co najwyżej typowe, szablonowe. Skupia się na algorytmach gwarantujących, że jakakolwiek generowana z bazy treść składa się na typowy dokument HTML.

Podobnie jest przy tworzeniu dokumentów unikalnych. Autor nie jest w stanie obejrzeć interpretacji swego dokumentu HTML na wszystkich komputerach na świecie. Zwłaszcza że dokument HTML może być interpretowany nie tylko jako strona WWW, lecz także inaczej: przeszukiwany przez roboty sieciowe, oglądany bez grafiki, konwertowany do czegoś szczególnego albo odczytywany przez syntetyzator mowy. Na interpretacje dokumentu HTML przez odległe systemy autor ma wpływ wyłącznie za pośrednictwem "interfejsu sieciowego", czyli zespołu standardów i dobrych praktyk.

Autor może widzieć interpretację tworzonego dokumentu HTML w swojej przeglądarce lub w swoim edytorze WYSIWYG. Jednak taki interfejs autora jest innej natury niż "interfejs sieciowy" służący optymalnej interpretacji dokumentu przez różne odległe systemy, stosownie do ich możliwości i potrzeb. Dlatego dowolny autorski warsztat powinien zawsze zawierać narzędzia konfrontujące dokument z normami tego interfejsu; walidator dokumentów SGML, narzędzia weryfikacji odsyłaczy, narzędzia normalizacji zapisu itp., pozwalające autorowi brać odpowiedzialność za każdy znak tekstu dokumentu.


Przesyłanie dokumentów HTML


Podstawy funkcjonowania "interfejsu sieciowego" opierają się na internetowym protokole HTTP i normie HTML.
RFC 2068:

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks (...). A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

Protokół HTTP jest protokołem warstwy aplikacji dla rozproszonych, wielomedialnych systemów wymiany informacji. Jest ogólnym, bezstanowym, obiektowo zorientowanym protokołem o różnych zastosowaniach (...). HTTP zakłada negocjacje co do typów danych, umożliwiając tworzenie takich systemów informacyjnych, które są niezależne od tego, jakie dane będą wymienianie za ich pośrednictwem.
Specyfikacja HTML 4.0:

HTML documents are sent over the Internet as a sequence of bytes accompanied by encoding information. The structure of the transmission, termed a message entity, is defined by RFC 2045 and RFC 2068. A message entity with a content type of "text/html" represents an HTML document.

Dokumenty HTML przesyłane są przez Internet jako sekwencje bajtów wraz z informacją o użytym sposobie kodowania. Struktura tej transmisji, nazywana message entity, zdefiniowana jest w RFC 2045 i RFC 2068. Dokumeny HTML to message entity o typie danych oznaczonym jako "text/html".

Protokół HTTP jest protokołem najwyższego rzędu. To znaczy, że zakłada on, że istnieje połączenie dowolnej natury fizycznej (kabel, radio, podczerwień), którym przesyłane są w sieci dane w postaci pakietów, które kierowane są tak, że ich komplet wychodzący od nadawcy trafia do odbiorcy (protokół TCP/IP). Protokół HTTP określa formę dialogu klienta z serwerem na temat danych, które klient chce pobrać.

Sekwencja bajtów


U swego źródła na serwerze dokument HTML jest sekwencją bajtów poprzedzoną nagłówkiem HTTP, określającym typ danych internetowych (text/html) oraz sposób zakodowania znaków tekstu w bajtach.

Dokument HTML musi spełniać wymóg, by znaki te należały do jednego tylko, określonego zestawu znaków. Zestaw znaków powinien być określony w nagłówku HTTP, ale w praktyce polega się na ekwiwalentnym określeniu go w nagłówku dokumentu HTML, za pomocą elementu meta z atrybutem http-equiv, np:

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-2">
<meta http-equiv="content-type" content="text/html; charset=windows-1250">


Wobec braku określenia zestawu znaków, w dokumentach HTML domyślnie przyjmowany jest zestaw Unicode/UTF-8, lub ustawienia odbiornika. Zestawem znaków może być każdy zestaw użyteczny w Internecie, tzn. taki, którego nazwa jest zarejestrowana w IANA i/lub jest on praktycznie obsługiwany przez odbiorniki. Podkreślany w Polsce wymóg stosowania zestawu ISO-8859-2 bierze się nie z norm Internetu czy HTML, lecz z ogólnego standardu ISO i Polskiej Normy zalecającej ten zestaw ogólnie dla "wymiany informacji w typowym środowisku biurowym". Oczywiście tylko w zakresie kodowania ośmiobitowego (bajt=znak). Standardem wielobajtowego kodowania znaków jest ISO-10646, odpowiadający Unicode.

W dzisiejszej praktyce o wiele dotkliwszym błędem jest niekonsekwentne lub błędnie określone kodowanie, wynikające z braku spójności warsztatu autora, niż preferowanie przez niego któregoś z użytecznych zestawów znaków.
Interpretacja dokumentów HTML

Odczytując pierwsze bajty dokumentu, klient - czyli przeglądarka - otrzymuje od razu najważniejszą w tym momencie informację o tym, jaki jest schemat kodowania (CES) i sposób kodowania znaków (CCS) dokumentu. Pozwala to zamienić ciąg bajtów na ciąg liczb naturalnych określających pozycje kodowe znaków.

Załóżmy, że odebrany ciąg bajtów wskazywał na proste kodowanie "bajt=znak" odnoszące się do zestawu ISO-8859-2, co pozwoliło ustalić ciąg pozycji kodowych znaków:
przykładowy niewielki fragment dokumentu, wartości pozycji kodowych wyrażone szesnastkowo:

3C 64 69 76 3E 3C 62 3E 54 72 65 B6 E6 3A 3C 2F 62 3E 3C 75 6C 3E 3C 6C 69 3E 57
73 74 EA 70 20 28 3C 69 3E 6B 72 F3 74 6B 69 3C 2F 69 3E 29 3C 6C 69 3E 4F 70 69
73 20 28 3C 69 3E 64 B3 75 67 69 3C 2F 69 3E 29 3C 2F 75 6C 3E 3C 2F 64 69 76 3E

Znając pozycje kodowe i zestaw znaków przeglądarka może już odczytać przykładowy fragment:

3C 64 69 76 3E 3C 62 3E 54 72 65 B6 E6 3A 3C 2F 62 3E 3C 75 6C 3E 3C 6C 69 3E 57
<  d  i  v  >  <  b  >  T  r  e  ś  ć  :  <  /  b  >  <  u  l  >  <  l  i  >  W

73 74 EA 70 20 28 3C 69 3E 6B 72 F3 74 6B 69 3C 2F 69 3E 29 3C 6C 69 3E 4F 70 69
s  t  ę  p     (  <  i  >  k  r  ó  t  k  i  <  /  i  >  )  <  l  i  >  O  p  i  

73 20 28 3C 69 3E 64 B3 75 67 69 3C 2F 69 3E 29 3C 2F 75 6C 3E 3C 2F 64 69 76 3E
s     (  <  i  >  d  ł  u  g  i  <  /  i  >  )  <  /  u  l  >  <  /  d  i  v  >

W ten sposób dokument został przesłany z serwera do klienta i odczytany jako tekst. Ponadto wiadomo już (z nagłówka HTTP wysłanego przez serwer), że tekst ten zawiera oznakowanie w języku HTML.

Kolejnym krokiem jest parsowanie dokumentu, czyli analiza oznakowania i ustalenie danych znakowych dokumentu (w tym podstawienie zawartości encji i referencji znakowych w miejsce odpowiednich odsyłaczy). Parsowanie opiera się na ustalonych dla HTML delimiterach oznakowania. Oznakowanie i dane znakowe są później odmiennie traktowane. Oznakowanie podlega analizie logicznej i konfrontacji z wewnętrznym arkuszem stylów, tworząc ramy dla interpretacji strumienia danych znakowych.

Oznakowanie dokumentu stanowią:


- deklaracje oznakowania - mogą wystąpić tylko w dwóch przypadkach: deklaracji typu dokumentu (<!DOCTYPE ... ), która powinna poprzedzać dokument i zawiera istotną informację o wersji HTML, lub deklaracji zawierającej wyłącznie komentarz <!-- ... --> (dowolnie wiele wystąpień w dowolnych miejscach dokumentu).


- znaczniki elementów (zawierające ewentualnie także atrybuty i ich wartości),
- odsyłacze do encji znakowych,
- odsyłacze do referencji znakowych,


 <div>
 <b>Treść:</b>
 <ul>
 <li>Wstęp (<i>krótki</i>)
 <li>Opis (<i>długi</i>)
 </ul>
 </div>

Po sparsowaniu, przykładowy fragment okazuje się elementem div zawierającym wyróżniony tekst (b) oraz wyliczenie (element ul), grupujące pozycje wyliczenia (elementy li). Treść tych pozycji zawiera także wyróżnienie czcionki (elementy i). Podział na wiersze dokonany tu tylko dla czytelności, znaki końca wiersza obecne w dokumencie nie są interpretowane jako takie. Zamieniane są na spacje, zaś szereg spacji na jedną spację.


Po sparsowaniu dokumentu przeglądarka zna strukturę elementów i ich zawartość. Może więc przystąpić do swego właściwego zadania, czyli interpretacji w formie wizualnej na ekranie.

Elementy naszego przykładowego fragmentu zostaną oddane jako prostokątne obszary wypełnione zawartością elementów. Sposób zestawiania tych obszarów, ich wielkości i proporcje a także parametry czcionek, określone są arkuszem stylów.


Typografia dokumentu HTML



Generalnie interpretacja wizualna dokumentów HTML opiera się na osobnym zestawie danych, zwanych tradycyjnie arkuszem stylów, które przypisują elementom strukturalnym cechy typograficzne.

Specyfikacja HTML

 

- określa tylko ogólny sens typograficzny elementów (np. tabela, wyliczenie, tytuł), natomiast każda przeglądarka ma "wbudowany" arkusz stylów precyzujący wartości typograficzne elementów: położenie, marginesy, odstępy, kolory, ramki, podkreślenia itd. stosownie do znaczenia danego elementu i jego atrybutów. Jest on wbudowany w tym sensie, że zwykle nie jest dostępny w formie dokumentu z definicjami. Niemniej jednak przeglądarka powinna zachowywać się tak, jakby taki ustalony zespół definicji istniał. Przykładowy wbudowany arkusz stylów dla HTML 4.0 - jako średnia z praktycznie stosowanych - przedstawiony jest w aneksie do Specyfikacji CSS2.

Na tym właśnie polega przenośność dokumentów HTML; z dokumentu oznakowanego w HTML przeglądarka dowiaduje się tylko o wytycznych co do interpretacji typograficznej, którą realizuje zgodnie z lokalnymi warunkami (system komputerowy, dostępne czcionki, wielkość okna, parametry monitora, ustawienia użytkownika, itd).

 

CSS - Cascading Style Sheets - kaskadowe arkusze stylów


Wbudowany arkusz stylów przeglądarki może być modyfikowany arkuszem stylów załączonym do dokumentu lub definicjami wpisanymi w dokument. W obu przypadkach obowiązuje ten sam język opisu cech typograficznych, standard W3C pod nazwą - CSS (Cascading Style Sheets - kaskadowe arkusze stylów). Z dokumentu HTML uszczegółowionego zapisami CSS, przeglądarka nadal zinterpretuje tylko to, co rozumie i potrafi ze względu na jej stopień obsługi CSS i jej lokalne warunki.

Nowsze przeglądarki umożliwiają zdefiniowanie własnego arkusza stylów CSS po stronie użytkownika. Taki arkusz modyfikuje "wbudowany" arkusz stylów przeglądarki a nawet styl załączony/wpisany do dokumentu. Odbiorca może mieć szczególne preferencje, ważniejsze od koncepcji autora, i ma narzędzie ich wyspecyfikowania (patrz np. w Internet Explorer w menu Narzędzia/Opcje internetowe/Dostępność).
Znaki a czcionki

Typową zawartością elementów jest tekst.

Wizualizacja tekstu polega na wyświetleniu glifów w odpowiedniej formie (wielkości, kolorze, itd.). Przełożenie kodowanych znaków na glify jest dość skomplikowanym problemem dotyczącym interfejsu sieciowego, w odróżnieniu od wizualizacji i formatowania już ustalonych glifów, co system komputerowy robi rutynowo.

Problem polega na tym, że między zestawami kodowanych, abstrakcyjnych znaków a czcionkami jako kolekcjami konkretnych glifów nie ma żadnej prostej odpowiedniości, bo są to zbiory innej natury.

Na przykład kod B1 (bajt 10110001) oznacza literę ą tylko w kontekście zestawu ISO-8859-2, w innym zestawie, np. windows-1250, oznacza znak ±. Z drugiej strony, glif ą w jednych czcionkach jest obecny, a w innych nie, zaś system jego identyfikacji w ramach czcionki zależy od rodzaju czcionki i systemu, w jakim jest zainstalowana.

Aby wyświetlić tekst dokumentu sieciowego, system komputerowy odbiorcy musi umiejętnie skojrzyć z sobą liczne dane oraz warunki zawnętrzne i wewnętrzne:

* zidentyfikować znak abstrakcyjny (dany numer pozycji kodowej w danym zestawie znaków dokumentu), np. ą.
* uwzględnić zawarte w oznakowaniu wymagania co do czcionki: jej ogólnego kroju (np. bezszeryfowy), konkretnego kroju (np. "Arial"), wariantu, stylu, itd.,
* uwzględnić dane zawarte w arkuszach stylów: wbudowanym, wpisanym w dokument, załączonym do dokumentu, wskazanym przez użytkownika (uwzględniając kaskadowość samych stylów i różnie określone preferencje),
* ustalić czy dysponuje konkretną czcionką spełniającą powyższe warunki, a jeśli nie to co zrobić (sięgnąć po inną czcionkę, oddać ą jako a, wyświetlić umowny znak braku glifu, itd.)
* znaleźć glifą w pasującej czcionce i wyświetlić go w odpowiednim miejscu, kolorze, wielkości, itd.

Pod tym względem w WWW dokonał się ogromny postęp. Punktem wyjścia na początku lat 90. była transmisja kodów ASCII, które obsługiwane były systemowymi czcionkami "naturalnie", tzn. analogicznie jak dane wewnętrzne systemu. Wszystko co ponad ASCII, mogło być przenoszalne w analogiczny sposób jak w systemach SGML-owych, czyli zapisywane w dokumencie jako encje mnemoniczne. Owo "wszystko" dotyczyło wtedy "upper ASCII" czyli pełnego zestawu ISO-8859-1. Stąd też normie HTML od początku towarzyszył zestaw encji nazwany "HTML Latin 1" obejmujący pozycje 128-255 zestawu ISO-8859-1.

Jednak środowisko naukowe już wcześniej powszechnie używało także znaków specjalnych: greckich, matematycznych i innych, dostępnych za pomocą prostego mechanizmu podstawienia specjalnej czcionki bez zmiany kodu znaku. Zarówno system TeX jak i PostScript oferował nietypowe znaki w miejsce "zwykłych" pod warunkiem wskazania specjalnej czcionki. Podobnie czyniło i czyni dalej wiele procesorów tekstu i systemów składu. Typograficzna tradycja "pisania czcionkami" okazała sią trudna do pogodzenia z telegraficzną tradycją transmitowania kodów. Różnica między lokalnym a odległym przetwarzaniem tekstu objawiła się tutaj w pełni.

Sposobem prostym, lecz dość doraźnym, było zestandaryzowanie kolejnego zestawu encji do obsługi przez odbiorniki HTML. Zestaw "HTML Symbol" obejmował te znaki specjalne, których glify były już dość powszechnie dostępne w komputerach środowiska akademickiego (czcionka "Symbol" firmy Adobe). W ten sposób, w drugiej połowie lat 90. HTML formalnie spełniał podstawowe wymogi publikacji akademickich w "atlantyckim" kręgu kulturowym. Można było pisać po angielsku, niemiecku a nawet islandzku, użyć greckiej litery "pi" ( π ), znaku przynależności do zbioru ( ∈ ) i odróżniać literę "iks" ( x ) od znaku mnożenia ( × ).

Efektem ubocznym tego doraźnego rozwiązania był rozdźwięk z obszernymi, SGML-owymi zestawami encji, od 1986 roku pracowicie standaryzowanymi przez ISO dla bogatych zastosowań. Mnożyły się byty: zestawy "encji HTML" to nie zestawy "encji ISO", nawet jeśli "HTML Latin 1" to nic innego jak zestaw encji dla ISO-8859-1. Dodatkowy zamęt powodowało to, że mnemoniczne nazwy encji nawiązywać mogły do standardów ISO/SGML albo do nazw znaków, jakie przyjęła dla języka PostScript firma Adobe.

Na szczęście komercyjne wymogi internacjonalizacji WWW i HTML, a zwłaszcza uwzględnienia języków delekowschodnich (CJK - chiński, japoński, koreański) wymagały wytyczenia dróg dla bardziej globalnego rozwiązania kwestii kodowania znaków. HTML w wersji 4.0 przyjmuje za domyślny zestaw znaków dokumentu HTML zestaw Unicode i nakazuje odbiornikom odczytywanie dowolnej referencji znakowej w odniesieniu do tego globalnego zestawu znaków. Tworzy to solidny fundament przenoszalności tekstów, a encje mnemoniczne wracają do swej roli tylko pomocniczych określeń znaków. Dokument HTML może być zakodowany uniwersalnie, niezależnie od czcionek, kontynentu i tradycji. Dzięki Unicode wiadomo jak mogą być kodowane dokumenty w języku indian Cherokee. Dlatego można tworzyć dowolne systemy i czcionki do wymiany i przetwarzania takich dokumentów. Nie na odwrót - na przykład tak, że trzeba najpierw kupić edytor i czcionki indiańskiej firmy by rozumieć ich dokumenty.

Rozwój sprzętu umożliwił jednocześnie operowanie czcionkami o obszernym repertuarze opisanym w odniesieniu do Unicode. Nie ma zatem potrzeby posiadania osobnych czcionek rumuńskich czy polskich, gdyż nowe czcionki obsługiwane są przez tzw. "zmienny wektor kodowania". Bajty odnoszące się do zestawu znaków dokumentu tłumaczone są najpierw na pozycją Unicode, a na tej podstawie odszukiwany jest odpowiedni glif. Na przykład bajt A2 w dokumencie kodowanym w ISO-8859-16 (zestawie przyjętym w Rumunii) będzie zrozumiany jako pozycja kodowa U+0105, zupełnie tak samo jak bajt B1 w dokumencie kodowanym w ISO-8859-2. W obu przypadkach dotyczy to tego samego glifu: ą. Czcionka taka zawiera więc tylko jeden glif ą, którym może obsłużyć wszelkie dokumenty we wszelkich znanych jej sposobach kodowania.

W ten sposob nastąpiło radykalne zerwanie z koncepcją komputerowego "pisania czcionkami", gdzie oprócz kodu znaku potrzebna była informacja do jakiej czcionki się odnosi. Dokumenty sieciowe wymagają koncepcji "czytania czcionkami", czyli dostosowania czcionek do zmiennego kodowania znaków. Ten kierunek rozwoju został narzucony również takim wybitnie "typograficznym" technologiom jak TeX czy PostScript.

Obecnie dostępne są czcionki obejmujące prawie cały Unicode, także darmowe, choć posługiwanie się nimi na co dzień w naszym kręgu kulturowym może być mało wygodne, jako że ideogramy CJK stanowią tam przytłaczającą większość znaków. Nowoczesne czcionki ogólnego użytku oferują niemal wszystkie litery pism wywodzących się z kręgu śródziemnomorskiego: łaciny i greki oraz hebrajskiego i arabskiego, uzupełnione o liczne specjalistyczne znaki pisarskie. Bardzo wyrafinowane zastosowania wymagają nadal specjalnych czcionek, ale też zwykle związane są z całymi specjalistycznymi systemami edycyjnymi. Ale nawet wtedy oparcie się na Unicode nadaje takim dokumentom trwałość i przenoszalność, jak to ma miejsce np. w przypadku matematycznych symboli...

---

Na podstawie dostępnych opracowań.