Kode-venner kritiserer HTML5

HTML5 Super Friends, som inkluderer Jeffrey Zeldman fra A List Apart og CSS-eksperten Eric Meyer, er overvejende glade for HTML5, men der er skønhedspletter på specifikationen.

En række webeksperter blander sig nu i debatten om den kommende version 5 af HTML-standarden. Gruppen på ni består af blandt andre design-guruen Jeffrey Zeldman, kendt fra bloggen A List Apart, og Eric Meyer, som er ekspert i CSS.

HTML5 Super Friends, som gruppen kalder sig, er positive over for udkastet til den kommende standard, men der er også en række knaster, som gruppen har peget ud.

Det gælder blandt andet valgfrihed mellem HTML- og XHTML-dialekter, hvor det skal tydeliggøres, at begge valg er lige gode. Det skal også sikres, at XHTML kan valideres og at World Wide Web-konsortiets syntakstjekker også kan håndtere XHTML 5.

Gruppen er også skeptiske over for en række nye HTML-elementer. Det gælder blandt andet article- og section-taggene, som næsten er identiske. Her foreslås det, at article-tagget droppes og section-tagget udvides med nye attributter. Og så er de ikke glade for, at footer-elementet er mere restriktivt end header-elementet.

HTML5 Super Friends har heller ikke meget tilovers for elementerne hgroup, aside og dialog, som efter deres mening kan dækkes af andre tags.

Det grafiske tag canvas får den opadvendte tommelfinger, men tilgængeligheden (accessibility) er for ringe, lyder holdningen.

Resten af kommentarerne er mest i småtingsafdelingen, men det falder super-vennerne for brystet, at udkastet anbefaler, at div-tagget kun anvendes som en sidste nødløsning. Gruppen mener, at et div-tags class-attribut stadig er en væsentlig kilde til semantisk forståelse i mange sammenhænge.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (32)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Kristian Thy

Uden at have sat mig yderligere ind i sagen vil jeg tro at man opfordres til at bruge semantisk meningsfyldte tags hvis de findes, fremfor en generisk div. Det er i hvert fald den tolkning der giver mest mening for mig sammenholdt med artiklens omtale af ting som header, footer, section osv.

  • 0
  • 0
#3 Rasmus Kaae

Er der nogen der kan fortælle mig hvorfor man bør holde sig langt væk fra tabeller i sine designs? Jeg har bestræbt mig på at gøre det i mine seneste designs - dog uden at kende den egentlige begrundelse :-)

  • 0
  • 0
#5 Rasmus Kaae

Jaeh, det kan man læse ind i navnet - men fortæl mig så hvilke tags der (baseret på deres navn) ligger op til at dele ting op i søjler og kolonner. Eller er det måske her jeg går galt i byen - fordi jeg lader html dele indholdet fremfor css?

Hverken span, div, eller p ligger op til at kunne placere indhold.

  • 0
  • 0
#6 Christian Nobel

Jeg kan heller ikke lige fange hvorfor man ikke skal bruge tabeller.

I årevis har vi været tudet ørene fulde over frames var noget værre noget, nu er det åbenbart tabeller den er gal med.

Og tabeller er altså meget mere end fodboldresultater - faktisk giver tabeller sammen med CSS mulighed for at style siden ganske glimrende, og vel at mærke sådan at siden skalerer fornuftigt i forhold til vinduesstørrelse.

/Christian

  • 0
  • 0
#7 Hans-Michael Varbæk

Søjler og kolonner, ja der er jo frames og iframes selvom det bliver personligt sjældent særligt godt eller pænt synes jeg.

<

table> kan stadigvæk bruges og kan også stadigvæk bruges til text. Det er faktisk slet ikke så svært..

Dette er kun et eksempel på hvor let det er at skrive en side i HTML: hxxp://guides.intern0t.net/ Kig på kildekoden og se hvor let det er beskrevet, det bliver næsten ikke nemmere end det. (Det er dog også en meget simpel side :-P

  • 0
  • 0
#8 Søren Koch

Enig. Jeg kan heller ikke se hvorfor tabeller er så slemme. Jeg har i årevis også brugt dem kombineret med css til side layout design og har gode erfaringer med det. Siderne bliver ganske overskuelige og brugerne har et ensartet design at se på hvilket mindsker fejlbrug.

Min eneste anke er at IE ikke håndterer klasse attributter til en tabel-header særligt godt (for eksembel centrerer den ikke en tabel hvis tabellen er inden i en gruppe og man samtidig bruger en 'class i headeren af tabellen (klasse inkluderer ikke noget med centrering i det hele taget)

  • 0
  • 0
#9 Per Sikker Hansen

Tabeller er ikke "slemme", men de giver sjældent semantisk mening.

Det der ligger i tabeller er at de ganske vidst tjener opgaven at vise data frem for en almindelig browser meget fleksibelt og pænt, med forholdsvis lidt CSS indblandet. Problemet med denne model er at når noget andet end en almindelig browser skal læse det, fx en webservice der skal trække et tekstelement ud fra et andet site (dette kunne fx være en nyhedstjeneste der ikke har et RSS feed, eller en personlig startside, eller noget andet) - så giver det bedre mening at få webservicen til at crawle ind i DOM'en og hente indholdet af

ud, end det giver mening at crawle igennem et HTML-træ og skulle finde tabelcellen der hedder.

Dette er bare ét eksempel, der kunne sagtens være flere, lavpraktiske situationer også. Generelt er vi ude i at internettet generelt og HTTP og HTML specifikt, bliver brugt til rigtig, rigtig meget. Jo bedre vi kan strømline markup'en og gøre den semantisk forståelig, des bedre kan vi integrere med hinandens systemer. Dér er tables som en design-løsning en hæmsko, omend ikke en stopklods.

  • 0
  • 0
#12 Jakob Skjerning

I starten var det begrænset, hvad der kunne gøres rent visuelt med HTML på en webside. På et tidspunkt (før årtusind-skifte?) kom en person på idéen med at anvende et eksisterende HTML-tag, table, til at lave mere interessante layouts.

Metoden var dog en midlertidig løsning - et hack, der hurtigt blev meget populært, da det gav designere en hidtil uset kontrol over udseendet af websiden. Den langsigtede løsning, CSS, var allerede på det tidspunkt under udvikling, men det tog desværre en del år før browser-understøttelsen var god nok til dagligt brug.

Nu til dags er der sjældent grund til at bruge tabeller som den primære måde at layoute sine websider på. Der er en række håndgribelige fordele ved at skifte til den standards-baserede, semantiske og strukturede måde at gøre tingene på, og der er et væld af ressourcer på internettet der forklarer hvorfor. Et udvalg af dem:

Eller hvis du bare vil have the executive overview: http://shouldiusetablesforlayout.com/ ;)

  • 0
  • 0
#14 Per Sikker Hansen

Begge dele er lige læsbare i min Firefox, uanset hvor langt jeg zoomer ind. Derudover har det ikke noget med semantik at gøre, hvilket er det primære argument for at bruge CSS.

Et andet argument for at bruge CSS er også, at CSS fungerer bedre og giver mere kontrol over designet end en table. Det altoverskyggende argument for at bruge tables til design idag er, at det går stærkt at producere - ligesom Visual Basic ;)

  • 0
  • 0
#15 Rasmus Kaae

tabeller kan vel ikke være et hack for layout, det er noget man altid har brugt - også i andre sammenhæng. bl.a. findes der tabel-layout til de fleste programmeringsbiblioteker m.m.

Jeg synes stadig jeg savner et sagligt argument for at tabeller bør dø til fordel for andre semantisk-misvisende tags.

  • 0
  • 0
#16 Jakob Skjerning

Tak Christian, det er et par gode eksempler, der fint viser at et tabel-baserede layout fylder mere (omtrent 140% mere) end det div-baserede.

Det er dog ærgeligt, at det div-baserede layout ikke er lavet på samme vilkår som det tabel-baserede og derfor ikke ændrer bredde, når man bruger text-zoom. Det kunne dog have været afhjulpet ret let som dokumenteret på http://www.456bereastreet.com/archive/200504/fixed_or_fluid_width_elastic/ og siger altså mere om den specifikke implementation end om div-baseredde layouts generelt.

  • 0
  • 0
#17 Jakob Skjerning

bl.a. findes der tabel-layout til de fleste programmeringsbiblioteker m.m.

Det gør der skam også i CSS - desværre er det kun IE8, der implementerer det lige pt.

Jeg synes stadig jeg savner et sagligt argument for at tabeller bør dø til fordel for andre semantisk-misvisende tags.

Det tror jeg heller ikke du får. Tabeller er helt fine, når de bruges semantisk korrekt; navnlig til at indeholde data på tabelform.

  • 0
  • 0
#18 Christian Nobel

Begge dele er lige læsbare i min Firefox, uanset hvor langt jeg zoomer ind.

Sjovt nok, for hvis jeg zoomer ind til 250%, så tilpasser bredden sig på tabellen, så det stadig er rimeligt pænt, det gør det ikke i CSS eksemplet.

Derudover har det ikke noget med semantik at gøre, hvilket er det primære argument for at bruge CSS.

Vil du være venlig at uddybe hvad du forstår ved semantik i denne kontekst.

Et andet argument for at bruge CSS er også, at CSS fungerer bedre og giver mere kontrol over designet end en table.

Det kan man så diskutere - hvis man også gerne vil give mulighed for at svagtseende kan bruge siden ved at zoome meget ind, så er jeg ikke enig.

Herudover mener jeg det er lidt forvrøvlet at tale om tabeller kontra CSS, for det ene udelukker ikke det andet.

/Christian

  • 0
  • 0
#20 Johan Færch

En af de absolut væsentligste pointer med at adskille indhold fra design: Indholdet ligger på siden mens designet kan lægges eksternt i en CSS-fil. Har du en site på 100 sider med tabeldesign på hver eneste side ville jeg nødig ændre layout på denne. Har du det der imod i din CSS-fil vil du kunne lave ændringer/fejlretninger over hele din site på én gang i løbet af ganske få minutter. Og der er ikke noget designmæssigt du kan gennemføre med tabeller som ikke kan gøres (bedre?) med CSS! På http://www.keeptrack.nu benyttes udelukkende CSS til designet. Selvfølgelig bruges tabeller - men kun til data som på http://www.keeptrack.nu/dk/Webskema.html

  • 0
  • 0
#22 Rasmus Kaae

Den side du henviser til er meget primitiv og ikke nødvendigvis et godt eksempel.

Jeg er med på tanken om at adskille indhold fra layout - men i min verden sker det på et helt andet plan. De fleste hjemmesider er drevet af en datakilde, f.eks. XML eller en database. Her er layout og præsentation HTML+CSS (ja, hele pakken).

De fleste hjemmesider jeg har stødt på er bygget op omkring en art CMS, hvilket betyder at der er samme adskillelse som nævnt ovenfor. At indføre en ændring som du hentyder til vil her blot være et spørgsmål om at ændre i skabelonen for siden (det være sig HTML eller CSS).

Tanken om at HTML skulle være et format til opbevaring af data burde være begravet hos de fleste - det er i hvert fald et format der skaber flere begrænsninger end muligheder.

  • 0
  • 0
#23 Kenneth Priisholm

@Rasmus: Jo, i HTML-sammenhæng er brug tabeller til layout et hack, der, præcis som Jakob antyder, opstod dengang browserne endnu ikke kunne håndtere CSS fornuftigt.

Tabel-baserede layouts har flere ulemper:

  • De er "tunge", hvilket er kedeligt i en tid hvor flere og flere browser nettet via telefon og mobil-opkobling.
  • De er besværlige at vedligeholde og re-designe da form og indhold er ubehjælpeligt filtret sammen.
  • De er ikke semantisk korrekte, hvilket måske ikke har betydning for menneske-øjne men i høj grad har det for maskiner - skærm-læsere, web-crawlere etc.

Det drejer sig i bund og grund om data-kvalitet og den opnås bedst når form og indhold og helst også funktion er pænt adskilt.

Bevares; der har længe været behov for semantiske forbedringer til HTML standarden, hvorfor folk har tyet til mikroformater og andre krumspring, men det råder HTML 5 udmærket bod på. Så mangler vi så bare lige at den browser, der stadigvæk dominerer markedet også understøtter standarden fornuftig...

  • 0
  • 0
#24 Rasmus Kaae

... men det er vel også et hack at man skal formatere sine hjemmesider så de er læsbare for skærmlæsere, webcrawlere, m.m.

Der var engang noget der hed RDF der netop kunne bruges til at pege data-læsere i den rigtige retning. Det må da være den rigtige vej, fremfor at hacke information ind i HTML-filerne.

  • 0
  • 0
#25 Christian Nobel

Hvorledes mener du at dette http://peecee.dk/uploads/092009/Scr... er dårligere læsbart end dette: http://peecee.dk/uploads/092009/Scr... ?

Interessant, for det ser altså helt anderledes ud når jeg ser på det i FF 3.0, der er CSS eksemplet krampet sammen på midten.

Der er ikke noget problem i Opera, så det ligger åbenbart i FF 3.0's fortolkning af CSS??

Men som også sagt tidligere, jeg mener bare at det er lidt hurtigt at give tabeller dødsstødet, og at tabeller ikke udelukker CSS og visa versa - det hele afhænger af løsningen.

/Christian

  • 0
  • 0
#26 Kenneth Priisholm

Fraværet af layout-specifikke tags og attributter til fordel for "clean", semantisk markup er ikke et hack - det er jo bare ren data...

Mikroformater kan man vel godt kalde en slags hack og hvis man kan slippe for den slags "semantik-boosts" er det selvfølgelig at foretrække, men de er IMHO ikke så decideret skadelige for data-kvaliteten som nestede tabeller, font-tags, etc. De bliver forhåbentlig overflødige efterhånden som de nye standarder vinder frem og modnes.

RDF var og er stadig ganske rigtig en af flere standarder, der skal booste semantik og "findability" på nettet, men det bruges kun sparsomt - har selv været knyttet til et projekt hvor det blev implementeret og vedligeholdt men aldrig brugt. Idéen er der jo ikke noget galt med, men der er bare den hage ved det, at når de færreste sites og services benytter teknologien kan den heller ikke udnyttes til fulde og så må man ty til almindelig web-crawling. Og det er så her, det er afgørende om man opmærker sine data nogenlunde semantisk korrekt - i en "shallow" struktur med et fornuftigt header-hieraki, etc.

  • 0
  • 0
#27 Michael Lykke

Der er mange årsager til at brugen af tabeller og font-tags til layout burde forbydes ved lov! Først og fremmest fordi det ganske enkelt er unødvendigt at benytte de ting for at lave layout og fordi det er et hack som ikke burde have været brugt de sidste 8-10 år.

Grunden til font tags er en rigtig dårlig idé er at det gør det umuligt at lave hurtige ændringer til dit layout. Hvis du ahr et website der består af 50 siders indhold som alle benytter font tags hvert eneste sted der skrives tekst så skal du rette hundredevis af steder for at ændre tekst-størrelsen, fonten eller farven hvorimod du med CSS nøjes med at rette op til et par steder afhængig af om det både er dine paragraphs og headers der skal rettes. For det andet så vil du have sider fyldt med lange font tags i stil med - Forestil dig den tag sat ind på ens ide 50 gange eller mere og se så hvor meget ekstra der fylder i forhold til at du i din css fil bare skriver: p {font-family: Verdana, Arial, Helvetica; font-size: 12pt; color: #999999;} Når man så samtidigt sørger for at ligge alle sine CSS tags i en seperat fil så bliver de cachet og skal derfor ikke loades hver gang, hvilket inline font tags skal.

Tabeller skal kun bruges til tabulære data - Hele ideen med HTML er at lave MARKUP af dit indhold, IKKE layout! Dvs. du skriver tags omkring indhold for at definere hvad er en header, footer, indhold, menu, links etc. Derefter benytter du så CSS til at styre layoutet med. Hele idéen med dette er at det gør det ekstremt nemt at ændre siden layout, men gør det samtidigt også ekstremt nemt at lave mange versioner af det samme indhold til print, mobiltelefoner, computere, skærmlæsere, søgemaskiner etc. Netop fordi dit layout defineres af CSS og ikke selve HTML'en så er det kun et spørgsmål om at loade det passende stylesheet for at fjerne alle menu'er og andet irellevant når man skal printe en side og på samme måde kan du have et stylesheet der kun viser der nødvendige indhold når siden skal ses på en mobiltelefon. Hvis du gør det samme med tabeller så vil du ofte være tvunget til at lave flere versioner af siden for hver platform der skal understøttes.

Forestil dig du har en typisk tabel-designet side med indholdet spredt ud over alle mulige tabeller i mange niveauer. Hvis du nu fx. har en stump indhold liggende i en TD et sted i koden og du nu vil have dette indhold vist i modsatte side og 300 pixel længere oppe så skal du til at rykke rundt i dine tabeller, flytte indholdet, lave nye tabeller osv. Hvis du derimod har nøjes med at lave semantisk markup og benyttet bl.a. div lag til at pakke ting ind så kan du via et par enkelte linier css vælge at formatere indholdet fuldstændig anderledes inklusiv at vise det et HELT andet sted end hvor det er indsat på siden.

Samtidigt er der masser af andre årsager til at tabeller er en dårlig idé - De er væsentligt tungere at loade for en browser, mange browsere kræver at HELE tabellen er loadet før den kan vises og dine sidder fylder mere dvs. du spilder mere båndbredde på at servere indholdet.

Samtidigt er DIV/CSS væsentligt bedre i forbindelse med SEO. Fordi din HTML ikke er fyldt med layout men kun indhold så kan søgemaskinerne nemt læse og indeksere dit indhold og da mange søgemaskiner vægter indhold ud fra dets placering på siden, så vil du samtidigt have yderligere en fordel med DIV/CSS. Du kan med DIV også vælge at placere alt det vigtige indhold øverst i selve filen til brug af søgemaskinerne uanset om du rent layoutmæssigt ønsker at vise det nederst eller et andet sted.

Hvis du samtidigt tjekker koden på forsk. store websites så vil du se at de fleste faktisk har forstået konceptet for længe siden. Prøv bare at tjek sider som tv2.k, dr.dk, berlingske.dk, microsoft.com osv. De benytter alle DIV/CSS til at lave deres layout og adskille design fra indhold og vi snakker om sider der har millioner af besøgende hver dag så kravet om et robust layout er absolut i højsædet da det ses af mange forsk. mennesker.

Personligt synes jeg faktisk det er uprofessionelt hvis man lever af at være webudvikler og ikke for længst er gået over til at benytte DIV/CSS osv. Tabeller er noget vi brugte i de tidligere dage af internettet før CSS kom på banen, så vi er tilbage i halvfermserne og det er trods alt 10 år siden. Problemet er nærmere at folk simpelthen ikke udvikler sig og følger med i den udvikling der er - De færreste brokker sig og stritter imod når man går fra statisk websider til dynamiske og fra access databaser til SQL server, MySQL og lign. Men når det så kommer til at "kode" semantisk korrekt HTML og bruge værktøjerne som de er tænkt så er der en flok der bare står af. Kom ind i kampen!

Tabeller skal kun bruges i den situation hvor der er tale om tabulære data - Det er hvad tabeller er beregnet til og hvad de er gode til. Det handler jo ganske enkelt om at bruge det rette værktøj til opgaven og når det kommer til layout så hedder det semantisk markup, div og CSS og IKKE tabeller og font tags.

Der er mange flere årsager til at benytte DIV/CSS - Dem kan man alle finde ved en simpel søgning på Google.

  • 0
  • 0
#32 Kenneth Priisholm

@Rasmus:

<

div> elementer antyder rent semantisk en inddeling af en web-side i sammenhængende enheder, f.eks. en artikel, en kommentar, en sidebar eller lign. - altså en sammenhængende mængde data, mens en, der ville være alternativet i et tabel-baseret layout, antyder een stump data i en horisontal række af vertikalt sammenlignelige enheder som f.eks. en tabel over adresser med gadenavn, postnummer, bynavn, etc.

Sidstnævnte giver naturligvis kun semantisk mening hvis det rent faktisk er tabulære data, der listes i rækker og kolonner og ikke hvis det er et design-grid til layout af side-elementer.

Som tidligere nævnt er det ikke af større betydning for en websides udseende men af stor betydning for en screen-reader eller, hvad der nok er vigtigere for de fleste websites, en "dum" web-crawler, der forsøger at udtrække mening fra et website vha. header-niveauer, block-quotes etc.

Man kan helt klart også overdrive brugen af

<

div> elementer, nested i n* niveauer - det har sågar et navn, "divitis". Det kan også undertiden være svært at danne sig et overblik over de semantiske sammenhænge på en side når man ser på en kode med

<

div> elementer, hvis id'er måske ikke er navngivet forklarende eller der ikke på anden måde er dokumenteret fornuftigt til den stakkel, der skal vedligeholde eller videreudvikle. Derfor er HTML 5 også en på mange måder kærkommen forbedring; i første omgang kvalitativt, da de nye tags giver perfekt mening rent semantisk for både mennesker og maskiner men også kvantitativt, da det sandsynligvis vil medføre "slankere" websider.

Skulle man have lyst til at give sine kreationer et semantisk reality-check kan man prøve W3C's "Semantic data extractor", http://www.w3.org/2003/12/semantic-extractor.html - enjoy! :)

  • 0
  • 0
Log ind eller Opret konto for at kommentere