Vývoj protokolu http a jazyka HTML

Ing. Petr Lampa
URL: mailto:lampa@dcse.fee.vutbr.cz

Ústav informatiky a výpočetní techniky, Fakulta elektrotechniky a informatiky VUT v Brně, Božetěchova 2, 612 66 Brno

Letní škola informačních technologií, Studnice 96

Protokol http

Protokol http je protokol, kterým komunikuje klient se serverem systému WWW. První verze protokolu vznikla při vývoji systému WWW ve středisku CERN. Pro přenos hypertextových dokumentů byl požadován jednoduchý protokol, bez složitého spojování, autorizace a signalizace. Původní protokol klientovi umožňoval pouze navázat spojení se serverem, zaslat požadavek ve tvaru GET <URL>, přečíst odpověď a uzavřít spojení. Server pouze přijal požadavek, zpracoval jej a odeslal požadovaný dokument nebo zprávu o chybě:

Brzy se ukázalo, že natolik jednoduchý protokol nestačí. Klient nebyl schopen rozeznat atributy zaslaného dokumentu jinak, než z přípony jména dokumentu. Původně to nevadilo, protože byl omezen počet zpřístupněných dokumentů a vesměs se jednalo o textové nebo hypertextové dokumenty. Dalším problémem byla neznalost velikosti dokumentu, klient musel číst data, která mu posílal server, tak dlouho, dokud server neukončil spojení. Uživatel při přenosu nevěděl, jak velký bude přenášený dokument a nemohl se podle toho zařídit. Rovněž neexistoval způsob, jak zjistit čas poslední modifikace dokumentu a klient proto musel přenášet každý dokument vždy znovu. První vylepšená verze protokolu vznikla doplněním základních hlaviček do požadavku klienta i odpovědi serveru. Základní sada hlaviček popisuje typ a atributy dokumentu a vychází ze standardu MIME (Multipurpose Internet Mail Extensions, RFC1521). Ostatní hlavičky slouží pro přenos pomocných informací a předávání parametrů mezi klientem a serverem.

V této podobě je protokol http používán dodnes. V květnu 1996 byla publikována definice protokolu http verze 1.0 ve formě dokumentu RFC 1945. Tato definice obsahuje jako podmnožinu původní jednoduchý protokol s označením 0.9. Pro urychlení schválení definice protokolu verze 1.0 byly vypuštěny od druhého návrhu mnohé nové rysy protokolu a byly přesunuty do návrhu protokolu http verze 1.1 (viz http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v11-spec-07.txt).

Protokol http verze 1.1

Základním nedostatkem protokolu http verze 1.0 je jednorázové spojení. Protokol nedovoluje při jednom spojení se serverem získat více dokumentů. Při původním použití systému WWW to příliš nevadilo, jeden dokument obvykle obsahoval pouze text a v něm pouze odkazy na další navazující dokumenty. Dnešní dokumenty ale často obsahují desítky vložených obrázků a pro zobrazení takových dokumentů musí klient přenést nejen vlastní dokument, ale také všechny vložené obrázky. Pro jejich získání používá klient také protokol http a musí proto vygenerovat tolik požadavků, kolik je v dokumentu obrázků. Sekvenční generování požadavků trvá poměrně dlouho, protože u přenosu malého objemu dat trvá nejdéle navázání spojení. Většina klientů proto generuje pro přenos vložených obrázků paralelně několik požadavků, které paralelně zpracovávají. Přesto nelze ani při této metodě využít teoretické přenosové kapacity spoje. Souvisí to s vlastnostmi protokolu TCP, který je optimalizován spíše pro déletrvající souvislý přenos dat při jednom spojení, než pro krátké, nezávisle spojované přenosy. Podrobnou analýzu lze nalézt v dokumentu http://sunsite.unc.edu/mdma-release/http-prob.html. Návrh protokolu http verze 1.1 řeší tento problém zavedením udržovaného spojení, které není ukončeno po přenosu jednoho dokumentu.

Nový protokol je rozšířením protokolu http verze 1.0, každý klient a server zvládající protokol verze 0.9, 1.0 i 1.1 musí být schopen komunikovat všemi nižšími verzemi protokolu. Protokol je rozšířen o požadavky uložení dat na server (PUT), modifikace dokumentu (PATCH), kopie, přesun a zrušení dokumentu (COPY, MOVE a DELETE), vytvoření vazby (LINK) a zrušení vazby (UNLINK). Poslední dva požadavky by společně s vhodným zpracováním mohly vyřešit principiální nedostatek systému WWW, údržbu konzistence odkazů. Server by mohl při vložení dokumentů zaregistrovat všechny odkazy z dokumentu a při případných přesunech a rušení varovat uživatele.

Trvalé spojení

Pokud klient i server zvládají protokol verze 1.1, mohou se dohodnout na udržení spojení po vyřízení požadavku. Klient musí požádat server o udržení spojení požadavkem, který obsahuje hlavičku Connection:
GET http://www.some.net http/1.1
Connection: keep-alive
Pokud server akceptuje požadavek na udržení spojení, zašle odpověď, do které doplní hlavičku Keep-Alive:
HTTP/1.1 200 OK
Keep-Alive: timeout=30, max=10
Pokud klient přijme odpověď serveru s touto hlavičkou, může zaslat další požadavek. Hodnota timeout oznamuje klientovi, jak dlouho bude spojení udržováno, pokud nezašle další požadavek. Hodnota max je maximální počet požadavků, kolik může v rámci udržovaného spojení klient zaslat. Požadavek na udržení spojení musí být opakován při každém dalším požadavku. Pokud některý požadavek hlavičku Connection neobsahuje, server uzavře po odeslání odpovědi spojení.

Přenos dynamicky vytvářených dokumentů

U dynamicky vytvářených dokumentů není dopředu známá délka a server nemůže generovat platnou hlavičku Content-Length. Pokud je však dokument složen z několika částí, které server pouze spojí a odešle, jsou délky jednotlivých částí známy v okamžiku, kdy začíná jejich přenos. Pro přenos takovýchto dokumentů byl zaveden způsob přenosu chunked:
HTTP/1.1 200 OK<CR><LF>
Transfer-Encoding: chunked<CR><LF>
<CR><LF>
1A4C<CR><LF>
text
...
<CR><LF>
2F8<CR><LF>
text
...
<CR><LF>
0<CR><LF>
Content-Type: text/html; charset=ISO-8859-2<CR><LF>
<CR><LF>
Pokud je na začátku uvedena hlavička Transfer-Encoding s hodnotou chunked, pak je dokument složen ze samostatných částí. Každá část začíná hexadecimálně zapsanou délkou části. Za koncem části musí být prázdný řádek a buď další část nebo prázdná poslední část s délkou 0, za kterou mohou být dodatečné hlavičky.

Výběr mutace dokumentu

Ve vícejazyčném prostředí je obvyklým problémem, jak vybrat vhodnou jazykovou mutaci dokumentu. Protokol http verze 1.1 nabízí automatický výběr. Předpokládá, že uživatel bude mít možnost nastavit v konfiguraci prohlížeče preferovaný formát dokumentu, jazyk a kód (tuto možnost má již dnes Netscape verze 2.0). Nastavené preference pak bude klient předávat při každém požadavku v hlavičkách Accept, Accept-Language a Accept-Charset:
Accept: text/html, text/plain;q=0.2, audio/*;q=0.2;mxb=100000
Accept-Charset: ISO-8859-2, unicode-1-1-utf-8
Accept-Language: cz, sk, en;q=0.9, de;q=0.5
Na těchto hlavičkách je trochu nezvyklé to, že oddělovačem preferencí je čárka, zatímco středník je oddělovač parametrů v rámci jedné preference. Nejsložitější je způsob zadávání preference formátu a kvality dokumentu. Specifikace každého preferovaného formátu dokumentu může obsahovat parametr q, určující relativní váhu (kvalitu). Pokud není uvedeno, je uvažována váha 1. Pokud je k dispozici dokument ve více formátech, je vybrán ten, který má nejvyšší preferovanou kvalitu (váhu). Dalším parametrem může být maximální přijatelná velikost (mxb). Pokud dokument ve zvoleném formátu přesáhne limit velikosti, zvolí se následující vyhovující formát. Priorita preferencí se stejnými vahami postupuje zleva doprava. Pokud server nemá k dispozici dokument v jednom z preferovaných kódů, či jazyků, předá dokument v implicitním kódu a jazyku. Pokud je k dispozici více mutací požadovaného dokumentu, obsahuje navíc odpověď serveru hlavičku URI, která obsahuje parametr vary:
Content-Type: text/html; charset=ISO-8859-2
Content-Language: cz
Content-Length: 1241
URI: <http://www.some.net/Welcome.html>; vary="charset, language"

Stavové informace

Protokol http je bezestavový. Mezi jednotlivými spojeními není uchovávána žádná informace. V některých případech by se ale možnost uchování informace hodila. Například, pokud není použito automatického výběru jazykové mutace dokumentu, je obvykle uživateli nabídnuta možnost výběru jazykové mutace volbou hypertextových odkazů. Zde nastává potíž, jak uchovat tuto volbu při průchodu dokumenty a odkazy. Existující řešení využívají CGI skriptů, ale tato řešení nejsou příliš perspektivní, protože jednak negenerují správné hlavičky odpovědi (Last-Modified, Content-Length, apod.), jednak nedovolují využít udržovaného spojení. Jeden z návrhů doporučuje přidat do odpovědi serveru hlavičku State-Info. Obsahem této hlavičky mohou být libovolná data, která pak musí klient předat v nezměněné podobě při všech požadavcích na tentýž server. Tím se problém udržení stavu přenáší ze serveru na klienta, klient musí udržovat data, která si u něj server takto uschoval. Úplný návrh mechanismu udržování stavových informací je k dispozici v dokumentu http://www.ics.uci.edu/pub/ietf/http/draft-kristol-http-state-info-01.txt.

Přenos části dokumentu

Při komunikaci se serverem se často stává, že přenos je přerušen. Pokud se jedná o krátký dokument, není to žádná tragédie, stačí opakovat požadavek a přenést dokument znovu. U dlouhých dokumentů to je velmi nepříjemné a může se stát, že se ani opakovaně nepodaří přenést celý dokument najednou. Je to podobný problém, jako u programu ftp, kde byl vyřešen zavedením příkazu reget, který umožňuje pokračovat v přerušeném přenosu. Server systému WWW však nemusí být vždy schopen zaslat tentýž dokument znovu, například pokud je dynamicky generován. Server proto musí signalizovat možnost opakování části přenosu pro každý požadavek hlavičkou Accept-Ranges. Pokud odpověď serveru obsahuje tuto hlavičku, může klient při neúspěšném přenosu zopakovat požadavek a zadat v něm požadovanou část dokumentu hlavičkou Range:
GET /doc/VeryLongDocument.html http/1.1
Range: 1000-8000,50000-
Požadovaná část je určena intervalem od počáteční po poslední požadovanou slabiku dokumentu. Pokud není uvedena horní mez, je přenesen dokument až do konce. Pokud není uvedena dolní mez, je přenesen zadaný počet slabik od konce dokumentu. V jedné hlavičce může být uvedeno více intervalů, oddělených čárkami. Pokud klient požaduje několik částí, zašle je server ve tvaru zprávy o více částech ve formátu MIME. Každá část navíc obsahuje hlavičku Content-Range, která identifikuje obsažený interval.
Content-Type: multipart/x-byteranges; boundary=MARK

--MARK
Content-Type: text/html
Content-Range: 1000-8000/327482

...
--MARK
Content-Type: text/html
Content-Range: 50000-327482/327482

...
--MARK

Jazyk HTML verze 2.0

První verze jazyka HTML byla definována pouze doprovodnou dokumentací k původní distribuci systému WWW z laboratoří CERN. Snaha o standardizaci této verze byla rychle předstižena dalším vývojem a ztratila brzy smysl. Následkem nečekaně rychlého celosvětového rozšíření systému WWW v posledních létech a nekoordinovaného vývoje různých verzí prohlížečů bylo neustále oddalováno přijetí jednotné verze definice jazyka HTML. Teprve koncem roku 1995 se podařilo definovat ty společné rysy jazyka HTML, které jsou běžně používány a které naprostá většina prohlížečů zvládá. Tyto společné rysy byly formálně shrnuty pracovní skupinou IETF (Internet Engineering Task Force) HTML ve formě standardu jazyka HTML verze 2.0, který byl publikován v listopadu 1995 ve formě RFC1866 (http://www.fee.vutbr.cz/pub/doc/rfc/rfc1866.txt).

Jazyk HTML verze 3.0

Jazyk HTML verze 2.0 obsahuje minimální společnou podmnožinu rysů používaných verzí jazyka. Tato podmnožina nezahrnuje mnohé dnes běžně používané prvky, jako jsou tabulky, podklad textu, zarovnání textu, apod. Těchto navrhovaných nových prvků jazyka HTML 3.0 je poměrně hodně a jsou postupně upřesňovány a formalizovány v nových návrzích jazyka HTML. První návrh specifikace jazyka HTML verze 3.0 ve formě návrhu dokumentu RFC z března roku 1995 se ukázal jako předčasný a ztratil platnost, protože návrhy dokumentů RFC musí být do 6 měsíců inovovány nebo přijaty. Návrh kompletní nové specifikace byl příliš velkým soustem a proto byl rozčleněn na samostatné návrhy rozšíření jazyka v jednotlivých oblastech, jako jsou tabulky, vzorce, atributy hlaviček, odstavců a odkazů, vložené obrázky a styly. Takto rozčleněné návrhy jsou snadněji průchozí a budou zřejmě postupně schvalovány. Návrh kompletní nové verze jazyka HTML 3 je tak samozřejmě neustále oddalován. V následující tabulce je uveden přehled samostatných návrhů rozšíření jazyka:

Tabulky RFC 1942
Vkládání souborů pomocí formulářů RFC 1867
Internacionalizace HTML draft-ietf-html-i18n-04.txt
Zápis citlivých obrázků u klienta RFC1980
Speciální typy odkazů draft-ietf-html-relrev-00.txt
Označování dialektů jazyka HTML http://www.w3.org/pub/WWW/TR/WD-doctypes
Použití stylů draft-ietf-html-style-01.txt
Styly CSS http://www.w3.org/pub/WWW/TR/WD-css1
Definice rámců ve stylech http://www.w3.org/pub/WWW/TR/WD-layout
Vkládání objektů http://www.w3.org/pub/WWW/TR/WD-object.html

Aktuální informace o stavu návrhu jsou dostupné z dokumentů pracovní skupiny HTML IETF na adrese http://www.ics.uci.edu/pub/ietf/html/. Původní specifikaci jazyka HTML verze 3.0 lze nalézt na adrese http://www.fee.vutbr.cz/pub/WWW/documents/draft-ietf-html-specv3-00.txt.old. Následující popis vychází z informací dostupných koncem června 1996. Je třeba zdůraznit, že vývoj běží stále dále a mezi dobou napsání článku a vyjitím se může ledacos změnit.

Jazyk HTML 3.2

Mezitím se ze strany výrobců prohlížečů objevila celá řada nových vlastností jazyka, které v mnoha případech nebyly v žádném z návrhů. Nakonec nezbylo standardizační skupině nic jiného, než akceptovat stav daný vývojem prohlížečů a pokusit se společně s výrobci dohodnout na podporované společné množině nových rysů jazyka. Prvním výsledkem této snahy bylo oznámení a zveřejnění prvního návrhu specifikace jazyka HTML verze 3.2 v květnu 1996. Přestože je označení této verze jazyka číselně vyšší než u původního návrhu, obsahuje ve skutečnosti méně nových vlastností. Dle zatím neúplných informací se zdá, že bude tato specifikace obsahovat pouze ty rysy jazyka, které jsou již implementovány v posledních verzích prohlížečů firem Netscape, Microsoft, SpyGlass, IBM a Sun. Například z již publikovaného návrhu zápisu tabulek budou zahrnuty pouze některé části. Naopak se vyjasňuje situace se styly. Zdá se, že Internet Explorer 3.0 a Netscape 4.0 budou zvládat styly CSS!

Definice barev a pozadí

Značka těla dokumentu <BODY> byla rozšířena o atributy barevného zobrazení dokumentu. Patří mezi ně BGCOLOR - barva pozadí, TEXT - barva textu, LINK - barva nepoužitého hypertextového odkazu, ALINK - barva vybraného odkazu, VLINK - barva použitého odkazu. Barvy mohou být zadány hexadecimálním číslem (#RRGGBB) nebo jménem barvy ze standardní palety karet VGA: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, sliver, teal, white, yellow. Poslední doplněný atribut BACKGROUND umožňuje zadat vložený obrázek, který má být zobrazen opakovaně jako podklad textu. Používání tohoto atributu zajisté oživilo fádní jednobarevné pozadí textových stránek, ale někteří autoři dokumentů používají natolik výrazná pozadí, že tím silně ztěžují čitelnost textu. Příklad použití barevného pozadí:
<BODY BGCOLOR="blue">
Toto je text dokumentu na modrém pozadí

Zarovnání nadpisů a odstavců

Úvodní značky vymezující nadpisy <H1> až <H6> a odstavce <P> byly doplněny o atribut zarovnání textu ALIGN. Zarovnání textu může být vlevo (implicitně, LEFT), na střed (CENTER), vpravo (RIGHT) nebo do sloupce (JUSTIFY). Většina posledních verzí prohlížečů tyto atributy správně interpretuje:
<H1 align="center">Toto je centrovaný nadpis</H1>
<P align="center">Toto je centrovaný text</P>
Pro centrování textu je dále doplněna samostatná značka <CENTER>, kterou lze použít pro zkrácení zápisu místo značky <P> s atributem ALIGN=CENTER.

Vložené obrázky

Značka <IMG> má doplněny atributy WIDTH a HEIGHT, které dovolují zadat velikost obrázku a tím vymezit pro obrázek prostor na stránce. Stránka tak může být zobrazena se správným rozložením ještě před tím, než prohlížeč přenese všechny vložené obrázky. Atribut ALIGN je obohacen o další povolené hodnoty. Hodnota LEFT má význam zarovnání obrázku na levý okraj stránky a následujícího bloku textu po pravé straně obrázku. Podobně hodnota RIGHT znamená zarovnání obrázku k pravému okraji stránky a textu po levé straně obrázku. Nový význam má hodnota MIDDLE, která znamená v centrovaném odstavci centrování obrázku. Pokud je na stejném řádku text, který se vejde včetně obrázku na šířku stránky, je vedle sebe rozložen text i obrázek:
<P align="center">text nad obrázkem<BR>
text zleva<IMG SRC="image.gif" align="middle">text zprava
<BR clear="all">
text pod obrázkem

text nad obrázkem
text zlevatext zprava
text pod obrázkem


Při toku textu kolem obrázku nastává problém, jak zahájit další text, který nemá být zalomen kolem obrázku a má začít až pod obrázkem. V návrhu je doplněn atribut CLEAR, který může být použit u značek nadpisů, odstavců, zalomení, oddělovacích čar, seznamů a bloků textu. Hodnotou může být LEFT, RIGHT, ALL nebo číselně vertikální mezera. Hodnota LEFT posune následující text až na místo, kde je levý okraj normální, čistý (clear). Podobně RIGHT posune text na místo, kde je normální pravý okraj, a hodnota ALL na místo, kde jsou oba okraje normální. Prohlížeče tento atribut zatím nezvládají, nebo jej interpretují jen u některých značek (například Netscape jen u <BR>).

Citlivé obrázky

Volba odkazů v citlivých obrazcích na straně prohlížeče je předmětem samostatného návrhu. Na rozdíl od značky <FIG> z původního návrhu jazyka HTML verze 3.0 nedovoluje zapsat alternativní zobrazení pro negrafické prohlížeče. Definice citlivých ploch je přiřazena k danému obrázku atributem USEMAP značky <IMG>. Odkaz obvykle vede na pojmenovanou definici ploch ve stejném dokumentu, ale může vést také na definici ploch v obecném URL. Odkaz na definici je odkazem dovnitř dokumentu a proto začíná znakem #, podobně jako cíl hypertextového odkazu uvnitř dokumentu:
<A HREF="http://www/htbin/map"><IMG USEMAP="#map"> ISMAP
   HREF="image.gif"></A>
Pokud je použit atribut USEMAP a prohlížeč mu rozumí, pak má přednost před hypertextovým odkazem <A>. Prohlížeče, které neumí zpracovávat odkazy v citlivých obrázcích na straně klienta, tento atribut ignorují a zpracují citlivý obrázek původní metodou.

Každému použitému odkazu musí odpovídat definice citlivých ploch značkou <MAP>. Jméno definice uvedené v atributu USEMAP musí odpovídat jménu uvedenému v atributu NAME značky <MAP>:

<MAP NAME="map">
<AREA SHAPE="rect" COORDS="20,200,200,400" HREF="news.html">
<AREA SHAPE="circle" COORDS="100,100,40" HREF="index.html">
<AREA SHAPE="POLY" COORDS="20,20,30,40,10,40" HREF="what.html">
</MAP>
Citlivé plochy jsou popsány značkami <AREA>. Formát zadávání citlivých ploch odpovídá zadávání ploch pro program imagemap na straně serveru. Plocha může být obdélníková (rect), kruhová (circle) nebo obecný mnohoúhelník (poly). Obdélník je popsán souřadnicí levého horního rohu, šířkou a výškou. Kruhová plocha je popsána souřadnicí středu a poloměrem. Mnohoúhelník je popsán souřadnicemi jednotlivých vrcholů. Definice citlivých obrázků na straně klienta je podporována v běžných prohlížečích (Netscape 2.0, Microsoft Internet Explorer 2.0).

Typografické značky

Firma Netscape zavedla u svých prohlížečů celou řadu doplňků, z nichž se mnohé týkají typografického řízení zobrazení dokumentu. Tyto značky implementovala také firma Microsoft ve svém prohlížeči a staly se tak de facto standardem. Proto byly posléze zahrnuty do standardu jazyka HTML verze 3.2. Jedná se o značku <FONT> a doplňkové typografické značky. V následujícím přehledu jsou uvedeny značky jazyka HTML verze 2.0 a zvýrazněně nové značky.
Logické značky
Značka Zobrazení Význam
<CITE>Systém WWW</CITE> Systém WWW citace
<CODE>x = a + i*b</CODE> x = a + i*b kód programu
<DFN>termín</DFN> termín definice termínu
<EM>nelze</EM> nelze zdůraznění
<KBD>rm abc</KBD>rm abc vstup uživatele
<SAMP>XmNwidth</SAMP> XmNwidth výpis, konstanta
<STRONG>nikdy</STRONG> nikdy silné zdůraznění
<VAR>filename</VAR> filename proměnná

Typografické značky

Značka Zobrazení
<B>tučně</B> tučně
<BIG>velkým</BIG> velkým
<I>kurzíva</I> kurzíva
<SMALL>malým</SMALL> malým
<S>přeškrknutě</S> přeškrknutě
<SUB>dolní index</SUB> dolní index
<SUP>horní index</SUP> horní index
<TT>neproporcionálně</TT> neproporcionálně
<U>podtrženě</U> podtrženě

Styly

Styly jsou zatím největší změnou oproti dosavadní filozofii jazyka HTML. Doposud byl jazyk HTML koncipován jako jazyk pro popis struktury dokumentu. Styly zavádí nástroje pro popis zobrazení, vzhledu dokumentu. Styly umožňují modifikovat zobrazení jednotlivých strukturálních elementů dokumentu vymezených značkami jazyka HTML. Doplnění jazyka HTML se skládá ze dvou samostatných návrhů. První řeší zabudování stylů do značek jazyka HTML. Druhý řeší vlastní formát definice stylů. Zabudování stylů do jazyka je předmětem návrhu "HTML and Style Sheets" (ftp://nic.nordu.net/internet-drafts/draft-ietf-html-style-01.txt). Definici stylu si předvedeme na příkladu:
<HEAD>
<TITLE>Dokument s vloženým stylem</TITLE>
<STYLE TYPE="text/css">
... definice stylu ...
</STYLE>
</HEAD>
Definice stylu je vložena do hlavičky dokumenty značkou <STYLE>. Typ použitého stylu je určen atributem TYPE. Jméno typu má formálně tvar registrovaného typu média dle RFC1590. Definice stylů nemusí být zapsána v hlavičce dokumentu, styl může být celé asociován značkou <LINK>:
<HEAD>
<TITLE>Dokument s připojeným stylem</TITLE>
<LINK REL="StyleSheet" HREF="style.css" TYPE="text/css">
</HEAD>
Atribut REL musí mít hodnotu STYLESHEET, která identifikuje, že odkaz definuje styl dokumentu. Definice stylů mohou být také uvedeny přímo u jednotlivých značek v textu. Většina značek má doplněn atribut STYLE, který může obsahovat definici stylu značky:
<P STYLE="...definice stylu...">
Hlavička musí v tomto případě obsahovat alespoň počáteční značku <STYLE> s uvedením použitého typu definic stylů. Definice stylů nemusí modifikovat zobrazení pouze standardních prvků dokumentu. Pomocí nového atributu CLASS je možné zavádět vlastní třídy standardních prvků dokumentu. Hodnotou atributu může být libovolné jméno odkazující se na definici stylu:
<P CLASS=italic>text kurzívou
Odkazovaná třída musí být samozřejmě definovaná v použité definici stylu. Navíc je zavedena nová značka <DIV> vymezující blok textu, který nemá žádný speciální význam, a může být použit pro definici nových typů bloků textu. Podobně je doplněna párová značka <SPAN>, která je určena pro typografickou kontrolu vymezené části textu, podobně jako například značka <B>.

Přesný formát zápisu definice stylu je zatím ve vývoji. Zatím existují dva návrhy. Definice stylů Cascading Style Sheets (CSS) je navrhována organizací WWW Consortium. Firma Novell navrhuje mocnější nástroj pro definici stylů - Document Style Semantics and Specification Language (DSSSL). Rozdíl mezi těmito návrhy je dosti podstatný. Návrh CSS dovoluje jen nastavovat existující atributy zobrazení pro jednotlivé strukturální prvky dokumentu. Návrh DSSSL zavádí metajazyk pro popis sémantiky a zobrazení dokumentu v systému SGML. Je vlastně doplňkem systému SGML a proto je také předložen jako návrh normy ISO/IEC (10179). Použitý metajazyk je funkcionálním programovacím jazykem podobným jazyku LISP. Z hlediska implementace je podstatně jednodušší návrh CSS. Poslední pracovní návrh specifikace stylů CSS získal podporu řady firem, mezi jinými také firem Netscape, Spyglass a Microsoft. Návrh specifikace stylů CSS je poměrně rozsáhlý. V následujících příkladech jsou proto pouze naznačeny možnosti definic stylů:

<HEAD>
<TITLE>Dokument s vloženým stylem</TITLE>
<STYLE TYPE="text/css">
@import url(http://www.some.net/style.css);
H1,H2 { color: green; font-size: 24pt; align: center }
P  { indent: 30em; align: center }
P.italic { font-style: italic }
BODY  { background: dark-green }
</STYLE>
</HEAD>
První řádek definice začínající znakem @ vkládá definici stylu z jiného zdroje, například definici firemního stylu dokumentů. Jedná se o obdobu příkazu include. Vlastní definice stylu se skládá z posloupnosti definic atributů pro jednotlivé prvky struktury dokumentu (H1, H2, atd.). Jméno prvku může být doplněno identifikátorem třídy a tím je pak odvozen nový strukturální prvek dokumentu s odlišnými vlastnostmi (např. P.italic). Definice atributů ve složených závorkách se skládá ze sekvence jmen a hodnot atributů. Oddělovačem je středník. Nastavení atributů se dědí podle zanoření značek. Například definici fontu pro dokument (značka <BODY>) dědí všechny prvky dokumentu, které nemají explicitně uvedenu definici fontu. Definice atributů může být dokonce kontextově závislá. Následující definice nastavuje barvu pro text položky seznamu zanořeného do jiného seznamu:
UL UL LI { color: red }
Definice stylu ve značce má formálně stejný tvar jako v hlavičce:
<BODY STYLE="background: yellow"
<P STYLE="color: green">text zeleně

Matematické výrazy

Princip zápisu matematických výrazů byl v návrhu jazyka HTML verze 3 převzat z větší části z programu LaTeX. Některé odlišnosti jsou dány syntaxí zápisu v systému SGML, kterému musí být jazyk HTML podřízen. Dále byly v některých případech zvoleny jiné jména symbolů, protože jsou preferovány názvy z norem ISO. Příklad zápisu výrazu:

<MATH>&int;<SUB>a</SUB><SUP>b</SUP><BOX>f(x)<over>x+1</BOX> dx</MATH>
Místo značek <SUB>, <SUP> a <BOX> lze použít zkratky podtržení (_), šipku (^) a složené závorky ({). Zápis matematických výrazů je jednou z částí nové specifikace jazyka, která je zatím nejméně podporována.
Zobrazení výrazu v prohlížeči UdiWWW

Rozšíření jazyka HTML firmy Netscape

Firma Netscape přišla s celou řadou doplňků jazyka HTML. Mnohé z nich pak byly převzaty dalšími výrobci a posléze do návrhu standardu HTML 3.2. Některé doplňky však jsou stále dostupné pouze v prohlížečích Netscape. Jedním z takovýchto rozšířením jazyka je možnost dělení okna prohlížeče do nezávislých oken a na úrovni dokumentu rozlišovat, co má být v kterém okně zobrazeno. Je to velice užitečné pro zobrazení obsahu a rejstříků současně s textem dokumentu. Jazyk HTML a patřičné prohlížeče tak mohou nahradit specializované systémy pro zobrazování dokumentů, například hypertextové dokumentace a nápovědy k programům.

Zobrazení dokumentů v dělených oknech musí být nejprve zahájeno počátečním dokumentem, který rozdělí okno prohlížeče na více částí. Počáteční dokument neobsahuje na rozdíl od normálních dokumentů tělo vymezené značkou <BODY>, ale pouze skupiny rámů, vymezené značkami <FRAMESET>:

<HEAD>
<TITLE>Dokument s dělením okna</TITLE>
</HEAD>
<FRAMESET COLS="20%,80%">
<FRAME SRC="content.html" NAME="content">
<FRAME SRC="page1.html" NAME="main">
</FRAMESET>
Tento dokument rozdělí okno prohlížeče na dvě okna vedle sebe, v levém zobrazí dokument "content.html" a v pravém "page1.html". Vlastní dokumenty, které jsou zobrazeny v jednotlivých oknech, mají formálně normální tvar. Skupiny rámů (FRAMESET) jsou rozděleny horizontálně (atribut COLS) nebo vertikálně (atribut ROWS) na více rámů (FRAME). Velikost jednotlivých rámů je zadána relativními nebo absolutními velikostmi. Obsah rámů je dán hypertextovým odkazem ve značce <FRAME>. Takovýto dokument by prohlížeč, který nerozumí značce <FRAMESET>, zobrazil prázdný. Proto je doplněna ještě značka <NOFRAMES>, která může doplnit alternativní zobrazení pro tyto prohlížeče. Přitom je využito společné vlastnosti všech prohlížečů, že značky, kterým nerozumí, ignorují, ale text mezi nimi zobrazí. Naopak prohlížeč, který umí zpracovat značku <FRAMESET>, blok vymezený značkou <NOFRAMES> ignoruje:
<FRAMESET COLS="20%,80%">
<NOFRAMES>
<H1>Dokument abc</H1>
<A HREF SRC="content.html">Obsah</A><p>
<A HREF SRC="page1.html">Část 1</A><p>
...
<BQ>Tento dokument obsahuje rámce, prohlížeč bez podpory rámců jej zobrazí v náhradním vzhledu
</NOFRAMES>
<FRAME SRC="content.html" NAME="content">
<FRAME SRC="page1.html" NAME="main">
</FRAMESET>
Problémem stávající implementace je nutnost doplnění odkazů o jména oken, do kterých má být odkazovaný dokument zobrazen. Například v uvedeném příkladu je třeba doplnit do všech odkazů v dokumentu "content.html" atribut TARGET se jménem okna z atributu <FRAME>. Dokumenty se tak stávají závislé na počátečním dokumentu, který vytvoří a pojmenuje daná okna:
<H1>Obsah</H1>
<A HREF SRC="page1.html" TARGET="main">Část 1</A><p>
<A HREF SRC="page2.html" TARGET="main">Část 2</A><p>
Pokud by tyto atributy scházely, pak by se dokument "page1.html" zobrazil také v levém okně a tím by přepsal zobrazený obsah. Variantou oproti doplňování atributu do všech odkazů je uvést jej ve značce <BASE>.

Pro úplnost dodejme, že podobný způsob zobrazení je zahrnut také do návrhu stylů jazyka HTML verze 3. Rozložení oken je definováno v definici stylu dokumentu příkazy @PAGE a @FRAME. Pro umístění textu do okna je použit atribut FLOW a pro definici okna, ve kterém bude zobrazen odkazovaný dokument, atribut TARGET:

<HEAD>
<TITLE>Dokument s vloženým stylem s definicí rámců</TITLE>
<STYLE TYPE="text/css">
@page { layout: column }
@frame { content: 20% }
@frame { main: 80% }
h1.toc { flow: content; target: main }
a.toc { flow: content; target: main }
</STYLE>
</HEAD>
<H1 CLASS=toc>Obsah</H1>
<A CLASS=toc HREF SRC="page1.html">Část 1</A><p>
<A CLASS=toc HREF SRC="page2.html">Část 2</A><p>

Závěr

Jazyk HTML je stále ve vývoji a každý měsíc se objevují nové a nové návrhy na rozšíření jazyka. Otázkou zůstává, které z nich se uchytí a budou podporovány většinou dodavatelů prohlížečů. Původně jednoduchý jazyk se postupně stává stále složitějším a tím se také stává stále náročnějším vývoj nových prohlížečů, které navíc nabývají na velikosti a vyžadují silnější hardware. Zatímco v počátcích vývoje systému WWW stály velké firmy stranou, dnes se zapojují do vývoje a také do konkurenčního boje o trh. Tím jsou dány některé snahy o úzce firemní řešení na úkor široké kompatibility a přenositelnosti dokumentů, která byla původním cílem projektu.