Kafli 6: Að skrifa HTML

Í gegnum árin hafa ýmsar tilraunir verið gerðar til þess að skrifa HTML, bæði þar sem vinnan er sett á höfund og á vafra.

XML, eða Extensible Markup Language er opið sniðmál sem staðlað er af W3C og hefur það að markmiði að kóða almennar upplýsingar á formi sem bæði er lesanlegt af tölvum og fólki. XML er skilgreint með SGML og notast við element og attribute. Eru því XML og HTML skjöl að mörgu leyti lík, nema að XML nota yfirleitt tög sem draga nöfn sín af verkefninu sem verið er að leysa.

XML skjöl verða að uppfylla vissar kröfur um réttmæti til að tölvur geti lesið þau, þau verða að vera gild (e. valid). Ef þau eru það ekki mun XML þáttari sem reynir að búa til DOM tré kasta villu og engu er skilað. XML skjöl verða einnig að byrja á XML skilgreiningu, t.d. <?xml version="1.0" encoding="UTF-8" ?> sem segir til um útgáfa af XML og stafasett sem notað er.

Við lok seinustu aldar var XML mjög vinsæl tækni sem var mikið notuð á internetinu. Þessar vinsældir ásamt því hversu erfitt það gat verið á stundum að þátta HTML (vafrar höfðu byggt inn virkni sem lagaði villur hjá notendum þar sem erfitt getur verið að skrifa HTML alveg kórrétt¹¹ kórrétt er að skrifa nákvæmlega rétt samkvæmt staðlinum, þar sem engar villur er að finna.) urðu til þess að fólk fór að vinna að því að gera útgáfu af HTML sem fór eftir sömu reglum og XML. XHTML, Extensible HyperText Markup Language, var staðlað af W3C og kom útgáfa 1.0 út sem W3C recommendation árið 2000 og útgáfa 1.1 árið 2001.

XHTML er vel formað XML þannig að hægt sé að þátta (e. parse) það með XML þátturum. Þegar búið er að þátta XML skjal höfum við tré sem tölvur geta unnið með.

Þetta þýðir að XHTML gerir kröfur á málfræði sem ekki eru til staðar í HTML:

Þessar kröfur eru ekki til staðar í HTML5. Við fyrstu sýn mætti halda að þessar kröfur séu af hinu góða. Hinsvegar þegar kemur að því að skrifa XHTML og alltaf fylgja þessum reglum, þá fara gallar að koma í ljós.

Þar sem XHTML á að vera vel formað XML er auðvelt að gera mistök sem valda því að vefur birtist ekki, t.d. ef það gleymist að loka elementi með endatagi, þá hreinlega birtist vefurinn ekki. Í IE6 (vinsælasti vafrinn á þeim tíma sem XHTML var sem mest í umræðunni) var ekki hægt að setja XML skilgreiningu inn í skjalið, þar sem skilgreiningin lét vafrann túlka vefinn í quirks mode.

HTTP hefur leið til að skilgreina hvernig skjal (með MIME type) kemur frá vefþjóni með Content Type skilgreiningu. Fyrir HTML er text\html notað en fyrir XML og XHTML er það application\xml. Margir af þeim vefjum sem voru strangt tiltekið skrifaðar í XHTML/XML voru sendar með vitlausu Content Type til vafra og þ.a.l. túlkaðar á sama hátt og HTML, að hafa vefina skrifaða í XHTML hafði í raun og veru engin áhrif á hvernig þeir voru túlkaðir af vöfrum.

Þó svo að þessi hugsun um að láta alla vefi vera skrifaða rétt og láta vafra framfylgja því, hafi verið rökrétt, þá virkar það ekki í reynd. Mun betra er að stefna að traustleika (e. robustness):

XHTML skjal sem er í lagi:

XHTML skjal sem er ekki í lagi og mun ekki birtast:

Sérð þú villuna? Í línu 9 er <p> elementi ekki lokað. Fyrir ekki stærri villu er refsað harkalega. Jafnvel í svona litlu dæmi er það ekki strax augljóst hvað vantar. Fyrir risa vefsíður með mikið af efni–sem jafnvel ótæknimenntað fólk vinnur við—er svona lagað afar óæskilegt.

Þó svo að HTML5 skjöl þurfi ekki að vera XML skjöl þá þýðir það ekki að þau séu ekki þáttuð. Það þýðir einfaldlega að flækjustigið við þáttunina er færð frá notanda (verða að skrifa kórrétt skjal) yfir til vafrans.

Þegar við förum að skrifa HTML (og annan kóða) lendum við tiltölulega hratt í því að vera að vinna með texta sem passar ekki á einn skjá, eða í eina skrá. Þá fer að skipta máli að vera skipulögð til að reyna eins og við getum að minnka það að fara fram og til baka, halda samræmi, og fleira. Þetta á sérstaklega við ef við erum að vinna í teymi.

Þó svo að HTML5 leyfi okkur að skrifa allskonar HTML þá viljum við halda vissu stigi af snyrtimennsku, því eins og sagt er, kóði lýsir innri manneskju. Þær leiðir sem við notum til að skrifa snyrtilegt HTML eru aðallega að:

Ef við skoðum minnsta HTML5 skjalið sem hefur allt það sem við þurfum til að skilgreina grunnvef:

þá getum við skilgreint það sem snyrtilegt HTML sem auðvelt er að lesa fyrir manneskjur. Sömu merkingu fáum við út úr eftirfarandi:

sem við gætum sagt að sé subbulegt. Vafranum er þó sama, bæði dæmin eru merkingarfræðilega nákvæmlega eins.

Til þess að sjá hvernig vafri túlkar HTML, getum við nýtt okkur „developer tools“ (eða „dev tools“) í vöfrum. Þá opnum við tólið, veljum „Elements“ í Chrome eða „Inspector“ í Firefox. Vafrinn þáttar bæði dæmi í sama DOM (Document Object Model) tréð, fyrir utan bil og nýja línu sem sett er fyrir lokun á <p>.

Þannig að HTML sem við skrifum er ein útgáfa (sú sem við sjáum með „view source“) en sú sem vafrinn birtir er önnur og er sú útgáfa kölluð DOM. Sú útgáfa getur breyst, t.d. ef við fjarlægjum eða bætum við elementum með JavaScript.

Það er gott að rifja upp Postel’s law og vera traust og öguð. Að skrifa snyrtilegt HTML getur hjálpað okkur við að losna undan hvimleiðum villum. T.d. skiptir máli hvar element lokast miðað við önnur element.

Hér er <title> ekki lokað og því mun það efni sem kemur á eftir verða túlkað innan þess, og vefurinn okkar ekki líta út eins og við myndum vilja. Vafrinn mun ekki taka fram fyrir hendurnar á okkur hér og loka <title> fyrir okkur. Af hverju? Það er ekki augljóst hvar eigi að loka því, hugsanlega viljum við hafa HTML í titlinum, vafrinn hefur enga leið til að túlka það.

Ef við lokum of mörgum <div>, gleymum að loka <ul>, eða gerum aðrar villur mun vafrinn ekki birta HTML eins og við viljum og merking vefsins okkar breytist.

Að auki eru ákveðnar reglur um það hvaða element má vera innan annars elements, hver er t.d. merking þess að hafa málsgrein innan málsgreinar, <p><p>Halló heimur!</p></p>? Í staðlinum er þetta skilgreint innan „content model“ hluta hvers elements.

Hugtakið linting á við þegar við höfum forrit sem athugar kóðann okkar og láta vita af mögulegum villum. Þessar villur geta verið tvenns konar:

Þessi forrit nýta static analysis á forritskóðanum okkur (hvort sem það er HTML, CSS, eða eitthvað annað forritunarmál). Forritin eru ekki keyrð, heldur eru þau þáttuð og borin saman við reglur forritunarmálsins og hugsanlega sérsniðnar reglur sem teymi hefur sett sér.

Þegar við vinnum í verkefnum með öðrum geta litlir hlutir í uppsetningu kóða hægt og rólega farið að skipta máli. Því getur verið mjög gott að skilgreina hvernig við skrifum forritin okkar og nýta lintera og álíka tól til að framfylgja þeim ákvörðunum. Dæmi um hvað við stöðlum gæti verið:

Til að aðstoða okkur við að skrifa snyrtilegt og rétt HTML eur til linting (eða validation) forrit (eða þjónustur) sem túlka HTML sem við gefum því og láta vita af villum sem eru til staðar. W3C rekur þá mest notuðu á https://validator.w3.org/ en þar getum við sent inn slóð á vef eða kóða til athugunar. Ef við sendum inn:

fáum við til baka lista af villum, eitthvað í líkingu við:

Einnig bjóða flestir textaritlar upp á aukapakka (plugin) sem birta linting villur meðan við skrifum og flýta þannig fyrir því að við skrifum snyrtilegan og góðan kóða.

Eitt af hinum helgu stríðum forritunarheimsins er hvort nota eigi tab eða space til að draga inn kóða. Þá er ekki verið að meina tab og space lyklana á lyklaborðinu sjálfu heldur hvort eigi að nota bil, (kóði 32 í ASCII) staf eða tab staf (kóði 9 í ASCII, eða \t). Þetta stríð hefur verið ýkt í poppmenningu og oft notað til að gantast með forritara.

Rök fyrir notkun (og ekki notkun!) á tab er að hægt er að skilgreina nákvæmlega hversu langt bil eitt tab (sjálfgefið er það yfirleitt birt sem fjögur bil) býr til á meðan að bil er alltaf nákvæmlega jafn langt. Sumir vilja að lína sé inndregin um ca. 2 bil, aðrir um 4. Forritunarumhverfi sem unnið er í hefur yfirleitt einhverja ákveðna stefnu sem flestir fylgja, t.d. í JavaScript heiminum eru tvö space yfirleitt notuð en í C# eitt tab.

Hvort heldur sem notað er skiptir ekki mestu máli, en það sem skiptir máli er að hafa samræmi í inndrætti á öllum kóða. Að blanda saman tab og space í kóða getur orðið mjög ruglandi og ætti að forðast í allra lengstu lög.

Ýkt dæmi með blönduðum bilum og tabs. Athugið að birting hér þýðir tab yfir í fjögur bil.

Eins og nefnt hefur verið, þá les vafrinn (eða annað forrit sem túlkar HTML) vefsíðuna okkar og þáttar (e. parse) í DOM (Document Object Model) sem síðan er birt. Í þessari þáttun er þó fleira sem gerist:

Þetta þýðir að röðun og stærð skráa sem við notum skipta máli. Ekki verður farið nánar í það, en það er eitthvað sem þarf sérstaklega að hafa í huga þegar farið er að vinna í stærri verkefnum sem nýta mikið af innfelldu efni, CSS, og JavaScript virkni.