Share
Ho recentemente scritto su ems; cosa sono, come sono usati e alcuni pezzi da tenere a mente quando li implementi tu stesso. Ho solo scalfito la superficie, e il thread dei commenti ha sollevato il doppio delle domande che l'articolo ha risposto! In questo follow-up prenderò le cose in modo più approfondito, guardando in modo ancora più dettagliato.
E su Dribbble Nota: L'articolo precedente copre tutte le basi. Vi consiglio di leggere su di loro prima di andare oltre.
L'argomento delle misurazioni senza unità (vale a dire valori senza pixel, percentuali, ems, yard, braccia ...) è stato offerto da un paio di persone l'ultima volta, specialmente perché avevo incoraggiato l'uso di ems per specificare altezza della linea.
Ems ha perfettamente senso in questo caso in quanto sono relativi al dimensione del font. Se il testo in questione cresce o si riduce, lo stesso vale per l'altezza della riga se è impostata in ems. Le unità assolute, come i pixel, farebbero davvero un casino. Lo stesso vale per spaziatura del carattere, un altro esempio di una dimensione che dovrebbe essere sempre relativo alla dimensione del carattere.
Tuttavia, possiamo migliorare su questo. Gli Ems complicano le cose mentre i loro valori precipitano a cascata; gli elementi ereditano i valori dei loro genitori. Prendi questa disposizione per esempio: un articolo che contiene un paragrafo:
Se applichiamo l'altezza della linea all'articolo, sarà anche ereditata dal paragrafo, il che va bene:
Ma ciò che il paragrafo sta effettivamente ereditando è il valore calcolato (in questo caso efficacemente 24px), quindi la sua altezza della linea è relativa alla dimensione del font dell'articolo, non sua. Se aumentiamo la dimensione del carattere del paragrafo all'equivalente di 20px:
quindi la sua altezza della linea rimane fedelmente a 24px. Idealmente, vorremmo che l'altezza della linea fosse 1.5 * 20 = 30px.
È qui che entrano le misure senza unità. Rimuovendo l'unità em dall'altezza della linea dell'articolo:
il paragrafo erediterà invece il valore senza unità, 1.5. L'altezza della linea del paragrafo è ora relativa alla sua dimensione del font, il bingo!
Accentsconagua
È interessante notare che, questo non si applica a spaziatura del carattere. E puoi completamente dimenticarti margini, indentatura del testo, questo genere di cose.
Se sei interessato a leggere di più sull'argomento, Eric Meyer lo ha trattato in modo solido nel 2006, oltre a Harry Roberts ha una grande panoramica delle unità di misura da un paio di anni indietro.
Mentre microtypography si riferisce ai piccoli dettagli all'interno di un documento (segni di punteggiatura, legature, sillabazione, crenatura e così via) macrotypography gestisce tutte le cose "grandi". Pensa a tutti gli aspetti della tipografia che rendono leggibile un corpo di testo; spazio bianco, lunghezza della linea (misura), rientranza di paragrafo ecc.
Dai un'occhiata a questo setup di colonne fluide:
Un layout perfettamente decente; due div, ciascuno del 50% di larghezza, con un po 'di padding a destra e a sinistra per formare le grondaie (all'interno di ogni div, supponendo che sia usato * ridimensionamento della scatola: border box). In genere, si sarebbe tentati di definire il padding utilizzando pixel o percentuali (anche migliori), se ti sentissi super flessibile.
Tuttavia, i pixel e le percentuali avranno entrambi un effetto negativo sulla leggibilità del contenuto, se (quando) la dimensione del carattere viene modificata. La larghezza di gronda, come in generale lo spazio bianco, dovrebbe essere effettivamente ridimensionata rispetto al testo. In questo esempio, abbiamo due colonne di testo, con gutter applicato come percentuale della larghezza della colonna, proprio come descritto sopra:
.colonna larghezza: 50%; fluttuare: a sinistra; imbottitura: 0 3%;
Questa è una demo dal vivo, dai un'occhiata e divertiti con essa ... Tuttavia, quando modifichi la dimensione del carattere, noterai che la grondaia diventa relativamente più stretta, sfocando la divisione tra le colonne di testo e rendendola più difficile da leggere.
Questo è un esempio estremo, con un testo assurdamente grande per la larghezza della colonna, ma illustra il punto ... Molto meglio sarebbe definire il padding usando ems:
.colonna larghezza: 50%; fluttuare: a sinistra; imbottitura: 0 1,2em;
In questo modo, la grondaia cresce e si restringe insieme al testo, mantenendo la distanza tra le colonne e mantenendo le cose leggibili.
Prova a giocare con questo ... Se non si sta ancora utilizzando ems, è probabilmente una delle due cose che non ti piacciono; il fatto che i loro valori cadono a cascata, o che devono calcolare quei valori in primo luogo.
L'approccio al 62,5% (proposto per la prima volta da Richard Rutter nel lontano 2004) ti aiuterà nel secondo. Molto semplicemente, invece di impostare la dimensione del carattere di base al 100% (che assumeremo 16px) lo impostiamo al 62,5%, in pratica a 10px.
Da quel punto, 1em = 10px. Perciò:
| Ems | Pixel equivalenti |
| 0.5em | 5px |
| ... | ... |
| 1.1em | 11px |
| 1.2em | 12px |
| 1.3em | 13px |
| 1.4em | 14px |
| ... | ... |
| 47.3em | 473px |
e così via, che dovrebbe rimuovere parte dell'aritmetica mentale. però, c'è un piccolo problema con questo approccio, e tutto ha a che fare con ...
Parliamo un po 'del 62,5% di avvertimento in un momento, ma prima dobbiamo stabilire alcune basi.
Nella loro forma più semplice, le query multimediali ci aiutano ad applicare le regole CSS in circostanze diverse, più comunemente a seconda delle dimensioni dello schermo. Le risoluzioni dello schermo sono misurate in pixel, quindi è logico definire le media query nello stesso modo:
@media solo schermo e (min-larghezza: 600px) / * alcune cose * /
Applichiamo questo alla nostra demo precedente, per dividere le colonne dopo un certo punto.
In questo primo approccio mobile, le nostre colonne vengono divise una volta che il viewport raggiunge 600px In questo caso, la cifra arbritraria di 600 px sembra andare bene; lunghezza della linea ottimale (o misurare) è un argomento molto discusso, ma come afferma Robert Brighurst:
Tutto ciò che va da 45 a 75 caratteri è ampiamente considerato come una lunghezza soddisfacente della linea per una pagina a colonna singola impostata in una faccia di testo serifata in una dimensione di testo. La linea di 66 caratteri (contando sia le lettere che gli spazi) è ampiamente considerata come ideale.
Robert Brighurst - Gli elementi dello stile tipografico
Nella nostra demo, con dimensione font di 1em, la misura ora colpisce circa 70 caratteri prima di dividerla in due colonne.
Una volta che abbiamo colpito due colonne, la misura è forse un po 'più ristretta di quanto vorremmo, ma queste colonne sono perfettamente adatte per gli scopi di questa demo. Tuttavia, i problemi sorgono quando modifichiamo la dimensione del carattere del nostro browser (comando hit +).
Con le dimensioni del carattere potenziate a "Molto grande" (sto usando Chrome) le nostre misure di colonna sono modo troppo stretto, rendendo il contenuto piuttosto illeggibile. Per questo motivo, dovremmo prendere in considerazione l'idea di rendere le nostre query multimediali relative anche alla dimensione dei caratteri.
Ricorda la formula del nostro precedente articolo?
Puntiamo a 600 px, da una dimensione del font ereditato di 16px. 600/16 = 37,5em, quindi cambiamo la nostra query multimediale per riflettere questo:
Ora, quando le impostazioni della dimensione del carattere del nostro browser vengono modificate, vediamo una differenza nel modo in cui la media query si comporta. Con testo più grande, ecco la query multimediale basata su pixel, con il viewport impostato a circa 630 px di larghezza:
Considerando che, a quella larghezza dello schermo, la query multimediale basata su em mantiene le cose ordinatamente in una colonna; bello e leggibile.
Ingrandisci / rimpicciolisci e osserva che la query sui media ha effetto Ecco la crisi; Le domande dei media basate su em sono totalmente disinteressate a qualsiasi dimensionamento html, corpo, o qualsiasi altra cosa; sono relativi alla dimensione del carattere del browser. Ciò significa che, impostando la dimensione del carattere di base su qualsiasi valore diverso dal 100%, dovrai gestire due scale di valori em.
Lavora da una base del 100% e tutto inizierà da una parità di condizioni. Inoltre, come argomenta Filament Group, lavorare in questo modo ti allontana dal pensare in pixel, che è una buona cosa.
Una parola è emersa più di ogni altra nella discussione dei commenti dell'articolo precedente; mixin. Se stai cercando di capire come funziona, allora perché non lasciare che un preprocessore CSS faccia il lavoro più pesante per te?
Con i preprocessori CSS, come Sass, LESS e Stylus, puoi definire mix e funzioni. Questi accettano i parametri, quindi calcolano e sfornano i valori CSS per te.
Nota: Se sei nuovo al concetto, dai un'occhiata a Mastering Sass: lezione 2 in cui Jeffrey introduce i mixin di Sass.
Mixin e funzioni sono in grado di gestire tutti i tipi di cose per te, inclusi i fastidiosi strumenti matematici che circondano gli ems.
Prendi questo semplice esempio da Garrett Winder a Erskine. Inizia la definizione di una funzione (chiamata "em") che accetta due valori (proprio come la nostra formula da precedenti) sebbene il valore di contesto abbia un valore predefinito di 16, quindi non è necessario specificarlo nuovamente a meno che non sia necessario.
Possiamo quindi utilizzare la funzione "em" nei CSS in seguito, chiedendole di calcolare l'equivalente di 30px:
Che, una volta compilato, emette il CSS nella sua forma grezza:
E questo non è l'unico esempio del suo tipo: migliaia di sviluppatori di front-end hanno tagliato i loro denti di pre-elaborazione scrivendo i propri mix di em. Rems anche; inserendo il valore di pixel desiderato in questo mixin descritto da Chris Coyier, puoi facilmente avere rems in uscita, con i pixel di fallback.
Ecco il mixin. 
Ecco l'uso. 
Ecco il risultato. La lista è quasi infinita, ma se hai qualche mix che ti piace usare nel tuo lavoro (per ems e rems in uscita) fammelo sapere nei commenti e li aggiungerò qui:
È un argomento vasto, c'è chiaramente molto da fare, ma immergersi nel mondo dello sme è una delle sfide più soddisfacenti nello sviluppo web front-end. Smetti di pensare ai pixel e inizia a pensare relativamente, oggi!
