Denne uken har jeg stått til ansvar for meg selv for artikkelen jeg linket til om web standarder. En ting er å ha en side som ser pen ut og fungerer i alle browsere, en annen er å ha en oversiktlig kode som gjør det enklere for meg å vedlikeholde og å oppdatere designen i fremtiden. Jeg som mange webdesignere flasket opp på HTML og tabelldesign har vært treg til å våkne opp til det 21 århundret.

Jeg har ledd av folk som på død og liv må ha de stygge validerings-knappene på siden sin. Og bare for å ha de klart så kan man fremdeles ha pene, funksjonelle sider uten at de er i nærheten av å validere, samtidig som man kan ha gusjefæle sider som er petimeterkorrekt XHTML Strict. Så hvorfor skal man gidde å ta seg bryet med å lære noe nytt? Det er på tide å fortsette der jeg slapp i essayet “Hvorfor webben igjen er sexy” og ta for meg det praktiske, prøving og feiling, og hvorfor obskure bokstavsammensetninger som XHTML og CSS faktisk er mer sexy enn man skulle tro.

Grunnleggende ideer
Forstår du ikke hvilken nytte du kan ha av standard-basert design (rent bortsett fra den selv-gratulerende valideringsknappen)? Vil du at sidene dine først og fremst skal se bra ut? Velkommen i klubben! Men etterhvert så skjønte jeg også hvordan standard-basert design kan hjelpe sidene mine til å se bra ut, ikke hindre det. Hovedprinsippet bak standards-basert design er nemlig dette: Å skille designet fra struktur. Det høres lett ut, men hva betyr det i praksis?

Har du lært webdesign det siste tiåret har du lært å bygge opp sidene ved hjelp av en eller flere av disse: font-tagger, tabeller, transparente GIFer (noen som husker disse?), frames og kanskje hvis du var riktig uheldig: Flash. Det som har vært feilen med de første av disse er at de er ren misbruk av HTML - et språk som ble laget for å strukturere innholdet i et dokument før de fleste hadde datamaskiner med skjermer som kunne vise grafikk. Det er smarte triks, som var nødvendige av mangel på bedre alternativ, men det er likefullt triks. Og de gjør det vanskeligere for deg.

Ved å skille design fra strukturkoden får man mange fordeler: Man kan lett vedlikeholde eller bytte design ved å endre en enkelt fil: stilarket (Cascading Style Sheet); man produserer sider som kan leses på mange forskjellige plattformer og i forskjellige skjermstørrelser; man sikrer seg at siden også kan leses i framtidige nettlesere (og andre lesere); man gjør siden lettere tilgjengelig og man kommer høyere opp på søkemotorer. Om bare en av disse tingene betyr noe for deg (og da spesielt hvor enkelt det blir å vedlikeholde sidene dine), er det verdt å sette seg inn i standard-basert design. Det er ikke så vanskelig som man tror.

Hva jeg gjorde feil
En hel del faktisk. Første gang jeg prøvde meg på en ren CSS-basert layout var med Monophobe.no, og vant til tabeller som jeg var tok jeg utgangspunkt i en av de ferdige klipp-og-lim layoutene på glish.com/css. Det er absolutt ikke en dum idé, for det er et godt utganspunkt for å lære seg hvordan man lager layout med CSS, og for å forstå kodestrukturen. Den første feilen jeg gjorde var å misforstå boksmodellen. For å få en tabell til å passe inn på hele siden må du sette bredden til 100%. Jeg antok automatisk at du måtte gjøre det samme med et DIV-element. I tillegg ville jeg ha litt padding slik at elementene ikke lå klistret opp til kanten. Ooops, hva gjør den horisontale scrollbaren her?

For det første vil en div alltid strekke seg bredden av moderelementet, å legge bredde til 100% er bare redundant. For det andre så er den totale bredden av elementet alltid bredde + padding + ramme. Slik at elementet mitt var 100% av sidebredden min pluss 10 ekstra pixler (som jeg hadde definert som padding). Både jeg og Explorer 5.x for Windows misforsto dette (og derfor må man hacke det til om man vil støtte denne browserversjonen). Jeg regner dette for å være nybegynnerfeil nummer en, men det lærer man fort av. Da er det verre å forstå hvordan floats virker.

Float er i prinsippet et enkelt konsept som lar det andre innholdet flyte rundt elementet på samme måte som om man skulle sette align=”left/right” på et bilde. Implementeringen kan få deg til å klø deg sterkt i hodet noen ganger, spesielt om man skal forsøke å få dette til både i Explorer og i gode browsere. Her er det bare å eksperimentere, lese artikler og hvis man er i tvil, jenke elementene på plass med position: absolute; i stedet. :-)

Men min aller største feil var at jeg begynte i feil ende. Jeg begynte med designet i stedet for strukturen (det var jo slik jeg alltid hadde jobbet), og endte opp med et salig rot av HTML med layout-triks stilisert med det jeg mente var et avansert stilark. Feilen man gjerne gjør er å lesse på med unødvendige diver, når man egentlig kan bruke så lite kode som overhode mulig. Mindre kode = mindre hodebry for en som heller tenker visuelt enn strukturert.

Minimalisere kodesuppe
Siden min kan abstraheres til denne basisstrukturen:

Ved å sette id i stedet for class på et div-element kan man unngå mye rot. For eksempel kan man bruke ren XHTML-kode for å strukturere overskrifter og tekstparafer i stedet for å gi dem en ny klasse hele tiden. Her er et eksempel fra min egen side hvor jeg ryddet opp i høyremenyen:

Før:
<div class="rightcontent">
<div class="hoyreinnhold"><div class="hoyreoverskrift">I KULISSENE</div>
<ul class="hoyrelist">
<li><a href="http://www.movabletype.org" title="Powered by Movable Type">Movable Type 2.65</a></li>
<li><a href="http://www.kung-foo.tv/itti.php" title="Musikkinformasjon fra Kung-Tunes">Kung-Tunes</a></li>
<li><a href="http://www.kung-foo.tv/ecto" title="Bloggposting via Ecto">Ecto</a></li>
</ul>
</div>
</div>

Etter:
<div id="rightcontent">
<div class="hoyreinnhold">
<h2>I KULISSENE</h2>
<ul>
<li><a href="http://www.movabletype.org" title="Powered by Movable Type">Movable Type 2.65</a></li>
<li><a href="http://www.kung-foo.tv/itti.php" title="Musikkinformasjon fra Kung-Tunes">Kung-Tunes</a></li>
<li><a href="http://www.kung-foo.tv/ecto" title="Bloggposting via Ecto">Ecto</a></li>
</ul>
</div>
</div>

I stilarket konverterte jeg .rightcontent (en klasse) til #rightcontent (en id). På samme måte konverterte jeg .hoyreoverskrift til #rightcontent h2. Dette gjør at alle h2 (overskrift nivå 2)-tagene inne i rightcontent-diven får automatisk riktig stil. Ditto med .hoyrelist -> #rightcontent ul.

Menyen min er konstruert slik at <div id="rightcontent"> setter posisjonen til høyrekolonnen, mens hver undermeny får en <div class="hoyreinnhold"> som definerer det grafiske utseendet: Ramme, transparent bakgrunn og en forløpning på toppen. Hver overskrift er strukturert som en annetnivås-overskrift. Stilarket ser at overskriften er en h2 som ligger inne i en id med navnet “rightcontent” og legger på korrekt utseende (fet skrift etc.).

Forvirret?
Her er det enkleste eksempelet på hva man mener med å separere struktur fra kode. Før i tiden markerte man at tekst skulle være italics med <i>, og bold med <b>. I følge XHTML-reglene skal vi nå bruke em og og strong i stedet. Hvis du ikke stiliserer det blir resultatet i dagens nettlesere nøyaktig det samme. Men det behøver ikke å være slik. Em står for Emphasis, eller trykk. Hvis man vil utheve noe i en tekst bruker man <em>, og hvis man vil utheve noe ekstra (strong emphasis) bruker man <strong>. Man kunne like gjerne ha tenkte seg at man satte farge på teksten i stedet slik at <em> ble grønn tekst og <strong> ble rød.

To be continued…
Denne artikkelen er en work-in-progress. Jeg føler jeg har nok materiale til en bok her, og teksten er like ustrukturert som hodet mitt. Nå skal jeg hjem og spise middag, så får jeg se hvor jeg langt jeg kommer i morgen. Tips, rettelser og kommentarer mottas med takk.