Visa din hemsida!

Underbart. Älskar Netflix-filtret i kombination med andra. Helt plötsligt blev det väldigt enkelt att hitta bra filmer!

Den ser la nice ut .

• <a href="tel:076-099 99 45" class="jumbo tel">076-099 99 45</a>

  Det är inte ett giltigt att ha mellanslag i `href`-attributets värde. Antingen bör de konverteras till entiteter (dvs mellanslag → `%20`), eller så kan mellanslagen helt enkelt skippas. Webbläsare kommer internt högs troligen konvertera mellanslagen till `%20` ändå, men det gör att när jag t ex hovrar telefonnumret i Opera så kommer det en `alt`-text-liknande popup med innehåll "address: tel:076-099%2099%2045", vilket ser lite tråkigt ut.

• Sidorna saknar `<meta charset="utf-8">`. Webbläsare gissar troligen rätt på detta ändå idag, men det är smidigare att ange det.

  "Egentligen" ska det ju inte behövas om servern är konfigurerad att skicka header med charsetinfo, men eftersom detta i de allra flesta fall runt om på nätet inte stämmer så är det inget läsare litar blint på. Det går faktiskt att gå på riktigt luriga nitar gällande detta: webbläsare tittar på de första 1024 byten i dokumenten (enligt nuvarande HTML-standard, men i praktiken kan det diffa (tidigare var rekommendationen 512 B)) efter `meta charset`-taggen eller motsvarande, och när den hittas så tolkas dokumentet enligt denna teckenkodning. Ifall ingen tagg hittas så är det lite odefinierat vad som händer. Vanligen försöker de gissa på rätt teckenkodning genom att känna igen karakteristiska tecken inom ett visst intervall (IE kollade 4096 B i äldre versioner, vet jag), vilket gör att om man exempelvis har en sida där man använt åäö inom den första biten (exempelvis i titeln) så kommer läsaren gissa rätt, men om man helt plötsligt har en sida där titeln inte innehåller åäö så kanske en läsare kan komma att gissa fel.

  Det har också funnits exempelvis XSS-attacker genom UTF-7 (proof-of-concept) som attackerat sidor som inte angivit explicit teckenkodning: genom att skicka meddelanden i UTF-7 har man kunnat undslippa datasanering, och sedan kunnat "lura" webbläsaren att tolka sidan som UTF-7 varpå de där knasiga tecknen helt plötsligt blivit giltig kod. Med en korrekt konfigurerad webbserver "ska" detta inte hända, men, tja, det har hänt, och `meta charset` är i vilket fall rekommenderat.

• På ett flertal platser används `-`, dvs bindestreck, där det borde vara ett `–`, dvs ett tankstreck. Antingen kan man köra den gamla härliga `&ndash`-entiteten eller helt enkelt skriva U+2013-tecknet i UTF-8-kodning.

• "á la" (akut accent) ska vara "à la" (grav accent) (och `-` ska vara `–`).

• "benämnd" → "benämnt".

• I alt-text står det exempelvis: "Logotyp för Mirello Media - en Webbyrå i Borås" — "Webbyrå" → "webbyrå" (och `-` till `–`, men det gäller som sagt lite här och var).

Hur man visar det på sidan spelar ingen roll för funktionen, men mellanslag är rent tekniskt inte giltiga i värdet till `href`-attributet.

<a href="tel:076-0999945" class="jumbo tel">076-099 99 45</a>

skulle visas så som du vill, samtidigt som det följer HTML-standarden, samtidigt som det inte ser skumt ut vid visuell inspektion av länken. För den delen så kanske

<a href="tel:0760999945" class="jumbo tel">076-099 99 45</a>

är än mer naturligt: telefonen bryr sig inte om bindestreck och annat ändå.

Ja, det är egentligen i praktiken tillräckligt idag. Dock så är `meta charset` fortfarande något som exempelvis W3C säger "alltid" ska anges.

Det finns ett historiskt problem i att så få siter använde HTTP-headern `charset` korrekt (vilket är vad du fixar i `.htaccess`), speciellt när UTF-8 började "slå igenom" på bred front, så att äldre versioner av webbläsare av ren pragmatik inte kunde förlita sig blint på denna. Exakt implementation kan alltså skilja sig från läsare till läsare. Detta ska bara vara en historisk notis idag, och jag vet inga exempel på webbläsare som ignorerar HTTP-headern om den finns, men `charset`-taggen ger "hängslen och livrem".

W3C säger:

Om man har satt HTTP-charset, och inte anger `meta charset` eller dylikt, så ska det inte bli fel så länge som dokumentet serveras över just den servern som är konfigurerad på det sättet. Att W3C ändå ger en "always"-rekommendation har nog dels att göra med den pragmatiska världen där läsare skulle kunna tolka lite som de vill för att vara "hjälpsamma", samt att ett dokument inte alltid måste komma att serveras över HTTP. Det finns också mer exotiska anledningar så som mytomspunna proxies som strippar HTTP-headers utan hänsyn till att bevara teckenkodning, även om jag inte sett någon sådan.

Kanske det största argumentet ur säkerhetsperspektiv är att inte blint lita på att webbservern alltid kommer vara korrekt konfigurerad. Mänskliga faktorn och en slarvig uppdatering kan vålla problem. Det ger även teoretiska möjligheter för kombinerade attacker: om en attackerare kan gå förbi `.htaccess`-tolkning så skulle det kunna kombineras med en UTF-7-attack. Samma anledning gör att man inte gärna lämnar lösenordsfiler inuti sin webroot även om man sagt till servern att inte servera dessa filer — då är man kanske bara en slarvig uppdatering eller mänskliga faktorn ifrån att läcka inloggningsuppgifter och annat.

Situationen verkar faktiskt vara i bättre skick idag än jag trodde innan jag började kolla upp detta i och med detta svaret. Jag trodde det var vilda västern gällande vilken teckenkodningsangivelse som tog preferens ifall båda var tillgängliga och sade olika saker, men det verkar vara entydigt för åtminstone någorlunda moderna läsare. Fortfarande så gäller dock att sidor har åkt på nitar när webbservern av någon anledning (vanligen slarv) helt slutat skicka charsetinformation samtidigt som `meta charset` saknats i dokumenten. Med "hängslen och livrem" skulle det inte varit något problem, och det kostar inte mycket att lägga till.

Jag har memorerat en del tecken som är smidiga och som jag använder hyfsat ofta, så som:

• U+00a0: " " — hårt mellanslag (i begrepp man inte vill ska radbrytas, t ex just "t ex" eller för den delen telefonnummer som var aktuellt ovan, eller för att undvika att vitutrymme kollapsar i exempelvis SweClockerskommen t  a   r    e     r)

• U+202f: " " — hårt tunt mellanslag (mellan mätetal och enheter: undviker radbrytning och grupperar begrepp)

• U+2026: "…" — ellipsis

• U+2013: "–" — talstreck (en dash)

• U+2014: "—" — em dash (egentligen inte så vanligt på svenska, men jag tar mig en del friheter )

• U+2212: "−" — minus (vilket ej heller är det vanliga bindestrecket "-")

samt en del ytterligare mattetecken. Det brukar finnas något sätt att skriva in dessa kombinationer i de flesta program man använder.

Så gör jag, i alla fall. Jag vet att Ubuntu erbjuder en snabbknapp för att gå in i "compose"-läge, varpå "---" ger ett em dash, osv.

OK, har själv aldrig klickat på någon sådan länk i en telefon . Personligen hade jag valt varianten med enbart siffror i `href`-målet, då det känns som att informationen där är till för "maskinen" snarare än "människan", och maskinen bara bryr sig om den faktiska informationen. Presentationen, med bindestreck och mellanrum, sker ju på hemsidan. Jag skulle nog även gått ändå till `+46…` i detta fall (se notis från RFC nedan).

"Begränsningen" kommer ursprunligen från RFC 1738 som beskriver URL-formatet och bl a säger:

`%20` som substitut för mellanslag ger därmed en giltig URL, men om man tittar vidare på specifikationen för `tel:`-formatet i RFC 3966 så står det bl a:

E.123 är ITU-T:s rekommendationer för hur man skriver exempelvis telefonnummer. RFC 3966 ger `-.()` som de fyra giltiga visuella separatortecknen (se `visual-separator` i RFC-texten).

Man kan i praktiken, även om det är emot standarden, slänga in `%20` (eller, som du märkt, rena mellanslag trots att det "egentligen" inte är en giltig URL), och jag har svårt att se en klient som feltolkar detta, men det blir lätt lite rörigt att blanda entiteter och signifikanta siffror, vilket också nämns som en motivering till "MUST NOT"-formuleringen ovan.

Man kan även notera att RFC 3966 säger:

"SHOULD" är bara en rekommendation till skillnad från "MUST", men det pekar också på att det viktiga i länkmålet är att det ska vara otvetydigt läsbart för "maskinen".

Ja, jag är vanligen av inställningen att kod som inte spelar någon roll ryker, men `charset` tycker jag har existensberättigande som god praxis. Som en bonus får det tyst på W3C:s validator .

———

Tillägg: Såg att det nu såg ut enligt:

  <title>Mirello Media | Vår söta webbyrå får en söt hemsida!</title>

    
  <meta charset="UTF-8">

`meta charset` ska generellt vara det första i `<head>`, till och med innan `<title>`. Eftersom `<title>` kan innehålla specialtecken utanför ASCII (vilket den ju faktiskt gör här) så är det lite bakvänt att definiera teckenkodning efter titeln. Om ingen HTTP-teckenkodning specificerats så kommer webbläsaren leta efter `meta charset`, och efter att den hittat direktivet tolka om sidan, så det är bara vinster av att ha det så tidigt som möjligt. Dessutom är ju `charset` en av få taggar som faktiskt har en hård gräns över hur långt in i dokumentet den ska finnas (<1024 B idag, som sagt), så praxis bör vara att lägga den så tidigt som möjligt.

Återigen inget som idag i praktiken bör spela någon större roll, mer än minimala vinster i tolkningstid. Jag hade för mig att W3C under framtagandet av HTML5 någon gång explicit skrev att `meta charset` skulle vara första taggen i `head`, men numera har de bara 1024 B-gränsen kvar i formuleringen. Det är ju dock logiskt mer "korrekt" om teckenkodningen definieras innan den behöver användas i `title`.

Attributvärden är skiftlägesokänsliga i HTML och brukar standardiseras på gemener, så `charset="utf-8"` är vanligare att se än `charset="UTF-8"`, även om man kan argumentera för att det senare egentligen är mer korrekt .

Nej, det den ska inte behöva göra det, om den låter HTTP-headern trumfa `meta charset`, vilket är vad läsare ska göra. Vad som händer i verkliga världen är dock inte alltid så vackert som teorin . En deltanke är ju också att `meta charset` ska kunna fungera som en fallbackmekanism ifall HTTP-steget missar, så den bör ligga på det mest naturliga stället.

Jag är säker på att jag åkt på niten med att just deklarera UTF-8 efter `<title>` på en sida en gång i tiden och ha fått skumma teckenkodningsproblem tills det fixades, men jag kommer inte ihåg tillräckligt för att ge exakt webbläsarversion eller tidpunkt. Det var nog ganska antikt, och det bör inte göra någon praktisk skillnad med någorlunda moderna läsare. Kombinerat med skakiga uppkopplingar så kan man dock även braka in i en webbläsarberoende tidsgräns — HTML5-rekommendationen säger att en läsare efter 500 ms kan börja "gissa" och då rendera med denna gissning.

Jag gjorde nyss några snabba test med olika webbläsare för att se hur de gör idag:

• Opera 12.16 behöver ha charset-taggen färdigdeklarerad inom de första 2¹⁷ = 131 072 byten för att läsa den, så de där 1024 som W3C specificerar överskrides med råge. Opera lyckas inte "gissa" rätt på UTF-8 helt utan hjälp.

• Chrome 36 verkade av någon anledning titta i 3879 B av HTML-dokumentet innan den gav upp och körde fallbackteckenkodning. Jag misstänker att detta blir 2¹² = 4096 bytes tillsammans med HTTP-header, för om jag ändrar storlek på den så ändras gränsen på motsvarande sätt (headerns längd räcker dock inte helt upp till 4096 B, så något ytterligare spelar in). Bara för att testa så tittade jag om den skulle gå i "fällan" att helt ignorera `charset` om jag skickade en header >4096 B, men det hade någon redan tänkt på, så där lyckades jag inte lura den . Chrome lyckas ej heller gissa rätt på UTF-8 helt utan hjälp.

• För Firefox 29 kunde jag inte hitta någon övre gräns, men det beror nog på att Firefox lyckas med gissningen efter att den inte hittat `charset` inom rätt spann. Jag märkte också att Firefox överhuvudtaget slutade ladda HTML-filen när den blev över ~20 MB (vilket både Opera och Chrome svalde; min Apachekonfiguration började dock klaga vid 2²⁷ = 134 217 728 B).

Kontentan är väl att alla läsare beter sig på olika sätt i någon mån. Intet nytt under webbsolen.

Min personliga sida: http://lambdan.se/
Inte mycket att skryta med, men jag gillar den.

Visst ja:

        <div class="adr">
          <b><span class="street-address">Skaraborgsvägen 62-64</span></b><br>
          <b><span class="region">506 30</span> <span class="locality">Borås</span></b><br>
        </div>

"region" ska nog snarare vara "postal-code": adr · Microformats Wiki — Examples → Sample `adr`.