Share
Jag skrev nyligen om ems; vad de är, hur de används och lite bitar att tänka på när du implementerar dem själv. Jag skrapade bara ytan men, och kommentarer tråden kastade upp dubbelt så många frågor som artikeln svarade! I denna uppföljning tar jag saker vidare och tittar på ems i ännu mer detalj.
E på dribbble Notera: Den föregående artikeln täcker alla grunderna. Jag rekommenderar att du läser upp dem innan du går längre.
Ämnet om enhetlösa mätningar (dvs. värden utan pixlar, procentandelar, ems, yards, fathoms ...) erbjöds upp av ett par personer förra gången, särskilt som jag hade uppmuntrat användningen av ems för att specificera radavstånd.
Ems gör perfekt mening i detta fall som de är i förhållande till textstorlek. Om den aktuella texten växer eller krymper, så gör linjens höjd om den sätts i ems. Absoluta enheter, som pixlar, skulle verkligen röra upp saker. Detsamma gäller för teckenavstånd, Ett annat exempel på en dimension som borde alltid vara i förhållande till typsnittstorleken.
Men vi kan förbättra på detta. Ems komplicerar saker som deras värderingar kaskad; element arva deras föräldrars em värden. Ta till exempel detta arrangemang: en artikel som innehåller en paragraf:
Om vi ansluter linjehöjden till artikeln kommer den också att vara ärvt av stycket, vilket är bra:
Men vad stycket faktiskt ärva är det beräknat värde (i detta fall effektivt 24px), så är dess linjehöjd relativt artikels typstorlek, inte egen. Om vi ökar punktens teckenstorlek till motsvarande 20px:
då är linjens höjd ständigt vid 24px. Helst skulle vi vilja att dess linjehöjd visas 1,5 * 20 = 30px.
Det här är där enhetlösa mätningar kommer in. Genom att ta bort em-enheten från artikelns linjehöjd:
stycket kommer att arva det enhetlösa värdet istället, 1.5. Styckets linjehöjd är nu i förhållande till sin egen typsnitt, bingo!
Accentsconagua
Intressant men det gäller inte teckenavstånd. Och du kan helt glömma bort marginaler, text-strecksatsen, den sorts saker.
Om du är intresserad av att läsa mer om ämnet Eric Meyer täckte det solidt tillbaka under 2006, plus Harry Roberts har en bra översikt över mätenheter från ett par år tillbaka.
medan microtypography hänvisar till de små detaljerna i ett dokument (skiljetecken, ligaturer, bindning, kerning och så vidare) macrotypography hanterar alla "stora" grejer. Tänk på alla aspekter av typografi som gör en textläsbar text; whitespace, linje längd (mått), stycke indragning etc.
Ta en titt på denna inställning av vätskekolonn:
En helt anständig layout; två divs, var och en exakt 50% bred, med viss polstring åt vänster och höger för att bilda rännorna (inuti varje div, förutsatt att * box-size: border-box används). Vanligtvis skulle du vara frestad att definiera vaddering med pixlar eller (ännu bättre) procentsatser om du kände dig super flexibel.
Men pixlar och procentandelar kommer båda att ha en skadlig inverkan på innehållets läsbarhet, om (när) teckensnittstorleken ändras. Rännbredd, som med blankutrymme i allmänhet, borde verkligen vara stor i förhållande till texten. I det här exemplet har vi två kolumner med text, med guttering applicerad som en procentandel av kolumnbredden, precis som vi beskrivit ovan:
.kolumn bredd: 50%; flyta till vänster; vaddering: 0 3%;
Det här är en levande demo, ta en titt och röra med dig själv ... När du ändrar teckenstorleken kommer du dock märka att rännan blir relativt smalare, suddig uppdelningen mellan textkolumnerna och gör det svårare att läsa.
Detta är ett extremt exempel, med absurd stor text för kolumnbredden, men det illustrerar punkten ... Det är mycket bättre att definiera vadderingen med hjälp av ems:
.kolumn bredd: 50%; flyta till vänster; vaddering: 0 1.2em;
På detta sätt växer rännan och krymper med texten, behåller avståndet mellan kolumnerna och håller läsbarhet.
Försök spela med den här ... Om du inte använder ems, är det förmodligen en av två saker som du inte tycker om dem. det faktum att deras värden cascade, eller måste beräkna dessa värden i första hand.
62,5% tillvägagångssättet (först föreslagit av Richard Rutter långt tillbaka 2004) hjälper dig ut på den andra. Helt enkelt, istället för att ställa in basstorlekstorleken till 100% (som vi antar är 16px) sätter vi den till 62,5%, effektivt 10px.
Från den punkten, 1em = 10px. Därför:
| Ems | Ekvivalenta pixlar |
| 0.5em | 5px |
| ... | ... |
| 1.1em | 11px |
| 1.2em | 12px |
| 1.3em | 13px |
| 1.4em | 14px |
| ... | ... |
| 47.3em | 473px |
och så vidare, som bör ta bort några av de mentala aritmetiska. dock, Det finns en liten fråga med detta tillvägagångssätt, och allt har att göra med ...
Vi pratar lite om 62,5% caveat på ett ögonblick, men först måste vi lägga ner några fundament.
I sin enklaste form hjälper mediefrågor oss att tillämpa CSS-regler under olika omständigheter, oftast beroende på skärmstorlek. Skärmupplösningar mäts i pixlar, så det är bara logiskt vi definierar mediasökningar på samma sätt:
@media bara skärm och (min bredd: 600px) / * några saker * /
Låt oss tillämpa detta på vår tidigare demo, för att dela upp kolumnerna efter en viss punkt.
I det här mobila första tillvägagångssättet delas våra kolumner när visningsporten når 600px Den arbitrada siffran på 600px råkar bara vara bra i det här fallet. optimal längd längd (eller mäta) är ett mycket debatterat ämne, men som Robert Brighurst säger:
Allt från 45 till 75 tecken anses allmänt som en tillfredsställande längd på linjen för en enkelkolonnersida som är inställd i ett serifed textyta i en textstorlek. Linjen med 66 tecken (räkna både bokstäver och mellanslag) anses allmänt som ideal.
Robert Brighurst - Elementen av typografisk stil
I vår demo, vid teckenstorlek på 1em, träffar åtgärden nu cirka 70 tecken innan den delas in i två kolumner.
När vi träffat två kolumner är åtgärden kanske lite smalare än vad vi helst skulle vilja, men dessa kolumner är helt okej för syftet med denna demo. Problem uppstår emellertid när vi ändrar webbläsarens fontstorlek (hitkommando +).
Med teckenstorleken förstärkt till "Very Large" (jag använder Chrome) är våra kolumnåtgärder sätt för smal, vilket gör innehållet ganska oläsligt. Av denna anledning bör vi överväga att göra våra mediefrågor i förhållande till typsnittstorlek också.
Kom ihåg formuläret från vår tidigare artikel?
Vi strävar efter 600px, från en ärvd skriftstorlek på 16px. 600/16 = 37,5em, så låt oss ändra vår mediafråga för att återspegla det:
Nu när vår webbläsarens inställningar för teckenstorlek ändras ser vi en skillnad i hur mediasökningen beter sig. Med större text, här är den pixelbaserade mediefrågan, med visningsporten inställd på cirka 630px bred:
På den skärmbredden håller em-baserade mediafrågan saker som är snyggt i en kolumn; trevlig och läsbar.
Zooma in / ut och titta på mediasökningen träder i kraft Här är krisen; Em-baserade mediefrågor är helt ointresserade i alla storlekar på html, kropp, eller vad som helst; De är i förhållande till webbläsarens textstorlek. Det innebär att genom att ställa in basstorleken till något annat än 100% måste du hantera två skalor av em-värden.
Arbeta från en bas på 100% och allt kommer att börja från lika villkor. Dessutom, som Filament Group argumenterar, arbetar det på så sätt bort dig från att tänka i pixlar, vilket är en bra sak.
Ett ord kom upp mer än någon annan i kommentarfältet i föregående artikel; blanda i. Om du kämpar för att få huvudet runt beräkningarna, varför inte låta en CSS-förprocessor göra det tunga för dig?
Med CSS preprocessorer, som Sass, LESS och Stylus, kan du definiera mixins och funktioner. Dessa accepterar parametrar, sedan beräkna och churn ut CSS-värden för dig.
Notera: Om du är ny på konceptet, ta en titt på Mastering Sass: Lektion 2 där Jeffrey introducerar Sass mixins.
Mixins och funktioner kan hantera alla typer av saker för dig, inklusive de besvärliga matematik som omger ems.
Ta det här enkla exemplet från Garrett Winder på Erskine. Han börjar definiera en funktion (kallad "em") som accepterar två värden (precis som vår formel från tidigare) trots att kontextvärdet har en standard på 16, så det behöver inte anges igen om inte nödvändigt.
Vi kan sedan använda den "em" -funktionen inom CSS och ber om att beräkna motsvarande 30px:
Vilken, när den sammanställs, matar ut CSS i dess råa form:
Och det här är inte heller det enda exemplet av dess typ - tusentals främre utvecklare har skurit sina förbehandlingständer genom att skriva egna em mixins. Rems också; genom att mata in det önskade pixelvärdet i detta mixin som presenteras av Chris Coyier, kan du lika enkelt ha rems utmatade med fallback pixlar.
Här är mixin. 
Här är användningen. 
Här är resultatet. Listan är nästan oändlig, men om du har några mixins som du gillar att använda i ditt eget arbete (för utmatning av ems och rems), låt mig veta i kommentarerna och jag lägger till dem här:
Det är ett brett ämne, det finns tydligt massor att ta in, men dykning i emsvärlden är en av de mer tillfredsställande utmaningarna i webbenutveckling. Sluta tänka på pixlar och börja tänka relativt, idag!
