Bókin um vef­forritun

Bók þessi varð til eftir að höfundur hafði kennt vefforritun við HÍ í nokkur ár án þess að hafa fundið hentuga kennslubók. Markmið bókarinnar er að veita inngang að vefforritun án nokkurrar reynslu af forritun, ásamt því að fara yfir breiddina¹¹ ólíkt því að fara á dýptina, gert er ráð fyrir að lesandi leiti sér frekari þekkingar og vinni verkefni til að byggja dýpri kunnáttu á efninu. á því sem vefforritun er. Eftir að hafa farið í gegnum efnið ættir þú að hafa þekkingu til þess að byggja vefi með HTML, CSS og JavaScript.

Verandi bók um vefforritun eru tenglar mikið notaðir til að vísa fram og til baka og útum allt í ítarefni og þess háttar. Ekki er þörf á að lesa allt ítarefni sem vísað er í, en það getur hjálpað við að byggja upp dýpri skilning á efninu. Reynt er eins og hægt er að nota íslensk orð yfir hugtök þar sem þau eru til. Stuðst er við Íðorðabanka Árnastofnunnar, sérstaklega Tölvuorðasafnið (5. útgáfa 2013) eða íslenskun höfundar.

Þar sem þessi bók gerir ekki ráð fyrir neinni fyrri reynslu í forritun er vert að fara lauslega yfir nokkur grunnhugtök áður en lagt er af stað.

Talnakerfi er kerfi sem notar tölustafi með tölustöfum. Tölvur telja yfirleitt ekki með tugakerfi²² eða tíundakerfi, kerfi sem hefur 10 sem grunntölu og notar tölustafina 0–9. (e. decimal) eins og í flestum daglegum athöfnum, heldur nota tölvur oftast tvíundakerfi (e. binary): talnakerfi sem hefur grunntöluna 2. Þá eru aðeins tölurnar 0 og 1 notaðar til að tákna allar tölur. Einfölduð ástæða fyrir þessu er að þessi gildi tákna annað hvort á eða af stöður sem hentar tölvum vel.

Einnig kemur fyrir að áttundakerfi (e. octal) og sextándakerfi (e. hexadecimal, oft stytt í hex) séu notuð, þau virka á sama grundvelli. Áttundakerfi notar 0 til 7 til að tákna allar tölur, en sextándakerfi 0 til 9 ásamt a, b, c, d, e og f fyrir tölurnar 10 til 15, engin munur er á því hvort notaðir séu lág- eða hástafir en gæti ætti samræmis.

Ef við erum að vinna með mörg talnakerfi skráum við grunntöluna með undirskrift við töluna sem við erum að vinna með, t.d. 10₂ fyrir tvíundakerfi eða 1₁₀ fyrir tugakerfi. Einnig eru forskeyti³³ forskeyti (e. prefix) (eða fortáknun) er þegar einhverju er skeytt fyrir framan, eftirtáknun (e. postfix) er þegar skeytt er fyrir aftan. stundum notuð: 0b fyrir tvíunda, 0o fyrir áttunda, og 0x fyrir sextánda.

Til að breyta tölu úr talnakerfi yfir í tugakerfi margföldum við grunntöluna með hækkandi veldi af grunntölunni frá hægri til vinstri, byrjað á 0, t.d.

Biti (e. bit, stytting á binary digit⁴⁴ eða réttara sagt portmanteau.) er gildi sem tekur annaðhvort af eða á stöðu og er oftast táknað með 0 eða 1, af eða á, true eða false.

Bæti (e. byte) er hópur af (oftast!) átta bitum sem getur túlkað 2⁸ = 256 gildi. Fyrir stærð á hlutum í tölvum eru notaðar tvær mismunandi túlkanir:

Ástæðan fyrir þessum mun eru líklega sú að fólk sem vinnur með raunverulega hluti (t.d. rafmagnsverkfræðingar sem hanna vélbúnað) hugsa og vinna almennt í tugakerfi en tölvunarfræðingar í tvíundakerfi. Þetta er líka ástæða þess að ef keyptur er harður diskur sem geymir 1 TB af gögnum geymir hann í raun og veru 1000⁴ byte sem eru 1000⁴/1024⁴ = 0,9095 TiB = 931,323 GiB.

Til þess að eiga í samskiptum við tölvur notum við jaðartæki⁵⁵ jaðartæki (e. peripheral device) er tæki (t.d. mús eða lyklaborð) sem er tengt við tölvu og leyfir okkur að koma upplýsingum inn í hana., og með þeim komum við skipunum inn í tölvuna í gegnum skel⁶⁶ því þetta er ysta lag stýrikerfisins. (e. shell). Skelin getur annaðhvort verið grafísk eða byggð á texta.

GUI (Graphical user interface) forrit, eru forrit með grafísku notendaviðmóti: við sjáum uppsett viðmót með myndum, texta, litum og þannig. Við notum þessi forrit yfirleitt með því að smella á viðeigandi hluta viðmóts (með t.d. mús, fingri, eða öðru jaðartæki) og skrifa inn texta. Dæmi um GUI forrit sem við notum mikið í vefforritun eru vafri og textaritill.

CLI (Command-line interface) forrit, eru forrit sem aðeins byggja á texta. Við skrifum inn texta í túlk, skipanalínu (e. command-line), fyrir skelina og fáum til baka línur af texta. Engar myndir eru notaðar (nema þær séu myndaðar með texta, oft kallað ascii art) en litaður texti er möguleiki. Í Windows er hægt að nota cmd.exe. zsh í macOS (í gegnum Terminal), og Bash á Linux.

Þegar við vinnum með texta (texta í sínu hreinasta formi, stafir án nokkurs útlits) notum við yfirleitt textaritla. Textaritlar geta verið frá mjög einföldum forritum (t.d. Notepad í Windows) yfir í flókin forrit sem hafa verið til í tugi ára (t.d. Vi og Emacs). Yfirleitt er best að lenda einhversstaðar í miðjunni, með textaritli sem auðvelt er að byrja að nota, en hægt er að bæta við virkni og læra betur á með tímanum.

Textaritlar sem vinsælir eru í dag og mælt er með eru t.d.: Visual Studio Code, frír ritill frá Microsoft; eða Sublime Text, eldri ritill sem getur verið hraðari í stærri verkefnum og í því að vinna með stærri skrár.

Visual Studio Code er smíðaður með veftækni—allt viðmót er útbúið með HTML, CSS og JavaScript! Mjög líklega er það ástæða þess að erfitt getur verið að vinna með stór verkefni eða stórar skrár í þeim.

Til þess að vinna með stafi og texta í tölvum þarf á einhvern hátt að skilgreina hvernig þeir eru geymdir. Þar sem tölvur vinna helst með tvíundakerfi, eru þau kerfi möppun⁸⁸ möppun (eða vörpun) er hugtak úr stærðfræði, þar sem föll varpa gildum á milli setta. Í forritun er þetta hugtak oft notað þar sem verið er að vinna með gögn, t.d. möppun á kennitölu yfir í einstakling. á tölu yfir í staf og öfugt. Við það að skrifa staf breytir ritill eða forrit stafnum í viðeigandi tölu í því skjali sem geymir textann.

Með fyrstu stafasettum sem skilgreind voru fyrir tölvur var ASCII (American Standard Code for Information Interchange) sem byggt var á hvernig skipst var á upplýsingum með símskeytum. Í ASCII eru sjö bitar notaðir til að túlka 128 stafi, fyrstu 32 eru stýristafir (e. control characters), stafir sem ekki eiga að birtast (t.d. er 1010₂ notað til að túlka bil), næstu 105 stafir kóða greinarmerki, tölustafi og 26 stafi enskastafrófsins (bæði há- og lágstafi).

Þegar við vinnum með texta í forritun getur það komið fyrir að við viljum birta tákn sem hefur ákveðna virkni í forritunarmálinu. Þá getum við notað lausnarstaf (e. escape character) til að skilgreina lausnarrunu (e. escape sequence) fyrir stafinn. T.d. eru enskar gæsalappir (") oft notaðar til að merkja streng (e. string), texta sem birta á, og \ notaður sem lausnarstafur. Þá getum við búið til lausnarrununa \" innan strengs til að birta ":

Af greinarmerkjum eru nokkur sem við þurfum að vita nokkuð nákvæm skil á:

Öll þessi greinarmerki falla undir að vera whitespace¹⁰¹⁰ auglýst er eftir íslensku orði fyrir whitespace. tákn (eða stýristafir), þau skilgreina lóðrétt og lárétt bil í texta, og eru í langflestum tilfellum ósýnileg. Í forritun geta þau skipt máli.

Það er mismunandi milli stýrikerfa hvort þetta tákn sé myndað þegar ýtt er á vendihnappinn. Windows táknar nýjar línur með bæði nýlínu og vendistaf: CRLF eða \r\n, en Unix kerfi (þ.m.t. Linux og macOS) nota aðeins nýlínu: LF eða \n. Þetta getur valdið vandræðum þegar unnið er með textaskrár á milli stýrikerfa.

Þegar tölvur fóru að vera notaðar utan Bandaríkjanna og þar sem fleiri stafir eru notaðir, voru fundin upp ný stafasett. Fyrir latneska stafrófið voru ISO-8859-1 og Windows-1252 mest notuð á vefnum, þar sem þau gat kóðað allt stafrófið í einu bæti per staf.

Til þess að koma í veg fyrir að hvert stafróf þyrfti sitt eigið stafasett og allan ruglingin tengdan því, var Unicode staðallinn búinn til, með það að markmiði að túlka öll stafróf jarðar ásamt öðrum sértækum stöfum (t.d. tjákn—emoji tákn). UTF-8 er stafasett sem kóðar alla stafi í Unicode og notar til þess allt að fjögur bæti. Fyrstu 128 stafir í UTF-8 eru þeir sömu og í ASCII, þannig að hægt er að opna ASCII skjöl sem UTF-8 án ruglings.

Á vefnum er UTF-8 langmest notaða stafasettið og það sem við notum. Textaritillinn sem við notum ætti að sýna okkur í hvaða stafasetti skjalið okkar er og leyfa okkur að breyta því. Ef við lendum í því að vista efni í textaritli en vafri birtir textann brenglaðan (sér í lagi íslenska stafi, t.d. halló þið sem er textinn halló þið vistaður í UTF-8 en birtur sem ISO-8859-1) er það vegna mismunar á stafasetti sem skjal er vistað í, og þess sem vafri birtir. Það er ekki hægt að greina 100% sjálfkrafa í hvaða stafasetti skjal eða vefsíða er í, við verðum að gera það sjálf til að koma í veg fyrir mögulega brenglun.

Í dæmum þar sem vísað er í vefþjóna og sá vefþjónn sem um ræðir skiptir ekki máli, er hægt að nota example.com, example.org eða example.net. Þessi lénsnöfn eru sérstaklega tekin frá til notkunar í dæmum. Það þýðir að enginn vaktar þau eða tekur við gögnum sem send eru á þau (ólíkt t.d. test.is eða example.is sem eru í eigu einhverra!)

„Orðin“ foo og bar eiga eflaust eftir að skjóta upp kollinum þegar verið er að læra vefforritun. Þegar verið er að skrifa dæmi þar sem einhver texti eða heiti á breytu þarf að koma fram, en heitið sjálft skiptir ekki máli, eru foo og bar (einnig foobar og baz) oft notuð.

Dæmi í JavaScript þar sem foo og bar eru notuð til að sýna samlagningu á tveim breytum, heiti breytanna skiptir engu máli.

Að nota þessi heiti fyrir breytur á sér langa sögu, allt frá sjöunda áratugnum og jafnvel alla leið til seinni heimstyrjaldarinnar með skammstöfuninni FUBAR.

Þó svo að þessi breytu heiti hafi lengi verið notuð til að sýna fram á virkni, þýðir það ekki að þetta sé góð hefð. Að nota abstrakt dæmi, ótengda raunveruleikanum hjálpar ekki til við að læra hvernig hlutir virka, höfundur reynir að halda sig frá þessu í dæmum eins og hægt er.

Annar „gervitexti“ sem skýtur upp kollinum er lorem ipsum, sem er texti sem einnig á sér langa sögu en á prenti. Þegar við vinnum útlit þurfum við oft að hafa mikið af texta til þess að sjá hvernig það mun haga sér. Þá er oft ekki búið að semja lokatextann og er þá lorem ipsum notað. Þessi texti er skemmd útgáfa af latneskum texta sem hefur verið notuð síðan a.m.k. 1960.

Internetið er alþjóðlegt netkerfi sem samanstendur af hundruðum milljóna tölva tengdra saman yfir tugþúsundir neta. Fyrir samskipti er notaður hópur samskiptaregla, Internet protocol suite sem flokkast í:

IP tölur eru notaðar til þess að aðgreina og staðsetja tæki tengd internetinu. Fyrsta útgáfa þeirra eru IPv4 tölur, sem samanstanda af fjórum, tveggja bæta tölum (0–255) sem mynda 32 bita IP tölu¹¹ Þegar þetta er skrifað er t.d. 130.208.165.186 IP talan fyrir vél sem hýsir vef Háskóla Íslands..

Þar sem við eigum mun auðveldara með að muna nöfn en tölur er til kerfi sem þýðir þarna á milli, það heitir Domain Name System eða DNS. Vegna þessa getum við slegið inn hi.is sem er lénsheiti (e. domain name) og DNS þjónar á internetinu láta okkur vita hvaða IP tala á við þann þjón.

Til þess að komast að því hvaða IP tölu ákveðið lén er með (og við höfum aðgang að því) getum við notað ping CLI forritið²² CLI forrit geta tekið við breytum, oftast með - eða -- fyrir framan. Í dæminu er -c 4 að skilgreina að framkvæma eigi fjórar fyrirspurnir.. Það sendir gögn frá tölvu á lén, ef þar á bakvið er tölva fáum við að vita IP tölu hennar. Sú tölva mun senda okkur gögnin til baka og ping forritið mun taka saman hversu langan tíma það tók og hvort öll gögnin hafi komið til baka.

Þar sem IPv4 tölur geta aðeins túlkað 2³² = 4.294.967.296 IPv4 tölur er skortur á IP tölum í heiminum og var seinustu IPv4 tölunum ráðstafað í janúar 2011. Til þess að komast hjá þessu var skilgreind ný útgáfa af IP tölum, IPv6 tölur sem geta túlkað 2¹²⁸ IP tölur. IPv6 tölur eru túlkaðar með átta hópum af fjórum sextándakerfis tölum með tvípunkt á milli. Dæmi um IPv6 tölu er 2001:0db8:85a3:0000:0000:8a2e:0370:7334³³ til eru vel skilgreindar leiðir til að stytta þær, t.d. er 2001:db8::8a2e:370:7334 stytting á dæminu.. Í dag eru bæði IPv4 og IPv6 tölur í notkun á internetinu.

Nokkrar IP tölur og hópar af IP tölum eru fráteknar og geta ekki verið notaðar á internetinu. Dæmi um slíkar tölur eru:

Ef við viljum eiga við hvernig tölvan okkar túlkar IP tölur og lén, getum við yfirskrifað með hosts skrá (/etc/hosts á mac og linux, C:\Windows\System32\Drivers\etc\hosts, til að breyta þarf stjórnandaréttindi). Þessi skrá inniheldur möppun á milli IP tölu og léns, t.d.:

Vefurinn (e. World Wide Web) er aðgengilegur yfir internetið og byggir á vefsíðum sem eiga sér ákveðið URL (Uniform Resource Locator) sem staðsetur þær. Þær eru sóttar yfir HTTP.

Vefþjónn (e. web server) er tölva sem tengd er internetinu og getur tekið við og svarað beiðnum sendum yfir HTTP á ákveðið URL. Vefþjónar hafa IP tölu og geta átt sér skilgreint lén, eða lénsnafn (e. domain name) sem er túlkað með DNS.

Vefþjónar hafa „opin port“, tölulegt staðfang sem skilgreinir hvaða ferli⁴⁴ ferli (e. process) er tilvik af forriti, það er möguleiki á að sama tölvan keyri mörg tilvik af sama forriti, t.d. ein tölva sem svarar fyrir margar IP tölur. tekur við beiðnum sem koma yfir net. Port 0–1023 eru vel skilgreind og aðeins er hægt að „bindast þeim“ (tengja ferli við port) ef notandi er stjórnandi (eða ofurpaur, e. superuser) á vefþjóni.

Dæmi um vel skilgreind port:

Oftast þegar forritarar vinna á eigin tölvum með HTTP, er port valið sem er utan vel skilgreindslista, t.d. 3000, þá er hægt að nálgast eigin tölvu með URL http://localhost:3000/.

HTTP stendur fyrir HyperText Transfer Protocol, samskiptareglur sem skilgreina hvernig dreift kerfi tölva vinnur saman yfir vefinn og skiptist á gögnum með hypertext, sem við munum læra meira um í samandi við HTML.

Fyrstu staðlar HTTP voru HTTP 1.0 og síðar HTTP 1.1, sem var formlega staðlaði samskiptareglurnar. Árið 2021 er HTTP/2 notkun að nálgast 50% á vefnum og HTTP/3 er formlega í vinnslu.

URL staðsetja og skilgreina hvernig við sækjum vefsíður yfir HTTP. Þau samanstanda af:

Dæmi um URL er http://example.org/example.html?start=true#kafli2 sem sækir vefsíðuna example.html á vefþjóninn example.org með http. Aukalega er start breytan send með gildið true. Vafrinn ætti að færa staðsetningu innan síðunnar að auðkenninu kafli2.

Í HTTP staðlinum er talað um URL og URI. Hvert um sig hefur nákvæma skilgreiningu, en munurinn er ekki augljós. Nýr, lifandi staðall, sameinar þessi tvö hugtök undir URL.

Vefsíða er sett saman með HTML, CSS og JavaScript og kallast þessi samsetti hluti yfirleitt framendi (e. front-end). Flóknari vefsíður hafa yfirleitt einhvern bakenda. Smíði vefsíðna er helsta viðfangsefni þessarar bókar.

Vafri er forrit sem hefur það hlutverk að sækja vefi sem eiga sér ákveðið URL yfir HTTP á vefþjón. Vafrinn túlkar það HTML, CSS og JavaScript sem vefsíðan inniheldur og birtir notanda.

Vafrar eru flókin forrit sem flestir hverjir geta túlkað milljarða vefsíðna. Þeir birta á skjánum það sem höfundar þeirra ætluðu sér, allt frá fyrstu árum vefsins í kringum 1990 og til þrívíðra leikja sem gerðir eru í dag. Til að geta þetta eru staðlar sem segja til um hvernig túlka eigi HTML, CSS og JavaScript.

Í anda þess hversu opinn vefurinn er höfum við í flestum vöfrum tækifæri til þess að skoða úr hverju hann er smíðaður með því að biðja vafrann um „view source“. Það að hafa aðgang að grunnkóða allra vefja á sama tíma og þeir eru skoðaðir hafði mikil áhrif á það hversu margir einstaklingar fóru að fikta og búa til sína eigin vefi.

Vefforrit er ekki vel skilgreint hugtak, en það er yfirleitt notað yfir forrit með ákveðið URL, aðgengilegt yfir vefinn, sem nýtir veftækni (HTML, CSS og JavaScript) til þess að útbúa viðmótið sem notandi sér.

Það að hafa URL er einn helsti styrkleiki vefsins, en með þeim hafa allir vefir ákveðna slóð sem við getum skoðað, deilt, leitað eftir, og nýtt án þess að nokkur miðstýring hafi eitthvað um það að segja, ólíkt t.d. „app stores“ þar sem fyrirtæki segir af eða á um hvort dreifa megi hugbúnaði eða ekki.

Vegna þess hve útbreiddur vefurinn er hafa margir staðlar verið útbúnir til að leysa hin ýmsu verkefni. Mörg forrit—ekki bara vafrar—nýta þessa staðla til að útbúa viðmót. Í dag er því hægt að nota vefforritun til að búa til forrit sem ekki bara birtast í vöfrum, t.d. textaritla, tónlistarforrit, öpp og ýmislegt fleira.

Framendi (e. front-end eða client-side) er sá partur vefsins sem notendur sjá og eiga við. Í grunninn er framendi búinn til með HTML, CSS og JavaScript. Til þess að einfalda og flýta fyrir smíðum á stærri og flóknari vefjum eru til margskonar framework eða libraries sem hjálpa. Dæmi um þetta sem eru vinsæl í dag eru React, Angular og Vue. Þó svo að þessi tól geti hjálpað okkur, þurfum við að vita hvað þessi tól gera, og því byrjum við á að læra HTML, CSS og JavaScript, án nokkura hjálpartækja.

Bakendi (e. back-end eða server-side) er sá partur vefsins sem er sendur yfir HTTP til framenda. Bakendinn samanstendur yfirleitt af vefþjóni, forriti sem útbýr framenda og einhverri gagnageymslu (t.d. gagnagrunnur). Vefþjónar geta stutt margskonar forritunarmál (t.d. C# eða Python) og forritunarumhverfi (t.d. .NET eða Django).

Stundum er talað um full stack forritun, en það er þegar forritari er fær í bæði framenda og bakenda forritun.

Til að byrja vegferð okkar sækjum við textaritil, opnum hann og búum til nýtt skjal. Hið klassíska til að skrifa er „halló, heimur“ eða „hello, world“ og fá það til að birtast á skjánum. Því getum við afritað eftirfarandi inn í textaritil:

og vistað skjalið sem index.html einhversstaðar þar sem við finnum það. Því næst opnum við vafra og með File > Open veljum við skjalið (eða með því að draga skjalið á vafra gluggann) og sjáum textann á skjánum.

Þegar við opnum skjalið svona beint á tölvunni okkar erum við ekki að nýta okkur bakenda eða vefþjón, heldur er vafrinn að opna skjalið beint af tölvunni, það sést á því að skjalið kemur ekki frá http://example.org eða http://localhost heldur file://mappa/index.html eða álíka. Þetta er í fínu lagi í fyrstu en þegar farið er að gera flóknari hluti þurfum við að keyra vefþjón á tölvunni okkar.

Ástæðan fyrir því að við notum index.html er sú að það skjal er notað sem sjálfgefna skjalið þegar mappa er opnuð, t.d. ef við höfum möppu sem heitir about á vefþjóninum okkar á example.org og innan í henni er skjalið about.html. Ef við opnum http://example.org/about fengjum við ekkert upp⁵⁵ í sumum tilfellum sjáum við skráaryfirlit (e. directory index) sem sýnir allar aðgengilegar skrár og möppur á vefþjón., aðeins ef við opnum http://example.org/about/about.html, hinsvegar ef við nefnum skránna í staðinn index.html myndi vefurinn birtast bæði ef við opnum http://example.org/about og http://example.org/about/index.html.

Til þess að koma vefsíðunum okkar yfir á vefþjóna eru nokkrar leiðir, en sú elsta er að nota FTP (File Transfer Protocol) eða SFTP (þar sem S stendur fyrir Secure eða SSH⁶⁶ Secure Shell (SSH) er samskiptastaðall sem leyfir örygg samskipti yfir óöruggt net). FTP leyfir okkur að opna stað í skráarkerfi vefþjóns og færa skrár fram og til baka.

Frítt og nothæft FTP forrit er t.d. Cyberduck fyrir Mac og Windows. Oft hefur verið mælt með FileZilla en frá og með 2018 hefur óæskilegum hugbúnaði verið dreift með forritinu svo ekki er mælt með að nota það.

Frá örófi alda höfum við sagt hvort öðru sögur: fyrst geymdar í minni einstaklinga, seinna skrifaðar á skinn eða pappír, síðan prentaðar með prentvél Gutenbergs, og fjölfaldaðar í prentsmiðjum.

Prentaður texti er í eðli sínu fastur. Við höfum blaðsíður í ákveðinni stærð sem textinn er prentaður á og eftir það eru engar breytingar mögulegar. En hvað ef svo væri ekki?

Árið 1941 gaf Jorge Luis Borges út smásöguna „The Garden of Forking Paths“ sem segir frá höfundi sem ætlar að skrifa stóra og flókna bók ásamt því að búa til stórt og flókið völundarhús. Síðar kemur í ljós að bókin og völundarhúsið er sami hluturinn, en sagan lýsir heim þar sem allar mögulegar niðurstöður atburða eiga sér stað samtímis. Þessi smásaga er talin kynna fyrst hugmyndina um HyperText.

Við lok seinna stríðs skrifaði Vennevar Bush greinina „As We May Think“ í Atlantic Monthly þar sem hann lýsir Memex. Þetta Memex tæki leyfir einstakling að halda utan um sitt eigið safn af upplýsingum. Það leyfir flokkun, athugasemdir og tengingar við annað efni svo hægt sé að fletta upp og leita ásamt því að deila með öðrum á einfaldan hátt. Sannkallað töfratæki sem Bush gerði ráð fyrir að myndi gjörbreyta heiminum.

Þessar hugmyndir, ásamt öðrum, höfðu mikil áhrif á þróun upplýsingatækninnar. Ted Nelson skilgreindi árið 1963 hugtakið HyperText: texti á stafrænu formi sem inniheldur vísanir þannig að lesandi getur strax fengið aðgang að þeim. Textinn er ekki lengur fastur, heldur teygir hann anga sína út og leyfir lesandanum að stýra sinni eigin leið í gegnum hann. Í raunheimum mætti líkja þessu við „veldu þitt eigið ævintýri“ bækur.

Í „Mother of all Demos“ árið 1968 kynnti Douglas Engelbart til sögunnar NLS („oN Line System“) sem inniheldur meðal annars mús, hypertext, útgáfustýringu (revision control), ritvinnsluforrit, fjarfundarbúnað og fleira sem í dag væri talið til nútímatækni.

Til þess að geta útfært í raun hugtakið um HyperText þurfum við einhverja leið til að ljá texta aukna dýpt og skilgreina tengingar, auk lýsingar á textanum sem er setningarfræðilega aðgreind frá textanum sjálfum. Umbrotsmál (e. markup language) leyfir okkur að gera það.

HyperMedia er það hugtak þegar við takmörum efnið okkar ekki aðeins við texta, heldur við fleiri miðla, t.d. myndir og myndbönd. Með fyrstu vinsælu stafrænu kerfunum til að útfæra HyperMedia var HyperCard sem kom út fyrir Machintosh tölvur árið 1987.

Við höfum mál sem skilgreinir snið (markup) á textanum. Hægt er að skipta þessum málum í almenna flokka:

Markdown er dæmi um létt umbrotsmál, búið til af John Gruber (í samstarfi við Aaron Swartz²² Aaron Swartz var einnig viðriðinn stöðlun á RSS, einn af stofnendum Reddit, og þáttakandi í gerð Creative Commons. Hann lést fyrir aldur fram, fjallað er um ævi hans í heimildarmyndinni „The Internet's Own Boy: The Story of Aaron Swartz“) árið 2004. Markmið þess er að leyfa fólki að skrifa texta með einföldum skipunum sem hægt er að þýða yfir í önnur form (t.d. HTML). Þessi bók er til dæmis skrifuð í Markdown.

Helsti kostur Markdown er að auðvelt er fyrir manneskjur og vélar að vinna með textann. Hægt er að smíða forrit sem þýða úr Markdown yfir í eitthvað annað, t.d. HTML.

Í kringum 1990 var Sir Tim Berners-Lee (TBL) að vinna hjá CERN sem eðlisfræðingur. Hann skrifaði minnisblað um kerfi sem hann sá fyrir sér að myndi auka möguleika á samvinnu með því að deila skjölum á einfaldan hátt. Í framhaldinu skilgreindi hann HTML: HyperText Markup Language. Sem grunn nýtti hann SGML (Standard Generalized Markup Language , umbrotsmál frá 1986 staðlað hjá ISO) en bætti við það (sjá t.d. í skjalinu „HTML Tags)“ og skrifaði fyrsta vafrann og vefþjóninn sem túlkuðu og birtu HTML (skrifað í Objective-C á NeXT tölvu). Fyrsta vefsíðan varð síðan aðgengileg 23. ágúst 1991³³ og er enn aðgengileg á sömu slóð í dag, því eins og TBL skrifaði: „Cool URIs don't change“.

Uppbygging og þróun fór fram á póstlistum þar sem þeir einstaklingar sem höfðu áhuga gátu tekið þátt og haft áhrif, t.d. stakk Marc Andreessen upp á <IMG> árið 1993 til að geta birt myndir á vefnum og er það ennþá notað í dag. Í kjölfarið komu fleiri vafrar fram á sjónarsviðið, t.d.:

Um leið og fleiri einn vafri voru komnir á sjónarsviðið þurfti að skilgreina hvernig HTML virki. Hver vafri um sig getur ekki útfært hlut á annan hátt en aðrir vafrar, eða bætt við sinni eigin, sérstöðluðu virkni.

Stöðlun á HTML 1.0 var fyrst reynd hjá IETF (Internet Engineering Task Force) en komst ekki úr því að vera drög. Útgáfa 2.0 var síðar stöðluð af IETF í RFC 1866 árið 1995. Tim Berners-Lee stofnaði W3C (World Wide Web Consortium) hjá MIT árið 1994 með stuðning frá Evrópusambandinu og DARPA. CERN dró sig þá til hliðar, enda stofnun sem sérhæfir sig í rannsóknum á sviði eðlisfræði, ekki því að vera leiðandi í upplýsingatækni. Allur kóði vafrans og vefþjónsins sem Tim Berners-Lee vann að hjá CERN var settur í almenningseign af CERN árið 1993.

Frá byrjun hefur víðsýni og frelsi einkennt vefinn. Umferð á netinu hefur að mestu verið hlutlaus, henni er ekki mismunað eftir því hvaðan hún kemur eða hvert hún fer. Ef netið væri ekki hlutlaust gætu þjónustuaðilar farið að gera greinarmun á umferð og skipt henni í hópa. Eftir því í hvaða hóp þú ert getur það t.d. haft í för með sér takmarkanir eða aukinn kostnað.

Frekar má lesa um sögu vefsins í History of the Web og vert er að endurtaka það sem kemur fram þar: „Understanding how an activity started and developed frequently gives a much greater insight into why things are as they are.“

Hlutverk W3C var—og er—að vinna að framþróun vefsins. Það er gert í gegnum vinnuhópa (e. working groups) sem taka að sér ákveðna staðla fyrir tækni vinna að því að staðla þær óstöðluðu hugmyndir eða óstaðlaða virkni sem er til staðar í dag.

Til að vinna þessa staðla eru útbúin forskrift (e. specification eða spec) sem segja til um hvernig hegðun á að vera. Hver sem er getur komið sér í þessa vinnu þar sem W3C eru opin félagasamtök. Flest þau sem vinna að stöðlunum eru þó í vinnu hjá vafrafyrirtækjunum en geta unnið saman á (tiltölulega) óháðum vettvangi að framþróun vefsins. W3C staðlar t.d. HTML, CSS, XML og SVG, en margt annað er þó einnig í stöðlun og vinnslu þar. Ferli stöðlunar er langt (tekur ár eða áratugi!) og strangt hjá W3C en í grófum dráttum er það:

Oft þegar unnið er með staðlaða hluti getur verið gott að lesa yfir staðalinn til að fá nákvæmari tilfinningu fyrir því hvernig hlutir eigi að virka. Þó ber að hafa í huga að staðlar eru skrifaðir fyrir þau sem útfæra vafrana (eða tækin sem birta vefsíður) en ekki höfunda efnis fyrir vafrana eða tækin.

Þetta verður sérstaklega áhugavert þegar unnið er með nýja tækni sem ennþá inniheldur villur, óskilgreinda hluti eða álíka.

Netscape Navigator 4.0 sem kom út árið 1997 (með stuðning við CSS, JavaScript og DOM) varð gífurlega vinsæll vafri. Uppi voru plön um að næstu útgáfur yrðu ekki ókeypis. Þegar Microsoft fór að dreifa Internet Explorer (IE) ókeypis með Windows í kringum 1997⁵⁵ sem síðar varð kveikja að stórri anti trust lögsókn á hendur Microsoft fór markaðshlutdeild Netscape að dala og hugmyndir um að græða pening á vafranum urðu að engu. Á frekar stuttum tíma tók IE alveg yfir markaðinn á meðan Netscape fór þá leið að endurskrifa Navigator 6.0 að öllu leiti, sem varð þeim kostnaðarsamt. Þetta tímabil er oft nefnt fyrra vafrastríðið.

Eftir að Netscape tapaði stöðu sinni var fyrirtækið selt AOL en áður en það gerðist var Netscape Navigator gerður open source og Mozilla stofnað sem umsjónaraðili þess verkefnis. Mozilla nafnið er talið vera komið frá Jamie Zawinksi, jwz, og standa fyrir mosaic killer⁶⁶ PBS gerði heimildarmyndina Coderush um þetta tímabil.

Í dag lifir Netscape Navigator að einhverju leyti í Firefox, en fyrsta útgáfan kom út árið 2002, þá undir nafninu Phoenix. Útgáfa 1.0 af Firefox kom út 2004.

Eftir fyrsta vafrastríðið var CSS orðið nógu vel skilgreint til að hægt væri að nota það í vefforritun en illa gekk að fá fólk til að skipta úr því að nota töflur til að setja upp vefi. Mikið var gert úr því að fólk myndi nýta sér töflulausa vefhönnun: að nota CSS til að setja upp vefi en ekki töflur.

Það varð þó breyting á með A List Apart sem varð til sem póstlisti 1997 en varð fljótlega að helsta veftímariti vefbransans og hefur verið það alla tíð síðan. Web Standards Project (WaSP) var stofnað 1998 með það að markmiði að þrýsta á vafra framleiðendur að auka stuðning við staðla og tókst það með útgáfum Netscape Navigator 6 árið 2000 og IE6 árið 2001. Zeldman, áhrifamikill vefmógúll, skrifaði grein í A List Apart 2001, „To Hell with Bad Browsers“, þar sem hann hvatti forritara og fólk sem vann á vefnum til að byrja að nota staðla. Þó svo að margir væru enn að nota gamla vafra sem ekki styddu staðlana þá væri ekki endalaust hægt að halda í þá og nóg væri nóg.

Það var samt ekki fyrr en árið 2003 sem töflulaus vefhönnun varð að alvöru með endurhönnun íþróttamiðilsins ESPN með XHTML og CSS, fyrsti stóri vefurinn til að vera gerður þannig. Vefur tæknitímaritsins Wired hafði þó verið endurhannaður árinu áður en útgáfa hans hafði ekki jafn mikil áhrif. Árið 2003 var CSS Zen Garden einnig stofnað, en það er vefur sem sýnir hvað var/er hægt að gera með CSS. Gefið var HTML skjal og máttu þeir aðilar sem sendu inn hönnun aðeins nota CSS en breyta neinu HTML. Þetta gekk vel og margar mjög framúrstefnulegar og nýtískulegar hannanir voru til sýnis. Árið 2013 var WaSP líka lagt niður með skilaboðunum, „our work here is done“.

Eftir að hætt var að gera vefi með töflum kom nokkur ládeyða yfir vafraframleiðendur og varð hún svo mikil að Microsoft tilkynnti árið 2003 að IE6SP1 yrði seinasti vafrinn þeirra. Það, ásamt því að hugtakið Web 2.0 var gert vinsælt af Tim O'Reilly, hleypti nýju lífi í markaðinn um 2004. Apple gaf út Safari fyrir Mac OSX, byggðan á KTHML árið 2003. WebKit, „vafravélin“ (e. browser engine) sem keyrir áfram Safari, var árið 2005 gerð open source af Apple.

Fyrsta alvöru vefþróunartólið, Firebug fyrir Firefox, kom út árið 2006 og gjörbreytti því hvernig vefir voru unnir. Í fyrsta skipti var hægt að breyta á einfaldan hátt, beint í vafranum, hvernig vefir höguðu sér. Þetta flýtti fyrir og einfaldaði vinnu vefforritara. IE 7.0 kom einnig út árið 2006, fimm árum eftir IE 6.0.

Með tilkomu iPhone árið 2007 og útgáfu Safari 3.0 á Mac OSX, Windows og iOS, varð vefurinn í fyrsta skipti fyrir alvöru aðgengilegur í símum í „almennilegum“ vafra. Tilraunir til að gera sérstakar vefsíður fyrir iPhone byrjuðu snemma, sérstaklega í ljósi þess að ekki var strax hægt að búa til öpp fyrir iOS.

Google gaf út Chrome vafrann árið 2008, byggðum á Chromium, open source vafra. Chromium var síðan aftur byggður á WebKit. Árið 2013 var Webkit verkefnið forkað⁷⁷ talað er um fork þegar hugbúnaðarverkefni er tekið og afritað af (yfirleitt) nýjum aðilum sem vilja fara með verkefnið í nýja átt og til varð ný vafravél, Blink sem Chrome notar í dag.

Eitt af því sem hamlaði verulega útbreiðslu nýrrar virkni í vöfrum á fyrstu árum vefsins var það að notendur vafra þurftu stanslaust að sækja nýjar útgáfur af vöfrum. Það gat valdið því að fólk keyrði óuppfærðan vafra í mörg ár og notaði hann til að sinna öllu því sem það þurfti á vefnum, sem aftur gerði það að verkum að flestir stærri vefir urðu að styðja gamla vafra lengur en æskilegt hefði verið. Í dag er þetta minna vandamál þar sem allir vafrar dreifa uppfærslum mjög ört og (í flestum tilfellum) án þess að brjóta neitt á milli uppfærsla. Chrome var fyrsti vafrinn til að gera þetta og er í dag hægt að sækja Chrome Canary eða Firefox nightly sem eru útgáfur af vöfrunum með því allra nýjasta, uppfærð næstum daglega.

Ættartré þeirra vafra sem við notum í dag er orðið frekar flókið og margþætt, en hægt er að skoða það á „evolution of the web“ fyrir vafra frá 1992–2013.

HTML stendur fyrir HyperText Markup Language og er lýsandi umbrotsmál (e. descriptive markup language) með sniði sem leyfir okkur að lýsa textanum okkar og nota HyperText hugtakið. Fyrstu útgáfur voru byggðar á SGML, Standard Generalized Markup Language, sem er ISO staðall sem skilgreinir almennt markup mál fyrir skjöl. Það byggir á tveimur hugmyndum:

Þremur árum eftir að W3C var stofnað var HTML 3.2 staðlað og gefið út sem W3C Recommendation í janúar 1997. Í desember sama ár var HTML 4.0 staðlað og skilgreinir það „nútíma“ HTML¹¹ þó svo að þessir staðlar séu enn við gildi ættum við ekki að nýta þá nema í sögulegum tilgangi..

Þegar við vinnum með HTML erum við ávallt að vinna með element²² hægt væri að þýða element sem stak, en þar sem þetta er mikið notað hugtak verður enskt heiti notað., sem er einstakur hluti af vef. Hvert element getur innihaldið önnur element, texta, eða ekkert. <p>Halló <strong>heimur</strong</p> er p element sem inniheldur málsgrein (e. paragraph) með textann „Halló “ og strong element (sem gefur til kynna að merking texta innan þess sé mikilvæg) sem inniheldur textann „heimur“.

Út frá þessum reglum (element inniheldur: element, texta, eða ekkert) getum við myndað tré. Tré³³ þó þetta sé nefnt tré, er það yfirleitt túlkað öfugt, rótarnóðan er sýnd efst og öll börn flæða niður. er gagnaskipan (e. data structure) sem notað er í tölvunarfræði til að tákna stigskipt (e. hierarchical) gögn með nóðum (e. node) sem eiga sér núll eða fleiri börn (e. children), og aðeins eina rótarnóðu (e. root node). Þetta tré myndar vefinn okkar með því að skipta upp og skipuleggja efnið okkar. Þegar vafri les og þáttar (e. parse) tréð, er búin til forritunarleg útgáfa af þessu tré sem heitir DOM (Document Object Model) tré. Dæmi um undirtré (e. subtree), partur úr stærra tré vefs: við höfum rótarnóðuna <article> sem inniheldur tvö <section> með efni:

þá túlkar það tré:

þar sem við höfum <article> sem rótarnóðu sem á tvö börn sem bæði eru <section> elementnóður, fyrra á tvö börn:

Seinna <section> á þrjú börn, sem öll eru elementnóður með stökum textanóðum. Í heildina eru þetta 16 nóður (þó tæknilega séu þau fleiri því allir strengir sem innihalda whitespace tákn milli elementa eru textanóður, með þeim eru þetta í heildina 25 nóður).

Whitespace tákn (bil, línubil, tab) hafa ekki merkingu í HTML, þannig að ef við notum fleiri en eitt bil eða línubil, þá eru þau felld saman í eitt bil. Ef við viljum setja athugasemdir innan HTML skjals getum við notað sérstakt athugasemda element sem mun aldrei birtast notanda: <!-- no comment -->, en er þó þáttað og til staðar í DOM tré sem athugasemdanóða.

Hvert element hefst á byrjunartagi, t.d. <p>. Að sama skapi ættu element í flestum tilfellum að enda á lokatagi, t.d. </p>. Í einhverjum tilfellum hefur element aðeins byrjunartag og er þá möguleiki á að sjálfloka (e. self closing) því (t.d. <hr />) en með tilkomu HTML5 er það ekki krafa (í lagi að skrifa <hr>).

Oft þegar rætt er um HTML er element og tag blandað saman og t.d. talað um p tag þegar það sem átt er við er p element. Þetta er viss smámunasemi en þarna er munur og því æskilegt að tala rétt um hlutina.

Til að mynda tengil (e. hyperlink)—og þar með búið til HyperText skjal—notum við <a> elementið (a stendur fyrir anchor⁴⁴ heitið anchor kemur til þar sem hugsunin er að elementið festi saman tvö skjöl: „The link starts at the "source" anchor and points to the "destination" anchor“): <a href="https://example.org">Lærum HTML</a> inniheldur textann „Lærum HTML“ sem vísar á „https://example.org“ með href⁵⁵ href stendur fyrir HyperText Reference (sjá nánari athugun á uppruna þessa) attribute (href er ekki krafa, án þess höfum við <a> sem myndar ekki hyperlink). Þetta hugtak er grunnurinn að vefnum, að hægt sé að tengja saman mismunandi vefi, óháð því að einhver „á hinum endanum“ geri neitt, eða að leyfi liggi fyrir.

Til þess að ljá element frekari merkingu getum við bætt við nafn-gildis pari (e. name-value pair)⁶⁶ almenn gagnaskipan sem skilgreinir færslu sem hefur nafn (t.d. titill) og gildi (t.d. Vefforritun). með því að nota attribute⁷⁷ gætum þýtt sem eigindi en höldum okkur við enska heitið. sem eru sett á byrjunartagið, t.d. href="https://example.org" sem myndar vísunina sem a element vísar á.

Venjan er, og halda skal sig við það, að skrifa nafnið með ASCII lágstöfum, síðan kemur samasem merki (=) beint á eftir, og þar beint á eftir gildið. Ekki er krafa um að umljúka gildið með gæsalöppum, en til að gildið sé skýrt er það æskilegt. Sum attribute eru aðeins notuð til að kveikja á gildi og er þá nóg að hafa aðeins heitið, t.d. <option selected>. Allar útgáfur sem fylgja eru dæmi um hvernig við eigum ekki að gera:

Til eru nokkur attribute sem leyfilegt er að setja á öll element, svokölluð global attributes. Af þeim ber helst að nefna:

Ef við viljum skilgreina okkar eigin attribute með gögnum á elementi þá notum við data-* attribute. Við getum búið til okkar eigin nafn sem ASCII lágstafa streng án bila með data- forskeyti, t.d. data-document-id="123" eða data-length="2m11s".

Element mynda ekki eingöngu tré, heldur býr hvert þeirra yfir merkingu—það hefur merkingarfræðilegt gildi (e. semantic value). Við höfum það í huga þegar við smíðum vefina okkar og útbúm þannig merkingarfræðilegt HTML. Við nýtum skilgreinda merkingu þeirra elementa sem til eru í stað þess að nota element sem láta efnið okkar líta „rétt“ út. T.d. væri ekki æskilegt að nota <strong> til að láta texta líta út fyrir að vera fyrirsögn, við notum <h2> eða annað fyrirsagnarelement. Að auki þarf að huga að merkingu þegar við blöndum saman elementum, þar sem ekki allt á við saman.Hvaða merkingu má draga af því að hafa tengil innan tengils (<a href> innan <a href>), eða fyrirsögn innan málsgreinar (<h1> innan <p>)?

Það er sérlega mælst til þess að markup í HTML skjali sé aðeins notað til að tjá merkingu en ekki framsetningu. Framsetningu á gögnum er stýrt með CSS og fáum við því hreina skiptingu á milli efnis og útlits. Mörg element eru til sem skilgreina merkingu en annars er hægt að nota attributes (sér í lagi class sem tengist beint yfir í CSS) til að ljá þeim frekari merkingu.

Með því skilja á milli merkingar og útlits er auðveldara að breyta öðru án þess að hafa áhrif á hitt. Þetta getur einfaldað okkur viðhald og gert breytingar ódýrari en þær annars gætu verið. Merkingarfræði getur líka aukið aðgengi að vefnum okkar, bæði fyrir einstaklinga sem nota lesvafra eða álíka og einnig fyrir vélar sem heimsækja vefinn okkar. Þessar vélar skoða vefinn okkar og draga ályktanir um efnið út frá því hvaða element eru notuð. T.d. Googlebot, Pocket, eða reader view sem sumir vafrar (t.d. Firefox og Safari) útfæra. Vafrinn sem túlkar efnið gæti líka nýtt merkingarfræði okkar til að birta efnið á nytsamlegan hátt sem höfundi hefði ekki dottið í hug. Að lokum notum við merkingarfræðilegt HTML því það er snyrtilegra og faglegra.

Áður fyrr þegar við höfðum ekki CSS, var merkingu og framsetningu blandað óhikað saman. Töflur ásamt ósýnilegum 1x1 myndum (spacer gifs) voru notaðar til að stýra útliti, <FONT> elementið var eina leiðin til að stýra stærð og lit á letri, t.d. með <FONT size="12" color="red" face="Comic Sans MS">Halló heimur!</FONT> sem gerði það að verkum að við fastsettum birtingu í merkingu skjals þegar hún ætti að vera óháð. Ef við vildum síðan breyta leturgerð vefsins þurfti að fara og breyta því á hverjum einasta stað sem hún var skilgreind.

Í dag er búið að fjarlægja öll þau element sem breyttu útliti vefs, eins og <center> og <font>. Einnig er búið að fjarlægja attribute af sama meiði, t.d. align, background, og bgcolor.

Þegar við skrifum HTML, þá skrifum við þannig að það beri merkingu. Við stýrum framsetningu með CSS og reynum eins og við getum að viðhalda hreinni skiptingu milli efnis og útlits. Í byrjun er mikilvægt að hafa þetta í huga, með HTML erum við að byggja upp efnið okkar, ekki að láta það líta vel út. Það kemur með CSS. Ef við viljum að fyrirsögnin sé enn stærri eða minni, þá notum við ekki vitlaus fyrirsagnar element. Ef við viljum fá auka bil, þá setjum við ekki inn óþarfa element til að ná því fram. Við bíðum þar til við lærum réttu handtökin með CSS.

Við höfum elementin <div> og <span> sem bera í eðli sínu ekki neina merkingu, þau hópa efni saman og draga merkingu sína frá börnum sínum. Þó svo að þessi element beri enga merkingu notum við þau samt í sumum tilfellum. Þegar við förum aðeins að nota þau, þá erum við komin á villugötur. Skil ekki alveg?

Þegar við skrifum HTML þá hugsum við um merkingarfræði og reynum að finna element sem passar við efnið okkar, en eyðum ekki of löngum tíma í að finna hið eina rétta element, notum <div> ef svo ber við. Við töpum okkur ekki í siðvendninni.

Öll HTML skjöl ættu að byggja á ákveðnum grunn elementum:

Öll sniðmál sem byggja á SGML þurfa að tilgreina Document Type Definition (DTD) sem skilgreinir málfræðina sem farið er eftir. Í HTML er þetta sett fram í fyrstu línu skjalsins, í DocType. Fyrir HTML 4, strict útgáfu skilgreinum við:

Enn í dag þurfum við að skilgreina í hvaða DocType HTML skjölin okkar eru. Ástæðan fyrir því er að vafrar í dag geta ennþá túlkað og sýnt vefi frá því á árdögum vefsins. Þegar enn var verið að skilgreina hvernig HTML var birt í vöfrum var mikið um ósamræmi og á tímabili var ekki hægt að innleiða nýjungar án þess að brjóta þá vefi sem þegar voru til. Þegar nýir vefir voru smíðaðir sem notuðu nýja staðla þurfti að velja sérstaklega að nota þá með því að skilgreina DocType. Ef vefur skilgreindi ekkert DocType var hann birtur í quirks mode, þar sem gert var ráð fyrir að hinir ýmsu kvillar væru til staðar. Hinsvegar ef vefur benti á rétt, staðlað DTD, var hann birtur í standards mode. Með þessari aðferð árið 1996 jókst notkun á CSS talsvert.

Þar sem tölvur geta verið heldur vandlátar á það í hvaða stafasetti við skrifum, þá skilgreinum við það sérstaklega í <head> með því að setja það á charset attribute á <meta>, element sem leyfir okkur að setja fram lýsigögn um skjalið okkar. Í langflestum tilfellum viljum við nota UTF-8.

Í HTML geta sérstakir stafir (e. character entity), verið skilgreindir með &X; þar sem X er:

Eftir áhugaleysi W3C á því að þróa HTML áfram (og mikinn fókus á XHTML og XML tengda tækni) tóku nokkrir aðilar sig saman og stofnuðu WHATWG (Web Hypertext Application Technology Working Group) árið 2004, með það að markmiði að vinna áfram að HTML og eðlilegri framþróun vefsins. Þessi vinna fór fram undir nafninu HTML5 þar sem hver sem er gat lagt til breytingar á HTML í gegnum póstlista en takmarkaður hópur ritstjóra stýrði því hvað fór inn í staðal.

Tveimur árum seinna, árið 2006, sá W3C að sér og hélt áfram þróun HTML sem HTML 5. En þar sem það er afskaplega ópraktískt að þróa tvo aðskilda staðla (HTML5 og HTML 5) á sama tíma þá voru þeir blessunarlega sameinaðir í einn HTML5 staðal árið 2007. W3C hætti þróun á XHTML 2.0 árið 2009 og farið var að öllu að þróa HTML5 sem framtíð HTML.

Árið 2012 tók W3C skyndimynd (e. snapshot) af staðlinum eins og hann leit út hjá WHATWG og fór í þá vinnu að gera staðalinn að W3C staðli. WHATWG hætti hinsvegar að tala sérstaklega um HTML5 og vinnur nú að framþróun HTML í lifandi staðli sem mun aldrei klárast og heldur áfram að þróast án þess að hlutir séu fjarlægðir.

HTML5 byggir hvorki á SGML né XML, en er afturvirkt (e. backwards compatible) fyrri útgáfum af HTML. Stefnan er að auka samvirkni (e. interoperability) og aðgengi að vefnum. Til að vera að fullu samhæft fyrri útgáfum verður HTML5 að skilgreina DocType:

Þetta er eina DocType sem við notum, nema við höfum mjög góða ástæðu til annars. Héðan í frá miðast öll umfjöllun við HTML5. Grunnurinn að vefsíðunum okkar verður þá:

Vefurinn er rétt að byrja en hefur samt nú þegar breytt svo miklu. Við sem vinnum við hann munum halda áfram að sjá breytingar; í því hvernig hann breytir þjóðfélaginu okkur og hvernig tæknin smám saman breytist. Vafrar munu halda áfram að batna, möguleikar til að birta flóknari og flóknari hluti munu aukast, t.d.: þrívíð grafík með WebGL, sýndarveruleiki með WebVR, og eitthvað sem okkur hefur ekki ennþá dreymt um.

HTML staðalinn skilgreinir lögleg element og gefur þeim merkingu (e. semantics). Vafrar og önnur forrit sem birta HTML nota þennan staðal og skilgreiningar til þess að birta HTML skjöl. Elementum er gróflega skipt í flokka eftir notkun, þar sem hvert element getur verið í einum eða fleiri flokkum:

Fyrir hvert element skilgreinir staðallinn nokkuð nákvæmlega hvernig elementið hagar sér og hvernig eigi að útfæra. Við sem höfundar¹¹ staðallinn er hugsaður fyrir bæði höfunda vefja—þau sem skrifa HTML—og höfunda vafra—sem túlka HTML og birta. vefja þurfum að skoða skilgreiningu á því hvernig á að nota, þá helst:

Eftir almennum skilgreiningum fylgir textalýsing á notkun elements, ásamt dæmum um notkun.

Þegar við skrifum HTML eru þetta elmentin sem við skoðum m.t.t. merkingarfræði. Til að aðstoða við leit er gott að nota skilgreiningar W3C, „HTML element reference“ frá MDN, eða „The Elements of HTML“ frá W3C.

Út frá merkingu þessara elementa setur vafri grunnútlit, t.d. eru fyrirsagnir stærri, málsgreinar hafa neðri spássíu (e. margin), og tenglar eru blálitaðir með undirstriki. Þessu útliti breytum við síðan með CSS, ekki með því að velja mismunandi (og hugsanlega) vitlaus element!)

Það sem fylgir er yfirferð á helstu elementum HTML.

Lýsigögn eru gögn sem skilgreina hvernig efni vefsíðu eigi að birtast, tengir önnur gögn við hana (t.d. CSS skjöl), eða skilgreina stöðu síðu í hópi síðna. Þessi lýsigögn eru ekki birt notanda beint í vafraglugganum og eru oftast skilgreind í <head>.

Til að mynda tengingu við önnur gögn²² þessi tenging er ekki hyperlink, heldur tenging t.d. við CSS sem skilgreinir útlit, eða JavaScript skrá sem skilgreinir virkni. notum við <link>. Ef rel attribute er sett þá einskorðast <link> við <head>, oftast með href sem vísar í skjal, t.d.

Hægt er að setja inn skrá í rót vefsvæðis sem heitir favicon.ico eða sem <link rel="shortcut icon" href="/icon.png"> til þess að fá fram þetta litla táknmynd sem situr yfirleitt vinsta megin í stikunni í vöfrum. Ástæðuna fyrir þessu má rekja allt aftur til 1999 þegar þessari virkni var hálfpartinn laumað inn í Internet Explorer 5.

Fyrir almenn lýsigögn notum við <meta>. Við höfum séð hvernig það er notað til að skilgreina stafasett með sérstöku charset attribute. Það má líka nota til að skilgreina önnur lýsigögn en þá skilgreinum við bæði name og content attribute. T.d. fyrir author sem skilgreinir höfund síðu, description sem skilgreinir almenna lýsingu eða generator sem skilgreinir tól sem útbjó síðuna.

Til að vísa í JavaScript notum við <script> sem annaðhvort inniheldur kóða og vísun í JavaScript skjal sem inniheldur kóðann okkar. Ef við höfum texta innan elements verður sá kóði keyrður þegar þáttari kemur að því. Ef src attribute er skilgreint þá verður skjal sem vísað er í sótt, þáttað og túlkað (kóðinn keyrður) áður en haldið er áfram, það er vegna þess að JavaScript kóði gæti skrifað út HTML. Það er óæskilegt, en möguleiki, svo vafrinn verður að bíða með HTML þáttun. Af þessari ástæðu er <script> oft sett á undan lokataggi fyrir <body>, þá getur vafri birt notanda gögn áður en JavaScript er túlkað. Af sögulegum ástæðum getum við ekki sjálflokað (e. self-closing) <script> elementi, við verðum alltaf að loka með endatagi.

Ef vafri hefur ekki stuðning við, eða slökkt hefur verið á JavaScript virkni er hægt að nota <noscript> elementið. Efni þess er birt aðeins ef JavaScript virkni er óvirk.

Dæmi sem nýtir öll lýsigögn sem minnst er á:

Flest element sem við notum í meginmáli vefs, <body>, eru flæði element, mörg þeirra geta einnig verið greinilegt efni (e. palpable content): þau innihalda eitthvað (eru ekki tóm) sem er ekki falið. Nokkur element falla aðeins undir þessa flokka og enga aðra:

Þegar við höfum sjálfstætt svæði innan skjals sem við munum vilja vísa í úr öðrum stöðum (hugsanlega með útskýringartexta), getum við notað <figure>. Þetta gæti verið skýringarmynd, graf, eða forritskóði.

Ef útskýringartexti fylgir með, er hann skilgreindur innan fyrsta <figcaption> elements. Efnið sem vísað er í er sett innan elementsins.

<dialog> er notað til að merkja part af vef sem þarf eða krefst aðkomu notanda. Þetta gæti verið skráning á upplýsingum, val á aðgerðum, eða svar við fyrirvara. Oft eru þessar upplýsingar birtar í hamsglugga⁶⁶ hér vantar betri íslenskun. (e. modal window) þar sem notandi verður að taka afstöðu til þess sem er birt. Í staðli eru skilgreind forritunarskil (e. API) þannig að hægt sé að nýta almenna birtingu (aðallega opna og loka „glugganum“) en eins og staðan er 2021, er þessi virkni ekki útfærð í öllum vöfrum og því ekki nothæf nema með fyrirvörum / fyrirvara.

Annað element sem fellur undir greinilegt efni er <div>. Þetta element hefur enga eiginlega merkingu, merking þess er skilgreint af því sem það inniheldur. Oft á tíðum grípum við til <div> þegar við hugsum ekki til enda hvaða og hverskonar efni við erum að merkja, oft eru önnur element sem henta betur.

Þetta þýðir samt ekki að við notum aldrei <div>! Þegar við förum að vinna í að setja útlit á vefina okkar, kemur það oft fyrir að við þurfum auka element og þá er það í mörgum tilfellum <div> element.

Með því að nota <pre> elementið getum við birt HTML kóða, nema til þess að efni þess sé ekki túlkað sem HTML þá setjum við < í stað <.

Við uppbyggingu á vef er æskilegt að skipta honum upp í kafla og svæði eftir efnistökum. Kafla og svæða element hjálpa okkur við það:

Áður fyrr voru <div> mikið notuð til að útbúa þessa skiptingu, t.d.

en í dag getum við notað merkingarfræðilegri element:

Fyrir þau svæði og þá kafla sem við skilgreinum er æskilegt að setja fyrirsagnir eins og þarf. Í HTML eru fyrirsagnir skilgreindar frá <h1> til <h6>, í minnkandi mikilvægisröð. Út frá þessu er hægt að skilgreina útlínu fyrir vefinn okkar sem hægt væri að horfa á eins og efnisyfirlit.

Merkingarfræðilega hefur <h1> mesta vægið og skilgreinir aðalumfjöllunarefni vefs og ætti aðeins að nota einu sinni á hverri vefsíðu. Þetta getur skipt máli fyrir lesvafra og vélar sem lesa vefina okkar. Þegar við byggjum efni á vef ættum við að skilgreina fyrirsagnir í röð og passa að göt myndist ekki þar sem hoppað er yfir fyrirsögn, t.d. frá <h1> í <h3>.

Í mörg ár hefur verið óljóst hvernig útlínur virki nákvæmlega, og hvernig þær muni virka. HTML staðallinn skilgreinir reiknirit (e. algorithm) til að útbúa útlínur sem tekur tillit til kafla og svæða. Einnig er <hgroup> element skilgreint sem leyfir að hópa saman fleiri en einni fyrirsögn, t.d. fyrir titil og undirtitil, og láta þá öll fyrirsagnar element vera túlkuð sem einn hóp.

Raunin er síðan sú að engin vafri hefur útfært þessa virkni síðan hún var skilgreind í kringum 2007. Hún veldur ruglingi, og allt lítur út fyrir að hún verði fjarlægð úr staðlinum. Þess vegna ætti ekki að nota <hgroup> eða endurnýta fyrirsagnir (byrja aftur frá <h1>) innan kafla og svæða elementa, heldur skilgreina útlínu yfir allt skjalið. Einnig ætti ekki að nota fyrirsagnar element til að skilgrena undirtitla, aðra mögulega titla og þess háttar.

Nokkur element mynda svæðarót⁵⁵ hér vantar betri íslenskun. (e. sectioning root), hugtak sem tengt er útlínum. Þessi element eiga í orði að virka með útlínu reikniritinu og mynda nýja rót þar sem útlína er reiknuð. Í reynd er þetta ekki útfært, en þessi element falla einnig undir aðra flokka og er lýst betur þar:

Texti vefsíðunnar samanstendur af orðalags elementum. Saman renna elementin í setningar sem hafa mismikið af innri elementum, allt frá málsgreinum sem aðeins inniheldur texta yfir í málsgreinar sem hafa orð og setningar með auknu væg og vísanir í annað efni. Mörg af orðalags elementum eru einnig flæði og greinanleg element.

Flest orðalags element eru:

Flest element að ofan eru til staðar í eftirfarandi dæmi:

Þegar við bætum við efni sem kemur annarsstaðar frá, t.d. myndir eða vídeó, þá notum við innfelld (e. embedded) element:

Þegar við vísum í efni þurfum við að gefa upp slóð. Þessar slóðir geta verið afstæðar (e. relative) eða nákvæmar (e. absolute). Oftast erum við að nota innfelld element þegar við vísum í slóðir en það á þó líka við t.d. <a href="."> og <link> þegar við vísum í CSS skrár.

Afstæðar slóðir (e. relative paths) eru slóðir sem líta út frá því skjali sem vísað er frá. Ef við erum stödd í index.html skjali og vísað er á img/mynd.jpg er gert ráð fyrir að img/ mappa sé til í sömu möppu og index.html er í.

Ef slóðin byrjar á / er byrjað á að fara „á rótina“ á viðkomandi vef og út frá því leitað að möppum og skjölum. T.d. ef við erum á https://example.org/files/images og vísum af þeirri síðu á /logo.png er leitað að myndinni á https://example.org/logo.png en ef / er sleppt er leitað á https://example.org/files/images/logo.png.

Nákvæmar slóðir (e. absolute paths) eru þær slóðir sem ekki eru afstæðar, þær vísa nákvæmlega í það sem átt er við. Í stað þess að vísa í logo.png vísum við í https://example.org/files/images/logo.png. Kostur við þetta er að vita nákvæmlega við hvað er átt. Á móti kemur sá stóri ókostur að ef slóð breytist þarf að breyta öllum vísunum. Við það að breyta files í assets verða allar slóðir brotnar á meðan að hlutfallslegum slóðum er sama svo lengi sem möppur og skrár haldast þær sömu innbyrðis.

Tvö gildi er hægt að nota þegar verið er að fara á milli mappa en það eru . og ... Stakur punktur . vísar í þá möppu sem við erum í en .. vísar í foreldri.

Ef við gefum okkur eftirfarandi möppur og skrár séu á léninu example.org:

þá á eftirfarandi við ef við erum stödd á https://example.org/verkefni/index.html:

Margar af þessum reglum eiga bæði við um vefslóðir og skráakerfi stýrikerfa. Þó er munur þar á, t.d. nota vefslóðir, macOS og linux / til að skipta á milli mappa en í Windows er \ notað.

Í sinni einföldustu mynd þá fellum við mynd með <img src="mynd.jpg">. Þetta er þó ekki nóg, við verðum að hafa alt texta skilgreindan með alt attribute, þetta er text sem veitir textalýsingu á myndinni fyrir þau sem ekki geta séð hana. Sjá nánar í kafla um aðgengi.

Einnig viljum við skilgreina vídd myndarinnar: breidd og hæð hennar með width og height attribute. Þar sem sækja þarf myndina eftir að HTML er sótt, veit vafri ekki vídd myndar fyrr en hún er sótt, síðan er hún felld inn, og gæti þá komið fram „hopp“ í viðmótinu: texti og efni færist til á síðunni.

Þegar við vinnum skalanlega vefi þurfum við einnig að huga að því að birta ekki of stórar myndir ef það er óþarfi. srcset attribute leyfir okkur að skilgreina mismunandi myndir eftir því í hvernig skjá verið er að nota, t.d. skjá með mikla upplausn eða litlum skjá (en hugsanlega með mikilli upplausn!)⁷⁷ farið betur yfir í umfjöllun um skalanlega vefi.

Það eru einnig til nokkur mismunandi myndaform sem hægt er að birta á vefnum, með <picture> getum við útbúið myndirnar okkar í mismunandi formum og gefið vafra val um hvaða mynd eigi að birta. Hvert myndaform er skilgreint með mime týpu (e. mime type)⁸⁸ Multipurpose Internet Mail Extensions, staðlað í RFC 6838, skilgreinir hvernig skrá verið er að eiga við. Þar sem mime type er skilgreint er það notað, ekki skráarending til að ákveða hvernig skrá er birt., t.d.:

Fyrir hvert format og/eða stærð/upplausn (getum notað media attribute) skilgreinum við <source> element innan <picture>, þar sem vafri velur fyrsta sem á við. Að lokum skilgreinum við eitt <img> element sem er með almennustu útgáfunni af myndinni okkar—sú útgáfa sem verður notuð ef allt annað klikkar. Þetta <img> element er líka það element sem notað er til að birta valda mynd.

Almennt notum <picture> þegar við:

Sum element eru, eða geta verið, gagnvirk fyrir notanda. Þá getur notandi smellt, slegið inn gögn, eða virkjað element á einhvern hátt.

<audio> bætir við hljóði (í formi skráar) eða hjóðstraum (í formi straums, lifandi hljóðskrá). <video> bætir við myndbandi eða hljóði með texta. Bæði element eru innfelld, en eru gagnvirk ef við skilgreinum leiðir til að stjórna þeim.

Þau attribute sem við getum sett á <audio> og <video> eru t.d.

Fyrir bæði <audio> og <video> getum við skilgreint mismunandi <source>, eins og í <picture> elementinu.

<track> elementið skilgreinir texta sem fylgir hljóði eða myndbandi, annað hvort texti eða skýringartexti¹⁰¹⁰ texti (e. subtitles) er þegar talað mál hefur textaútgáfu í ákveðnu tungumáli, t.d. enskt tal en íslenskur texti. Skýringartexti (e. captions eða closed captions) er textaútgáfa af öllu viðeigandi hljóði sem kemur fram, t.d. lýsing á tónlist, eða hljóðáhrifum (e. sound effect).. Fyrir elementið skilgreinum við attribute:

Öll element sem ekki eru <track> eða <source> innan <audio> eða <video> eru aðeins birt ef stuðningur í vafra er ekki til staðar.

<a>, anchor elementið, með href attribute býr til tengil sem hægt er að nota. Aukalega er hægt að skilgreina attribute:

Í flestum tilfellum er href attrbute URL sem tengt er á, en einnig er hægt að skilgreina tengla sem opna tölvupóst með mailto: forskeytinu, eða opna síma, með tel: forskeytinu.

<details> elementið leyfir að skilgreina efni sem hægt er að opna til að fá frekari upplýsingar. Fyrsta <summary> element innan þess skilgreinir samantekt eða yfirskrift, önnur element innan <details> eru aðeins birt ef það hefur verið opnað, eða ef open attribute er til staðar.

Töflur, listar, og form koma oft fyrir þegar við erum að smíða vefi. Töflur til að vinna með töfluleg gögn, listar til að hópa saman efni, og form til að taka við upplýsingum frá fólki.

Að vinna með töfluleg gögn krefst aðeins flóknari uppsetningar en á öðrum gögnum í HTML. Töflur eru skilgreindar með töflumódeli í staðli: skilgreina þarf töflu, dálka, raði, gagnareiti (e. cell), og hugsanlega fót eða samantekt. Mælst er til að hafa lýsingu á töflum til að auðvelda lestur gagnanna.

<th> skilgreinir gagnareit sem er fyrirsögn, annaðhvort í röð (þá í byjun <tr>) eða dálks (þá í röð af fyrirsögnum innan <thead>).

Við getum skilgreint eftirfarandi attribute:

Til að tilgreina hvað fyrirsögn á við, notum við scope attribute:

<td> skilgreinir gagnasellu (e. data cell) í töflu. Getum skilgreint colspan, rowspan, og headers; eins og fyrir <th>.

Nokkur flæði og greinileg element skilgreina lista af efni.

<ol> skilgreinir raðaðan lista (e. ordered list) af efni. Ef reversed attribute er skilgreint á listanum eru atriði í lækkandi röð, annars í hækkandi röð. Til að tilgreina annað byrjunargildi en 1 getum við skilgreint heiltölugildi í value attributeinu.

Til að breyta birtingu á merki getum við notað CSS, eða sett type attribute:

<ul> skilgreinir óraðaðan (e. unordered list) lista af efni. Litið er svo á að breyting á röð barna skipti engu máli fyrir merkingu listans.

Til að merkja atriði í <ol> eða <ul> listum notum við <li> elementið. Ef það er innan <ol> lista og þarf að skilgreina númer sitt notum við value attribute með heiltölugildi.

Oft er <ul> ásamt <nav> notað til þess að skilgreina valmynd, það oft að <menu> elementið var skilgreint til að gera nákvæmlega það.

Fyrir nafngildis (e. name value) lista notum við <dl> (description list). Við skilgreinum eitt eða fleiri nöfn með <dt> (term) og fylgjum því á eftir með einu eða fleiri gildum <dd> (definition). Þetta getum við notað til að merkja t.d. skilgreiningar, spurningar & svör, eða atriðaskrá.

Þegar við viljum fá upplýsingar frá notanda notum við yfirleitt form. Þau leyfa okkur að skilgreina mismunandi tegundir af leiðum til að skrá gögn ásamt aðferðum til að sannreyna þau að einhverju leyti áður en þau eru send.

<form> skilgreinir safn af elementum sem safna gögnum sem hægt er að vinna með, og senda á bakenda til úrvinnslu. Á það er hægt að setja attribute:

Hvernig nafn-gildis pör eru kóðuð þegar um method="post" er notað, skilgreinum við með enctype:

Til að taka við gögnum notum við <input> elementið sem er gagna element eða reitur sem leyfir notanda að slá inn eða eiga við gögn, hefur þó nokkur attribute, t.d.:

type attribute skilgreinir hvernig reiturinn er birtur, í flestum tilfellum bætir eða breytir vafri hvaða innsláttur er í boði út frá þessu attribute.

Ef við viljum taka við mörgum línum af texta notum við <textarea>. cols skilgreinir fjölda stafa per línu, rows fjölda lína sem skal sýna. Öll börn innan <textarea> birtast sem breytanlegur texti, þar með talið allt HTML.

Til þess að útbúa fellilista (e. drop-down list) notum við <select>. Hvert gildi sem hægt er að velja er skilgreint í <option> elementi sem er barn <select>, texti þess er birt notanda en ef value attribute er skilgreint er það gildi sent fyrir það gildi. Ef hægt á að vera að velja fleiri en eitt atriði úr listanum er multiple attribute notað. Til að hópa saman gildum getum við sett <option> element innan <optgroup>, það getur haft label attribute fyrir sýnilegt heiti.

Ef við viljum endurnýta lista af gildum eða útbúa lista af tillögum af innslátti fyrir fólk, getum við notað <datalist> elementið. Við skilgreinum id attribute fyrir það og inni í því skilgreinum við möguleika með <option> eins og fyrir <select>. Síðan vísum við í listann með list attribute sem inniheldur id gildið.

Til að merkja reiti notum við <label> sem merkir texta eða heiti við <input>, <select>, <textarea> eða aðra reiti. Ef <label> element inniheldur viðeigandi element er nóg að velja/smella á heitið til að færa fókus í innsetningu. Ef element eru aðskilin notum við for attribute á <label> þar sem gildið er id á <input>, <textarea> eða <select> elementi. Við ættum alltaf að skilgreina <label> þegar við vinnum með form til að auka aðgengi þeirra.

Fyrir flóknari form getum við notað <fieldset> til að hópa hluta forms saman, t.d. fyrir persónuupplýsingar. Fyrir hvert <fieldset> getum við skilgreint fyrirsögn með <legend>, vafrar hafa sjálfgefna birtingu á því hvernig þetta er birt en við getum breytt því með CSS.

Oftast höfum við a.m.k. einn takka í formunum okkar, takka sem sendir gögnin áfram, til þess notum við <button>. Einnig er hægt að skilgreina type="reset" til að útbúa takka sem endurstillir form, færir alla reiti í upphafsstöðu.

Þegar við tökum við gögnum í gegnum form er yfirleitt unnið með þá áfram, annað hvort í JavaScript eða á bakenda á vefþjóni. Almennt þegar við vinnum með gögn sem notendur geta sent inn viljum við treysta engu. Margar af þeim öryggisholum og málum sem koma upp í vefforritun má rekja til gagna sem koma inn í gegnum form. Þó svo að hægt sé að nota required, type="number", eða pattern attribute; þá er auðvelt að komast framhjá þessu, t.d. með því að nota „devtools“ í vafra til að breyta HTML áður en gögn eru send.

Þetta ber að hafa alltaf í huga þegar unnið er með gögn. Gögn sem koma frá framenda eru í eðli sínu ótraust og gætu innihaldið óæskileg gildi sem gætu valdið óskunda. Því verður alltaf að sannreyna þau þar.

Í 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.

Aðgengi (eða stafrænt aðgengi) og aðgengismál (e. accessibility eða a11y, 11 stafir eru milli fyrsta og seinasta stafs) er oft tengt við það að „fatlað fólk“ geti notað vefina okkar en það er frekar takmörkuð sýn á aðgengi. Aðgengi snýst um að fólk geti notað vefina okkar. Við getum öll orðið „fötluð“ tímabundið, hvort sem það er vegna slyss sem setur okkur í gips á annarri hönd eða þreytu sem veldur því að erfitt sé að rýna í texta.

Í gegnum tíðina hefur það oft verið þannig að barátta fyrir auknu aðgengi skilar sér í betri heim fyrir okkur öll. Fyrir raunheima er þetta tekið saman í hugtakinu „algild hönnun“ eða „Universal Design“ sem stefnir að því að öll hönnun sé aðgengileg öllu fólki, alltaf. Gott dæmi um þetta eru niðurtektir (e. curb cuts) á gangstéttum, lækkun sem upphaflega var ætluð hjólastólum en í dag hentar mun fleiri aðilum, t.d.: fólki með barnavagna, sendlum, og fólki sem dregur ferðatöskur.

Sem fagaðilar ættum við auk þess ekki að mismuna fólki og það mun aðeins aukast að lög verði sett sem banna mismun, hvort sem hún er viljandi eða ekki eða að þessum lögum verði framfylgt með sektum. Því er það að segja „en fólk með fötlun mun ekki nota vefinn okkar“ lítið annað en afsökun fyrir því að huga ekki að virkni sem bætir vefinn fyrir alla.

Að útfæra vef með grunn aðgengi í huga er ekki erfitt en getur verið dýrt að gera eftir á. W3C heldur úti staðli, Web Content Accessibility Guidelines 2.1. WCAG byggir á fjórum prinsippum um aðgengi á vefnum:

Útfrá hverju prinsippi eru leiðbeiningar um hvernig stuðla megi að aðgengi, 13 í heildina. Fyrir hverja leiðbeiningu eru skilgreind árangursviðmið (e. success criteria) sem falla í einn af þrem flokkum:

Til að aðstoða okkur við að útfæra vefi sem standast tilmæli WCAG er hægt að fylgja Techniques for WCAG 2.1, sem útlistar aðferðir til að uppfylla WCAG með lýsingu og prófanalýsingum, t.d. Using alt attributes on img elements.

Engin lög eru til staðar um aðgengi að vefjum á Íslandi, en stjórnvöld hafa beint þeim tilmælum til opinberra aðila að ná WCAG2.0 AA:

Birkir Rúnar sérfræðingur í aðgengismálum á vef, birti árið 2013 nokkrar greinar á vef Advania þar sem hann fór yfir stöðu aðgengismála á Íslandi:

Þegar við smíðum vef eru nokkur atriði sem við getum sérstaklega haft í huga og eru þau sett hér fram í engri sérstakri röð. Þetta er ekki tæmandi listi, heldur einföld ráð til að útbúa aðgengilegri vefi.

Skilgreina lang attribute á <html> til að skilgreina á hvaða máli vefurinn er og er það notað t.d. af lesvöfrum til að velja tungumál.

Ef við höfum vef með fleiri en einu tungumáli getum við sett lang á þau element sem innihalda texta á öðru máli en rest af vefnum:

Oftast eru þetta einföld gildi, t.d. is fyrir íslensku eða en fyrir ensku. Þar sem tungumál eru flókin, getur þetta gildi verið flókið. Eftirfarandi er löglegt:

Titill vefs, <title> er það fyrsta sem skjálesarar lesa og skal því vera lýsandi. Ekki ætti að nota sama titil á allar síður og ekki nota óljós eða of almenn orð. <title>Lærum vefforritun – forsíða</title> frekar en <title>Forsíða</title>.

Takmarka skal notkun á efni sem birtist aðeins þegar mús er haldið yfir (hover, sveimað) elementi, þar sem það felur almennt efni fyrir notendum, getur valdið rugling þegar smellt er og er ekki nothæft á snjalltækjum. Að láta hluti birtast þegar sveimað er yfir getur oft verið ódýr og fljótleg lausn þegar birta þarf mikið af upplýsingum, t.d. í valmynd, en það getur líka verið löt lausn.

Fyrir vídeó með töluðu máli getur verið mjög dýrmætt að bæta við texta. Fólk með slaka heyrn, fólk sem talar ekki málið eða þau sem ekki geta einhverra hluta vegna kveikt á hljóði græða öll. Hægt er að nýta <video> element með <track> elementi sem barni til að bæta við vtt skjali með texta. Þó að það sé ekki tæknilega flókið getur það verið afskaplega tímafrekt.

Skrifa ekki of flókinn texta, í of löngum línum eða með of smáu letri, þarsem texti er í eðli sínu það sem við notum til að miðla upplýsingum okkar. Því er mikilvægt að vanda frágang og birtingu hans.

Passa að nota ekki liti og litasamsetningar sem geta reynst erfiðar, þá bæði að litamótstaða (contrast) sé góð (hægt að nota tól eins og Color Contrast Checker) og að nota ekki litasamsetningar sem geta reynst litblindum erfiðar (Color Oracle er tól sem hermir eftir litblindu)

Skilgreina alt texta á myndir með <img alt="lýsandi texti fyrir mynd"> og ef mynd er aðeins til skrauts, skilja eftir tómt. Alt textinn er birtur ef mynd nær ekki að hlaðast, eða lesinn af lesvöfrum í samhengi við efni. Forðast í lengstu lög að hafa myndir af texta. Skjálesarar taka fram þegar alt texti er lesinn svo það er óþarfi að byrja textan á „mynd af…“ eða álíka.

Stundum er title atttibute ruglað saman við alt, og þá sérstaklega þegar óskað er eftir að fá tooltip, eða texta sem birtist þegar mús stoppar yfir elementi.

Nota fyrirsagnir rétt og í röð, frá <h1> til <h6> eins og farið var í að ofan <- burt með seinasta. outline og ekki mörg h1

Skrifa lýsandi texta þegar við búum til tengla, ekki smella hér. Oft á tíðum er texti tengils lesin sérstaklega í lesvöfrum og ætti því að innihalda eins mikið samræmi og hægt er. <p>Hægt er að eyða öllu með því að <a href="…">smella hér.</a>.

Fyrir vefi með stórar valmyndir sem koma á undan efni (í HTML kemur valmynd á undan, óháð birtingu), ætti að útbúa tengil alveg efst sem vísar beint í efni (svokallaður „skip navigation link“). Þennan tengil má fela með CSS þannig að skjálesarar finni hann aðeins og bjóði notendum upp á að sleppa við að fara í gegnum alla valmyndina og beint í efnið.

Breyta sem minnst af grunnhegðun vafra, t.d.

Nota sjálfvirk tól til að hjálpa til en ekki treysta í blindni, t.d.

Þessi tól keyra „static analysis“ og bera saman við vel skilgreind viðmið, öll blæbrigði í útfærslu okkar týnast, þó þau séu aðgengileg, jafnvel aðgengilegri.

Góð leið til að prófa aðgengi vefs er að sleppa því að nota mús og sjá hvort við getum gert allt sem hægt er á vefnum. Margir nota ekki mús eða álíka og reiða sig að miklu leyti á lyklaborðið. Í þessu samhengi viljum við ekki fjarlægja sjónræn merki um hvar fókus er, þegar farið er í gegnum vef með því að nota Tab lykil á lyklaborðinu ætti alltaf að sjást hvaða gagnvirka elementi er valið.

tabindex

Annar staðall frá W3C sem kemur að aðgengi er Accessible Rich Internet Applications. Þessi staðall skilgreinir auknar merkingar á element sem skjálesarar geta nýtt til að bæta upplifun. Hann gefur til kynna til hvers ákveðin svæði eru og hvert hlutverk þeirra er með role attribute. T.d. að innan einhvers elements sé leiðarkerfi með role="navigation" eða að það innihaldi leit með role="search".

Með ARIA getum við einnig skilgreint auka upplýsingar um element, t.d.:

Yfirleitt er þó betra að nýta rétt element (t.d. <nav>) og attribute (t.d. required) í staðinn fyrir að setja ARIA merkingar á allt. Sjá nánar í On HTML belts and ARIA braces.

Í öllum eftirfarandi dæmum eru ARIA merkingar óþarfar:

Noktun á ARIA merkingum á mest við þegar verið er að skrifa flóknari vefforrit sem nýta JavaScript virkni til hins ítrasta. Í W3C skjalinu Using ARIA er farið yfir hvernig nýta megi ARIA en þá eru líka tilteknar fimm reglur fyrir notkun:

Til að gera form aðgengileg þurfum við helst að merkja reiti á aðgengilegan hátt með því að nota <label>. Ef fleiri upplýsingar eru tengdar við reitinn, t.d. frekari upplýsingar um hvernig fylla skuli út, er hægt að nota aria-describedby="id-a-reit" til að tengja þá saman, sjá dæmi. Ef form er langt getur verið nytsamlegt að skipta því upp með <fieldset>.

Fyrir flóknari töflur þarf að skilgreina fyrir hvaða reiti fyrirsagnir eiga við með því að nota scope. Ef ekki, þá heyrir sá sem skoðar töfluna ekki samhengið, nánar um að smíða aðgengilegar töflur má lesa á WebAIM: Creating Accessible Tables

Helsta tólið, fyrir utan vafra, sem notað er til að lesa vefi eru skjálesarar. Tól sem sækja vefsíður, vinna úr þeim og lesa innihaldið upp. Hvernig virkar þinn uppáhaldsvefur ef þú þarft að hlusta á hann?

Hægt er að fá skjálesara fyrir flest stýrikerfi, t.d.:

Að prófa vef í skjálesara er í dag tiltölulega auðvelt, þá sérstaklega með VoiceOver og TalkBack. Með því að læra nokkrar skipanir er hægt að finna mörg aðgengisvandamál og fá betri sýn á hvernig vefurinn okkar er „lesinn“.

Þegar búið er að smíða vef verður það oft krafa að hann komi fram í leitarniðurstöðum þegar leitað er að ákveðnum lykilorðum. Leitarvélabestun er það þegar efni er meðhöndlað þannig að það komi frekar fram í leitarniðurstöðum og sem efst. Leitarvélar horfa til mörg hundruð breytna þegar ákveðið er hvaða vefir komi upp við leit, en þó við vitum ekki nákvæmlega hverjar þessar breytur eru, þá getum við haft áhrif á þær að einhverju leyti. Almennt er reglan sú að það eru engir galdrar, engin örugg leið til að vera #1 og að ef það hljómar of gott til að vera satt… þá er það það.

Merkingarfræðilegt HTML er grunnurinn sem góð leitarvélabestun byggir á. Á eftir því kemur gott efni sem er skipulagt, læsilegt og einstakt. Skipulagt að því leiti að lýsandi titlar brjóta það upp í einingar, læsilegt með því að vera ekki of langt eða flókið og einstakt þar sem það kemur ekki oft fyrir á sama vefnum og fjallar um þau lykilorð sem við einblínum á og ekki of mörg í einu.

Titillinn á vefsíðunni (<title>) sem inniheldur efnið okkar ætti að vera lýsandi (lykilorð að koma fram) og allar fyrirsagnir að vera einstakar og hnitmiðaðar. Nota skal rétt heading element, <h1> til <h6>. Allir tenglar á vef ættu að falla inn í textann eins og hægt er (ekki útbúa <a href="">smelltu hér!</a> tengla) og vera lýsandi fyrir það efni sem tengt er í. Myndir ættu að vera skilgreindar á aðgengilegan máta með alt texta.

Lýsigögn fyrir vef ættu að vera sett upp fyrir helstu þjónustur, t.d. Facebook og Twitter, sem oft á tíðum nota eitthvert staðlað form eins og OpenGraph (sem er þó viðhaldið af Facebook). Einnig er hægt að setja lýsingu á vef í <meta name="description"> og mun t.d. Google nýta þann texta til að birta með leitarniðurstöðum að einhverju leiti.

Minnstu upplýsingar sem ætti að skilgreina fyrir vefi svo helstu þjónustur birti viðeigandi upplýsingar eru titill, lýsing og mynd. Þar sem engin óháður staðall er til fyrir þetta þarf að bæta við öllu þrennu fyrir báðar þjónustur:

Þegar verið er að bæta við þessum upplýsingum er oft nauðsynlegt að gera ítrekað breytingar meðan verið að ná hlutunum réttum.

Flestar aðrar þjónustur nýta það sem kemur frá Facebook eða Twitter. Það að „fletja út“ þessar upplýsingar til birtingar fyrir notandur er stundum kallað unfurling.

Slóðir (URL) á vefi ættu að vera einfaldar og skiljanlegar, https://example.org/vorur/simi-utgafa-x, ekki https://example.org/?productid=123. Forðast ætti það að dreifa efni á margar slóðir: það ætti aðeins að vera aðgengilegt á einni, viðurkenndri (canonical) slóð. T.d. ætti efni ekki að vera aðgengilegt á vef og líka sér „m“, eða mobile vef. Ef ekki verður komist hjá því að hafa efnið aðgengilegt á fleiri en einni slóð er hægt að nota áframsendingar og það að merkja með <link rel="canonical" href="...">. Sjá nánar á Google: Building Smartphone-Optimized Websites. Eftir að við höfum á einum tímapunkti gert efni aðgengilegt á slóð, ættum við að reyna eins og við getum að koma í veg fyrir að það hætti að vera aðgengilegt á þeirri slóð, t.d. með því að nota áframsendingar, því eins og Tim Berners-Lee sagði, Cool URIs don't change.

Til að hjálpa ennfremur til getum við skilgreint veftré fyrir leitarvélar í sitemap.xml, sem er þá tæmandi listi yfir þær síður sem vefurinn okkar inniheldur. Leitarvélar fá þá betri mynd af því hvaða efni er til staðar og hvenær það breytist. Að sama skapi getum við skilgreint robots.txt skrá sem takmarkar eða stýrir að einhverju leyti hvernig leitarvélar og aðrir róbótar sem heimsækja vefi láta, t.d. hversu oft þeir ættu að sækja efni og hversu mikið í einu. Einnig ætti að búa til villusíður, t.d. fyrir 404 villur, ef síða finnst ekki.

Eftir að vefur fer í loftið getum við sett upp og nýtt okkur hin ýmsu tól til að fylgjast með, t.d. fjölda heimsókna, hvaðan komið er og villum sem koma upp. Með því að nota þau gögn getum við brugðist við, aðlagað efni og mætt betur raunþörfum fólks sem heimsækir vefinn. Þá er einnig hægt að gera tilraunir til að bæta vefina okkar, t.d. A/B testing.

Frekari upplýsingar má lesa í Search Engine Optimization Starter Guide frá Google, Beginners Guide to SEO eða með því að finna efni sem hefur verið vandlega bestað fyrir leitarvélar á vefnum.

Þegar við höfum skrifað efnið okkar í afskaplega fínu HTML skjali, merkingarbæru og aðgengilegu, langar okkur að ljá það lífi með útliti. Þar sem HTML er descriptive markup mál¹¹ Skilgreint í kafla 2: Markup mál. er því ekki ætlað að tjá útlit. Þar kemur CSS inn í myndina.

CSS stendur fyrir Cascading Style Sheets og er style sheet language. Það er notað til að lýsa framsetningu á skjali skrifuðu í markup máli, t.d. HTML, XHTML, XML og SVG. CSS kom fyrst fram á sjónarsviðið árið 1994 þegar Håkon Wium Lie lagði til Cascading HTML style sheets. Í tillögunni er farið yfir hvernig vafrinn stjórni að mestu allri birtingu og „höfundurinn á HTML skjölum hafi engin áhrif á birtinguna“, sem var vissulega rétt, fyrir tíma CSS var engin leið til að breyta litum á stökum tenglum, aðeins öllum í einu!

Þó svo að það væri ekki hægt að breyta litum á tenglum lét fólk það ekki stoppa sig í að nýta það sem í boði var til að lífga upp á vefsíður. Töflur og gegnsæjar gif myndir²² „Spacer GIF“ var leið til að útbúa 1⨉1 gegnsæja GIF mynd og teygja hana með því að nota t.d. <img src="spacer.gif" width="100" height="100"> innan gagnareits með bakgrunnslit (<td>) í töflu, hönnun var útfærð með töflum. tröllriðu öllu eftir að Creating Killer Websites kom út og fólk gat loksins tjáð sig á vefnum með hönnun.

Árið 1996 var CSS 1 staðlað hjá W3C en átti erfitt uppdráttar fyrstu árin eftir það. Stuðningur í vöfrum var ekki mikill og þegar virkni var útfærð var hún oftar en ekki ósamhæfð milli vafra. CSS 2 staðallinn kom út 1998 og kynnti til leiks position eigindið sem leyfði enn frekari stjórn yfir útliti. Stuðningur við CSS hélt þó áfram að vera lítill og ósamhæfður í vöfrum. Vefforritarar létu sér nægja að nota töflur og sáu sumir hverjir ekki ástæðu til að tileinka sér nýja tækni sem ekki var vel studd. Web Standards Project (WaSP) fór gagngert að þrýsta á vafraframleiðendur til að útfæra CSS rétt samkvæmt staðli og var stofnuð til þess „CSS Action Committee“ sem einnig gekk undir nafninu „The CSS Samurai“. Partur af því sem þessi hópur gerði var að útbúa viðmiðs útfærslu af CSS sem vafrar gátu hlaðið upp og borið saman við mynd. Þetta próf var kallað acid test³³ Upprunalega kemur frá því þegar sýra var notuð til að greina gull frá öðrum málmum. og varð til þess að stuðningur fór hægt og rólega að aukast.

Þegar þessir staðlar voru orðnir ágætlega studdir í nýlegri vöfrum um aldamótin, var þónokkuð af fólki ennþá að nota eldri, úrelta vafra eins og t.d. Netscape Navigator. Þar sem engin pressa var á notendur til að uppfæra og hlutirnir virkuðu var ennþá stöðnun, flestir vefforritarar sáu ekki ástæðu til að tileinka sér nýja tækni. Þetta breyttist síðan með töflulausum eða merkingarfræðilegum endurhönnum á Wired árið 2001, og ESPN árið 2003, og CSS Zen Garden sem opnaði árið 2003 sem sýndi fólki líka hvers CSS var megnugt.

CSS 2.1 kom fyrst út árið 2004 og innihélt sá staðall aðallega lagfæringar á villum í CSS 2. Brösuglega gekk þó að ná yfir allar villurnar. W3C setti því staðalinn fram en setti aftur í draft og hélt það áfram alla leið til ársins 2011. Af þessu lærði W3C og var CSS 3 sett upp á annan máta: í staðinn fyrir að gefa út einn stóran staðal með allri virkni sem staðla ætti, er virknin þróuð í einingum. Í dag eru tugir af einingum í vinnslu og eru þær á hverjum tíma í mismunandi stöðu, hvort sem þær eru draft, candidate recommendation eða proposed recommendation.

CSS er einfalt að læra en ekki auðvelt að nota. Í grunninn eru þetta nokkrar reglur með einfaldri málfræði sem leyfa okkur að lýsa því hvernig element eigi að birtast. Þar sem það er einfalt að læra á CSS en ekki auðvelt að skrifa CSS til að lýsa því útliti sem óskað er eftir, lenda margir upp á kant við CSS. Vegna þessa eru margir sem sem líta CSS hornauga og kenna því um að ekki gangi vel. Þetta er vert að hafa í huga áður en byrjað er að læra CSS.

Það er líka gott að hafa í huga að þó að CSS sé einfalt er það mjög kröftugt. Flest öll þau útlit sem við sjáum á vefnum eru smíðuð með CSS (stundum eru myndir eða þrívíddarvirkni notuð til að smíða útlit óháð CSS). Með mikilli þolinmæði má smíða ótrúlega hluti með CSS⁴⁴ Þó svo að CSS sé ekki hannað eða nýtt sem forritunarmál, þá er það óvart „turing complete“..

Með þolinmæði og tíma er hægt nota CSS sem verkfæri til að skapa list:

Þar sem CSS er sú tækni sem við notum til að ljá HTML líf þurfum við að tengja saman HTML og CSS. Það eru nokkrar leiðir til þessa:

Skjalið styles.css:

Skjalið index.html:

Í þessu dæmi eru allar þrjár leiðirnar notaðar.

Hreinlegri og betri lausn er að geyma allar þessar upplýsingar um útlit í CSS skjalinu:

Þarna höfum við endurbætt (e. refactor) fyrra dæmið: breytt uppbyggingu á kóða til hins betra án þess að breyta lokaniðurstöðunni.

Málfræði CSS er einföld, flest það sem við gerum byggist á því að vinna með reglusett sem samanstenda af selectors og yfirlýsingum. Hægt er að setja inn athugasemdir í CSS innan /* og */ en í CSS er engin leið til að skilgreina athugasemd sem tekur yfir eina línu (oft gert með // athugsemd eða # athugasemd).

Selector er strengur sem lýsir því hvaða element við viljum að taki við yfirlýsingum. Sér í lagi getum við skrifað:

Gervi-klasar skiptast síðan áfram í flokka:

Hægt er að tengja saman selectors með   bili (e. whitespace), >, + eða ~:

Ef fyrir eftirfarandi HTML:

skilgreinum við CSS sem stýrir útliti með mismunandi selectors, sjá athugasemdir við hvern um hvað er gert: