frågan kommer senare lyda: “Hur klarade vi oss utan detta förr?”. Känns nästan som steget mellan tabeller och div.
Extra krydda på de tråkiga elementen i din webbdesign
Att besöka en webbplats innebär att man redan har en speciell förväntning på hur webbplatsen fungerar redan innan sidan laddat klart. Flödet och funktionen är ganska exakt likadan vart än du kommer på internet.
Det kommer finnas länkar som står ut med en annan färg än brödtexten, det kommer finnas en bild som oftast är centrerad eller högerställd. Det kommer finnas en slags meny som står ut för att visa och hjälpa till med navigationen. Läs hela inlägget →
CSS3 ::selection attributet
Det sägs att man lär sig något varje dag, det stämmer även denna dagen. Oftast när vi snackar om CSS3 så hamnar box-shadows, text-shadows, rundade hörn och animering i fokus.
Hittade via Quirksmode (demo finns på sidan) attributet ::selection som helt enkelt stylar om den markerade texten på en webbsida via CSS.
::selection { background-color: #ccc; color: #000; } ::-moz-selection { background-color: #ccc; color: #000; }
Enkelt, snyggt och kan ge den där lilla extra effekten på vissa projekt. Givetvis kan du punktmarkera vissa element med ex. p::selection {}. Fungerar givetvis enbart i moderna webbläsare.
Fem typsnitt för att använda med font-face
För något år sedan var det lite oklart vilka licenser som kunde användas med inbäddade typsnitt på webben, nu har jag inte riktigt hängt med 100% i utvecklingen men ett par sidor har ploppat upp som listar typsnitt som kan användas. Läs hela inlägget →
Varför prefix på radius och shadow?
Egentligen mer en fråga eller rättare sagt hur tänker man här.
Varför har både Geckoutvecklarna (Firefox) och utvecklarna av Webkit bestämt sig för att använda sig utav -moz respektive -webkit för de experimentella implementeringarna utav CSS3 specifikationen?
Låt oss kolla lite på vad vi har att jobba med, box-shadow, text-shadow med mera. Alla dessa funktioner kommer att vara standard i CSS3 final. Nu vid draft är det, som vanligt, diskussioner om hur implementering ska se ut och hur det det bör renderas, tolkas och skrivas. Sure – det går jag med på.
För både box-shadow och text-shadow så är tolkningen av parametrarna likadana. IE stödjer naturligtvis inte funktionen än, men det spelar ingen roll just nu.
Borde vi inte kunna skippa -moz/-webkit? Borde inte båda webbläsarna naturligt reagera på kommandot utan prefixet också?
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.
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.
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.