ps. Nikke Lindqvist har en lista på andra svenska bloggar som firar nakenheten idag.

App-ikoner är de nya fav-ikonerna! Om en smartphone-användare gillar din sajt så kan han/hon välja att bokmärka den genom “Add to Home Screen”, eller “Lägg till på hemskärmen”.
Då skapas ett bokmärke på hemskärmen, som ser ut som en vanligt app, med tillhörande app-ikon. Om din sajt inte har någon app-ikon så skapar telefonen en liten skärmdump som används istället – inte särskilt snyggt. Men detta är snabbt åtgärdat!

För att din sajt ska få en app-ikon i iPhone eller iPad skapar du en bild som du sedan hänvisar till i din html-kod. I head-taggen lägger du in en link med rel-attributet apple-touch-icon:

<link rel="apple-touch-icon" href="/images/touch-icon.png" />

Eftersom de olika varianterna av iPhone och iPad har olika upplösning måste man skapa ikoner med olika storlekar. Bilderna ska ha följande mått, enligt Apples egna dokumentation:

• iPhone 3GS: 57×57 pixlar
• iPhone 4: 114×114 pixlar
• iPad: 58×58 pixlar

Vad jag erfar så räcker det dock med de två översta – iPaden använder verkar använda den största. Måtten anges i ett sizes-attribut. Det fullständiga exemplet ser alltså ut så här:

<link rel="apple-touch-icon" href="/images/touch-icon-small.png" />
<link rel="apple-touch-icon" sizes="114x114" href="/images/touch-icon-big.png" />

Apple lägger automatiskt till glans och rundade hörn på din ikon. Här ser du ett exempel på hur en ikon ser ut i original, jämfört med hur den visas på användarens hemskärm:

Om du inte vill ha glans och runda hörn på din ikon kan du lägga till ordet precomposed i rel-attributet. Då visas ikonen i sitt originalutseende (via Sarah Parmenter):

<link rel="apple-touch-icon-precomposed" href="/images/touch-icon.png" />

Men, kanske någon undrar, hur gör man då för Android-mobiler? Svaret är enkelt: Man kan göra likadant! Android stöder nämligen också apple-touch-icon-precomposed, så om du använder det kommer din ikon alltså användas för majoriteten av smartphoneanvändare.

Vill du veta ännu mer om att skapa ikoner för iOS? Läs vidare på: How to Design App Icons for iPhone and iPad.

ps. För att uppmärksamma användaren om att de kan bokmärka/lägga till din sajt på hemskärmen kan jag tipsa om add2home.js (via Emil Stenström). Det är ett litet script som öppnar upp ett meddelande i närheten till “Add to Home Screen”-knappen för att upplysa användaren hur de bokmärker din sajt. Snyggt!

link = $('<a href="http://lillbra.se">Min blogg</a>');
$('body').append(link);

Eller så kan du infoga en html-sträng direkt, så här:

$('body').append('<a href="http://lillbra.se">Min blogg</a>');

Men om elementet man skapar ska ha många attribut, blir det ofta kladdigt i koden med långa strängar. Så med jQuery kan du skicka med attribut, och även fästa events, till elementet genom en hashmap direkt när du skapar det:

var link = $('<a />', {
className: 'close',
href: '#',
text: "Hide more info",
click: function(e){
e.preventDefault();
$(this).parent().slideToggle();
}
});

Snyggt och överskådligt! Se fler exempel på detta här: Beatiful Element Creation With jQuery (via Jonathan Cristopher).

Även detta sätt kan dock bli rörigt om man ska bygga en större html-struktur, med nästlade element.
Då kan man använda templates. Tanken med templates att du skapar en mall, i form av en html-struktur, som du sedan fyller med data, t.ex. ett eller flera json-objekt. jQuery har sitt eget template-plugin, men det finns även andra som Mustache och Underscore.
Först skapar man alltså mallen – den kan ligga inline som en script-tagg i html-koden:

<script id="vcard-template" type="text/x-jquery-tmpl">
<div class="vcard">
<a class="fn url" href="${ website }">${ name }</a>
<span class="org">${ company }</span>
</div>
</script>

Sedan hämtar man ut mallen och fyller den med sitt data, för att sedan infoga det på sidan:

author = { name : 'Jonatan Larsson',
website: 'http://lillbra.se',
company: 'Valtech' };
$('#vcard-template').tmpl(author).appendTo('#contact');

Se fler exempel på hur du använder jQuerys templates här.

När man infogar element på sidan bör man tänka på att uppdatera DOM-trädet så få gånger som möjligt. Om man t.ex. skapar en lista så ska man undvika att infoga ett li-element åt gången:

list = $('#my-list');
for (var i=0; i<items.length; i++){
list.append('<li>' + items[i] + '</li>');
}

Istället kan man skapa html för alla li-element och sedan injecta dom en enda gång:

htmlItems = '';
for (var i=0; i<items.length; i++){
htmlItems += '<li>' + items[i] + '</li>');
}
$('#my-list').html(htmlItems);

Angående prestanda kan det ibland också vara bättre att skapa eller infoga element med native javascript, till exempel använda .innerHTML() istället för .html(), eller .createElement() istället för strängar. Den nyfikne kan även kolla in prestandamätningar mellan olika template-plugins här. Lycka till!

Men detta kan du ändra på. Det enklaste och bästa sättet att tillåta andra element är att definiera extended_valid_elements i TinyMCE-inställningarna. För att, till exempel, tillåta <time>-taggen med ett datetime- och data-attribut skriver du följande:

tinyMCE.init({
...
extended_valid_elements : "time[datetime|data-is-start]"
});

TinyMCE i EPiServer

Om du utvecklar för EPiServer måste du göra dessa TinyMCE-inställningar genom EPiServer. Det gör du genom att skapa en klass med TinyMCEPluginNonVisual-attributet:

using EPiServer.Editor.TinyMCE;
namespace Customer.Web.Plugins.TinyMCE
{
[TinyMCEPluginNonVisual(AlwaysEnabled = true, PlugInName = "ExtendedValidElements", EditorInitConfigurationOptions = "{ extended_valid_elements: 'time[datetime|data-is-start]' }")]
public class ExtendedValidElements
{}
}

Och i din episerver.config-fil lägger du till (via Frederik Vig):

...
<tinyMCE mergedConfigurationProperties="valid_elements, extended_valid_elements, invalid_elements, valid_child_elements" />
</episerver>

TinyMCE i WordPress

Om du använder WordPress så gör du dina TinyMCE-inställningar i en egen funktion som du lägger till som ett filter med namnet tiny_mce_before_init. Detaljer om hur du gör detta hittar du här: Adding html5 capability to WordPress.
Lycka till!

Utseendet för ett element bestäms då det skapas
Webbläsaren läser och ritar ut ett element i taget, med start uppifrån och ned i html-dokumentet. För varje element som ritas ut, avgör webbläsaren om den dessutom måste rita om tidigare element.
Se en video på hur en sidrendering i Firefox ser ut i slow motion här (via Snook).

Css-selektorer evalueras från höger till vänster
Nyckeln i en css-selektor är det som står längst till höger. Webbläsaren börjar tolka selektorn från höger och fortsätter sedan tills den kan avgöra om utseendet ska appliceras på aktuellt element. Ju fler noder måste evalueras för att se om regeln stämmer för elementet, desto mer jobb är det för webbläsaren.

Med detta som bakgrund ger Google Page Speed följande råd till hur du skriver effektiva css-selektorer:

Undvik universalselektorer
Nycklar som matchar alla element är självklart krävande. Använd ej: body * {...}

Gör regeln så specifik som möjligt
Id:n är mest effektiva, följt av klasser och sist taggnamn och universal-selektorer. Använd t.ex. klasser och id:n som nyckel istället för taggnamn. Jämför följande: #comment p {..}
#comment .text {}

Undvik redundanta selektorer
Låt klasser och id:n tala för sig själva, skriv inte kombinationer när de inte behövs, som t.ex.: div#comment
p.text

Undvik descendant selektorer
Håll selektorerna korta, och ha inte med förälderelement som gäller för alla element, t.ex.: body ul li a {...}

Undvik :hover pseudoe-selektorn för element som inte är länkar i IE
Kan orsaka problem i Internet Explorer 7 & 8, överväg att använda javascript istället.

Undvik css-expressions
Stöds bara av Internet Explorer och är deprecated. Använd media-queries eller javascript istället.

Hur stor effekt det ger att följa ovanstående råd är såklart olika från fall till fall. Men speciellt mobiler och läsplattor är inte så kraftfulla och där kan optimering ge märkbar effekt. Tomas Fuchs har kollat närmare på vilken sorts css som slöar ned renderingen på iPaden, och främst är det nyheterna inom css3 som orsakar problem. Enligt honom bör vara försiktig med att använda följande:

text-shadow och box-shadow
Krävande och slöar ned sidan kraftigt.

-webkit-gradient
Webbläsaren skapar en bitmap av gradienten vilket inte är optimalt. Istället kan man använda canvas till att måla stora gradienter.

-webkit-transform
Orsakar hårdvaruacceleration, och är buggigt.

opacity
Genomskinligheten kan tydligen störa hårdvaruaccelerationen och på så sätt orsaka långsam sidladdning.

Till sist: Prestandaoptimeringar i all ära, men kom ihåg att inte offra semantiken för att skriva snabbare selektorer. Att sätta id:n på alla element är alltså ett no-no – skapa en ren semantisk html i första hand Och för dig som vill läsa mer kan jag rekommendera följande artiklar:

• Efficiently Rendering CSS – CSS-Tricks (via @madr)
• Writing Efficient CSS for use in the Mozilla UI – MDN
• Use the table-layout CSS property to speed up table rendering – Eric Wendelin (via @madr)

Relaterade artiklar på lillbra.se:

• Att tänka på när du knappar css
• 4 css-tips jag INTE följer

Facebook har skapat OpenGraph, ett metadata-protokoll för att beskriva sidor och relationer på webben. Så för att ange vilken bild Facebook ska använda lägger du in följande meta-tagg i din head-tagg:

<meta property="og:image" content="http://lillbra.se/images/facebook-thumbnail.png"/>

Du måste dessutom specificera namespace för protokollet på detta sätt:

<html xmlns:og="http://ogp.me/ns#">

Bilden du använder ska vara minst 50×50 pixlar stor och ha en ratio på högst 3:1. Filformat som stöds är png, jpeg och gif.

OpenGraph-protokollet har utöver og:image, tre andra egenskaper som är obligatoriska att ha på sidan: title, type och url. Så det fullständiga exemplet ser ut så här:

<html xmlns:og="http://ogp.me/ns#">
<head>
<meta property="og:title" content="Lillbra.se"/>
<meta property="og:type" content="blog"/>
<meta property="og:url" content="http://lillbra.se"/>
<meta property="og:image" content="http://lillbra.se/images/facebook-thumbnail.png"/>

Läs mer om OpenGraph och på vilka sätt Facebook använder det här.

OpenGraph och HTML5-validering

Om du använder HTML5 som doctype (och det gör du väl!?) kommer ovanstående exempel att orsaka valideringsfel. Jag har hittat tre metoder att hantera detta problem:

Antingen kan du se till att endast skriva ut meta-taggarna för Facebook, genom att kontrollera user-agent-strängen. För alla andra besökare serveras alltså valid html utan OpenGraph-element. Ett exempel på hur du gör detta hittar du här.

Ett annat alternativ är att använda det gamla sättet att peka ut bilden med en link-tagg istället för en meta-tagg. Så här:

<link rel="image_src" href="/images/facebook-thumbnail.png" />

Detta sätt rekommenderades innan OpenGraph fanns, men fungerar fortfarande. Hur länge Facebook stöder detta är dock oklart.

Det tredje och sista alternativet är att använda HTML+RDFa – en standard för att använda RDFa (där du kan definiera xml-namespaces) tillsammans med HTML5. Då skriver du så här (via Semantic Overflow 1 & 2):

<!DOCTYPE html>
<html version="HTML+RDFa 1.1" xmlns:og="http://ogp.me/ns#">
<head>
<meta property="og:image" content="http://lillbra.se/images/facebook-thumbnail.png"/>

HTML+RDFa är dock en working draft och W3Cs validator stöder inte HTML+RDFa, och därför kommer du inte kunna validera din kod med den.

Annat att tänka på

Många rapporterar problem med att Facebook inte visar rätt bild, både när man använt OpenGraph och det gamla sättet. Själv har jag inte stött på några problem, bara man följer ovan beskrivna regler. Och Facebook har en egen länk-inspektor där du kan ange en url och få ett resultat på vilken metadata Facebook kan hämta för den sidan. Lycka till!

ps. Om du använder WordPress hittar du en enkel steg-för-steg guide till hur du implementerar OpenGraph här.

Roller

Roller kan användas för att beskriva vilken roll (duh!) en viss del eller visst element har på sidan eller i applikationen. Du använder roller genom att lägga till attributet role i din html-kod, t.ex:

<div role="banner">

Det finns 61 stycken roller, mer eller mindre självförklarande, som t.ex. alertdialog, tabpanel, progressbar.
De mest övergripande rollerna kallas landmarks och kan användas av skärmläsare för att navigera runt till huvuddelarna av dokumentet, d.v.s. samma användning som en “Hoppa till innehållet”-länk. Landmarks-rollerna är följande:

• application – del av sidan som anses vara mer applikation än dokument
• banner – t.ex. sidhuvud som beskriver webbplatsen
• complementary – stödmaterial till huvudinnehållet som även är meningfullt om det skulle vara fristående
• contentinfo – metadata om huvudinformationen
• main – huvudinnehållet på sidan
• navigation – navigationsmeny
• search – sökfunktion

Som synes har några av rollerna stora likheter med betydelsen av vissa html5-element. Steve Faulkner har en bra jämförelsetabell mellan landmark roles och html-taggar där du kan se förhållandet mellan dem (via Bruce Lawson).
För samtliga roller bör man tänka på att inte sätta ut roller som konkurrerar med html-elementets semantiska betydelse (via html5doctor). Till exempel ska ett button-element inte ha något annat än en button-roll.

Egenskaper och tillstånd

Egenskaper och tillstånd används för att meddela en skärmläsare eller annat hjälpmedel när förändringar görs på sidan. Egenskaper och tillstånds sätts genom attribut med formatet aria-*. Till exempel:

<div aria-hidden="true">

Man kan använda flera attribut på samma element och de ska med fördel kombineras med roll-attributet. T.ex:

<a role="button" aria-haspopup="true" aria-owns="minPopup">

Skillnaden mellan egenskaper och tillstånd är att egenskaperna (t.ex. aria-labelledby) oftast inte ändras för ett element, medan tillstånd (t.ex. aria-checked) ändras löpande då användaren interagerar på sidan.
Det finns totalt 35 stycken egenskaper och tilstånd. Några av de, i mina ögon, viktigaste är:

• aria-live – Indikerar att ett område eller element kommer att uppdateras. Värde: off/polite/assertive, beroende på om användaren ska meddelas vid en uppdatering eller ej.
• aria-describedby – Hänvisning till ett annat element som innehåller mer information som användaren kan behöva för att använda elementet. Värde: element-id.
• aria-hidden – Om ett element är gömt eller inte. Värde: true/false.
• aria-selected – Om ett element är valt eller inte. Värde: true/false.
• aria-owns – Visar att ett element hör ihop med ett annat element, även om DOM-trädet inte avspeglar denna relation. Värde: element-id.
• aria-expanded – Om ett element, eller annat element som det kontrollerar, betraktas som utfällt eller inte. Värde: true/false.
• aria-haspopup – Om ett element har en popup-/dropdown-meny kopplad till sig. Värde: true/false.

Verktyg för utvecklare

Om du använder WAI-ARIA och vill testa resultatet för användaren kan du använda dessa verktyg (via eutveckling.se):

• Juciy Studio accessibility toolbar Firefox plugin – plugin som känner av och tolkar WAI-ARIA-attribut
• Validator SAC – en validator som har WAI-ARIA-stöd

Läs mer om hur du kommer igång med WAI-ARIA i artikeln Introduction to WAI ARIA på dev.opera.com. Lycka till!

The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good ‘ol play on words. It’s time to show off your .

Dustin Diaz – CSS Naked Day

Är din blogg också naken? Skriv en kommentar!

ps. I slutet av förra året bytte jag mallar och utseende här på bloggen, så för er som endast läser RSS-flödet och inte sett det ännu kan jag tipsa om att när CSS Naked Day är över kolla in den “nya” designen

1. Identifiera en iPad-användare

För att avgöra om man ska visa iPad-versionen för en besökare är det bästa sättet att känna av vilken User-Agent besökaren har. Så här ser User-Agent-strängen ut för iPad:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

Ett alternativ till automatisk avkänning är att istället skapa en egen url för den iPad-specifika versionen, något som inte är helt ovanligt för redan existerande iphone/tablet-sajter, t.ex. touch.facebook.com.

2. Håll koll på skärmbredden

iPadens skärmupplösning är 1024×768 pixlar. Safari på iPad försöker automatiskt skala om sajter för att se bra ut i bredden 768 pixlar (porträttformat). För att undvika en sådan automatzoomning sätter du meta-taggen viewport såhär:

<meta name="viewport" content="width=device-width" />

En liten hake är att Safari alltid räknar sin bredd som 768 pixlar oavsett hur man håller sin iPad. Så om du roterar iPaden till landskapsformat, rendreras innehållet inte om utan skalas bara upp för att passa den ökade bredden.

Uppdatering 2010-04-10

Men med hjälp av CSS Media Queries kan man känna av vilken ledd som iPaden hålls (landscape eller portrait), och ha olika css-filer beroende på det:
<link rel=”stylesheet” media=”all and (orientation:portrait)” href=”portrait.css">
<link rel=”stylesheet” media=”all and (orientation:landscape)” href=”landscape.css”>

CSS Media Queries kan också alltså komma väl till pass för att servera en css speciellt för iPaden – läs mer om detta hos x7 Labs och hos Cloud Four.

3. Utnyttja touch-events

Safari på iPad stöder DOM TouchEvents. Med touchstart, touchmove, touchend, och touchcancel kan du identifiera hur användaren pekar på sajten. Till hands finns även
jQTouch – ett intelligent jQuery-plugin som t.ex. hjälper dig att känna av när användaren gör en swipe.
Notera att, samtidigt som nya events finns, är det andra som saknas: mouseover, mouseout och mousemove finns inte tillgängliga, och inte heller pseudo-klassen :hover i css.

4. Skippa Flash

Kom ihåg att Safari på iPad inte stöder några plugins. Så om du använder dig av Flash så kommer det inte att visas. Använd istället html5-element som <video> eller <audio> för bild och ljuduppspelning, eller javascript och css-animationer för animeringar och bildspel.

5. Testning

Om du inte har en egen iPad och vill testa hur sajten ser ut för iPad-användare så kan du använda Chris Pedericks suveräna User Agent Switcher till Firefox för simulering. Du kan även testa i iPhone-simulatorn som finns tillgänglig om man är medlem i Apples iPhone Developer Program.

För fler detaljer runt utveckling för iPad rekommenderar jag Apples egna Technical Note TN2262: Preparing Your Web Content for iPad (via Ajaxian). Lycka till!

ps. Frågan om man bör utveckla en iPad-sajt eller inte återstår ju, men det tar vi i nästa bloggpost

wtai://<library>/<function> (; <parameter>)* [! <result>]

Med schemat kan man både ringa upp nummer och lägga till kontakter. Här är två konkreta exempel på hur det kan se ut i html-kod:

<a href=”wtai://wp/mc;0845000000″>08 - 45 00 00 00</a>
<a href=”wtai://wp/ap;0845000000;Anders”>Lägg till i kontakter</a>

Funktionerna ovan är MakeCall (=mc) och AddPhoneBookEntry (=ap). Läs hela specifikationen för wtai: här (pdf).

Vilket schema ska man använda?

Om man inte gör en mobilsajt skulle jag välja att använda tel: istället för wtai:. Dels för att tel: är det officiellt registrerade och rekommenderade schemat. Men även för att wtai: är utvecklat endast för mobiltelefoner medan tel: i teorin ska fungera på andra enheter också.

Wtai har tidigare haft större stöd bland mobiler än tel:, men frågan är om det inte håller på att ändras. Iphone stöder inte wtai:, vilket naturligtvis är ett stort avbräck. Apples iPhone Dev Center rekommenderar istället tel:, vilket också kan vara en anledning att använda just det schemat.

[tags]wtai, tel, callto, URL-scheman, länkar[/tags]