Mediascreen » webbstandarder

Validering av HTML5

Marcus — Wed, 22 Dec 2010 16:01:32 +0000

Jag har funderat ett tag på en försiktig övergång till HTML5 som min default standard. Det finns egentligen inget som hindrar en ett byte av doctype och användning av exempelvis data-attributet och placeholders för inputs. Det som har fått mig att tveka är HTML5′s slappa syntax. Validering kan ge en stor tidsbesparing när man letar konstiga layoutbuggar. Att först kunna utesluta felaktigt nästlade element gör att man snabbt hittar slarvfel. Vanlig validering av HTML5 ger inte den möjligheten eftersom många saker som kan ställa till oförutsedda problem numera är formellt korrekta.

Jag hade hoppats på att w3c’s validator så småningom skulle få ett strikt (XML) läge för de som föredrar hårdare validering, men det verkar som om någon annan hunnit före. HTML Lint kan bland annat kolla så att alla element är stängda, att indenteringen är snyggt gjord och att alla attribut har citattecken. Är en ganska ny tjänst men verkar fungera bra. Jag tror dessutom att det kommer fler liknande tjänster i takt med att fler går över till HTML5.

One Web Principle – missförstånd och tolkningar

Marcus — Sun, 08 Jul 2007 20:54:48 +0000

Den senaste tiden har jag snöat in lite på den mobila webben. Det kanske verkar konstigt för de som känner mig och vet att jag aldrig varit någon varm anhängare av mobiltelefoni och oftast vägrar svara på SMS… Nu har jag dock krupit till korset och beställt en Nokia N95 – den kan man ju faktiskt göra en hel del med.

Hur som helst. Den som börjar läsa in sig på webbutveckling för telefoner/mobila enheter råkar snabbt ut för begreppet One Web. Problemet är bara att det är ganska löst definierat, att det inte finns så många exempel på hur principen ska tillämpas och på att den ofta blandas ihop med struktur-/form-separationen i (x)html/css.

En av de bättre förklaringarna till vad One Web är har W3C begravt en bit in i Scope of Mobile Web Best Practices från 2005:

The representations of a resource identified by a given URI should provide thematically similar information targeted and formatted appropriately for their context. Such targeting and formatting may take place anywhere in the delivery chain between source and end user.

Access to a URI from different devices or different locations should result in thematically similar information but may result in both the appearance and the specific content being different

The user should have the choice of accessing the same information whatever the device used in whatever environment. This point is elaborated in the Best Practice recommendations [BP].

Samma innehåll ska alltså inte ha olika url:er – oavsätt förpackning, formgivning och övriga anpassningar. Att definiera olika stilmallar för olika mediatyper/läsare är bara första steget. Att anpassa även (x)html, bildstorlekar, annonser, navigering och sekundärt innehåll är inte bara tillåtet – det rekommenderas.

Om anpassning görs beroende av vilken typ av display som används så bör det finns en möjlighet att välja bort anpassningen. Även om det inte skrivs rakt ut så verkar det antas att webbplatser gjorda för vanliga skärmar är standarden (dvs innehåller full information) och att dessa sedan anpassas och destilleras för mobilanvändare. Dessa ska sedan kunna välja bort anpassningen får att komma åt den ”riktiga” desktop-versionen. För inte kan de väl mena att alla ska kunna välja bland alla former av innehållet? Det kan lätt bli ganska många versioner att välja bland. Det skulle ju exempelvis kunna finnas varianter för olika skärmstorlekar, operativsystem, webbläsare, mediatyper, länder och så vidare.

Någon exakt definition av tematiskt liknande information (thematically similar information) har jag inte hittat, men som jag tolkar principen så handlar det om att hitta essensen av en sida. Vad handlar just denna sida om? Vad skiljer den från andra sidor på samma webbplats? Svaret på dessa frågor borde ge en bild av var miniminivån av överensstämmelse mellan olika varianter av sidan bör ligga.

Läs mer

Snabbkurs i modern webbdesign

Marcus — Fri, 20 Apr 2007 10:29:55 +0000

För alla som håller på att lära sig bygga webbplatser med standarder och css så är Smashing magazines sammanställning av mini-intervjuer med 35 framgångsrika webbdesigners en utmärkt översikt över de metoder, resurser och typsnitt som utgör den gemensamma grunden i branschen. De tillfrågade fick svara på:

1 aspect of design you give the highest priority to.
1 most useful CSS-technique you use very often.
1 font you use in your projects very often.
1 design-related book you highly recommend to read.
1 design magazine you read on a daily/weekly basis (online or offline).

Enkel html-editor sökes

Marcus — Thu, 19 Apr 2007 14:23:11 +0000

Det är alltid lika frustrerande att bygga en validerande, semantiskt strukturerad webbplats åt någon bara för att upptäcka att de har tänkt att uppdatera den med Frontpage 98 eller något liknande. Resultatet blir en massa trassel för den som uppdaterar webbplatsen eftersom editeringsprogrammet inte klarar av att visa webbplatsen och en webbplats med en massa underliga buggar som beror på kombinationen felaktig kod och avancerad css. Tyvärr verkar det inte finnas så många alternativa editorer att rekommendera.

Jag tycker inte mina krav på en bra html-editor är orimliga:

Inbyggd ftp-klient. För de flesta nybörjare är separata ftp-program ganska komplicerade och att behöva lära sig flera olika program för att göra enkla uppdateringar är inte så populärt.
Gediget stöd för webbstandarder. Borde nästan inte behöva påpekas idag.
Stöd för filer inkluderade med de vanligaste skriptspråken. Att lägga menyer och liknande i separata filer är ett vanligt och praktiskt sätt att minska arbetet vid uppdatering och underhåll.
Möjlighet att bevara struktur men inte formatering vi inklistring av innehåll från exempelvis MS Word eller webbsidor. Styckeindelning, länkar och rubriknivåer skulle till exempel behållas men formateras i enlighet med de befintliga stilmallarna.
Ingen omskrivning av befintlig källkod utan att användaren valt det.
Stöd för avancerad css är önskvärt men inte nödvändigt. Framför allt är det viktigt med editeringsbarhet av innehållet – att allt ser ut som det kommer göra i en webbläsare är inte lika viktigt.
Helst inga formateringsmöjligheter alls utan bara möjlighet att göra strukturella markeringar av innehållet (em, strong, ul, ol osv.).
Lågt pris. Gratis är givetvis bra, men allt under 400 kronor skulle vara rimligt.

Egentligen skulle en enkel what-you-see-is-what-you-mean-editor med ftp-stöd klara av det mesta. Trots detta så har jag inte lyckats hitta så många alternativ, men de som kommer närmast är:

Nvu. Gratis, men har inte uppdaterats sedan 2005.
KompoZer. Gratis. En inofficiell uppdaterad version av Nvu.
Mozilla Composer. Gratis och en del av Mozilla Suite. Bygger delvis på Nvu.
Amaya. W3Cs experimentella webbläsare/editor. Gratis. Verkar lovande när det gäller funktionalitet, men målgruppen är ju inte riktigt nybörjare.
Style Master CSS editor. Kostar 60 dollar men verkar vara mycket kompetent när det gäller hanteringen av css. Den enda av editorerna som har ett modernt utseende.

Har du fler tips på editorer så fyll gärna på i kommentarerna.

Skatteverket börjar följa webbstandarder

Marcus — Mon, 19 Mar 2007 15:45:55 +0000

Skatteverket lanserade en ny layout på sin webbplats förra veckan och i samband med detta passade man på att skärpa upp tillgänglighet och användarvänlighet några snäpp. Nyheter är bland annat möjligheten att få innehåll uppläst för sig, enkla stilmallar för utskrift, en ljusare och luftigare layout samt kortkomandon och möjlighet att ställa in bland annat textstorlek och radhöjd. Framför allt så stödjer man numera moderna webbstandarder, men har valt att lägga ribban förhållandevis lågt då man valt xhtml 1.0 Transitional som doctype.

Efter att ha tittat igenom koden på några sidor och gjort några testvalideringar så tycker jag att det ser ganska bra ut för att vara en såpass omfattande webbplats. Den enda som jag kan se som avviker från xhtml 1.0 Strict är avsaknaden av fieldsets i formulären samt target-attribut på några ställen och det borde inte vara några problem att ordna. Kanske finns det sidor längre ner i strukturen som kräver en förlåtande doctype.

Nästa stora steg är att införa läsvänliga url:er. Vissa delar av webbplatsen har redan delvis läsliga adresser, tyvärr läggs alltid såväl datum som någon form av hash-värde till. Det borde räcka med datum eller månad samt ett ordningstal om det skulle finnas fler än en webbsida med samma namn under samma avdelning.

Stoppa kommentarspam utan att förstöra tillgängligheten

Marcus — Thu, 15 Mar 2007 12:44:43 +0000

Här på bloggen började jag få problem med kommentarspam redan några veckor efter jag startade den. Den första tiden handlade det om enstaka poster i veckan men efter en tid så kunde det ha samlat sig 20-30 nya spamposter över en natt. Något behövde göras.

Några faktorer gör det ganska enkelt för mig att lösa spamproblemet: Jag skriver på svenska medan de flesta spambottar är kalibrerade för engelska, min blogg har så få besökare att den är ett väldigt lågprioriterat mål och jag använder ett egenbyggt bloggverktyg vilket gör att det inte finns några färdiga lösningar för just mitt spamfilter. Eftersom jag ville ha ett filter som skulle fungera ett tag framöver och som jag skulle kunna använda på andra webbplatser försökte jag ändå komma fram till en lösning som skulle vara effektiv även för lite större webbplatser, lätt att använda och inte stänga ute funktionshindrade besökare.

Bildbaserade CAPTCHAs uteslöt jag direkt eftersom de är omöjliga att använda för dem som använder skärmläsare och dessutom ofta svårare för vanliga besökare än spambottar att uttyda. Det går visserligen att lösa tillgänglighetsproblemet genom att komplettera med ljuduppspelning av vad som står i bilden, men det gör hela lösningen ännu mer komplicerad.

En annan vanlig lösning är att kombinera svartlistor, vitlistor, analys av kommentartexten och manuell moderering i olika konstellationer. Fördelen med detta är att skyddet ofta inte märks för besökarna. Nackdelarna är att även vanliga kommentarer kan stoppas och att det ständigt måste underhållas och kalibreras. Denna typ av lösning kan vara praktisk för riktigt stora aktörer (som får så många kommentarer att de kan se mönster eller som kan distribuera spamigenkänningen mellan tusentals individer) men skulle kräva för mycket underhåll för min smak.

Slutligen för valet på en enkel kontroll där besökaren fyller i den siffra som visas med bokstäver. Genom att seeda slumpgeneratorn med ett tidsberoende tal så behöver ingen information om vilken siffra som ska fyllas i skickas med till servern.

Om det skulle behövas är det relativt enkelt att öka komplexiteten:

Sifferintervallet kan ökas för att skapa fler möjliga alternativ.
Siffrans placering i meningen innan fältet där den ska fyllas i kan ändras genom att skapa flera olika meningar som alterneras. För att detta ska vara meningsfullt måste dock betoningen på siffran tas bort…
Komplexiteten i algoritmen som avgör vilken siffra som ska visas kan ökas. Eftersom den är kopplad till en tidsangivelse så är varje algoritm möjlig att gissa för den som ser tillräckligt många exempel.
För att öka svårighetsgraden kan systemet relativt lätt anpassas till att kombinera flera olika tal till enkla matteproblem som skrivs ut som text.

Som alla andra spamskydd baserade på någon form av CAPTCHA så fungerar inte skyddet mot manuell knäckning det kräver också att den som lämnar kommentarer förstår svenska hjälpligt. På det stora hela så tror jag dock att lösningen kommer att fungera bra, men det är väl bara att vänta och se.

För den som vill läsa mer om spamskydd och CAPTCHA är Wikipedias artikel som alltid ett bra ställe att börja på. W3C har en grundlig genomgång av tillgänglighetsaspekten och Juicy Studio har en ganska teknisk artikel om hur olika alternativa tekniker skulle kunna fungera.

Enkelt verktyg för effektivare stilmallar

Marcus — Thu, 08 Mar 2007 09:45:23 +0000

CSS Tweak är en liten webbtjänst som optimerar stilmallar. Den tar bort överflödiga enheter och slår ihop deklarationer för font, list, border och margin. Om du inte har för vana att använda kortversionerna för deklarationer (eng: shorthand properties) i stilmallar så kan CSS Tweak ge en bra bild över hur stora optimeringsvinster som är möjliga.

För mig är inte den stora vinsten minskningen av filstorleken, den största anledningen till optimering är att kortare stilmallar leder till bättre överblick och mindre letande när man arbetar med dem. Det förutsätter givetvis en bra struktur på reglerna och kommentarer där de behövs – se därför till av avmarkera remove comments och välja Leave my layout alone om du använder CSS Tweak.

För en repetition av kortversionerna rekomenderar jag Roger Johanssons guide Efficient CSS with shorthand properties.

Stapeldiagram med CSS för utskrift

Marcus — Fri, 02 Mar 2007 23:09:46 +0000

Att göra en version för utskrift av stapeldiagrammet jag experimenterade med visade sig vara lättare sagt än gjort. De flesta moderna webbläsare skriver inte ut vare sig bakgrundsbilder eller bakgrundsfärger om inte besökaren explicit slår på den möjligheten – och det tror jag inte någon vill förlita sig på. Dessutom tar sig webbläsarna i regel friheten att byta ut för ljusa textfärger till svart eller mörkgrått. Till detta kommer en hel mängd små underliga buggar som bara verkar komma fram vid utskrift.

Efter en del kompromissande nöjde jag mig med denna variant (bara print-stilmall, välj print preview för att se den). Förutom förenklingen (gråskala, ingen bakgrund, inga skuggor, ingen ram) så valde jag att ta bort siffrorna i staplarna. De verkade inte gå att göra tillräckligt ljusa för att synas mot de mörka staplarna, men om man nöjer sig med ramar istället för bakgrund för staplarna så är det inte några problem att visa dem. Kanske skulle det vara en bättre lösning (ingen informationsförlust), men jag ville se om det gick att få samma grafiska stil på diagrammet vid utskrift som på skärmen.

Exemplet är än så länga bara testat i Firefox 2 och Internet Explorer 7.

För den som gör speciella printstilmallar så är webbläsarnas egna regler för vad som ska visas lite irriterande. Som flera tidigare har påpekat borde den bästa lösningen vara att webbläsarna litar på att de som har specificerat media="print" vet var de gör. En stilmall specificerad för ett speciellt medium borde alltid ha företräde framför webbläsarnas egna räddningsförsök (men givetvis stå tillbaka för en lika specifik användarstilmall).

Stapeldiagram med CSS

Marcus — Wed, 28 Feb 2007 07:45:23 +0000

Tidigare har jag använt PHP-biblioteket JpGraph i några olika projekt för att skapa grafer av olika slag. Det är dock inte alltid praktiskt att generera bilder för att visa statistik, så jag har lekt lite med css för att se om det inte går att hitta alternativa metoder.

Med utgångspunkt i Eric Meyers vertical bargraphs har jag försökt ta fram en lite snyggare och enklare variant. Målsättningan var att skapa stapeldiagram från semantiskt korrekt html med ett minimum av extra element, utan för komplicerad css som enkelt skulle kunna genereras dynamiskt och fungera i alla moderna webbläsare utan några css-hacks.

Eftar att ha provat med både tabeller och listor så fastnade jag till slut för definition lists som den enklaste metoden för att märka upp datan. Det finns många åsikter om hur definition lists ska användas, själv hör jag till den grupp som menar att man med fördel kan användas dem att koppla ihop nyckel-/värde-par. Tabeller skulle varit mer korrekt, men de kräver för mycket extra stilregler för olika webbläsare för att vara praktiskt i längden.

Det finns några saker med exemplet som inte fungerar så bra. Den extra koden som krävs för att sätta ut axelmarkeringarna är antagligen ganska förvirrande för besökare utan stöd för stilmallar. Möjliga lösningar är att använda sig av en bakgrundsbild (svårare att generera dynamiskt) eller att lägga in en beskrivande rubrik som förklarar vad siffrorna betyder (innebär ännu mer kod). Dd-elementet innehåller ett span-element som kan tas bort om man inte behöver bakgrundsskuggan överst och till höger.

Har testat exemplet i IE7, IE6 och Firefox 2 på Windows XP samt i Safari 2 och Firefox 2 på Mac OSX.

Hör av dig om du har förslag på förbättringar eller har egna exempel på lösningar.

Här är mitt exempel.

Stockholms stadsbiblioteks nya webbplats i öppen beta

Marcus — Wed, 14 Feb 2007 16:43:07 +0000

När Stockholms stadsbiblioteks nya webbplats smygstartar på allvar (den har tidigare varit tillgänglig i skissform) blir det den mest intressanta offentliga webbplatsen i Sverige, åtminstone i ett webb 2.0 perspektiv. Den erbjuder RSS-flöden för det mesta (exempelvis sökningar, kommentarer på enskilda böcker, fysiska evenemang), möjlighet att skriva recensioner och sätta betyg, diskutera med andra besökare och givetvis sköta alla vanliga biblioteksärenden. Än så länge har webbplatsen begränsad funktionalitet (och ganska många brister) men jag har stora förhoppningar om version 1.0. Jag har redan ansökt om att bli betatestare (d.v.s. få ett konto för att kunna använda personaliseringsfunktioner, recensioner med mera). och min plan är att göra utvärderingen av den nya webbplatsen till en liten följetong här. Första delen lägger jag ut i morgon och den kommer att handla om biblioteket.se och bloggvärlden.