Det fina med Espresso är, framför allt om du har två skärmar, att du ser ändringarna på sajten direkt medan du grejar i CSS-koden. Du kan också hitta vilka stilregler som påverkar ett speciellt objekt på sidan genom att klicka på det. Lite som webbläsarpluginet Firebug fast med fördelen att du kan spara dina ändringar direkt.

Några schyssta features i Espresso:

• Se dina CSS- och HTML-ändringar på webbsidan samtidigt som du gör dem
• Visuella verktyg för att ange CSS-kod (även CSS3 som skuggor, toningar etc)
• Synka och publicera filer mot ditt FTP-konto automatiskt (om du önskar)
• Smidigt att växla mellan olika filer som berör webbsidan medan du redigerar
• Färgkodning, automatisk komplettering för HTML5, CSS3, Javascript, PHP, Python mm.

Programmet kostar $79 (ca 500 kr), men du kan ladda ner och prova programmet gratis i 15 dagar.

Vilket är ditt favoritverktyg för CSS-kodning (gärna tips för Windows och Linux)?

Några av de många nyheterna i HTML5:

• Data kan lagras lokalt i en databas, vilket gör att du även utan uppkoppling kan komma åt och redigera t ex Google Docs-dokument (Google har en egen lösning för detta redan Google Gears).
• Videouppspelning direkt i webbläsaren utan plugins som Flash, Silverlight eller annat.
• Formatera text (t ex fetstil, kursiv, färg) utan tunga javascriptlösningar som idag krävs för att skapa textredigering i stil med den som används när du t ex redigerar inlägg i WordPress.
• Canvas-element gör det möjligt att skapa avancerade gränssnitt utan t ex Flash eller Silverlight.

Som du kan se kommer många av de saker som idag kräver tunga och plattformsberoende plugins finnas direkt i alla webbläsare.

Nyheterna i CSS3 gör att ännu större del av formen kan placeras direkt i CSS istället för i bilder. Det blir på så sätt mindre data att ladda och mycket enklare att anpassa sidan för olika kanaler (storlekar på datorskärmar, mobiltelefoner, utskrift mm).

Några av nyheterna i CSS3:

• Skuggor. Det går fint att lägga till skuggor på text eller andra objekt direkt i koden.
• Rundade hörn. Det krävs inte längre ett gäng bilder för att göra en ruta med rundade hörn.
• Opacitet. Äntligen en enhetlig standard för att göra färger och objekt halvtransparanta.
• Övertoningar. Tona från en färg till en annan utan att blanda in Photoshop.
• Fler bakgrundsbilder. Varje objekt kan innehålla fler än en bakgrundsbild.
• Kolumner. Webbläsaren klarar automatiskt av att hantera kolumner, inget mer manuellt brytande av flödande text.

Trots att standarderna inte är spikade än så har de stora webbläsarna börjat implementera många av komponenterna i både CSS3 och HTML5. Undantaget är (som vanligt?) Microsoft Internet Explorer som har väldigt svagt stöd på båda fronterna i version 8. Som tur är är Explorer 9 på god väg och där lovar Microsoft att istället ligga i framkant (kolla in betan här).

Eftersom det fortfarande är många webbläsare som inte stödjer en stor del av de nya standarderna så kan det vara bra att använda dem med måtta. Använder du rundade hörn och skuggor på vissa objekt på din webbsida får du leva med att de blir kantiga och skugglösa för en ganska stor del av besökarna än så länge.

Det finns massor av roliga och bra exempel på nätet vad de nya standarderna kan prestera. Här följer ett par (många av dessa kräver Apple Safari eller Google Chrome för att fungera i dagsläget – ett perfekt läge att prova en ny webbläsare om den du kör idag inte har hängt med i utvecklingen  ):

• Jeff Batterton har ”ritat” en Iphone med hjälp av CSS3, helt utan bilder.
• Apple har i sin kamp för HTML5 tagit fram ett antal exempel på hur öppna webbstandarder kan ersätta t ex Flash.
• Spelbar demo av det klassiska spelet Wolfenstein 3D.
• Fallande löv
• Tweets flyger omkring som bollar (kan inte förklara, klicka på dem för att förstå ).
• Sketchpad knäcker MS Paint vilken dag som helst.

Hur mycket använder du dig av HTML5 och/eller CSS3 idag, och till vad?

Detta är ju trevligt, men det är också funktioner som är kul att se en, två gånger, sen stänger man av dem och börjar surfa. Så vad finns det för verkliga nyheter i Safari som man faktiskt har praktisk nytta av? Detta är min högst subjektiva lista från de fem första dagarna med Safari 4 Beta som standardläsare.

Precis som i Google Chrome har webbsidesflikarna flyttats till fönstrets översida och namnlisten på programmet tagits bort. Detta gör att ytterligare skärmyta frigjorts till förmån för hemsidesinnehåll, mycket trevligt på ett datorsystem som inte anammat konceptet fullskärmsläge.

Inbyggd Google-sökning med automatisk föreslagning av sökord.

Bättre sökning i adressfältet. Borta är dropdown-listen, nu får man istället riktigt rapp hjälp med potentiella adresser när man börjar skriva in önskad URL.

Som gammal Firefox-användare är det skönt att man nu kan hoppa mellan tabbar med Ctrl-Tab istället för Kommando-Shift-Pil.

För oss som designar webbsidor och lagt till Develop-menyn (aktiveras under Advanced-fliken i inställningarna) så finns nu massor av uppdaterade godbitar i Safaris Web Inspector, något som jag direkt hade nytta av när vi felsökte lite JavaScript i bloggen och då enkelt kunde exekvera JavaScript-funktioner direkt från Web Inspectorns kommandotolk. Dessutom finns det finfina verktyg för debugging och profiling av JavaScript och inspektion av element i ens HTML-kod (ungefär som en vackert designad version av Firebug för Firefox).

För de som gillar webbstandarder (och vem gör inte det?) så är det kul att äntligen se en officiell version av en webbläsare som helt och hållet klarar av Acid3-testet (vad är det?). Nedan (från vänster till höger) ser vi som jämförelse Firefox 3.0.6, Google Chrome, Internet Explorer 8 Beta och Opera 9.63 och så sist men inte minst Safari 4 Beta.

Precis som Firefox 3 har Safari nu full page zoom, dvs om du zoomar in eller ut på en sida så är det inte bara texten som påverkas, utan hela sidan zoomas korrekt utan att den trasas sönder av ”felaktig” storlek på text. Precis som det ska vara med andra ord.

Enligt Apple exekverar Safari 4 Beta JavaScript sex gånger snabbare än IE8 och fyra gånger snabbare än Firefox 3.1 och det märks att den är riktigt rapp – skönt.

Finns det då något som jag inte gillar med den nya versionen av Safari? Ja, av någon anledning pajjar kontrollpanelen i WordPress (2.7.1) när man ska lägga till en länk i sitt inlägg, något som funkade utmärkt i gamla versionen av Safari, men jag förväntar mig en fix när som helst.

Har du provat 4:an? Något du tycker jag glömt tagit upp här ovanför eller har du andra synpunkter på Safari? Dela med dig bland kommentarerna.

Men – är detta viktigt och varför ska jag bry mig?

Varför HTML i e-posten?

En stor del av all e-post som skickas idag är formaterad som HTML. Detta helt enkelt för att det ger mottagaren en bättre läsupplevelse. Vem ser det dessutom inte som självklart att kunna ha med en bild mitt i sitt meddelande, utan att denna ligger som en bilaga man måste öppna i ett separat bildprogram?

För något år sedan var stödet för HTML helt okej i de flesta fristående e-postklienter som Outlook, Outlook Express, Thunderbird, Entourage och Eudora. När Microsoft sedan släppte bomben Outlook 2007 så ställdes allt detta på ända.

Från att i äldre versioner av Outlook haft Internet Explorer för att visa HTML-formaterade e-postmeddelanden, så gick man nu över till att använda Microsoft Word (!) – ett program som ganska förståeligt har ett betydligt mer begränsat stöd för HTML. De av er som prenumererade på vårt nyhetsbrev vid den här tiden, och bytte till Outlook 2007, märkte genast detta genom att layouten helt plötsligt såg mycket mystisk ut.

För att bringa lite ordning i all den oreda som bland annat detta gav upphov till (Microsoft Outlook är ju som bekant en väldigt vanlig e-postklient) startades för en tid sedan the Email Standards Project vilket är något av ett gräsrotsprojekt för att få tillverkarna av e-postapplikationer att stödja aktuella webbstandarder.

På samma vis som för webbläsare har man således tagit fram ett så kallat acid-test via vilket man testar e-postklienternas stöd för aktuella webbstandarder. Via projektets hemsida kan du som skall designa HTML-baserad e-post (för hand) dessutom enkelt se vad dagens vanligaste e-postklienter stödjer (eller inte stödjer).

Så – bör man då använda HTML?

HTML är här för att stanna – helt enkelt för att det förhöjer läsupplevelsen så markant. Som e-postdesigner är detta således något man får leva med. Då Outlook är en så pass vanlig e-postklient, kan det vara en god idé att designa sina brev efter det programmet – de flesta andra klienter fixar ju kalaset ändå. Dessutom bör du även bifoga en ren textversion av brevet – då kan ju faktiskt alla läsa ditt brev.

Mer information om vad exakt Outlook 2007 stödjer i HTML-väg (och inte stödjer) hittar du på denna sida.

Vi har tidigare berört XML i artikeln HTML vs XHTML. Men varför har det blivit så populärt och hur kan du använda det?

Att använda XML

XML är alltså ett sätt att lagra data. Att det blivit så populärt beror sannolikt på att det är generellt och lätthanterligt och att det således fått stöd i praktiskt taget alla programspråk. Dessutom är det en öppen standard som kan användas av alla.

Både HTML och XML baseras på SGML, därför är tankesättet bakom dem snarlikt och för den som arbetat med HTML är därför XML enkelt att förstå.

Om du har en adressbok och vill spara kontaktinfo om dina vänner i XML så skulle detta kunna se ut så här:

<addressbook>
  <contact>
    <firstname>Fredrik</firstname>
    <surname>Berglund</surname>
    <phonenumber type="home">
      021-XXXXXX
    </phonenumber>
    <phonenumber type="cellphone">
      070-XXXXXXX
    </phonenumber>
  </contact>
  <contact>
    <firstname>Jimmie</firstname>
    <surname>Eriksson</surname>
    <phonenumber type="home">
      021-YYYYYY
    </phonenumber>
    <phonenumber type="cellphone">
      070-YYYYYYY
    </phonenumber>
  </contact>
</addressbook>

HTML är ju som bekant ett textbaserat format, och sålunda även XML. Därför är det lätt att förstå innehållet i en XML-fil. Skulle vi nu vilja läsa in denna adressbok i skriptspråket PHP (som givetvis har stöd för XML, i detta fall med tillägget SimpleXML), och sedan skriva ut hemnumret till Jimmie Eriksson, så skulle vi kunna göra detta på följande vis (utan felhantering):

<?php

  $xml = simplexml_load_file('addressbook.xml');

  foreach($xml->contact[1]->phonenumber as $number)
  {
    switch ((string) $number['type'])
    {
      case 'home':
        echo $rating
        break;
    }
  }

?>

Här läser vi in adressboken som vi lagrat i filen addressbook.xml. Hela tanken med XML är att allt data sparas i en trädstruktur. Först besöker vi därför kontakt nummer två (contact[1]) där data om Jimmie finns lagrad (börjar på 0), sedan itererar vi igenom de telefonnummerstyper som finns där. När vi sedan hittar typen home (hemnumret) så skriver vi helt enkelt ut det på skärmen.

Enkelt och smidigt – precis som det ska vara!

Ett av dessa är skrivaren, något som kan vara mycket intressant för just hemsidesskapare.

Gör om, gör rätt

Alla har vi sett webbsidor med länkar kallade klicka här för en utskriftsvänlig version eller något snarlikt, länkar som i sin tur laddar en nedbantad version av samma sida.

Problemet med detta förfarande för utskrift av webbsidor, är att det kräver att hemsidesskaparen (eller för den delen ett skript) hela tiden skapar två versioner av samma dokument – och det är bland annat sådant som CSS finns till för att lösa.

Så, hur berättar du då för webbläsaren att du har CSS-kod för både skärm och skrivare? Jo, genom att ange följande i head-sektionen av ditt HTML-dokument:

<link rel="stylesheet" type="text/css"
   href="screen.css" media="screen" />
<link rel="stylesheet" type="text/css"
   href="print.css" media="print" />

Genom att ange olika media-attribut så kan du tillhandahålla olika formatering beroende på media (print och screen är alltså bara två av ett flertal olika alternativ).

När besökaren i detta fall besöker din sida och sedan väljer att skriva ut den, formaterar webbläsaren automatiskt om innehållet så att det följer de riktlinjer du angivit i filen print.css – detta medan riktlinjerna angivna i filen screen.css gäller för presentationen på skärmen.

Det finns dock en del skillnader vad gäller formateringen för skrivare, gentemot vanlig formatering för skärm. Egenskaper unika för pappersmedia finner du samlade här. Läs gärna även den välskrivna handledningen i ämnet hos A List Apart och börja nyttja den verkliga kraften hos CSS redan idag (och sluta jobba dubbelt bara för att kunna låta dina besökare skriva ut din webbsida ordentligt).

Lycka till!

Barn av SGML

Både HTML och XHTML är så kallade märkspråk (markup language). Dessa baserar sig i grund och botten på det anpassningsbara märkspråket SGML och är för det otränade ögat ytterst snarlika. Skillnaden mellan de två är att HTML är en direkt tillämpning av SGML, medan XHTML baseras på XML, som i sin tur är en restriktiv tillämpning av utvalda delar av SGML. Båda märkspråken tillåter dig dock att åstadkomma exakt samma saker.

Det fina med XML och XHTML är att dokument som är byggda med dessa tekniker måste vara välforumlerade, dvs, de måste följa standarden till punkt och pricka. Om ett program som avkodar ett XHTML-dokument (eller vilket XML-dokument som helst för den delen) stöter på något som inte följer standarden, så har programmet rätt att helt sonika avbryta avkodningen och visa upp ett felmeddelande. Detta skiljer sig drastiskt från HTML-dokument, där HTML-parsern (avkodaren / webbläsaren) i regel är väldigt förlåtande gentemot felaktigt skrivna HTML-dokument.

Det finns således flera fördelar med XHTML och XML framför HTML. För det första är det betydligt enklare att skriva ett program som avkodar dessa typer av dokument då det inte krävs tillnärmelsevis lika mycket felhantering. Detta har gjort att stödet för XML blomstrar i olika typer av programmeringsspråk samt att mängder av dokumenttyper numera baserar sig på XML då det är så lättbearbetat (ett känt exempel är senaste versionen av Word som sparar sina filer i XML-formatet .docx samt ”konkurrenten” .odt som används av bland annat OpenOffice.org). Då XML-baserade dokument är enklare och smidigare att avkoda / traversera lämpar de sig dessutom bättre för resurssvaga enheter som exempelvis mobiler.

Vidare hjälper en strikt standard som XHTML hemsidesmakare att skriva korrekta dokument (även om det givetvis kan vara bekvämt med ett mer förlåtande märkspråk som HTML). Uppstår ett fel så bör webbläsaren helt sonika visa ett felmeddelande istället för att försöka reparera och visa den ”trasiga” hemsidan (i praktiken fungerar det dock sällan på detta viset). Till sist minskar dessutom risken att en hemsida ser olika ut i olika webbläsare – detta då det finns ett visst mått av godtycke när det gäller att hantera felaktigt skrivna HTML-dokument.

Är det alltså XHTML jag bör använda?

Svaret på denna fråga blir både ja och nej. Som du ser ovan finns det flera fördelar med XHTML gentemot HTML – kan du HTML är det dessutom en barnlek att gå över till XHTML.

Problemet idag är dock ett relativt sett dåligt stöd från många webbläsare och då primärt Internet Explorer som förvisso kan visa XHTML-sidor, men som kräver att de servas som ett HTML-dokument istället för som ett riktigt XML-dokument. Detta gör att många av fördelarna med XHTML, dvs snabbare avkodning och betydligt resurssnålare avkodare (webbläsare) ändå går förlorade. Dessutom pågår fortfarande utvecklingen av HTML, och W3C (organisationen bakom standarder som HTML, XHTML och CSS), rekommenderar i dagsläget både HTML och XHTML.

Vilken av dessa två standarder man väljer blir således mycket en smaksak*. Ett strikt men enkelt format att avkoda (XHTML) eller ett förlåtande men betydligt mer resurskrävande format (HTML).

* Ovanstående inlägg visar således, med all önskvärd tydlighet, författarens preferens.

HTML Validator

Ladda hem.

För att din hemsida skall fungera problemfritt i både dagens och framtidens webbläsare så måste den validera – dvs följa W3Cs standarder, varav en av de viktigaste är HTML. Ett enkelt sätt att kontrollera detta är med insticksprogrammet HTML Validator. Varje gång du besöker en sida så kontrollerar den huruvida koden är korrekt och visar dig resultatet med en liten ikon i webbläsarens nedre högra hörn. Dubbelklicka på ikonen för att få fram källkoden och markeringar om eventuella fel.

Web Developer

Ladda hem.

Insticksprogrammet Web Developer erbjuder dig en hel flora med smarta funktioner för att undersöka hur hemsidor är uppbyggda och hur de beter sig. Bland annat låter den dig validera JavaScript, ändra webbläsarens fönsterstorlek till vanliga skärmupplösningar, markera ut HTML-objekt när du för muspekaren över dem, visa sidan utan CSS, utan bilder eller utan JavaScript, stänga av cookies och mycket, mycket mer.

Firebug

Ladda hem.

Firebug låter dig inspektera och i realtid editera din HTML-kod, CSS-kod och JavaScript direkt genom webbläsaren. Bland annat kan föra muspekaren över en hemsidas element och direkt få fram den del i HTML-koden som byggt upp det elementet, med tillhörande CSS-inställningar. Gillar du inte vad du ser kan du ändra koden och direkt se resultatet. Felsökning deluxe och ren magi.