!

Dette materialet blir ikke lenger vedlikeholdt. Du vil finne oppdatert materiale på siden: http://borres.hiof.no/wep/

XHTML
HTML
XML
Quirksmode
mime-type
DOCTYPE
Børre Stenseth
HTML >HTML-headere

HTML-header

Hva
Hvordan nettlesere tolker en vev side

Det er mange forhold som bestemmer hvordan en nettleser framstiller en vevsise. I denne modulen skal vi se litt på den informasjonen vi eksplisitt og implisett setter i HTTP-headeren og header-elementet på siden. Blandt annet er følgende viktige faktorer:

  • Servere (eller programmer på serveren) konfigureres for å levere ulike mime-typer for ulike filtyper (.html, .xml, .xhtml). Filekstension er altså avgjørende for hvilken mime-type vevsiden presenterer seg som.
  • Servere (eller programmer på serveren) leverer eller leverer ikke angivelse av hvordan teksten er kodet, tegnsettet.
  • Nettlesere bestemmer seg for å vise den aktuelle siden basert på følgende premissser
    • Content-Type
    • charset
    • filtype
    • selve headeren
    • brukervalg i menyen
  • Nettlesere er satt opp med default vedier, typisk hvilket tegnestt som skal brukes, dersom ikke nettleseren er i stand til å finne på noe annet basert på informasjonen over.

Når vi da i tillegg legger inn typen nettleser og versjon som en ekstra dimensjoner, er det klart at kompleksiteten blir stor. Det er både meningsløst og urimelig komplisert å foreta noen komplett analyse av denne situasjonen. Vi skal nøye oss med å peke på noen momenter på noen enkle vevsider.

mime-type

Serveren er satt opp til å levere mime-type i HTTP-headeren avhengig av hva slags ekstension fila som skal sendes har. Se W3C [1] og Webmaster Toolkit [2] . De mest aktuelle er normalt slik:

.html text/html
.htm text/html
.htmls text/html
.xml application/xml
.xhml application/xhtml+xml

Når vi genererer materiale for en nettleser fra egen prgramkode må vi huske å sende med denne informasjonen. F.eks. Skriver jeg i Python:

#! /usr/bin/python
print 'Content-type: text/html\n'
# then I write the HTML-page
 

encoding

Tolkning av tegnesett er ett av de kinkige problemene. Vi har et grunnleggene problem i og med at en tekstfil i seg selv ikke avslører hvordan den er kodet. Vi må angi dette på en eller annen måte. Denne informasjonen kan gjøres tilgjengelig på flere måter:

  • Klienten sier hva slags encoding den ønsker seg fra serveren ved hjelp av HTTP-headeren accept. Serveren sier (av og til) hva den leverer..
    Klienten tolker den informasjoen den får tilbake i tråd med dette, og kan da lese ytterligere informasjon fra selve siden.
    Dette må vi passe på når vi lager våre egne sider fra kode. Python eksempel:
    #! /usr/bin/python
    print 'Content-type: text/html; charset=utf-8\n'
    # then I write the HTML-page
     
  • vevsiden annonserer encoding i XML hodet, dersom det brukes:
    <?xml version="1.0" encoding="utf-8"?>
       

    Det er idag lite aktuelt å bruke XML-header i sider som skal vise HTML-informasjon, men det kan være at vi skal inspisere en XML-fil i en nettleser som greier denne jobben.
  • vevsiden annonserer encoding i en meta-tag i head elementet:
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /?>
       

    eller i HTML5
    <meta charset=utf-8" /?>
       

Så kan man spørre seg hva som skjer dersom denne informasjonen ikke er konsistent. En typisk og triviell situasjon som er helt avgjørende og som det ofte syndes mot: Den editoren vi bruker for å lage vevsiden lagrer selve fila i et annet format enn det vi tror, og angir. Dette fort gjort og ulike editorer har svært forskjellig strategi for hva som er default, hvordan vi setter default encoding og hvordan vi kan endre encoding på en eksisterende fil.

DOCTYPE

Vi vet at vi kan få en nettleser til å vise svært enkle sider.

<html>
<head><title>Hi</title></head>
<body>hi there</body>
</html>

eller endog:

<html>
hi there
</html>

Dette sier oss noe om hvilken toleranse nettlesere har, men demonstrerer ikke noen god strategi for å lage rike vevsider med bruk av stilsett og dynamikk.

Vi ser litt på noen eksempler på komplette vevsider av ulik type.

XHTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
               "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
    <title>mypage</title>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
</head>
<body>
<p>
 hello
</p>
</body>
</html>

Vi ser at fila begynner med DOCTYPE. og så kommer det en angivelse av html. Hva slags html er så spesifisert en PUBLIC-del og en SYSTEM-del (SYSTEM er implisitt). SYSTEM-delen er direkte en angivelse av adressen til en DTD-fil som beskriver språket, mer om DTD (Document Type Definition) i modulen DTD . Du kan forsøke å åpne http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd i nettleseren. Nettlesere henter aldri denne fila når de skal vise en HTML-side. Det er PUBLIC-delen som brukes som en identifikator av hva den kan vente seg.

Vi ser videre at selve html-elementet har egenskapen xmlns (xml namespace) som angir hvilket språk som gjelder for hele dette elementet. Vi kan i prinsipp definere og blande flere namespace på en vevside.

HTML5

<!DOCTYPE html>
<html>
<head>
    <title>mypage</title>
    <meta charset="UTF-8" />
</head>
<body>
<p>
 hello
</p>
</body>
</html>

Vi ser at dette er befriende enkelt i forhold, og det demonstrerer i en viss forstand ambisjonene med HTML5; Det er dette som er html.

Quirksmode

Nettlesere er svært tolerante programmer. Det vil si at de skal kunne handtere HTML kode av ymse slag. Spesielt er det viktig for nettlesere å kunne vise sider som er skrevet for eldre versjoner av HTML. Når en nettleser går i "quirksmode" så gjør den det for nettopp å forsøke og tolke det den finner på en tolerant måte. Denne fleksibiliteten er viktig med tanke på sammenhengen mellom HTML og CSS. Vi kan ha som utgangspunkt for vår skriving av vevsider at vi ikke ønsker quirksmode. På den måten oppnår vi mest mulig samsvar mellom den documenttypen vi har angitt, (x)html-koden og stilsettet.

Så spørsmålet blir da: Hva er det som får en nettleser til å gå i "quirksmode" og hva kan vi gjøre for å hindre det.

Det første som er viktig er at Internet Explorer går i quirksmode dersom det er noe anne enn "whitespace" før angivelse av documenttypen, <DOCTYPE. Det vil si at en kommentar eller, og det er det viktige, en XML-header, sender Internet Explorer rett i quirksmode. En konsekvens av dette er at det generelt er en tvilsom strategi å publiserer XHTML- sider med XML-header.

Nye nettlesere gir oss mulighet for å se hvordan nettleseren har behandlet din side. Du kan velge menyer som følger: I FireFox: Tools/Page, i IE 8: Tools/Developer Tools. Her vil du se om den siden du leser er framstilt i Quirksmode eller Standard Mode.

Nærmere forklaring både av quirksmode, konsekvensene og strategier for å unngå det finner du f.eks. hos Wikipedia [3] , Peter-Paul Kochs Quirksmode [4] og Jukka Korpela [5]

Referanser
  1. XHTML Media Types W3C www.w3.org/TR/xhtml-media-types/#application-xhtml-xml 14-04-2011
  1. Mime Types webmaster toolkit www.webmaster-toolkit.com/mime-types.shtml 14-04-2011
  1. Quirksmode Wikipedia en.wikipedia.org/wiki/Quirks_mode 14-03-2010
  1. Quirksmode Peter-Paul Koch Quirksmode.org www.quirksmode.org/ 14-03-2010
  1. Quirksmode Jukka Korpela www.cs.tut.fi/~jkorpela/quirks-mode.html 14-03-2010
  1. XML-validering W3C validator.w3.org/ 14-05-2010
  1. XML-validering Proze Network www.validator.ca/ 14-03-2010
Vedlikehold
Børre Stenseth, april 2011
( Velkommen ) HTML >HTML-headere ( Hvilken leser )