PHPdude
-
Innlegg
988 -
Ble med
-
Besøkte siden sist
Innholdstype
Profiler
Forum
Hendelser
Blogger
Om forumet
Innlegg skrevet av PHPdude
-
-
hva er forskjellen på html5 og xhtml?
HTML5 er den nyeste HTML-generasjonen/versjonen.
"XHTML" er ikke noe annet enn et kallenavn på XML-basert HTML (kontra SGML-basert HTML). Videre har vi XHTML1, som da er spesifikke versjoner av HTML, som er ganske identiske med HTML4, men som HTML4 kun finnes som SGML-variant, så finnes XHTML1 kun som XML-variant.
Med HTML5 derimot, så er dette helt endret. HTML5 har både SGML og XML-variant, uansett hvilken man velger å bruke så er det "HTML5" (XML-varianten blir populært kalt "XHTML5").
"Forskjellen" blir da at HTML5 er noe spesifikt (nyeste versjon av HTML), mens XHTML er et generelt begrep, som bl.a. kan referere til HTML5 (men ikke til HTML4).
Jeg leser meg opp på xhtml, og når jeg begynner å forstå dette, vil jeg da kunne bruke html5?
Driver du med lærestoff om XHTML1, så vil det gå glatt å overføre til HTML5 ja.
Eller er det altfor stor forskjell på disse?Nei. HTML5 viderefører så godt som alt fra XHTML1 og HTML4.
Mistenker at det ble forvirrende mye tall og uttrykk her nå, men det er egentlig ikke mer komplekst enn at alt her er HTML, og er i grunnen veldig veldig likt. Ingen av disse tingene er noen "blindgate", og de forskjellene som er involvert her er noe du uansett vil måtte lære deg etterhvert.
-
1
-
-
Ja. En URL som ikke eksisterer bør resultere i 404. Både på grunn av intrikate problemstillinger som kanskje/ kanskje ikke rammer deg. Og på grunn av mer åpenbare grunner, som at det hjelper søkemotorer.
Pass på at "404-siden" virkelig sendes med HTTP-kode 404, og ikke bare som vanlig HTTP 200 med "404" skrevet i en overskrift eller noe sånt - en vanlig nybegynnerfeil jeg stadig kommer over.
-
... når dette kunne vært unngått ved å tenkte nøyere gjennom HTML strukturen.
Som jeg mener å ha vært bra klar på: Påstanden min er basert på at HTML allerede er helt i tråd med "best practices".
Mener du at poenget ditt holder allikevel, så synes jeg det er på tide med et konkret eksempel på hvordan dette er problematisk.
Ta for eksempel et tre som dette:
<body> <div id="primary-navigation"/> <div id="content"/> <div id="sidebar"/> </body>
Hvilke problemstillinger vil kunne oppstå hvis man setter display:table-row på body og display:table-cell på body > div?
Og hvis noen, så hvordan hadde ting vært noe bedre om man heller bare hadde satt "float:left"; på body > div?
(Ja, du er velkommen til å velge et eget eksempel.)
(Skjermlesere vil fortsatt her vektlegge P som en paragraf, mens det visuelt kanskje nå er gjort om til en liste, et sitat eller noe annet som ikke burde vektlegges som et avsnitt.)
Enten så er <p> det beste mulige markup-valget (og da det som gir skjermleseren best grunnlag for å videreformidle innholdet), ellers så er det allikevel ikke i CSS-delen hvor problemet ligger.
-
Slik jeg ser det er det ikke helt gunstig å endre rendringen av elementer slik du beskriver (med display:inline på DIV, display:list-item på P og display:block på feks SPAN).
Om man må endre hvordan layout rendres så radikalt, synes jeg det er et signal om at HTML og content i utgangspunktet ikke er gjennomtenkt nok, og at man prøver gjøre opp for manglende fundament ved å male det i fine farger.
"Gunstig" er ikke noen god beskrivelse nei. For de som ikke forstår problemstillingen vil fort vekk "tvilsomt" ende opp som god beskrivelse, men for de av oss som forstår hva som er hva rundt og hvordan de forskjellige tingene her er ment å brukes, vil nok heller "irrelevant" være beskrivelsen.
Disse endringene går også utover andre ting, som feks tilgjengelighet. Skjermlesere, userstyles ol. får unødvendig med «støy» når de skal tolke sidene og man lager problemer for seg når en skal tilpasse sidene til ulike medier og browsere.
Dette er bra argumentert for hvorfor "riktig" HTML er bra og viktig, men det fungerer ikke som et argument mot å bruke CSS til å endre hvordan elementer brukes i layout.
«Tabeller er så 2001» er ikke et argument for å gå bort fra hvordan dataen er presentert på best måte. At tabeller ikke skal brukes til layout, betyr ikke alt all layout skal gjøres med andre HTML-elementer endret i CSS.
Da har du ikke sett poenget mitt, og neppe heller motivasjonen til CSS-arbeidsgruppa, når de gjorde "display" til en del av CSS. At du helt korrekt kan peke på to forskjellige ytterpunkter og slå fast at det er to dårlige fremgangsmåter, betyr ikke at det ikke finnes gode/smarte/riktige bruksområder i mellom.
Og nei, ingenting av det jeg skriver er et argument for "å gå bort fra hvordan dataen er presentert på best måte" - heller tvert imot.
Har man griddata er tabell fortsatt beste metode.
Kort og greit: Skal dataen din vises som tabell, bruk tabell. Skal det være en liste, bruk en liste.
Det viser egentlig bare din manglende innsikt i det du argumenter for (og som jeg er enig i): Ja, hvis innholdet er tabulært, så er det <table> som skal brukes. Men, nei, hvis greia er at innholdet skal ha grunnleggende layout ala en tabell, så er det ikke nødvendigvis <table> som skal brukes.
Det er jo dette som er hele fundamentet bak HTML og CSS!
Slik jeg forstå det du skriver, er vi enige. Så la meg utdype hva jeg mener:
Du understreker som meg at CSS er for visuell identitet, og at HTML er for struktur.
HTML burde vel da være så generisk og fjernet fra CSS som mulig, og CSS burde vel ikke blandes inn i strukturen?
Enig. Er på nettopp det grunnlaget jeg sier at "display:table;" (og "display:*;" i det hele tatt) er rimelig uproblematisk å bruke. For selv om selve ordet som brukes er "table", så er det rett og slett en helt annen greie enn HTML-tabeller, som er irrelevant i forhold til problemstillingen rundt hvordan man skriver HTML.
Selvfølgelig er dette ingen som helst grunn til å senke kvaliteten på markup/HTML.
Koden vi diskuterer bruker klasser som .table og .row og .cell, som berører hva jeg mener er problemet.
Ok, forholdt meg bare til akkurat de ordene som ble skrevet i innleggene jeg. Er vertfall hjertens enig i at den fremgangsmåten du referer til der er tilsvarende problematisk som misbruk av <table>.
Slik jeg oppfatter best practise CSS og HTML er det en annen bruk som er optimal. Derfor står jeg fortsatt fast på at om målet er å lage en tabell, så kan man like gjerne bruke en tabell.
Det er bare det at man lager ikke en tabell selv om man setter display:table;! Det eneste man gjør er at man tar i bruk en grunnleggende layout-struktur som (tilfeldigvis) tilsvarer det man er vant til fra den beryktede "tabellsuppa". Resultatet trenger jo ikke en gang å ligne på en tabell, men kan jo f.eks brukes til helt vanlige multi-kolonne-design.
Det er så "enkelt" som at man bruker den HTML-strukturen som best reflekterer innholdet mest mulig uavhengig av hvordan man ser for seg designet - er det tabulært innhold så er det antagelig <table> som passer, hvis ikke må man finne noe annet som passer. (der skjønner jeg at vi er helt enig)
Hva man deretter gjør i CSS er rett og slett irrelevant! (der finner jeg det uklart hva du egentlig mener.)
-
Slik
jeg ser det er det ikke helt gunstig å endre rendringen av elementer
slik du beskriver (med display:inline på DIV, display:list-item på P og
display:block på feks SPAN).
Om
man må endre hvordan layout rendres så radikalt, synes jeg det er et
signal om at HTML og content i utgangspunktet ikke er gjennomtenkt nok,
og at man prøver gjøre opp for manglende fundament ved å male det i fine
farger.
"Gunstig"
er ikke noen god beskrivelse nei. For de som ikke forstår
problemstillingen vil fort vekk "tvilsomt" ende opp som god beskrivelse,
men for de av oss som forstår hva som er hva rundt og hvordan de
forskjellige tingene her er ment å brukes, vil nok heller "irrelevant"
være beskrivelsen.
Disse
endringene går også utover andre ting, som feks tilgjengelighet.
Skjermlesere, userstyles ol. får unødvendig med «støy» når de skal tolke
sidene og man lager problemer for seg når en skal tilpasse sidene til
ulike medier og browsere.
Dette er bra argumentert for hvorfor "riktig" HTML er bra og viktig, men det fungerer ikke som et argument mot å bruke CSS til å endre hvordan elementer brukes i layout.
«Tabeller
er så 2001» er ikke et argument for å gå bort fra hvordan dataen er
presentert på best måte. At tabeller ikke skal brukes til layout, betyr
ikke alt all layout skal gjøres med andre HTML-elementer endret i CSS.
Da har du ikke sett poenget mitt, og neppe heller motivasjonen til CSS-arbeidsgruppa, når de gjorde "display" til en del av CSS.
At du helt korrekt kan peke på to forskjellige ytterpunkter og slå fast
at det er to dårlige fremgangsmåter, betyr ikke at det ikke finnes
gode/smarte/riktige bruksområder i mellom.
Og nei, ingenting av det jeg skriver er et argument for "å gå bort fra
hvordan dataen er presentert på best måte" - heller tvert imot.
Har man griddata er tabell fortsatt beste metode.
Kort og greit:
Skal dataen din vises som tabell, bruk tabell. Skal det være en liste, bruk en liste.
Det viser egentlig bare din manglende innsikt i det du argumenter for
(og som jeg er enig i): Ja, hvis innholdet er tabulært, så er det
<table> som skal brukes. Men, nei,
hvis greia er at innholdet skal ha grunnleggende layout ala en tabell,
så er det ikke nødvendigvis <table> som skal brukes.
Det er jo dette som er hele fundamentet bak HTML og CSS!
-
display:table er som en mann i kanindrakt. Det er fortsatt en mann. Det ligger i ordet <table> at det er for tabular data, derfor skal man ikke bruke den til layout. Jeg er ikke en av de som griner om noen gjør det likevel. Men hva ligger i ordet display:table da? At det ikke er snakk om tabular data? Tabell er tabell, og det var det også i 2001. Såvidt jeg vet er denne omveien til tabeller ikke støttet av eldre IE-versjoner, nok en grun til å heller bruke <table> eller <div> med float/posisjonering. Mulig mine fordommer er grunnløse, men jeg ser på display:table som en tulleting.
Svakhetene med å bruke HTML-tabeller til annet enn tabulære data kan overhodet ikke overføres til "display:table"-funksjonaliteten i CSS.
CSS-delen dreier seg kun om presentasjon, akkurat som CSS skal. Det "ligger ikke noe i ordet display:table" annet at elementet da skal bruke tilsvarende layout-modell som mange er kjent med fra <table>. Det har ikke noen mer betydning på innholdet enn om du hadde satt "display:list-item" på en <p>, eller satt "display:inline" på en <div>.
"display:table" er ikke noe mer en tulleting enn hva "display:block" eller "display:inline" er det - ei eller er det noen fantastisk løsning på all verdens problemer...
-
...
Det som er litt irriterende da, er at istedet for å forsøke å faktisk fronte en teknologi som er åpen, og tilgjengelig for alle, og teknisk overlegen så er folk motstandere fordi det er laget av Microsoft. Skam dere.
Pass heller selv på at du ikke slenger ut mildt sagt kontroversielle påstander som enkle faktum og ikke stempler "folk" som ute av stand til å være saklige ovenfor Microsoft-produkter.
Silverlight har støtte for 3D, og i motsetning til WebGL, så er 3D objekter en del av "DOM" treet.
Kom med en referanse du, til Silverlights alternativ til WebGL. Det du beskriver, høres mer ut som en mellomting på et høyere abstraksjons-lag, mer i tråd med Flash sine 3D-muligheter enn WebGL - et område hvor også web-plattformen har funksjonalitet også, for den saks skyld... men som altså er noe annet enn WebGL.
Jeg er bra sikker på at Silverlight ikke har noe GPU-akselerert 3D-API på DirectX/OpenGL-nivå, sånn som WebGL. Og har oppfattet det sånn at MS har noe problemer rundt å få dette på plass, siden DirectX har veldig mangelfull kompatibilitet med forskjellige enheter, og MS av "strategiske" grunner ikke vil lage noe basert på OpenGL.
Men jeg tviler ikke på at jobbes hardt (og bra) med saken, så du kan kanskje oppdatere meg på status?
Jeg ser at Silverlight 5 skal komme med nye 3D-API, det er kanskje sånn kommende funksjonalitet du sikter til?
-
Tilgang til mikrofon og webcam er noe som nevnes av en del. "Kommende" er et passende ord for HTML5-støtten, såvidt jeg har forstått.
Mikrofon og webcam er i grunnen et kurant punkt ja. Det er spesifikasjoner for dette under arbeid ja, som har de første implementeringene på plass. "Kommende" passer greit.
Så er jo en da "interessant" observasjon (mest i forhold denne artikkelen) at mikrofon og webcam-støtte er noe som også er "kommende" for Moonlight...
-
3 argumenter jeg kommer på nå her, men finnes nok mange fler.
Avanserte applikasjoner som kjøres på klienten.
DRM og generell rettighetsstyring
Sikkerhet
- DRM: Er mye meninger om det er en "mangel" eller en "bonus", men det er vertfall en oppfattet mangel for endel ja.
- "... og generell rettighetsstyring". Du formulerer det som et utspring av DRM-punktet, men nevner det som et eget tredje punkt. Tenker du det som et bredere bruksområde av hva man vanligvis forbinder med DRM-funksjonalitet, så må det regnes under det samme. Tenker du det som noe helt generelt på utviklings-nivå, så er det vare tøv, og vertfall milevis unna noe konkret.
- Sikkerhet: Tøv og svada.
Det konkrete er altså DRM. Hvis det er det du mener påstanden din står på, så OK...
-
La flammekrigen begynne!
..., men faktum er dessverre at html5 ikke dekker alle behov man har for nettet slik at løsninger som flash og sliverlight kommer til å eksistere i samspill med andre åpne teknologier.
Hvilke behov er det web-plattformen ikke dekker? Et sånt "faktum" bør det gå glatt å konkretisere.
Ja, vertfall Flash, kommer til å ha en stor rolle for Internett-innhold i lang tid fremover, men "historiske faktum" og "personlig smak", er det som slår meg som grunnen - ikke den moderne web-plattformens mangler.
-
2014? But I need it now!
Så bruk det da. Er meningen det.
Eksperter og involverte i web-standardiseringsarbeid og nettleser-samarbeid har her fått seg noen viktige datoer.
For vanlige webutviklere er disse tidspunktene uten praktisk betydning. Vi bare forholder oss til hva nettleserne støtter av funksjonalitet, og der er det masse fra HTML5 på plass. Og mer på full fart inn.
-
Siden du begynner på bar bakke så annbefaler jeg: http://www.w3schools.com//
+1
Jeg tenker også at w3schools.com er en tragisk oppblåst side, som gjerne burde byttet navn til ie6schools.com. Referanse-sidene deres er tvers gjennom dårligere enn alternativene og den faglige veiledning der er til tider direkte vranglære etter dagens standard (i tillegg til masse faktafeil) - ekstra sørgelig når så mange presenterer siden som bra for nybegynnere.
Ganske drøyt, men dog bra at noen faktisk har lagd en egen side for å opplyse om problemene.
Synd at W3Schools scorer noe ganske vanvittig på Google sin søke-ranking.
Jeg er også mye enig i "W3Fools" sin liste over alternativer.
HTMLDog.com tilbyr faglig veiledning for nybegynnere hvor de har klart å forenkle alt stoffet på en god måte, uten at det går over i vranglære.
Opera Web Standards Curriculum er den eneste lære-ressursen jeg har registert som tar for seg hele pakken og som har så høy kvalitet og glitrende innsikt, at hvis man jobber seg gjennom og har forstått innholdet, så er man en god (fersk) webutvikler.
Den bærer dog litt preg av å være ment for instruktør-grupper, som gjør den litt overveldende for en enslig nybegynner.
The MDC (Mozilla's Doc Center) har virkelig blitt knallbra det siste året. Her er det masse bra innhold for alle nivåer.
-
Jeg la nettopp inn følgende CSS:
@fontfacefont-family: "bank gothic";
src: url(bank gothic);
}
p.customfont {
font-family: "bank gothic", bank gothic;
}
Fortsatt virker ikke formatet "font-family:'bank gothic';"
Jeg prøver å få teksten til å vises på www.undervisningsbyrået.no i fonttypen "Bank Gothic".
"src: url(bank gothic);" ser ut som en tvilsom URL til en font-fil. Foreslår at du går over og sjekker at det virkelig er riktig... Kan evt. være greit å bruke en absolutt URL til testing vertfall, og med Firebug, eller tilsvarende, kan du vel også se om nettleseren virkelig får lastet ned fonten.
-
Et alternativ til iframes kan være ajax. Det er noe mer avansert, men...
Et langt bedre alternativ er å heller lære seg grunnleggende HTML, smartere PHP og enda mer grunnleggende deler som HTTP og URL.
Client-side/HTTP-caching der det passer, og en smart gjennomtenkt cache-strategi på server-siden/PHP. Når man først har forstått sånne grunnleggende muligheter, er man også langt bedre rustet til etterhvert å krydre med "Ajax" for enda bedre ytelse-opplevelse for brukerne.
Og ja, tanken om løse dette med HTML-frames er det bare å glemme med en gang. Om ikke for noen av de mange andre problemer frames fører med seg, så gjør hvertfall problemene i forhold til søkemotorer det uaktuelt for nettbutikker.
Jepp, I kinda figured that out the hard way. men hva mener du med "grunnleggende html"?
Med det mente jeg først og fremst forståelse av HTML utover navn på elementer og attributter - hva slags rolle HTML er ment, og bør, dekke for websider, og hvordan HTML passer inn, og brukes sammen med, de andre komponentene i websider.
Siden jeg kan html, jeg vil påstå at jeg er veldig flink i html, så jeg vil vite med en lite utdypelse.Jeg har registrert mange selv-utnevnte eksperter på HTML, som bare blir store spørsmåls-tegn når det kommer til tanker om det jeg skrev nå rett over...
Dette er ting som man gradvis lærer seg gjennom erfaring, hvis man holder fokus på alt hva man fortsatt kan lære, istedenfor hvor flink en mener man allerede er.
Men AJAX ser ut som løsningen, og det ser ikke vanskelig ut å implementere i min nåværende kode. Jeg syntes det var merkelig at du kommer med et "alternativ" som bare er AJAX beskrevet anerledes;)
Å bytte ut bruken av frames med Ajax-teknikker blir langt fra det samme som å kunne lage en web-side som løser ytelses-utfordringene dine, uten å ta i bruk "fancy" "løsinger" som Ajax, som da egentlig bare skyver problemene litt unna, så de ikke blir like synlig i første omgang.
Men for all, du må jo gjøre ting etter din egen beste vurdering. Så håper jeg bare at du seriøst søker etter bedre forståelse av forbedringsmulighetene her.
-
Klart det. Kan fortsette med noe sånt som dette:
if(isUploaded) { alert('Filen er allerede lastet opp!'); } else { alert('Filnavnet er ikke brukt.'); }...men mistenker da at det du egentlig trenger er å lære Javascript+DOM, så du forstår det som skjer og hvordan du kan integrere det på siden din. Og det er altså en oppgave som går utover denne tråden,
-
Må det virkelig være FTP? Blir nok veldig mye enklere hvis du kan sette opp en web-server som serverer de opplastede filene via HTTP (evt. med login).
var req = new XMLHttpRequest(); req.open("HEAD", "http://example.com/files/2B5.jpeg", false); req.send(); var isUploaded = (req.status == 200);Eksempel (ikke testet) med bruk av XHR/"Ajax" for å sjekke om filen eksisterer. Merk at det er brukt HTTP HEAD, istedenfor vanlig HTTP GET, for å få testet om filen/URL'n eksisterer uten å måte laste den ned.
-
Et alternativ til iframes kan være ajax. Det er noe mer avansert, men...
Et langt bedre alternativ er å heller lære seg grunnleggende HTML, smartere PHP og enda mer grunnleggende deler som HTTP og URL.
Client-side/HTTP-caching der det passer, og en smart gjennomtenkt cache-strategi på server-siden/PHP. Når man først har forstått sånne grunnleggende muligheter, er man også langt bedre rustet til etterhvert å krydre med "Ajax" for enda bedre ytelse-opplevelse for brukerne.
Og ja, tanken om løse dette med HTML-frames er det bare å glemme med en gang. Om ikke for noen av de mange andre problemer frames fører med seg, så gjør hvertfall problemene i forhold til søkemotorer det uaktuelt for nettbutikker.
-
Open source fanatisme vs Bedre funksjonalitet?
Ikke så vanskelig å velge. Såvidt jeg vet så er Firefox den eneste av de store nettleserne som ikke støtter h.264, så godt at MS tar litt grep her.
Sammen med Opera.
Det er ikke Open Source fanatisme, men prinsippet om at weben skal være patentfri.
At man skal måtte betale royalities for å lage en nettleser eller for å legge videoer på nett er ikke vanskelig å være imot.
Opera støtter h.264 gjennom Gstreamer.
Nei, og ja og nei.
For det første: Nei, Opera støtter ikke H.264. Installerer en Opera på f.eks Windows, vil ikke H.264 fungere.
Ja, tror du har rett i at Opera implementer video-funksjonaliteten gjennom GStreamer. Allikevel vil ikke H.264 fungere i Opera (på Windows), selv om man manuelt installerer H.264-"plugin" til GStreamer. Dette fordi Opera benytter en egen integrert GStreamer-variant.
Unntaket er på Linux-OS hvor Opera benytter seg av den "globale" GStreamer-installasjon. Hvilket da betyr at f.eks i Ubuntu, så vil Opera støtte H.264 hvis man installerer pakken for H.264-støtte i GStreamer.
Det er hvertfall dette jeg har lest fra offisielle Opera-kilder, og jeg finner ikke noe i farta som sier noe annet.
-
cvłñ: Han har nok flere alternative stilark, som det er meningen at brukerne skal få velge mellom. De fleste nettlesere har innebygd valgmulighet for dette (bortgjemt) i "Vis"-menyen.
Trådstarter: Tror du kan finne løsninger gjennom et Google-søk som dette:
http://www.google.com/search?q=alternate+stylesheet+switcher
-
Nei, men man må til med noe helt basic Javascript.
Fremgangsmåten kan illustreres så enkelt som dette:
document.getElementById('video1').addEventListener('ended', function(){ document.getElementById('video2').play(); }, false); -
XMLHttpRequest ("Ajax") støtter lasting av eksterne sider fra versjon 2 (XHR Level 2), som vertfall er støttet av Firefox og WebKit. Opera vet jeg ikke, og IE8 har en proprietær variant som i grunnen støtter det samme.
"Problemet" er at det, av sikkerhetsgrunner, kreves at den eksterne websiden spesifikt tillater at andre websider skal få laste siden.
Hvis den eksterne websiden du tenker på har satt opp tillatelse for sånn ekstern lasting (noe veldig få websider har pr. i dag), så skal det være en veldig enkel rett-frem sak for nettleseren på Iphone. Hvis den ikke har det, så har du neppe noe annet valg enn å først bruke din egen webserver til å laste den eksterne websiden og så laste den eksterne siden fra din egen webserver.
-
IE er en forferdelig nettleser. Denne oppdateringen ser ut til å gjøre den mye bedre. Håper det blir bra nok. Det er helt utrolig at MS har ventet til 2010 med å fikse den. En eneste tragedie for de mangfoldig millionene med brukere som har brukt den i så mange år.
Det er nå så (og ille nok), men IEs delvis dårlige sluttbrukeropplevelse ødelegger tross alt bare for de som bruker IE. IEs elendige støtte for webstandarder derimot, ødelegger for alle, uansett.
Heldigvis er virkelig IE9 en stor forbedringer her, selv de har langt å gå for og ta igjen alle de årene med minimal utvikling på dette området.
-
Hell yeah!
-
"WTH" er generelt en god reaksjon på IE's standard-støtte ja, men i dette tilfellet ligger ikke egentlig feilen oss IE.
Det du sender ut er rett og slett ikke HTML. I tillegg til noen små-feil har du puttet inn to elementer som ikke eksisterer i HTML4. <footer> finnes riktignok i HTML5, men <topPanel> finnes ikke i noen HTML-versjon.
I motsetning til de andre nettlesere, så velger IE å ignorere all CSS for elementer, som den ikke kjenner til. Altså blir alle CSS-reglene du setter på disse to elementene ignorert av IE, og da blir naturlig nok visningen ikke helt som tenkt.
Sørg for at siden validerer først, så vil du nok se at vertfall IE8 klarer å vise siden likt som de andre:
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fbjorntoregjerde.com%2F
De to problem-elementene bør du antagelig bare bytte ut med <div>.
NRK satser på HTML5
i Diskuter dataartikler (Tek.no)
Skrevet
Er ingen som har nevnt åpen kildekode. Åpne standarder er ikke "åpen kildekode"/"fri programvare", men to godt adskilte konsepter som på hver sin måte regnes for å ha positive egenskaper i forhold til konkurranse.
http://en.wikipedia.org/wiki/Open_source
http://en.wikipedia.org/wiki/Open_standard