Share
Ik heb onlangs over ems geschreven; wat ze zijn, hoe ze worden gebruikt en wat stukjes en beetjes om in gedachten te houden wanneer je ze zelf implementeert. Ik kraste echter alleen maar aan de oppervlakte, en de thread opmerkingen gooide twee keer zoveel vragen als het artikel antwoordde! In deze follow-up zal ik verder gaan met het bekijken van ems in nog meer detail.
E on Dribbble Notitie: Het vorige artikel behandelt alle basics. Ik raad aan dat je ze leest voordat je verder gaat.
Het onderwerp van unitless metingen (dat wil zeggen: waarden zonder pixels, percentages, ems, yards, vadems ...) werd vorige keer door een paar mensen aangeboden, vooral omdat ik het gebruik van ems voor het specificeren van lijnhoogte.
Ems is in dit geval volkomen logisch omdat ze relatief zijn ten opzichte van de lettertypegrootte. Als de betreffende tekst groeit of krimpt, neemt ook de regelhoogte toe als deze in ems is ingesteld. Absolute eenheden, zoals pixels, zouden de dingen echt verpesten. Hetzelfde geldt voor letterafstand, een ander voorbeeld van een dimensie die zou moeten altijd relatief zijn ten opzichte van de lettergrootte.
We kunnen dit echter verbeteren. Eems compliceren dingen terwijl hun waarden in elkaar overlopen; elementen nemen de em-waarden van hun ouder over. Neem bijvoorbeeld deze regeling: een artikel met een alinea:
Als we de regelhoogte toepassen op het artikel, wordt deze ook geërfd door de alinea, wat prima is:
Maar wat de alinea eigenlijk erven is de berekende waarde (in dit geval dus effectief 24 px), dus de lijnhoogte is relatief aan de lettergrootte van het artikel, niet die van hemzelf. Als we de lettergrootte van de alinea verhogen tot het equivalent van 20px:
dan blijft de lijnhoogte vast op 24px. Idealiter zouden we graag zien dat de lijnhoogte ervan 1,5 * 20 = 30 px is.
Dit is waar eenheidloze metingen binnenkomen. Door de em-eenheid van de lijnhoogte van het artikel te verwijderen:
de alinea zal in plaats daarvan de niet-unitaire waarde erven, 1.5. De regelhoogte van de alinea is nu relatief aan zijn eigen lettergrootte, bingo!
Accentsconagua
Interessant genoeg is dit echter niet van toepassing op letterafstand. En je kunt het helemaal vergeten marges, tekst streepje, dat soort dingen.
Als je meer wilt lezen over het onderwerp Eric Meyer heeft het al in 2006 uitvoerig behandeld, plus Harry Roberts heeft een goed overzicht van meeteenheden van een paar jaar geleden..
Terwijl microtypography verwijst naar de kleine details in een document (leestekens, ligaturen, woordafbreking, tekenspatiëring enzovoort) Macrotypografie behandelt alle "grote" dingen. Denk na over alle aspecten van typografie die een tekstbestand leesbaar maken; witruimte, lijnlengte (maat), alinea-inspringing enz.
Bekijk deze instellingen voor de vloeistoffkolom:
Een perfect fatsoenlijke lay-out; twee divs, elk precies 50% breed, met wat opvulling links en rechts om de goten te vormen (binnen elke div, ervan uitgaande dat * box-sizing: border-box wordt gebruikt). Doorgaans zou u in de verleiding komen de opvulling te definiëren met behulp van pixels of (zelfs betere) percentages, als u zich super flexibel zou voelen.
Pixels en percentages hebben echter allebei een nadelig effect op de leesbaarheid van de inhoud, als (wanneer) de lettergrootte wordt gewijzigd. De breedte van de tussenruimte, zoals met witruimte in het algemeen, zou eigenlijk moeten worden aangepast aan de tekst. In dit voorbeeld hebben we twee tekstkolommen, met goten toegepast als percentage van de kolombreedte, net zoals we hierboven hebben beschreven:
.kolom breedte: 50%; zweven: links; opvulling: 0 3%;
Dit is een live demo, neem een kijkje en rommel er zelf mee rond ... Wanneer u echter de lettergrootte wijzigt, zult u merken dat de rugmarge relatief smaller wordt, waardoor de scheiding tussen de kolommen van de tekst vervaagt en het moeilijker wordt om te lezen.
Dit is een extreem voorbeeld, met absurd grote tekst voor de kolombreedte, maar het illustreert het punt ... Veel beter zou zijn om de opvulling met ems te definiëren:
.kolom breedte: 50%; zweven: links; opvulling: 0 1.2em;
Op deze manier groeit en krimpt de rugmarge samen met de tekst, waarbij de afstand tussen kolommen wordt bewaard en de dingen leesbaar blijven.
Probeer eens met deze te spelen ... Als u nog geen ems gebruikt, komt dit waarschijnlijk door een van de twee dingen die u niet bevalt; het feit dat hun waarden cascade zijn of dat ze die waarden in de eerste plaats moeten berekenen.
De 62,5% -benadering (voor het eerst voorgesteld door Richard Rutter in 2004) zal u helpen bij de tweede. Simpelweg, in plaats van de basislettertype-grootte in te stellen op 100% (wat we aannemen is 16px), stellen we het op 62,5%, effectief 10px.
Vanaf dat moment 1em = 10px. daarom:
| Ems | Equivalente pixels |
| 0.5em | 5px |
| ... | ... |
| 1.1em | 11px |
| 1.2em | 12px |
| 1.3em | 13px |
| 1.4em | 14px |
| ... | ... |
| 47.3em | 473px |
en zo verder, wat een deel van de hoofdrekenen zou moeten verwijderen. Echter, er is een klein probleem met deze aanpak, en alles heeft te maken met ...
We zullen het even hebben over het voorbehoud van 62,5%, maar eerst moeten we een aantal basissen neerleggen.
In hun eenvoudigste vorm helpen mediaquery's ons CSS-regels toe te passen onder verschillende omstandigheden, meestal afhankelijk van de schermgrootte. Schermresoluties worden gemeten in pixels, dus het is logisch dat we mediaquery's op dezelfde manier definiëren:
@media only-scherm en (min-width: 600px) / * sommige dingen * /
Laten we dit toepassen op onze vorige demo, om de kolommen na een bepaald punt op te splitsen.
In deze eerste mobiele benadering worden onze kolommen gesplitst zodra de viewport 600 px bereikt De arbritrary figuur van 600px is in dit geval prima; optimale lijnlengte (of maatregel) is een zeer besproken onderwerp, maar zoals Robert Brighurst stelt:
Alles van 45 tot 75 tekens wordt algemeen beschouwd als een bevredigende lengte van de regel voor een pagina met één kolom die is ingesteld in een van tekst voorzien tekstveld in een tekstgrootte. De regel met 66 tekens (inclusief letters en spaties) wordt algemeen als ideaal beschouwd.
Robert Brighurst - De elementen van de typografische stijl
In onze demo, op lettergrootte van 1em, raakt de meetwaarde nu ongeveer 70 tekens voordat hij in twee kolommen wordt gesplitst.
Zodra we twee kolommen raken, is de maat misschien een beetje smaller dan we idealiter zouden willen, maar deze kolommen zijn perfect in orde voor deze demo. Er doen zich echter problemen voor wanneer we de lettertypegrootte van onze browser wijzigen (opdracht hit +).
Met font-size boosted tot "Very Large" (ik gebruik Chrome) zijn onze kolommaten dat wel manier te smal, waardoor de inhoud vrij onleesbaar is. Daarom moeten we overwegen om onze mediaquery's ook relatief te maken met de lettergrootte.
Denk aan de formule uit ons vorige artikel?
We streven naar 600px, van een overgeërfde lettergrootte van 16px. 600/16 = 37,5em, dus laten we onze media-query veranderen om dat te weerspiegelen:
Wanneer de instellingen van de lettertypegrootte van onze browser worden gewijzigd, zien we nu een verschil in de manier waarop de mediaquery zich gedraagt. Bij grotere tekst is dit de pixelgebaseerde mediaquery, waarbij het kijkvenster is ingesteld op ongeveer 630 px breed:
Terwijl bij die schermbreedte de op em gebaseerde mediaquery dingen netjes in één kolom houdt; leuk en leesbaar.
Zoom in / uit en bekijk hoe de mediaquery van kracht wordt Dit is het knelpunt; em-gebaseerde mediaqueries zijn totaal ongeïnteresseerd in elke dimensionering van de html, lichaam, of wat dan ook; ze zijn relatief ten opzichte van de lettertypegrootte van de browser. Dit betekent dat u, door de basislettertype-grootte in te stellen op iets anders dan 100%, twee schalen van em-waarden moet beheren.
Werk vanaf een basis van 100% en alles begint met een level playing field. Trouwens, zoals Filament Group beweert, helpt je door op deze manier te werken je af te leiden van het denken in pixels, wat een goede zaak is.
Het ene woord kwam meer naar voren dan het andere in de commentaarthread van het vorige artikel; mixin. Als u moeite heeft om de berekeningen te maken, laat dan een CSS-preprocessor het zware werk voor u doen?
Met CSS-preprocessors, zoals Sass, LESS en Stylus, kunt u mixins en functies definiëren. Deze accepteren parameters en berekenen en genereren vervolgens CSS-waarden voor u.
Notitie: Als je nieuw bent in het concept, bekijk Mastering Sass: les 2 waarin Jeffrey Sass-mixins introduceert.
Mixins en functies kunnen allerlei dingen voor je aan, inclusief de lastige wiskunde rond ems.
Neem dit eenvoudige voorbeeld van Garrett Winder in Erskine. Hij begint met het definiëren van een functie ("em" genaamd) die twee waarden accepteert (net als onze formule van vroeger) hoewel de contextwaarde een standaardwaarde van 16 heeft, dus deze hoeft niet opnieuw te worden gespecificeerd, tenzij noodzakelijk.
We kunnen daarna die "em" -functie binnen CSS gebruiken en hem vragen het equivalent van 30px te berekenen:
Die in gecompileerde vorm de CSS in zijn onbewerkte vorm uitvoert:
En dit is ook niet het enige voorbeeld van dit type - duizenden ontwikkelaars aan het front hebben hun voorbewerkingstanden gesneden door hun eigen em-mixins te schrijven. Rems ook; door de gewenste pixelwaarde in te voeren in deze mixin van Chris Coyier, kun je net zo goed uitgepakte rems hebben, met fallback-pixels.
Hier is de mixin. 
Hier is het gebruik. 
Dit is het resultaat. De lijst is bijna eindeloos, maar als je mixins hebt die je graag in je eigen werk gebruikt (voor het uitvoeren van ems en rems), laat me dat dan weten in de comments en ik voeg ze hier toe:
Het is een breed onderwerp, er is duidelijk veel om op te nemen, maar duiken in de wereld van EMS is een van de meer bevredigende uitdagingen in de front-end webontwikkeling. Stop met denken aan pixels en begin vandaag relatief te denken!
