Dubbla arbetet när HTML5 och CSS3 slår igenom
Det känns som att vi snart närmar oss en brytpunkt. I och med Windows 7 och utrullning av Internet Explorer 8 via Windows Update så håller reliken IE6 på att försvinna. Efter en snabb uträkning av webbläsarstatistiken så verkar cirka 35% av webbläsarna ha bra (webkit) eller helt okey (gecko) stöd för CSS3 och HTML5.
Vi närmar oss alltså en brytpunkt snart där valet mellan att utveckla med HTML4 och CSS2.x samt HTML5 och CSS3. Det farliga ligger inte så mycket via CSS där det är enkelt att via conditional statements är enkelt att rikta sig mot felande webbläsare, jag är mer orolig för skiftet mellan HTML5 och HTML4. Nya taggar som canvas, header, video, article, footer med mera är väldigt lockande för utvecklare för att komma undan div-hell med nästlade divar i all oändlighet.
Det finns inget lika enkelt sätt att köra conditional comments för HTML
Kommer vi få se de klassiska “Only usable with Firefox/Chrome/Safari Version x.y”-rutorna (vilket Google Wave just nu tagit fasta på) eller kommer utvecklare skippa HTML5, och då hålla tillbaka utvecklingen och möjlig “tvingad uppgradering”, och köra vidare med HTML4?
Möjligheten för dubbla arbetet finns fortfarande, även om chansen inte är stor för utvecklare är by nature lazy. Men tänk om …
Personligen vill jag använda HTML5, och kommer troligen göra det i viss mån via mina egna sidor vilket inte har som målgrupp att fungera på IE6. Förhoppningen ligger fortfarande på Microsoft och IE9 att de har insett hur efter de ligger, nu har de löst många krav på säkerhet, UI och stabilitet. Dags att ta tag i nästa generations webbkodning också.
Box-shadow ger problem med transparenta bilder
På bloggen har jag aktiverat en del CSS3-egenskaper, bland annat box-shadow och text-shadow, vilket ger bra effekter när de används rätt och subtilt.
Idag upptäckte jag något som kommer gäcka och irritera många när CSS3 blir mer allmänt använt. Box-shadow och transparenta bilder går inte ihop.
Önskad effekt i exemplet ovan är att använda rundade hörn med en subtil skuggning runt. Men eftersom box-shadow enbart sätter skugga runt boxen och inte under så kommer den transparenta bilden tappa i effekt om den används.
Notera att padding är satt på 3px runt bilden i exemplet.
Exempel på hur du använder box-shadow
box-shadow: <horisontal offsett> <vertikal offsett> <blur> <färg>;
För att använda box-shadow redan nu så använd -moz-box-shadow samt -webkit-box-shadow.
Lösningen involverar mer CSS3
Hur man löser problemet är egentligen lika briljant som enkelt. Du använder ett annan CSS3 metod: border-radius.
På bilden i mitt exempel så sätter jag border-radius: 5px; -moz-border-radius: 5px; -webkit-border-radius: 5px; för att följa mitt rundade hörn.
Kommer följa upp denna bloggpost med mer ingående analys av både box-shadow och border-radius.
Använd taggar som ditt arkiv i WordPress
De flesta som bloggar eller driver en sida med några slags nyheter har ett arkiv med gamla inlägg. Ett arkiv i sin traditionella mening blir snabbt fullt och oöverskådligt då man listar alla inlägg som någonsin postats. Alla inlägg är även sorterade i kategorier som också blir fulla av inlägg, osorterat och överblicken försvinner.
Min idé är lite annorlunda
Istället för att prompt använda kategorier är min plan att använda taggar som arkiv istället. Istället för att lista alla inlägg på samma sida så visar jag ett tagg-moln vilket dynamiskt visar de ledord jag främst använder på mina inlägg. Fördelarna med detta är många:
- Du hjälper besökaren med överblicken av sidan. Vad som är störst är det som nämns och används mest.
- Du sprider och fördelar din länkjuice bättre, mer länkar = mindre kraft för varje enskild länk (typ SILO).
- En statisk kategori är oftast för generell och trubbig, taggen har en spets som är individuell för varje inlägg.
- Du undviker duplicate content om det används rätt.
- Taggarna är alltid up-to-date.
Arkiv med taggar i praktiken
Först och främst måste du ha All in One SEO installerat på din WordPress-blogg. Markera Use noindex for Categories för att se till att Google m.f inte indexerar dina kategorier längre. Notera att du fortfarande kan ha kvar dina kategorier, se bara till att de “försvinner” från Googles ögon då de kan utgöra en risk för att innehåll kan förekomma flera gånger.
Öppna temafilen archive.php med din favoriteditor, hitta the_loop och ändra the_content() till the_excerpt(). Vad vi gör att istället för att skriva ut hela inlägget i arkivet så skrivs ett utdrag från inlägget ut. Fortfarande så handlar det om risken för dubbla innehåll på sidan.
Öppna file archives.php (Märk skillnaden från ovan). i den här filen kan du ta bort det du känner för, det viktigaste är att infoga till tagg-moln någonstans. Funktionen som kommer användas är wordpress egna, wp_tag_cloud(), vilken är tillräckligt kompetent för det vi ska åstadkomma.
[php]
$args = array(
‘smallest’ => 8,
‘largest’ => 36,
‘unit’ => ‘pt’,
‘number’ => 75,
‘format’ => ‘flat’,
‘separator’ => ‘\n’,
‘orderby’ => ‘name’,
‘order’ => ‘ASC’,
‘link’ => ‘view’,
‘taxonomy’ => ‘post_tag’,
‘echo’ => true
);
wp_tag_cloud( $args);
[/php]
Vad de olika parametrarna gör förklaras mer i länken ovan.
För att fixa till problemet med att alla taggar får samma meta beskrivning så editerar vi header.php, Hittar <meta name=”description” … /> och byter ut mot:
[php] <meta name="description" content="<?php if (is_tag()) { single_tag_title(‘Arkiv: ‘); echo " | "; bloginfo(‘description’); } else { bloginfo(‘description’); } ?>" />[/php]
Detta bör fixa så att Google Webmasters Tool inte klagar för mycket.
Nu bör du ha ett bättre fungerande arkiv. Givetvis bör du komplettera med din populäraste poster, poster som kanske behöver lite extra exponering och en sökfunktion.
Resultatet kan ses live på min Arkivsida eller via skärmdump nedan.
Fortsättning på detta? Kanske ta bort kategorierna helt och enbart använda dem internt och fortsätta optimera så det som är relevant, enkelt och bäst ur de flesta synpunkter (användarsynpunkt/SEO/hantering) kommer fram.
Tips, idéer eller invändningar?
Typografera din webbdesign med font-face
Egentligen förstår jag inte varför inte @font-face används mer än vad det gör, cirka 75,41% av besökarna (siffror ska tas med en nypa salt som vanligt) stödjer inbäddade typsnitt på ett sätt eller ett annat. Internet Explorer (kors i taket) har faktiskt haft stöd sedan version 4, om än på ett annat sätt, vilket är ganska imponerande.
@font-face med typsnittet GrauBlauWeb
Nåväl, tänkte gå igenom lite snabbt hur du kan lösa snygga fonts för större delen av dina besökare, men även med typografisk fallback för de som inte har stöd för tekniken.
För det första så är det en stor skillnad vi måste reda ut, Internet Explorer stödjer enbart @font-face via sitt egna format .eot (Embeded Open Type) och inte .otf, vilket är det öppna typsnittsformatet, som resten av webbläsarna. Microsoft har därför lagt ut ett uråldrigt verktyg på 20MB som kan konvertera .ttf till oet. Detta känns krångligt eftersom det finns smartare vägar via onlineverktyg.
Verktygen som vi ska användas är först: Online font converter vilket konverterar typsnittet till .ttf, sedan ttf2eot vilket tar hand om den sista konverteringen till .eot. När .eot-filen är redo på din dator så är också du redo att implementera CSSen som krävs för att få det hela att fungera.
@font-face { font-family: 'namn'; src: url('din/katalog/namn.eot'); src: url('din/katalog/namn.eot?#iefix') format('embedded-opentype'), url('din/katalog/namn.woff') format('woff'), url('din/katalog/namn.ttf') format('truetype'), url('din/katalog/namn.svg#namn') format('svg'); font-weight: normal; font-style: normal; }
Byt ut “namn” till det du tycker att typsnittet ska heta i CSS-filen, helst och mest logiskt så döper man nog det till typsnittets namn.
.head { font-family: namn, Arial, sans-serif; }
Ovanstående kod är ganska simpel, namn är det namnet du har gett ditt typsnitt, Arial står för din fallback, som kan bytas ut till ett webbsäkert typsnitt som ser ut som det nya typsnittet. En fallback är att rekommendera för att fånga upp de sista 25% av besökarna som inte har stöd för tekniken.
Hoppas du har förstått grunderna i konceptet, det finns mer att läsa på css3.info och w3.org annars.
WWW-prefix ska inte spela någon roll
Idag 2009 ska man väl inte behöva bry sig om www framför webbadressen? Om en webbplats vill använda www, kör på, men lös ändå ändå en 301-redirect ifall någon som skriver adressen utan www-prefixet.
Om jag skriver example.com och får fram ett fel så är det föga troligt att jag testar med www före. Det behövs nog inte påpekas hur många besökare och eventuella intäkter som kan gå förlorade på detta.
Studentkåren Sundsvall är ett dåligt exempel
Att lösa problemet är inte svårt, om man kör med Apache och har mod_rewrite aktiverat så är det enbart lägga in ett par rader i sin .htaccess:
[sourcecode language="plain"]RewriteCond %{HTTP_HOST} ^example.com$
RewriteRule (.*) http://www.example.com/$1 [R=301,L][/sourcecode]
ASP.NET användare kan kolla in Response.Status och Response.Addheader, kör du PHP så fungerar header() fin-fint för en redirection.
Enkelt, smidigt och klart mer tillgängligt.
Problematik kring val av språk på en webbplats
Scenariot jag står inför idag är hur ett val av språk ska fungera på en sida som ska översättas på flera olika språk. Problemet ligger inte i hur jag ska komma runt problemet med att lösa en funktion som ändrar språket på sidan, utan mer hur det ska visas så inga missuppfattningar uppstår.
Språkval hos Försäkringskassan
W3.org skriver: Do not use flag icons to indicate languages.
Och jag håller med resonemanget, en flagga som indikator för ett språk är en otroligt dålig idé. Tänk på svenskan som ett dåligt exempel – svenska pratas i Sverige och vissa delar av Finland, ska då en från Finland välja en svensk flagga för att få språket på sitt egna språk? Samma problematik finns för Kanada, USA och Storbritannien, alla talar engelska med vissa små variationer, ska de behöva välja Storbritanniens eller Amerikanska flaggan? Eller är engelska så globalt att det går att visa som en ikon över jorden?
Förslaget som W3 skriver om att använda text för språk istället för en ikon är bättre, men ger upphov till viss mer problematik ändå. En besökare som kommer in på webbplatsen scannar av sidan snabbt och fokuseringen ligger främst på grafik och inte lika mycket på text till att börja med. Hur ska man utforma språk-funktionen så att den blir synlig, som ikoner, men fortfarande är funktionell?
Informationen jag funnit om detta är främst äldre, 2006 och bakåt, och det verkar inte har blivit så mycket mer nytänk över detta sen dess. FunkaNu har sitt förslag med ikoner – men de är både små och komplicerade, man kan inte förvänta sig att en besökare förstår skillnaden på EN och SV.
Vad de flesta av undersökningarna och tänkarna har missat är en användares vana. På nätet är vi idag relativt vana och bekväma med att välja en flagga. Vi förstår att den amerikanska och den brittiska flaggan representerar i stort samma språk, vi vet att svenska flaggan står för svenskt språk med mera. Med detta i fokus – är det verkligen så illa att välja en flagga istället för text i så fall?
Hur tänker du vid de här situationerna? Flagga eller flagga+text eller enbart text?
Den perfekta balansen inom webbdesign
Du har en webbplats, du har ett mål med webbplatsen med att den ska vara perfekt inom alla områden. Snart inses det dock bland ditt team av webbdesigners, webbutvecklare, seo-magiker och experter inom affiliate och annonsintäkter att det inte går att göra ett område perfekt utan att försaka ett annat.
Stock: sxc.hu
Din webbdesigner har oftast expertis på layout, funktionell och användbar webb. Han säger att allt ska anpassa och fixas så att största möjliga målgruppen ska nås. En meny måste se ut på detta viset och ha visst antal submenyer för att underlätta navigering och framkomlighet. Tekniken måste absolut vara bakåtkompatibel med alla versioner av de flesta webbläsarna.
Din SEO-expert kommer in och säger att så här kan det inte se ut, eftersom Google och bing rankar webbplatser bättre på sätt Y istället för detta sättet – hur bra det ändå må vara mot kunderna – så måste vi ju synas. Rankar vi inte si och så mycket på dessa ord så kommer allt arbete vara bortkastat.
Webbutvecklaren kommer in och säger mer han inte bryr sig så mycket om det här som syns, han vill göra häftigare funktioner och cool dynamik mellan tjänsterna. “Tänk om” samt “Vad häftig om” är vanliga meningar, han kräver att allt som går att göra görs.
Experten på affiliate kommer sedan in och kräver annonsplacering. Han är oftare mer inne på SEO-magikerns spår eftersom “mer trafik, häftiga intäkter och kurvor”. Nej, sidan ska besudlas med så mycket annonser och affiliate-länkar som möjligt. Helst ska många ord länkas så folk klickar bort från sidan så mycket som möjligt.
Texten ovan är smått (ganska) överdriven, men poängen är detsamma. Vad är den perfekta balansen mellan funktion, design, annons, seo och användbarhet?
Credit where credits due
Blev idag kontaktad av en webbdesigner, låt oss säga webbdesigner XY, för att inte peka några finger, XY hade en förfrågan om jag kunde hantera konvertering från .psd till wordpress-tema åt honom. Visst, sa jag direkt – men vad blir min ersättning och kommer jag få någon credit för jobbet?
Vad han svarade glömmer jag aldrig:
Nej, alltså, du gör detta gratis. Det är mitt namn som kommer stå på temat och jag som senare kommer få in ersättning för jobbet. Du kan inte räkna med att få sätta ditt namn på den färdiga lösningen.
Svaret chockade mig lite, speciellt den första biten – att hans namn enbart skulle stå på jobbet. Detta skulle i praktiken betyda att jag, som person, lägger ner x antal timmar på ett jobb som jag aldrig ens kommer få någon ära för, och som de flesta vet så är ära något som betyder extremt mycket för framtida kunder och framtida försäljningar.
Missförstå mig nu helt rätt. Jag har ingenting att gör något för föreningar eller för syften som jag är involverad i helt gratis, där får jag alltid uppskattning och arbetet jag gjort blir ändå erkänt. Men jag kommer nog aldrig göra så mycket för någon annan där jag får noll credit/ersättning för arbetet jag gör, speciellt inte som frilansare.
CSS-ramverk fyller ingen funktion
Helt plötsligt kom de som svampar från jorden – CSS-ramverk. Direkt höjdes mina ögonbryn och funderingen – varför?
Att bygga en webbplats med tillhörande CSS-regler skiljer oftast så mycket från projekt till projekt att det enbart är ett fåtal regler man oftast använder igen och igen. Baseras då webbplatsen på ett ramverk som tar 15KB eller mer så säger ju logiken sig själv – hur många KB använder du av det ramverk du använder? Ju större ramverk, ju mindre du använder av det, desto mer behöver besökaren ladda hem i onödan. Argument som att alla har bredband håller inte, speciellt inte i en webb som håller på att bli mobil med både bredband och mobiltelefoner.
Att bygga sitt egna ramverk är däremot en betydligt bättre idé, du kommer bygga det från grunden med de regler och funktioner som du vill utgå och bygger dina sidor med och därmed elimineras allt skräp som ett publikt ramverk innehåller. Vad ramverket kan innehålla är grunderna till din layout – det vill säga regler för header, content, några reset-regler för de element du ska inkludera i din webbsida och generella regler som .clear, .left och .right. Den tid du lägger på detta kommer snabbt sparas in, det kommer bara ta några projekt sen är du i hamn.
Resonemang mot flashsidor
Gick igenom mitt flöde innan och hittade 10 anledningar varför flash oftast suger skrivet av joinsimon. Kom direkt att tänka på en speciell webbyrå här i staden som gjorde ett karismatiskt men ytterst tveksamt framträdande för något år sedan för oss blivande webbdesigners. VDn som kom in som en storm och talade med stora ord om webbdesign och utveckling var visserligen hänförande att lyssna på men jag kollade på honom med stor skeptisk blick.
Hans övertygelse var att allt på webben kommer vara flash och flash är det absolut bästa, otroliga och saldo-fyllande tekniken som någonsin skapats. Mina frågor om flash som enda teknik undveks mycket skickligt och personligen kände jag att flash är något jag kommer ge blanka fan i.
I bakspåret av flash-blockerare, hat från användare och artikeln ovan så känns mitt val ganska rätt – flash irriterar oftare än vad det bidrar till funktion och jag skulle aldrig välja flash framför en lösning utan tredje-parts plugins.
Ta sig iväg från pluggandet
Livet består en stor del med att plugga, vägskäl vart man tar vägen och val man gör som påverkar sin situation. Nu är jag vid ett stort vägskäl – min magkänsla skriker på mig att börja jobba istället för mer plugg, mitt huvud säger att det kanske inte går att få jobb och folk skriker åt mig att de vill ha mina tjänster.
Jag är förbryllad och vet inte hur jag ska göra, jag har enbart en sak till att göra innan examen men jag vet inte om jag kan tacka nej till erbjudanden mer snart. Nästa stora erbjudande kommer jag troligen känna att detta är för bra för att vara sant så det kommer jag ta.
Tills dess – plugg, examensarbete och jobbande vid sidan av som är på agendan.
Missbruk av kolumnfunktionen i CSS3
Det snackas mer och mer om CSS3 och jag är en av de personerna som verkligen väntar på att det ska gå att använda fullt ut. En tanke slog mig för ett tag sedan när jag skrev om kolumn-bredd och radlängder, CSS3 kommer få stöd för flerkolumn-layouts i texter.
Detta kan skapa lite problem om det inte används rätt, eller används utan eftertanke på långa texter. Att ha långa kolumner fungerar jättebra i böcker, tidningar och i annan tryckt media, webben har en helt annan förutsättning. Ögat kan inte scanna av sidan på samma sätt för att få en överblick – man måste helt enkelt skrolla ner sidan för att veta hur sidan är uppbyggd, hur mycket text som finns och för att hitta det man vill åt.
Tillåt mig att demonstrera ett exempel på en längre text uppdelad i två kolumner.
Vänster: Långa kolumner nedåt. Höger: Korta kolumner nedåt.
Till vänster är en lång text. Funktionen blir att man läser ända ner till botten av texten för att sedan få scrolla upp igen och börja på andra kolumnen.
Min idé är att istället använder sig av ett fler-kolumnsystem som platsar på de flesta skärmar. Det vill säga – besökaren läser vänster sedan högerkolumnen innan man går nedåt på sidan. Givetvis får man separera de olika kolumnblocken med bilder, underrubriker eller liknande för att ge läsaren en chans att navigera genom texten.
Hur kolumnsystemen kommer påverka användbarheten och tillgängligheten på webbplatser återstår att se. Förhoppningen ligger i att det kommer användas på rätt sätt och inte skapa fler problem än funktionen löser.
Relaterade poster i WordPress utan att förstöra kommentarerna
Ett par timmar har gått åt till att få igång en egen relaterade poster funktion till WordPress. Själva scriptet är inte ett dugg konstigt utan kan hittas lite överallt även om jag ville sätta en egen twist på det hela.
Målet var att skapa en funktion som visar bilder samt titeln på inlägget istället för en vanlig tråkig lista. Koden jag använde (utan CSS) blev till slut följande.
[code language="php"]
$tags = wp_get_post_tags($post->ID);
if ($tags) {
$tag_ids = array();
foreach($tags as $individual_tag) $tag_ids[] = $individual_tag->term_id;
$args=array(
'tag__in' => $tag_ids,
'post__not_in' => array($post->ID),
'showposts'=>3, // Number of related posts that will be shown.
'caller_get_posts'=>1
);
$my_query = new wp_query($args);
if( $my_query->have_posts() ) {
echo '<div class="related-posts"><h3>Möjligen relaterat innehåll</h3><ul>';
while ($my_query->have_posts()) {
$my_query->the_post();
?>
<li>
<a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>">
<img src="<?php echo get_bloginfo('template_url'); ?>/thumb.php?src=<?php echo catch_that_image('default2') ?>&w=150&h=100&zc=0&q=100" alt="<?php the_title(); ?>"/>
<span><?php the_title(); ?></span></a>
</li>
<?php
}
echo '</ul></div>';
}
}
Jag använder helt enkelt den klassiska funktionen catch_that_image(), med en lite twist för att få olika storlekar på defaultbilden, och thumb.php för att visa bilden och sen är resten som vanligt.
Problemet som visade sig var att även att wp_query() kallades med new, vilket i min bok kallas för en ny instans av objektet, så sattes alla kommentarsvariabler till den senaste relaterade posten med kommentarer. Detta är en sidoeffekt som direkt inte är önskvärd.
Lösningen är väldigt enkel: spara variabler och återanvänd dem. Innan jag börjar min nya loop så sparar jag ner ett par variabler från den gamla loopen.
[code language="php"]
$old_comment = $comments; $old_id = $id; $old_post = $post; $old_withcomments = $withcomments;
Och efter loopen återställer jag helt enkelt värdena som de var innan.
[code language="php"]
$comments = $old_comment; $id = $old_id; $post = $old_post; $old_widthcomments = $withcomments;
Nu får vi fram exakt den effekten som önskades från början, allt som krävs är lite CSS-magi. Resultatet kan du se under detta inlägget.
Smidigaste sättet eller är jag fel ute?
Typografi på webben, radlängd och blockstorlek
Problemet med CSS, och typografi på webben i övrigt, har varit hur man ska kalkylera blockstorleken på ett element för att det ska bli “lagom” längd att läsa. Problemet ligger oftast att längden varierar med textstorleken man väljer så det finns aldrig något definitivt och att en underliggande regel, speciellt för många webbdesigners, har varit att 550px är lagom för 11px-12px text.
Fel, fel och fel. För längre texter är det otroligt jobbigt att läsa så bred text, satsa hellre på att krympa ner än att öka upp blockstorleken om ni vet att mycket text kommer publiceras i blocket.
Typografiska regler på webben är som sagt fortfarande ganska nytt, bestritt och ingenting som egentligen är huggit i sten, men det finns ändå en del tankar som man kan kalla för “best praxis”.
Textstorlek*30+100=kolumnbredd
Tekniken består i att ta din text-storlek och multiplicera den med 30. Det vill säga: 12*30 = 360px. Du kommer säkert hamna på ett snitt av 60-65 bokstäver per rad och allt är väl. Men, dagens skärmar och upplösningar låter oss tänja lite på denna regeln. Metoden kommer ursprungligen från Robert Bringhurst men jag tycker inte den riktigt kan anpassa mot webb.
Vad jag anser så fungerar det lika bra att slänga till ~100px extra, främst eftersom man kan infoga lite mer intressanta bilder och väga upp “god typografi” på annat sätt. Tänk ändå på att hålla intervallen ca 40 till ca 80 tecken på en rad.
Top secret SEO
Stefan på Innovatoren har upptäckt hur proffsen egentligen gör. det handlar inte om att optimera, det handlar om kontakter.