Teori vs Virkelighed

Teoretisk er det et fint design-mål, at minimere brugen af overflødig HTML, og adskille præsentationen (CSS) fra indholdet på en side. Et stykke hen ad vejen kan det også lade sig gøre, da der findes semantiske elementer til mange typer af indhold. Tanken bagved er, at HTML koden kun skal bruges til semantisk betydning. I praksis er det dog svært, at adskille præsentationen helt fra indholdet.

Der i den virkelige verden mange eksempler på HTML kode, der er genereret af såkaldte Content Magnament Systems (CMS), som er fuld af fejl og overflødig brug af elementer. Det er selvfølgelig meget kritisk, men i praksis har det ikke den store betydning. Brugerne har sjældent problemer, og søgemaskinerne kan stadig indeksere siderne fint alligevel.

Det betyder dog ikke, at en optimering af kodningen ikke vil have nogen gavnlig effekt. Ofte vil det dog være op til udviklerne af et givent CMS, at få løst de problemstillinger der måtte være.

Det er kun Ií ekstreme tilfælde, at det kan have direkte negativ indvirkning i søgemaskinerne. Eksempelvis hvis et CMS har udskiftet overskrifter med div elementer, enten fordi brugeren har brugt det medfølgende wysiwyg værktøj forkert, eller fordi der er fejl i værktøjet.

WYSIWYG værktøjer

Det er de færreste som håndkoder deres artikler i dag, eller som koder deres egne hjemmesider. Vi bruger i dag CMS systemer til at levere vores indhold til internettet, og det er sjældent vi selv programmere dem.

Det kan ske, at wysiwyg værktøjer i CMS systemer har fejl og mangler, som gør at den HTML de levere, ikke er helt efter bogen. Heldigvis er det ofte i småtingsafdelingen, og altså ikke noget som bør få større konsekvenser i søgemaskinerne – eller for den sags skyld – skærmoplæsere.

I nogle af de værste tilfælde, der kan det være, at et WYSIWYG værktøj tillader indsættelse af såkaldte (non-breakable spaces). Eller de kan bruger br elementer til at adskillelse af tekstafsnit, i stedet for at afslutte afslutte det gamle afsnit og begynde et nyt (</p> og <p>). Udfordringen kan være, at fortolke brugerens brug af linjeskift. Hvad skal der eksempelvis ske, hvis en bruger indsætter flere linjeskift? Det korrekte vil selvfølgelig være, at det ikke skal være muligt at lave større mellemrum imellem afsnit, ved at indsætte linjeskift. Man kan i stedet indbygge en "margin" eller "padding" funktionalitet, men så er editorens også ved, at blive for kompliceret for gennemsnits-brugeren. Man kan så vælge et kompromis, og alligevel indføre br elementet. Rent design-næssigt kan det dog være et problem.

Nogle værktøjer bruger måske endda div i stedet for p elementer, hvilket vil være i blandt de større fejl. Det sjove er dog, at søgemaskinerne ikke har større problemer med at forstå tekst i div elementer. Det kan dog give andre udfordringer, og er selvfølgelig et åbenlyst semantisk problem.

Før i tiden opstod problemet ofte, når man forsøgte at erstatte tabel-baserede layouts med div-baserede. I dag opstår problemet nok fordi, at det kan være en udfordring at programmere WYSIWYG værktøjer til browsere, da der kan kan være forskelle på, hvordan de enkelte browsere opføre sig. Dertil kommer udfordringerne omkring den nye HTML5 document outline og nye sektions elementer. Det er dog langt fra umuligt at levere gyldig-HTML, og vi kan håbe på, at disse værktøjer med tiden vil blive bedre.

Ofte vil det ikke kun være WYSIWYG som er problemet, men også den øvrige kode som leveres af CMS systemet. Det kan enten være fejl i et template, eller det kan være fejl i selve CMS systemet.

Fortæl os hvad du tænker: