Tekst je gore definiran kao niz znakova,
no mo~zda bi ga bilo bolje definirati kao niz
"rije~ci" (u jo~s ~sirem smislu nego kod atribut~a),
odvojenih prazninama. Praznine su razmaci, novi redovi
i jo~s neki rje~de kori~steni znakovi (npr.
tabulator), kao i nizovi takvih znakova.
Posljedica toga je da se prilikom
renderiranja (prikazivanja u browseru)
prikazuju samo te rije~ci u ~sirem smislu, sa samo
onoliko praznog mjesta izme~du rije~ci koliko je
potrebno za normalno pra~tenje teksta (dakle, obi~can
jednostruki razmak izme~du rije~ci, s prelaskom u novi
red kada sljede~ta rije~c vi~se ne stane u trenutni
red). Na primjer, ako u izvornom
XTHML dokumentu pi~se
prve rijeci
, to ~te se renderirati ovako:
onda novi red s cudnim razmacima
pa jos malo rijeci
a onda, nakon toga, jedan red s jako puno (nije bitno koliko tocno, bitno je samo da ih ima sto vise) rijeci da se vidi kako funkcionira prebacivanje u novi red
prve rijeci onda novi red s cudnim razmacima pa jos malo rijeci a onda, nakon toga, jedan red s jako puno (nije bitno koliko tocno, bitno je samo da ih ima sto vise) rijeci da se vidi kako funkcionira prebacivanje u novi red
-- vidimo da je browser potupno zanemario vi~sestruke razmake i prazne redove, te sve praznine shvatio ravnopravno i poslo~zio rije~ci s minimalnim razmacima za normalno pra~tenje toka teksta.
Naravno, postoji element unutar kojeg mo~zemo isklju~citi ta pravila ("pre"-element, preformatted), postoji element koji nala~ze eksplicitan prijelaz u novi red, kao ~sto postoji i znakovna jedinica za razmak koji ~te ostati sa~cuvan prilikom primjene gornjeg algoritma (ne~te se pretvoriti u novi red, niti ~te se slijepiti s ostalim razmacima oko njega). Sve se to mo~ze napraviti u XTHMLu, no ideja je da u ve~tini slu~cajeva o tome ne trebate previ~se misliti. Glavna snaga XTHMLa je u definiranju logi~cke strukture dokumenta, a tek kasnije, ako se poka~ze potreba, ide se u mijenjanje detalj~a koji utje~cu na s~am fizi~cki izgled dokumenta u browseru. To odvajanje sadr~zaja od izgleda je vrlo mo~tan alat za pisanje lako odr~zavaju~tih web-stranic~a, te je tako jedan od glavnih argumenata za XTHML+CSS pristup, po kojem ~temo mi raditi na ovim vje~zbama.
Radi se o tome da u XTHMLu postoje tzv. logi~cki, ili strukturalni elementi, koji govore ne~sto o funkciji koju njihov sadr~zaj ispunjava u dokumentu. Na primjer, "address" element govori da je njegov sadr~zaj adresa (misli se na geografsku adresu, ne na memorijsku:). Kako ~te se ona ispisati, XTHML nam ~zeli re~ti da ne trebamo previ~se brinuti o tome. Na primjer, element "<address class="example">Bijeni~cka 30, Zagreb</address>" se mo~ze renderirati recimo ovako:
Bijeni~cka 30, Zagreb
Mi, naravno, mo~zemo (pomo~tu CSSa) to~cno specificirati kako se address-elementi ispisuju, no u prvoj fazi pisanja dokumenta, mo~zemo samo staviti odgovaraju~te logi~cke elemente u dokument, znaju~ti da ~temo ih kasnije mo~ti lako formatirati. Drugo i va~znije, kad pomislimo da smo mogli adrese recimo desno poravnati, ili nam se ne svi~da pozadina koju smo im stavili, jedna ispravka u~cinit ~te ~sto zelimo na svim mjestima odjednom -- ne moramo i~ti kroz dokument i ru~cno reformatirati svaki put kad nai~demo na address element.
Tre~te, nedostatak strogih pravila o tome kako npr. adrese ispisivati po defaultu, zna~ci da ih razni specijalni browseri, poput onih na mobilnim telefonima, mogu renderirati tako da budu vidljivije u tim uvjetima (manji ekran, manje boj~a,...), a da i dalje ostanu u skladu sa standardom. I ~cetvrto, takvo razmi~sljanje spre~cava mentalno asociranje odre~denog taga s prezentacijskim efektom koji on ima na ekranu.
Primjer: u XTHMLu postoje elementi h1 do h6, koji slu~ze za specificiranje naslova na razli~citim dubinama logi~cke strukture dokumenata (npr. h1 mo~ze biti glavni naslov sitea, h2 naslov pojedine web-stranice, h3 podnaslovi unutar nje i tako dalje. (Naslov na po~cetku ove stranice je h3 element, a podnaslov je h4.) Ti elementi su postojali i u HTMLu, ali je bilo puno preciznije specificirano kako ~te se renderirati -- npr. h1 vrlo velikim slovima, h2 malo manjim, h3 normalnom veli~cinom ali podebljano, i tako dalje. Kao posljedica toga, mnogi ljudi su shva~tali "<hx>" tagove kao "naredbe za pove~tavanje ili podebljavanje slov~a". To je vrlo pogre~sno, na vi~se razin~a. Niti je (X)HTML programski jezik (da bi imao naredbe), niti je sve ~sto ~zelimo napisati velikim slovima uvijek naslov, niti veli~cina tog naslova mora biti u direktnom skladu s njegovom razinom u dokumentu (naslov ne mora uvijek biti ve~ti od podnaslova -- mo~ze biti istaknut na drugi na~cin).
I najva~znije, pojam "veli~cina slova" uop~te ne mora biti dobro definiran za XHTML dokument. Uz dana~snje tehnologije, takvi dokumenti se mogu renderirati na malim ekran~ci~tima mobilnih ure~daja (gdje veli~cina od 50ak piksela o~cito nema puno smisla), na tekstualnim terminalima (gdje su sva slova iste veli~cine), ili se pak mogu ~citati od strane specijaliziranog softwarea (onda mo~zemo govoriti o boji i vrsti glasa, ili intonaciji, ali nikako o veli~cini slov~a). Zaklju~cak: treba se koncentrirati na logi~cku strukturu. Treba re~ti ~sto je naslov, ~sto je adresa, link, skra~tenica, citat, nagla~seni tekst, i tako dalje, te prepustiti okru~zenju pojedinog korisnika da dokument renderira u skladu s tehni~ckim mogu~tnostima i preferencijama.