Vanliga misstag inom webbuteckling

Note: this article is a Swedish translation of Web development mistakes, Redux.

När jag besöker en webbplats gillar jag att ta en titt under ytan och se hur koden är konstruerad, särskilt om den tillhör en konkurrent eller en presumtiv kund. Det kan ge en ganska bra bild av kompetensnivån hos den som har byggt webbplatsen. Tyvärr får jag väldigt ofta se riktigt skräckinjagande exempel på hur man inte bör göra.

Webben är full av webbplatser som använder ruskigt ogiltig, ostrukturerad och otillgänglig kod. Även webbplatser byggda av erfarna webbutvecklare, som borde veta bättre, innehåller ofta mängder av problem. Ingen är perfekt – jag har själv gjort mig skyldig till många felaktigheter genom åren. Därför har jag gjort en lista med misstag som är alldeles för vanliga att se på webben. Jag hoppas att den kan hjälpa åtminstone någon att undvika en del onödiga misstag.

Varje misstag beskrivs först, och följs sedan av en förklaring av varför det är ett misstag, och hur man bör göra i stället. I många fall länkar jag också till kompletterande information.

DOCTYPE-förvirring
DOCTYPE-deklaration saknas helt, är felaktig, eller ligger på fel ställe. Jag har till exempel sett HTML 4.0 Transitional användas i <frameset>-filer och i dokument som innehåller XHTML, DOCTYPE-declarationer som ligger efter den öppnande <html>-taggen, och ofullständiga DOCTYPE-deklarationer.
Varför? Av två anledningar. För det första är en DOCTYPE-deklaration obligatorisk, enligt W3C:s specifikationer för HTML 4.01 och XHTML 1.0. För det andra använder moderna webbläsare DOCTYPE-deklarationen för att avgöra vilket visningsläge de ska använda. För att få mer enhetliga resultat i olika webbläsare, särskilt när man använder CSS, bör man se till att de använder sitt “Standardläge”. Mer information om detta, som kallas “DOCTYPE switching”, finns i Fix Your Site With the Right DOCTYPE! och Activating the Right Layout Mode Using the Doctype Declaration.
<span>-mani
Ett vanligt sätt att styra hur något ser ut med hjälp av CSS är att omge det med ett <span>-element och ge det elementet ett class-attribut. De flesta har nog sett exempel som <span class="heading"> och <span class="bodytext">.
Varför? Det är i det flesta fall helt onödigt, har inget semantiskt värde, och skräpar bara ner koden. Använd rubrikelement (<h1> - <h6>) för rubriker, styckeselement (<p>) för stycken, och använd HTML-listor för att skapa listor. Använd CSS för att styra hur elementen presenteras. Om nödvändigt, ge elementen class- eller id-attribut.
(för mycket) Visuellt tänkande
Att behandla webben som WYSIWYG genom att börja med att fokusera på design och layout i stället för att tänka på struktur först, och utseende senare.
Varför? De flesta som använder webben kan se, men alla kan det inte. Dessutom är det inte möjligt att göra webben helt WYSIWYG. Det kommer alltid att finnas skillnader så länge folk använder olika webbläsare, operativsystem, skärmstorlekar, skärmupplösningar, fönsterstorlekar, färgkalibrering och textstorlekar. Webben är inte tryck eller TV. Gör din design flexibel.
Brist på semantik
Icke-semantisk uppmärkning. Att basera sitt val av HTML-element på hur de flesta grafiska webbläsare är förinställda på att visa det, i stället för att utgå ifrån vilken betydelse elementet har.
Varför? Detta misstag är nära besläktat med “<span>-mani”. Båda misstagen innebär att man inte använder HTML-element på rätt sätt för att ge sitt innehåll betydelse. Utan semantisk HTML är det mycket svårare för icke-grafiska webbläsare och sökmotorrobotar att tolka innehållet. Semantisk HTML är också generellt sett enklare att styra utseendet på med hjälp av CSS.
Teckenkodningsproblem
Att ange en teckenkodning i HTTP-headern som servern skickar, och använda en annan i själva dokumentet. Detta kan förvirra webbläsare och få dem att visa innehållet på fel sätt.
Varför? Därför att man vill att alla besökare ska kunna läsa innehållet.
Dåliga alt-attribut
Saknas helt eller är värdelösa. <img>-element som saknar alt-attribut kan man hitta miljarder av på webben. Inte riktigt lika vanliga är värdelösa attributvärden som “spacer GIF used to make the layout look good”, “big blue bullet with dropshadow”, och “JPEG image, 123 KB”. Kom ihåg att alt-attributet är obligatoriskt för <img> och <area>-element.
Varför? Alt-attributet är obligatoriskt, och utan det kommer eventuell information i bilden att vara osynlig för skärmläsare, icke-grafiska webbläsare, sökmotorrobotar och besökare som har bilder avstängda i sin webbläsare. Observera att den alternativa texten ska vara relevant. Ange inte alternativ text för dekorativa bilder eller för bilder som används enbart för layout. För sådana bilder ska en tom sträng anges: alt="".
Ogilitga id- och class-attribut

Att ha flera id-attribut med samma värde i ett och samma dokument, eller att använda otillåtna tecken i id- och class-attribut och CSS-selektorer.

För CSS gäller detta (CSS 2.1 Syntax and basic data types):

In CSS 2.1, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [A-Za-z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit.

För HTML gäller detta (Basic HTML data types):

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (“-“), underscores (“_”), colons (“:”), and periods (“.”).

Varför? Webbläsare som följer specificationerna kommer inte att visa dokumentet som förväntat. Om ett dokument har flera element med samma id-värde är det troligt att eventuella JavaScriptfunktioner som använder det värdet kommer att sluta fungera eller bete sig oförutsägbart.
Webbläsaravkänning
Att använda skript, antingen på servern eller i webbläsaren, för att försöka känna av vilken webbläsare besökaren använder, och skicka eller utföra webbläsarspecifik kod. Detta ger väldigt ofta fel resultat på grund av till exempel helt nya webbläsare, uppdaterade webbläsare eller webbläsare som utger sig för att vara någon annan (Opera är förinställd på att göra detta).
Varför? Det skapar onödig komplexitet, och kommer att sluta fungera förr eller senare, om man inte lägger ner orimligt mycket tid och energi på att underhålla skriptet. Genom att utveckla med webbstandarder kan man använda samma kod för alla webbläsare.
Inga enheter i CSS
Längdvärden (horisontella eller vertikala mätvärden) kräver enheter i CSS, utom när värdet är noll. Det är inte som i HTML, där man kan skriva width="10". I CSS måste man skriva width:10px; (eller vilken enhet man nu använder).
Varför? Det fungerar inte i webbläsare som följer specifikationen.
Webbläsarspecifik CSS
Rullist-styling, expressions, filter med mera. CSS som bara fungerar i Internet Explorer.
Varför? Ogiltigt, och fungerar bara i en specifik webbläsare. Om du absolut måste använda IE-specifik CSS, lägg den i en separat fil och använd conditional comments, eller något annat sätt, för att se till att bara IE ser de ogiltiga CSS-reglerna.
JavaScriptberoende
Att göra en webbplats beroende av JavaScript. Fler än många vill tro använder en webbläsare som saknar stöd för JavaScript, eller har stängt av JavaScript i sin webbläsare. Aktuell statistik (Browser Statistics at W3Schools, TheCounter.com) tyder på att det rör sig om 8-10 procent av webbanvändarna. Sökmotorrobotar har heller inget vidare stöd för JavaScript, även om det finns rapporter om att Google jobbar på JavaScriptstöd för deras GoogleBot. Om din webbplats kräver JavaScript för att man ska kunna navigera i den, förvänta dig ingen bra placering hos sökmotorer.
Varför? Otillgängligt och dåligt för webbplatsens sökmotorplacering.
Flashberoende
Att anta att alla har Flash installerat. Alla har inte det. Och de flesta sökmotorrobotar har det inte (det finns rapporter om att Google har börjat experimentera med att indexera Flashfiler, men själva rekommenderar de fortfarande att allt innehåll och all navigering finns i HTML-filer), så om din webbplats, eller webbplatsens navigering, kräver Flash för att fungera, kommer den inte att få någon bra sökmotorplacering.
Varför? Otillgängligt och dåligt för webbplatsens sökmotorplacering. Jag säger inte att man inte ska använda Flash över huvud taget, bara att man ska använda det med förnuft.
Text som bild
Att göra bilder av text, och inte ha ett mer tillgängligt alternativ (alt-attribut). Det gör inte bara att det tar längre tid för besökarna att ladda sidan, det gör det också omöjligt för alla besökare att kopiera texten, och för de flesta att försora den.
Varför? Otillgängligt, tar längre tid att ladda, dåligt för webbplatsens sökmotorplacering.
Dåliga formulär
Otillgängliga och svåranvända formulär. Använd <label>-, <fieldset>- och <legend>-elementen, och använd inte någon “Rensa”-knapp.
Varför? Otillgängligt, försämrad användbarhet. Läs Creating Accessible Forms, Better Accessible Forms och Reset and Cancel Buttons för mer information om hur man skapar tillgängliga och användbara formulär.
Gammaldags HTML
Flera nivåer av tabeller-i-tabeller, osynliga GIF-bilder, HTML som används för presentation. Så vanligt att det nästan inte behöver nämnas.
Varför? Ökad komplexitet, onödigt mycket HTML-kod, långsamt, otillgängligt, dåligt för webbplatsens sökmotorplacering.
IE-fixering
Att bygga för Internet Explorer för Windows i första hand, och sedan, om tid finns, anpassa för andra webbläsare och plattformar.
Varför? Tar längre tid och uppmuntrar dålig kodning. IE/Win är ökänt för att acceptera slarvig och ogiltig HTML som fungerar dåligt i andra webbläsare. IE/Win hanterar också giltig HTML, som fungerar i alla webbläsare, så genom att använda giltig HTML blir alla webbläsare nöjda och man sparar tid. Se även The IE Factor.
Ogiltiga HTML-attribut
Att använda förkastade eller webbläsarspecifika attribut som till exempel marginwidth, leftmargin, language, height för <table>-element och border för <img>-element.
Varför? Ogiltigt och onödigt. Använd CSS i stället. Använd type, inte language, för att ange vilket skriptspråk (nästan alltid JavaScript) som används i <script>-element.
Okonverterade et-tecken (&)
Många URI:er innehåller långa querysträngar med okonverterade et-tecken (&). Det är ogilitgt, och kan leda till problem. Et-tecken måste skrivas som &amp;.
Varför? En förklaring, med tillhörande exempel, finns i Ampersands and validation.
Ramar (frames)
Användandet av ramar för att dela webbläsarfönster i flera av varandra oberoende dokument.
Varför? Först och främst vill jag säga att det finns tillfällen när ramar kan vara bra. Två exempel är intranät och vissa webbapplikationer. För publika webbplatser har ramar för många tillgänglighets- och användbarhetsproblem. Problem med bokmärkning, utskriftsproblem, svårigheter att länka till en undersida, och problem med sökmotorrobotar är några av nackdelarna med att använda ramar.
Otillgängliga datatabeller
Tabeller som innehåller tabulär data men är uppmärkta som om de vore layout-tabeller, dvs utan att använda några av de många element och attribut som är till för att göra tabeller strukturerade och tillgängliga.
Varför? Skärmläsare och andra tillgänglighetsteknologier har svårt att tolka en datatabell på ett begripligt sätt om den inte är korrekt uppmärkt. Flera länkar till artiklar som beskriver hur man märker upp datatabeller finns i artikeln A table, s’il vous plaît, hos the Web Standards Project.
Divitis och classitis
Nära besläktade med <span>-mani. Att lägga till onödiga <div>-element och class-attribut.
Varför? Se “<span>-mani” och “Brist på semantik”.
För bred låst bredd
Gör inte en layout med låst bredd för bred. Observera att jag inte tänker ge mig in i debatten om låst eller flexibel bredd här.
Varför? Om den angivna bredden är bredare än besökaren får plats med på sin bildskärm tvingas besökaren skrolla i sidled, vilket är mycket dåligt för användbarheten.
Vaga och/eller utseendekopplade class- och id-namn
Att ge en class eller ett id namn efter dess utseende i stället för efter dess funktion.
Varför? Att göra det är att be om förvirring när man ska ändra design eller layout. En klass som heter largeblue kan komma att göra text liten och röd, och ett element med id="leftcol" kanske placeras till höger i den nya layouten.
Ingen bakgrundsfärg
Att inte ange någon bakgrundsfärg för <body>-elementet.
Varför? Alla har inte samma förinställda bakgrundsfärg i sin webbläsare.
Icke välformulerad XHTML
Att använda XHTML som inte är välformulerad (well-formed).
Varför? Om man skickar XHTML som application/xhtml+xml (vilket man bör göra) visar strikta webbläsare, som Opera och webbläsare baserade på Mozilla, ett felmeddelande i stället för dokumentet om det innehåller icke välformulerad XHTML.

Det är en ganska lång lista med saker att se upp med. Naturligtvis är det bättre ju fler av dessa misstag man undviker att göra. Om det är någon tröst har jag gjort mig skyldig till att göra många av dessa misstag genom åren. Förhoppningsvis kan den här listan hjälpa andra att göra färre misstag i framtiden.

Posted on September 6, 2004 in Web Standards

Comments

  1. Eftersom jag följer dina tips.. så tittade jag lite i din kod.. kom inte längre än till tredje raden innan jag började undra…

    Är din sida verkligen på engelska? :-)

  2. September 28, 2004 by Roger Johansson (Author comment)

    Hehe ;)

    Jodå, huvudsakligen är innehållet på engelska. I artiklar som är på svenska har jag angett det i koden där det som är på svenska börjar.

  3. Hej!

    Denna artikel länkar jag idag som komplement till min egen doctypeinfo ;)

    Vi blir fler och fler kul

    mvh/Lena

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.