Bredd på hemsida med tanke på fönsterstorlek i Macintosh

Du säger att du inte vill ha någon "elastisk deg" utan vill designa statiskt, men samtidigt ser du problemet i statiska designer, och att olika personer kommer ha olika bredder på sina läsare. Det ligger en liten motsägelse där och lurar .

Gällande "elastisk deg" så är det ju inte så att folk sitter och kontinuerligt ändrar bredden på sina läsare: det är det mest designern som gör under utvecklingsprocessen. Poängen är att oavsett vem som dyker på din sida så ska den initiala upplevelsen vara så bra som möjligt. Om man verkligen vill så kan man lägga till något i stil med "ses bäst i en bred display", men i praktiken hjälper det sällan användare, så det kan gärna skippas (om det inte är någon faktiskt funktionalitet som kräver en viss bredd). Det är aldrig bra att "lägga skuld" på sina besökare på det sättet.

Jag kommer skriva en del runt konceptet nedan. Kanske du hittar något du inte tänkt på tidigare som gör att du omvärderar tänket kring en statisk design, kanske inte. Det är tillåtet att hoppa över texten .

——

Förr

Hur man designar en sida från grunden är väldigt subjektivt; om du frågar de som började med webbutveckling på 1990-talet och i praktiken närapå ända fram till ~2010 så var det inget konstigt att utgå ifrån en "pixelbredd", sätta statiska bredder på alla element och köra på ("This site is best viewed in 800x600" osv). Fortfarande skulle jag säga att det inte är ovanligt att en utvecklare börjar med en tänkt "maxbredd" och sedan jobbar därifrån, med vissa skillnader (en annan ansats är att börja från "andra hållet" (buzzword: "mobile first")). Dock så vill man generellt att sidan även ska hantera andra bredder smidigt.

Dagens enhetsflora

Användare kommer idag besöka din sida från en mängd olika enheter; det handlar inte bara om antingen stationär på 1280 pixlars bredd eller mobil på 360 pixlars bredd, utan snarare hela spannet. Som du märkte så är det för den delen i sig problematiskt att anta att alla kör "maximerade" webbläsare.

Låt säga att en användare kommer från en platta: det är möjligt att de med sin höga pixeltäthet rent tekniskt har 1280 adresserbara pixlar i bredd (Nexus 7 har som exempel 1920x1200 pixlars upplösning), men i praktiken skulle det bli extremt liten text att pixelmappa rakt av, så generellt använder den en multiplikator för att rendera för en lägre "bredd" och sedan använda sina extra pixlar till att extrapolera (Nexus 7 renderar mig veterligen sidor i 960x600 dp).

Även om du tänker att det inte är så många som surfar på plattor idag (vilket i sig inte är glasklart) så kan du tänka på att det för ett par år sedan i stort inte var någon som surfade på platta — hur kommer det se ut bara ett år fram i tiden? Vill du behöva göra om hela designen då igen? Vill du att de som använder platta eller av annan anledning surfar i en lägre upplösning redan idag ska få en ihoptryckt upplevelse?

Adaptiva tankar

Jag tror att du som bästa ansats bör förbereda direkt för att din sida ska fungera smidigt i flera bredder. Det betyder inte att designen i ditt "1280 pixlar brett"-läge måste ändras — men du kan behöva förbereda för att dynamiskt ändra om objektplacering och annat för att din sida ska kunna vara sömlöst läsbar i mindre bredder och format. Detta går att göra ända ner till mobilnivå, varpå du kan ha en och samma sida för alla enheter som skalar automatiskt (se media queries).

För att få en överblick så är Google Web Fundamentals ett levande dokument som introducerar en hel del av dessa koncept (exempelvis avsnittet Responsive Web Design Basics). Det är nästan lite väl evangeliskt på sina ställen kan tyckas, men där finns en hel del intressanta poänger att hitta. I sämsta fall håller man inte med om det som står, och då har man ändå troligen lärt sig något nytt.

Pixlar mot relativa enheter

Terminologin "1280 pixlar bred" är i sig en artefakt från en "svunnen tid" . Det är inte så lätt att "en pixel är en pixel" längre, liksom antyddes med Nexus 7-exemplet ovan. Se exempelvis den dagsfärska laptoprecensionen av Dells nya 13.3"-laptop med 3200x1800 pixlars upplösning — den hade ju kunnat få plats med 2.5 av dina hemsidor på bredden, men varje sida skulle då bara bli runt 12 cm bred på skärmen, vilket man förstår blir rätt plottrigt. I stället skalas dessa pixlar på olika sätt.*

Uttryck hellre dina bredder, fontstorlekar, etc., i teckenrelativa enheter så som `em` och `%`. Detta kommer spara gråa hår när du framgent försöker få din sida att skala fint för att fungera på olika enheter, just för att "en pixel är en pixel" inte längre håller. Kort sagt så kan man i CSS-sammanhang säga att `1em` är en referensenhet som betyder "nuvarande teckenstorlek", `1.5em` betyder "1.5 gånger nuvarande teckenstorlek", osv. Man kan även använda `100%` och `150%` direkt, med några subtila skillnader mellan `em` och `%`. Relativa enheter kommer också (åtminstone i teorin) sömlöst hantera situationen när användare av en eller annan anledning väljer att förstora/förminska text i sina webbläsare, då de helt enkelt bara ändrar sin webbläsares referensstorlek, dvs till vad ditt CSS-dokuments initiala `100%` är relativt.

Ett vanligt mönster är att börja sin CSS-fil med att deklarera `body { font-size: 100%; }` för att definiera att man vill använda browserns "vanliga" teckenstorlek (vilket i sig ofta (←OBS) betyder `16px`) och sedan ange alla övriga mått på sidan i em (eller någon annan relativ enhet, men det kan förenkla att vara konsekvent där det går). `1.6em` blir då 60 % större än referensstorleken i objekt som ligger direkt under `body`, men enheten är hela tiden relativ till "förälderns" teckenstorlek, så ett element med `font-size: 1.4em` inuti en behållare med `font-size: 1.6em` blir relativt dokumentets basstorlek 160 % ⋅ 140 % = 224 % i storlek. Egentligen är det ju ofta just förhållandet mellan olika delar i en design som är intressant, snarare än deras statiska storlekar.

Magin i detta ligger inte minst i att kunna använda "media queries" för att vid en viss brytpunkt ändra till `body { font-size: 90%; }`, och då se alla mått på sidan sömlöst skalas ner till 90 % av fullbreddsversionen.

Kan också nämna att om man har stark tro på att en webbläsares standardteckenstorlek är `16px` så kan man ange `body { font-size: 62.5%; }` varefter `1em` motsvarar `10px`, vilket gör det lätt att översätta mellan pixlar och em. Personligen tycker jag att det känns "hackigt" och frångår en del grundtankar bakom relativa enheter, men liksom rubriken nedan påvisar så kan olika lösningar passa olika situationer.

Följ praxis tills praxis inte bör följas

Som slutkläm ska det nämnas att "responsiv design" ibland används som närmast ett ofelbart mantra, vilket inte heller är bra. Det kan alltid finnas lägen då andra infallsvinklar passar bättre, med den mängd tvångsvillkor en webbdesigner kan stå inför (mängd reklam som ska få plats, inte minst). Det är inte meningen att försöka vara så evangelisk här, men idag bör frågan en designer ställer sig snarare vara varför man inte ska välja en adaptiv design framför en statisk, och övervikten går ständigt än längre åt det adaptiva hållet.

——
*: I praktiken så har situationen med att ange exempelvis teckenstorlekar i pixlar förbättrats lite sedan de nya enheterna först började dyka upp, och det kan finnas situationer där man vill uttrycka bredder utifrån exempelvis rasteriserade bildelement där pixelpositionering är rimligast, men generellt så är det ofta mer rättfram att använda relativa enheter.

Jag fick också inpräntat många av mina grundkunskaper i webbdesign under den väldigt statiska perioden, och jag bidade min tid med ett vakande öga på håll gällande "responsiv design"-boomen som började ~2010 innan "best practices" började cementeras. Blir vi bara av med åtminstone IE8 (officiellt stöd yxas av Microsoft tidigt 2016, av allt att döma) så ser situationen bättre ut än eventuellt någonsin vad gäller browserkompatibilitet, trots alla dessa olika skärmbredder, så man behöver inte vara ledsen över utvecklingen .

Har du legat i ide ett tag så kan det också vara värt att kolla in nyheterna i HTML5 jämfört med HTML4 (och XHTML som pushades stenhårt runt 2000 och en tid därefter kan vi med gott samvete lägga bakom oss helt och hållet). Det finns en mängd förenklingar som gör livet enklare för alla parter. Återigen så har vi IE8 som kan få för sig att agera betongsugga, men det går att kompensera relativt smärtfritt genom polyfills (som också är ett rätt nytt begrepp, introducerat just i samband med HTML5).

Enklaste ansats är i mina ögon att redan idag nyttja en del av de godsaker HTML5 och CSS3 ger dig, och sedan fylla i eventuella luckor med polyfills för de webbläsare som saknar stöd (vilket troligen bara kommer vara äldre IE-läsare om du inte svävar ut alltför mycket) ifall det skulle krävas. I framtiden kan man sedan helt enkelt fasa ut dessa polyfills utan bekymmer, samtidigt som man kan koda någorlunda "modernt" redan i nuläget.

Det är inte ovanligt att hitta någon sorts "maxbredd" även i dagens designer (inte minst av rent typografiska skäl), men väldigt ofta finns det ingen direkt anledning att tvinga en viss fast bredd. Det räcker att ha ett horisontellt elastiskt element för att en sida ska kunna skala mjukt. När det börjar bli för trångt så kan man sedan minska teckenstorlek, ändra kolumnlayout, möblera om element, med mera. En läsare som har mindre tillgänglig bredd än vad du planerat med din "maxdesign" hade ju ändå inte kunnat använda sidan så som den var tänkt, så då kan man ju åtminstone försöka presentera en sida som går att läsa. Att sidan ska vara användbar vid olika bredder kan vara ett första mål. Att sedan dessutom göra den "snygg" kan vara socker på toppen.

Om du, som du säger att du tänkte göra, börjar utforska hur responsiva sidor löser sin design så kommer du troligen se att det kan gå rätt smärtfritt att förvandla en tänkt statisk layout till mer dynamisk. Responsive Web Design Patterns från den där Googlesidan jag länkade innan visar upp ett par vanliga mönster som används frekvent, med länkar till både minimala demonstrationssidor och faktiska stora externa sidor som är byggda på respektive sätt.