Läste en mycket bra artikel på A List Apart av Ethan Marcotte om hur css3 specifikationen ”Media Queries” kommer till sin rätt när vi formger webbplatser för olika motagarenheter. Med hjälp av Media Query kan vi inte bara identifiera olika enheter utan även inspektera olika karakteristika på den enhet som renderar webbplatsen.
Läs hela artikeln här eller gå direkt till Ethans exempelsida och förstora/förminska webbläsarfönstret
/johan
Intressant css3 läsning av David DeSandro. Mycket ”best practice” metoder.
Gänget på Opera hakade naturligtvis på detta och noterade också att David i sitt exempel ovan använt gradienter vilket de inte ansåg vara ”pure css3″. Resultatet blev en modifierad logga av Håkon Wium Lie, ”the godfather of CSS”.
Se Håkons exempel här
…ibland tror jag vi alla kan behöva fundera lite på hur vi använder oss av vår kära e-post
Har jag missat någon punkt, maila mig inte, lägg in en kommentar 
För att en font ska rendera korrekt på en webbplats måste besökaren ha den specifika fonten installerat på sin dator. Detta medför att webbformgivaren varit hänvisade till 10-15 sk webbsäkra typsnitt utav alla de hundra tusen eller så möjliga, en viss begränsning m.a.o.
Det finns ett antal tekniska lösningar för att kringgå problemet med lokalt installerade typsnitt, alla med mer eller mindre svåröverkomliga hinder och begränsningar i funktion och tillgänglighet. Gemensamt för dem alla är dock att de inte håller sig till någon ratificerad webbstandard.
Här nedan är några exempel:
Det finns dock en lösning som är enkel att använda och som stödjs av w3c: CSS3 Web Fonts. Denna s.k. @font-face tekniken fungerar idag i: IE6, IE7, IE8, FireFox 3.5+ (PC & Mac), Safari (PC & Mac) and Opera 10, det ger att ca 95% av besökarna på din webbplats kan se typsnittet korrekt.
Det korta och svaret är: Licenskostnaderna för typsnittet!
Här nedan följer ett litet exempel på hur det ser ut i dagsläget.
Kunden:
Har ett hustypsnitt från en större leverantör som de vill implementera på sin webbplats.
Konsulten (Intellecta):
Köper licenser för fem datorer så att vi kan arbeta med typsnittet i formgivningen av webbplatsen och all annan ev. tryckt material .
Kostnad ca 4.000skr för typsnittet (alla vikter och stilar).
Intellecta undersöker sedan möjligheten att använda typsnittet på webben med hjälp av inbäddade typsnitt (@font-face). Svaret från typsnitsleverantören var något nedslående.
Kostnaden för att köpa hela typsnittsfamiljen för alla varianter av ”gammalmedia” med licenser för 5 datorer är ca 4000kr. Kostnaden för en (1) font på webben som enbart skulle fungera i Explorer är 89.000skr.
Här står vi idag…
En lösning för den som kan tänka sig att vara lite fri i sitt val av typsnitt är att leta efter gratistypsnitt. Tyvärr så är det sällan till någon hjälp då kunden oftast är ganska specifik i sina önskemål om typsnitt.
Förslag på hur vi kommer vidare mottages tacksamt.
/johan liw
…så nu tar vi ett par varv ”Progressive Enhancement” igen.
För ett par veckor sedan skrev Mathias ett inlägg om css 3 och hur den standarden kan komma att påverka webben. Om vi lyfter diskussionen något från det rent tekniska till att handla om hur vi hanterar marknadens olika webbläsare och hur de renderar sidor på olika sätt hamnar vi snart i diskussioner som rör s.k. Progressive Enhancement (PE).
(fritt översatt från wikipedia)
I teorin betyder det att man startar med en enkel, semantiskt korrekt HTML som rymmer allt väsentligt innehåll (se bild 1). På detta lägger man sedan ett lager design i form av CSS för att sedan avsluta med ett yttre lager funktionalitet/upplevelse i form av JavaScript. Vi strävar efter att alla ska få en tillfredsställande upplevelse vid besöket, besökare med mindre avancerade webbläsare möts av en enklare, men fullt användbar, webbplats medan besökare med mer kapabla webbläsare får både ”pukor och trumpeter”.
(Bild 1, lånad från den utmärkta artikeln Understanding Progressive Enhancement av Aaron Gustafson)
I praktiken så fungerar det tyvärr inte riktigt på detta sätt. Vi levererar idag nästan alltid all ”extra” upplevelse till majoriteten av alla webbläsare även till de webbläsare som inte förstår implementeringen (läs IE 6-7). Vad som händer är att vi initialt har ambitionen att arbeta med PE men när det kommer till kritan och vi står där och ska testa i mindre kapabla webbläsare arbetar vi in ”pukorna och trumpeterna” även i dessa med hjälp av extra HTML/CSS och avancerade JavaScript trix, detta tillintetgör hela idén med PE
Inställningen till det visuella ögongodiset bör ses som en typ av belöning till de webbläsare som stödjer den avancerade kod som gör det möjligt snarare än något som saknas eller inte fungerar i de webbläsare som inte ännu är riktigt är med i matchen.
Häri ligger mycket av förändringen i inställningen, en design är inte felaktig för att den ser annorlunda ut i IE7 och vi har inte varit slöa då vi inte levererat en pixelperfekt lösning i alla webbläsare. Vi belönar, visuellt, användare med mer kapabla webbläsare, medan besökare med mindre kapabla webbläsare får en fullt användbar webbplats med lite mindre ögongodis.
Jämför tex. bild 2 och bild 3 här nedan. Bild 2 är hur Twitter ser ut i Internet Explorer 7, notera de kantiga hörnen på boxar etc. Jmf. sedan med Bild 3, Twitter i Safari. Nu kanske man ska akta sig för att uppskatta tidsåtgången för att implementera alla de runda hörn som finns på Twitter (Safari) så att de fungerar även i IE 7, men jag gör det ändå. Min uppskattning är att man enbart på dessa detaljer spar minst en arbetsdag css/html.
Bild 2: Twitter i Internet Explorer 7 utan runda hörn
Bild 3: Twitter i Safar, med runda hörn
Nu får det vara slutvevat för denna gång. Här nedan har jag samlat några länkar för den som vill läsa mer i ämnet. För dig som inte riktigt känner att du vill/orkar läsa mer om detta vill jag starkt rekommendera denna sammanfattning: Do websites need to look exactly the same in every browser?
I en gästartikel på Smashing Magazine skriver Dirk Jesse mycket utförligt om Flexibel layout med extra fokus på moderna webbläsares förmåga att zooma sidor.
More problematic is the overwhelming confidence of developers that the individual decision-making is better for users from the accessibility point of view. When applied to fixed layouts the web-developer delivers a clear message:
- Dear users, your browser can zoom my fixed layout – so please help yourself if you want or need to!
För ganska precis ett år sedan lanserade IKEA en ny webbplats helt baserad på em mått. I och för sig inget nytt men när man tittar lite närmare och konstaterar att i stort sett alla bilder även de har relativa em mått då börjar det bli intressant.
Under en längre tid har det diskuterats fram och tillbaka över vilken typ av layout som är den optimala, låst, flytande eller elastisk layout. Det är idag ganska givet att majoriteten avråder från att använda en låst, pixelbaserad laout till fördel för de övriga två. Varför är det då så att det fortfarande produceras webbplatser med fasta mått?
Utifrån ett strikt användarperspektiv är det ganska enkelt att argumentera för en elastisk layout, den är helt enkelt den mest flexibla, användarvänliga lösningen. Användaren har frihet att förstora text och bild, hon/han kan använda ett smalt eller brett webbläsarfönster efter önskemål samtidigt som utvecklaren kan sätta en max bredd så att radlängderna inte blir för långa.
Från formgivarens sida ser det lite annorlunda ut. Formgivare vill ha kontroll över designen, kontroll över läsbarhet och hur sidan upplevs. Den kontrollen blir störst med en låst, pixelbaserad design. Här finns också en inbyggd problematik i att Photoshop används som designverktyg samtidigt som det verktyget är mycket statisk i sin natur.
Utvecklarperspektivet handlar till stor del om en viss ökad komplexitet med en elastisk/flytande layout kontra en pixelbaserad. Med den elastiska handlar det främst om att hålla ordning på alla em värden, vilka måste konverteras från designerns pixelvärden. Sedan måste man hantera bildstorlekar på ett smidigt sätt. Bildstorleken måste sättas i css dokumentet som em värden, följden av det är att man i förväg måste bestämma vilka bildstorlekar som kan användas i det redaktionella materialet.
Med den flytande layouten kan det bli problem om formen kräver en pixelperfekt passform, kan vara svårt att uppnå i alla lägen.
Beställarens syn på ovanstående kokar oftast ned till hur budget ser ut, en fast pixelbaserad layout är oftast minst komplex och därför billigast.
Självklart bör ett beslut om vilken typ av layout som ska användas tas så tidigt i processen som möjligt men absolut senast vid designstarten.
Vem är det som äger beslutet? Inte helt givet, det kan ligga hos flera resurser inblandade i ett projekt, men det kan också vara ett gemensamt beslut/ställningstagande att man generellt gör någon av de tre alternativen och ev. avvikelser från detta blir ett medvetet val. Vad som inte är så lyckat är när frågan inte blir belyst och beslutet tas i all enskildhet av utvecklaren.
Mer att läsa:
@media 2010
2 dagar av @media 2010 London avverkade
Här följer en lista på några av de presentationer jag följde.
Dag två startade med en riktigt bra och engagerande dragning av Andy Clarke (@Malarkey) om hur vi inte bör låta oss begränsas av inte fullt så avancerade webbläsare utan designa för de mest kapabla och sedan hantera de andra. Om hur vi kan hantera IE6 med hjälp av universiellt css, helt enkelt strippa ie6 från all avancerad form. Måste tillstå att tanken är lockande, läs Andys resonemang här. Detta följdes upp av Remy Sharp (@rem) om html5 javascript APIS, mycket demos på vad som är möjligt att göra.
För den som vill läsa ett något mer strukturerat inlägg om @media 2010 så har Peter Gasston gjort en mycket bra sammanfattning
/johan liw