Share
Jeg skrev nylig om ems; hva de er, hvordan de er brukt og noen biter og biter å huske på når du implementerer dem selv. Jeg skjøt bare overflaten skjønt, og kommentarstrengen kastet opp dobbelt så mange spørsmål som artikkelen svarte! I denne oppfølgingen vil jeg ta ting videre, se på ems i enda mer detalj.
E på Dribbble Merk: Den forrige artikkelen dekker alle grunnleggende. Jeg anbefaler at du leser på dem før du går videre.
Emnet for unitless målinger (dvs. verdier uten piksler, prosenter, ems, yards, fathoms ...) ble tilbudt opp av et par personer sist gang, spesielt ettersom jeg hadde oppmuntret bruken av ems for å spesifisere linjehøyde.
Ems gir perfekt mening i dette tilfellet som de er i forhold til skriftstørrelse. Hvis teksten i spørsmålet vokser eller krymper, gjør også linjens høyde hvis den er angitt i ems. Absolute enheter, som piksler, ville virkelig ødelegge ting. Det samme gjelder avstand mellom bokstavene, Et annet eksempel på en dimensjon som burde Vær alltid i forhold til skriftstørrelsen.
Vi kan imidlertid forbedre dette. Ems kompliserer ting som deres verdier cascade; elementene arver deres foreldres em-verdier. Ta dette arrangementet for eksempel: en artikkel som inneholder et avsnitt:
Hvis vi bruker linjehøyden til artikkelen, vil den også bli arvet av avsnittet, som er greit:
Men hva avsnittet faktisk arver er beregnet verdi (i dette tilfellet effektivt 24px), så er linjens høyde i forhold til artikkelsens skriftstørrelse, ikke dens egen. Hvis vi øker avsnittets skriftstørrelse til tilsvarende 20px:
så forblir linjen høyt på 24px. Ideelt sett ønsker vi at linjens høyde skal vises 1,5 * 20 = 30px.
Dette er hvor enhetsløse målinger kommer inn. Ved å fjerne em-enheten fra artikkels linjehøyde:
avsnittet vil arve den enhetløse verdien i stedet, 1.5. Linjens linjehøyde er nå i forhold til sin egen skriftstørrelse, bingo!
Accentsconagua
Interessant skjønt gjelder dette ikke avstand mellom bokstavene. Og du kan helt glemme marginer, text-indent, den typen ting.
Hvis du er interessert i å lese mer om emnet, dekket Eric Meyer det solidt tilbake i 2006, pluss Harry Roberts har en flott oversikt over måleenhetene fra et par år tilbake.
mens microtypography refererer til de små detaljene i et dokument (tegnsetting, ligaturer, bindestrek, kerning og så videre) macrotypography håndterer alle de "store" greiene. Tenk på alle aspekter av typografi som gjør en teksttekstlig tekst; hvite rom, linjelengde (mål), punktinnrykk osv.
Ta en titt på denne væskekolonneoppsettet:
Et helt anstendig layout; to divs, hver en nøyaktig 50% bred, med noe polstring til venstre og høyre for å danne rennene (i hver div, forutsatt at * box-size: border-box brukes). Vanligvis vil du bli fristet til å definere padding ved hjelp av piksler, eller (enda bedre) prosenter, hvis du følte deg super fleksibel.
Imidlertid vil piksler og prosenter både ha en skadelig effekt på innholdets lesbarhet, hvis (når) skriftstørrelsen endres. Gutterbredde, som med hvite rom generelt, burde virkelig være dimensjonert i forhold til teksten. I dette eksemplet har vi to kolonner med tekst, med guttering brukt som en prosentandel av kolonnebredden, akkurat som vi beskrevet ovenfor:
.kolonne bredde: 50%; flyte: venstre; polstring: 0 3%;
Dette er en live demo, ta en titt og rot deg med det selv ... Når du endrer skrifttypestørrelsen, vil du imidlertid se at rennen blir relativt smalere, slett avstanden mellom tekstkolonnene og gjør det vanskeligere å lese.
Dette er et ekstremt eksempel, med absurd stor tekst for kolonnebredden, men det illustrerer punktet ... Langt bedre ville være å definere polstringen ved hjelp av ems:
.kolonne bredde: 50%; flyte: venstre; polstring: 0 1.2em;
På denne måten vokser gutten og krymper sammen med teksten, opprettholder avstanden mellom kolonnene og holder tingene lesbare.
Prøv å spille med denne ... Hvis du ikke bruker ems, er det sannsynligvis nede på en av to ting du ikke liker om dem. det faktum at deres verdier cascade, eller å beregne disse verdiene i utgangspunktet.
62,5% tilnærming (først foreslått av Richard Rutter vei tilbake i 2004) vil hjelpe deg på den andre. Ganske enkelt, i stedet for å sette grunnfontestørrelsen til 100% (som vi antar er 16px) setter vi den til 62,5%, effektivt 10px.
Fra det punktet, 1em = 10px. Derfor:
| Ems | Ekvivalente piksler |
| 0.5em | 5px |
| ... | ... |
| 1.1em | 11px |
| 1.2em | 12px |
| 1.3em | 13 piksler |
| 1.4em | 14 piksler |
| ... | ... |
| 47.3em | 473px |
og så videre, som bør fjerne noen av de mentale aritmetikkene. derimot, Det er et lite problem med denne tilnærmingen, og alt har å gjøre med ...
Vi snakker litt om 62,5% -grensen i et øyeblikk, men først må vi legge ned noen grunnlag.
I sin enkleste form hjelper medieforespørsler oss til å bruke CSS-regler under forskjellige omstendigheter, vanligvis avhengig av skjermstørrelse. Skjermoppløsninger måles i piksler, så det er bare logisk, vi definerer medieforespørsler på samme måte:
@media bare skjerm og (min bredde: 600px) / * noen ting * /
La oss bruke dette til vår tidligere demo, for å dele kolonnene opp etter et bestemt punkt.
I denne mobile første tilnærmingen deles våre kolonner når visningsporten når 600px Den arbitrære figuren på 600px virker bare bra i dette tilfellet; optimal lengde på linjen (eller måle) er et høyt debattert emne, men som Robert Brighurst sier:
Alt fra 45 til 75 tegn er allment betraktet som en tilfredsstillende lengde på linjen for en enkeltkolonne-side i et serifert tekstflate i en tekststørrelse. Linjen på 66 tegn (teller både bokstaver og mellomrom) anses allment som ideell.
Robert Brighurst - Elementene av typografisk stil
I vår demo, ved skriftstørrelse på 1em, treffer målet nå rundt 70 tegn før de splittes i to kolonner.
Når vi treffer to kolonner, er målet kanskje litt smalere enn vi helst ville ønske, men disse kolonnene er helt greit for denne demonstrasjonsformål. Imidlertid oppstår problemer når vi endrer nettleserens skriftstørrelse (hit kommando +).
Med fontstørrelse forsterket til "Very Large" (jeg bruker Chrome) er våre kolonne tiltak vei for smal, noe som gjør innholdet ganske uleselig. Av denne grunn bør vi vurdere å gjøre våre medieforespørsler i forhold til skriftstørrelsen også.
Husk formelen fra vår tidligere artikkel?
Vi tar sikte på 600px, fra en arvelig skriftstørrelse på 16px. 600/16 = 37,5em, så la oss endre mediaspørsmålet for å gjenspeile det:
Nå, når nettleserens skriftstørrelsesinnstillinger endres, ser vi en forskjell på måten mediesøket oppfører seg på. Med større tekst, her er det pikselbaserte medieforespørselen, med visningsporten satt til rundt 630px bred:
Mens på den skjermbredden holder em-baserte mediesøket ting pent i en kolonne; fint og lesbart.
Zoom inn / ut og se på media spørringen tre i kraft Her er knasten; em-baserte media spørringer er helt uinteressert i noen størrelsesorden på html, kropp, eller hva som helst; De er i forhold til nettleserens skriftstørrelse. Dette betyr at ved å sette grunnfontestørrelsen til noe annet enn 100%, må du styre to skalaer av em-verdier.
Arbeid fra en base på 100% og alt vil begynne fra et jevnt konkurranseområde. Dessuten, som Filament Group hevder, arbeider på denne måten beveger deg bort fra å tenke i piksler, noe som er bra.
Ett ord kom opp mer enn noe annet i kommentar-tråden i forrige artikkel; mixin. Hvis du sliter med å få hodet ditt rundt beregningene, hvorfor ikke la en CSS preprocessor gjøre det tunge løftet for deg?
Med CSS preprosessorer, som Sass, LESS og Stylus, kan du definere mixins og funksjoner. Disse aksepterer parametere, og deretter beregner og slår ut CSS-verdier for deg.
Merk: Hvis du er ny på konseptet, ta en titt på Mastering Sass: Leksjon 2 der Jeffrey introduserer Sass mixins.
Mixins og funksjoner kan håndtere alle slags ting for deg, inkludert de plagsomme matematikkene som omgir ems.
Ta dette enkle eksemplet fra Garrett Winder på Erskine. Han begynner å definere en funksjon (kalt "em") som aksepterer to verdier (akkurat som vår formel fra tidligere), selv om kontekstverdien har en standard på 16, så det trenger ikke spesifiseres igjen med mindre det er nødvendig.
Vi kan da bruke den "em" -funksjonen i CSS etterpå, og spør den om å beregne tilsvaret 30px:
Som, når den blir utarbeidet, utfører CSS i sin råform:
Og dette er ikke det eneste eksemplet av sin type heller - tusenvis av fremre utviklere har kuttet sine forbehandlingstenner ved å skrive sine egne em mixins. Rems også; ved å legge inn den ønskede pixelverdien i denne mixen kjennetegnet av Chris Coyier, kan du like enkelt få remmer utgitt, med fallback piksler.
Her er mixin. 
Her er bruken. 
Her er resultatet. Listen er nesten uendelig, men hvis du har noen mikser du liker å bruke i ditt eget arbeid (for å sende ut ems og rems), gi meg beskjed i kommentarene, og jeg legger dem til her:
Det er et bredt emne, det er tydelig masse å ta med, men å dykke inn i emsverdenen er en av de mer tilfredsstillende utfordringene i front-end webutvikling. Ikke tenk piksler og begynn å tenke relativt, i dag!
