Responsive Facebook Like Box & Twitter Follow Button
Här i menyn till höger kör jag en Facebook Like Box och en följ-knapp för Twitter. När jag nu arbetar för att få varje litet element i detta WordPress-tema att agera responsive så stötte jag ganska snabbt på patrull på grund av deras fasta bredd.
Man lär sig något nytt varje dag, background-position-x/y
Labbade lite med en bakgrundsbild i min footer igår. En simpel bakgrund i body-elementet och sedan background-position-x/background-position-y för att positionera ut den absolut korrekt på sidan.
Readmore-länk bredvid föregående text i WordPress
Krånglig rubrik men problemet är lite mer lättföreståligt. Tänk en typisk startsida i WordPress som är uppbyggd med the_content(‘Läs mer’); (eller liknande). Allt är fint men du kommer helt plötsligt på att Läs mer ska ju ta vid där föregående text slutade! Problem direkt!
Enkelt sätt för att få två kolumner till samma höjd
Att få två kolumner att ständigt ha samma höjd i ren CSS är pain-in-the-ass rent ut sagt 9 gånger av 10, speciellt om du inte vill bland in bilder i din lösning.
Overflow hidden och position absolute
Tänkte ta upp en liten fallgrop jag råkade ut för ett tag sedan när det handlar om CSS och elementen overflow kombinerat med position absolute. Läs hela inlägget →
Små tips för att förbättra hastigheten på din webbplats
Det är alltid trevligt med webbplatser som är riktigt snabba och när det verkligen känns att vi tagit oss ur tidsåldern där 512kbit ADSL och modem utgjorde de största farthindarna på webben. Även att mobila lösningar som än en gång är slöa så kan man göra mycket för att optimera hastigheten och ändå behålla funktionerna på webbplatsen.
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.
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.
Webbsäkra färger – ingenting att bry sig om
Svar på frågan: Webbsäkra färger, något man behöver bry sig om?
Fortfarande idag finns det många applikationer inriktade mot webbdesign, grafisk design och ritande som har en färgpalett som heter “websafe colors“. Frågan är varför, eftersom vi knappt behöver bry oss om det i dagens läge?
Anledningen till att just dessa 216 färger kallas webbsäkra är att i urminnes tider så hade inte skärmarna högre färgomfång än 256 färger. Av dessa 256 färger så var en 10-20 stycken reserverade för operativsystemet.
Min första PC köptes 1997, grafikkortet på 4 MB och hade en otrolig färgomfång på cirka 16 miljoner färger. Dessa webbsäkra färger är alltså en kvarleva sedan innan dess.
Kort svar på frågan: Nej, du behöver inte bry dig om webbsäkra färger längre, i princip kommer samma sak snart hända med typsnitt i och med @font-face och CSS3.
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.
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.
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.
CSS Naked Day ’09
Dags igen för 9 April, dvs den internationella högtiden och firandet av webbstandarder. CSS Naked Day 09 har precis börjat. Jag firar genom att strippa ner och klä av Cynatic dess kläder – dvs designen och visa det som finns bakom och att man tror på semantik, validering och en god struktur. Svenska bloggar som deltar finns på Nikke Lindqvist blogg
Mer info: http://naked.dustindiaz.com/
Länktips: 5 snabba om CSS selectors
Har skrivit en gästartikel borta på webbrelaterat om CSS och dess selectors och pseudofunktioner.
Artikeln handlar om hur man på bästa sätt kan använda selectors för att styra utseendet på HTML-koden på sin sida. Finns också bra tips hur man kan minimera antalet wrappers eller extra taggar bara genom att vara smart i sin CSS-kodning.
Spring iväg och läs 5 snabba om CSS selectors och pseudoklasser nu!
Float float och mer float!
Hade en diskussion med en kompis för något år sedan om floatade element och varför tre eller fler floats inte fungerar utan fler än en container. Enligt honom så var man tvungen att nästla flera wrappers beroende hur många floats i sidled man ville ha. Jag funderade inte mer på det men det finns tydligen ett sätt!
Tänk att vi har sex stycken element som vi vill ska flyta från vänster:
[code language="html"]
Nu vill vi att alla element ska lägga sig fint jämsides. CSS fixar som vanligt biffen.
[code language="css"]
#wrapper { background-color: #ccc; min-height: 200px; float:none; }
#float1, #float3, #float5 { background-color: red; }
#float2, #float4, #float6 { background-color: blue; }
#float1, #float2, #float3, #float4, #float5, #float6 { float: left; width: 200px; height: 200px; }
Som ni ser är alla element float: left, med storlek 200 pixlar. Det extra som ni bör notera är float: none; i #wrapper vilket är ett ful-hack för att förhindra ett element att flyta iväg (enkelt förklarat).
Full demo på /lab/float sidan.