Publicat pe Lasă un comentariu

EM vs REM vs PX – De ce nu ar trebui să „folosiți doar pixeli”

Dezbaterea a fost purtată de multe ori – ce unități de măsură ar trebui să folosim în CSS?

Noi, ca mulți alții, eram gata să renunțăm la REM și să ne întoarcem la iubitul pixel. Am pierdut din vedere motivul pentru care am adoptat utilizarea REM-urilor în primul rând. Problema nu se învârte doar în jurul dimensiunilor fonturilor – este vorba și despre accesibilitate.

TL;DR:

  • Pixelii sunt ignoranți, nu-i folosiți.
  • Utilizați REM-uri pentru dimensiuni și spațiere.
  • Utilizați EM-uri pentru media queries.

Pixeli

Pixeli (px) sunt ceea ce ne-am obișnuit cu toții de-a lungul anilor. Toată lumea știe ce este un pixel (deși dimensiunea unui pixel nu este întotdeauna aceeași, dar asta este pentru o altă zi). Toată lumea se simte confortabil cu utilizarea pixelilor. Sunt ușor de tradus. Designerii lucrează de obicei în pixeli, așa că este ușor să luați dimensiunile direct din Photoshop direct în build.

Atunci ce este în neregulă cu pixelii?

Accesibilitate

Sunt un mare susținător al accesibilității pe web. Aș prefera oricând accesibilitatea în detrimentul „frumosului”.

Dacă vă setați toate dimensiunile fonturilor, dimensiunile elementelor și spațierea în pixeli, nu tratați utilizatorul final cu respect.

În majoritatea browserelor, un utilizator își poate seta dimensiunea implicită a fontului din browser pentru a avea o dimensiune diferită de cea implicită (de obicei 16px). Dacă utilizatorul își setează valoarea implicită la 20px, toate dimensiunile fonturilor ar trebui să se scaleze în mod corespunzător.

Cu toate acestea, dacă site-ul web stabilește în mod explicit dimensiunile fonturilor în pixeli, un titlu setat la 30px va fi întotdeauna 30px. Acest lucru ar putea suna grozav din punctul de vedere al designerului/dezvoltatorului – dar nu sunteți utilizatorul, nu mai faceți site-uri web pentru dumneavoastră.

Din fericire, setarea dimensiunilor fonturilor în pixeli nu ruinează complet accesibilitatea. Utilizatorul poate în continuare să mărească și să micșoreze imaginea cu ctrl plus +/- (cmd în loc de ctrl pe OS X). Cu toate acestea, putem face mai bine.

REM-uri

Dacă sunteți familiarizați în vreun fel cu lumea designului web, veți fi auzit, fără îndoială, de REM-uri. Dacă nu sunteți, REM-urile sunt o modalitate de a seta dimensiunile fonturilor pe baza dimensiunii fontului elementului HTML rădăcină. Acestea vă permit, de asemenea, să scalați rapid un întreg proiect prin modificarea font-size-ului rădăcinii (de exemplu, la o anumită interogare media/dimensiune a ecranului).

” unit reprezintă font-size-ul elementului rădăcină (de exemplu, font-size-ul elementului <html>element). Atunci când este utilizat pe font-size pe acest element rădăcină, reprezintă valoarea sa inițială.”

Cum se calculează PX din REM

Un exemplu de bază și cel mai comun: font-size html este setat la 10px, paragraful este setat la 1,6rem – 1,6rem * 10px = 16px.

Setarea unui font-size rădăcină de 10px este cel mai comun scenariu când văd oameni care folosesc REM-uri. Permite o conversie rapidă între valorile pixelilor și valorile REM prin simpla împărțire a numărului la 10.

Cu toate acestea, setarea fontului de bază în pixeli are în continuare aceeași problemă ca și exemplul cu pixeli de mai sus. Accesibilitatea este anulată.

În timp ce REM-urile au cu siguranță utilizările lor, sunt dispus să pariez că majoritatea oamenilor folosesc REM-urile pentru că sunt văzute ca fiind mai cool decât pixelii. Rar văd un proiect în care cineva chiar schimbă dimensiunea fontului HTML rădăcină în funcție de dimensiunea ecranului; și pe bună dreptate. Cu excepția cazului în care aveți un design foarte greoi din punct de vedere tipografic, este puțin probabil să doriți să scalați totul deodată.

Atunci cum putem să ne deblocăm pasul greșit în materie de accesibilitate?

Setați dimensiunea fontului HTML rădăcină ca un procent. Acesta este un procent din dimensiunea implicită a fontului din browserul implicit al utilizatorului. O metodă tipică este de a seta dimensiunea fontului HTML la 62,5%. Acest lucru se datorează faptului că 62,5% din 16px (dimensiunea implicită tipică a fontului din browserul implicit) reprezintă 10px. Aceasta ar însemna totuși 1,6rem = 16px. Acest lucru înseamnă că, dacă dimensiunea implicită a fontului din browserul utilizatorului este modificată, de exemplu, la 20px, 1,6rem ar fi acum egal cu 20px. Așadar, dacă utilizatorul dvs. dorește fonturi mai mari, lăsați-l să o facă. Designer fericit. Dezvoltator fericit. Toate numerele sunt în continuare ușor de prelucrat.

Scenariul ideal ar fi să lăsăm dimensiunea fontului HTML la 100%, dar acest lucru îngreunează puțin calculele matematice. De exemplu, 16px este acum 1rem, 20px este 1,25rem, 24px este 1,5rem etc.

Sass/SCSS to the rescue

Lucrul cu toate aceste numere în cap ar fi destul de consumator de timp. Din fericire, dacă folosiți Sass/SCSS, LESS sau orice alt preprocesor CSS, nu ar trebui să vă faceți griji. Puteți folosi funcții care să calculeze aceste lucruri în locul dumneavoastră.

Ce se întâmplă cu EM-urile?

EM-urile se comportă inițial într-un mod similar cu REM-urile, până când vine vorba de anvelopare. Nu am fost niciodată un fan al EM-urilor, mai ales când vine vorba de dimensiunile fonturilor. De exemplu, luați un div cu o dimensiune a fontului de 2em, apoi adăugați un paragraf cu o dimensiune a fontului de 2em. Dimensiunea fontului acelui paragraf este acum 2ems în raport cu div-ul. Pierd rapid urma calculelor matematice și nu mai știu ce mărime este, iar acest lucru devine rapid imposibil de gestionat. Asta este ceea ce rezolvă REM-urile – dimensiunea se referă întotdeauna la rădăcină.

Ce se întâmplă cu media queries?

Am stabilit că utilizarea valorilor pixelilor prevalează asupra setărilor implicite ale browserului, deci convertirea simplă a tuturor dimensiunilor pixelilor în REM-uri este cel mai bun lucru de făcut, nu? Nu chiar.

Această postare pe blog evidențiază unele dintre principalele diferențe dintre utilizarea pixelilor, EM și REM în interogările media (https://zellwk.com/blog/media-query-units/). Mergeți să citiți și apoi reveniți.

În rezumat, atât pixelii, cât și REM-urile pentru interogările media eșuează în diverse browsere atunci când se folosește zoomul browserului, iar EM-urile sunt cea mai bună opțiune pe care o avem. REM-urile eșuează mult mai mult decât pixelii în acest moment, așa că le vom scădea complet.

Pentru că devine totuși un pic mai complicat. Atât EM-urile, cât și pixelii au neajunsurile lor cu media queries atunci când vine vorba de diferența de o zecimală a acestei unități. Dacă se întâmplă să folosiți atât media queries cu lățime minimă, cât și cu lățime maximă în același bloc de cod, veți avea o perioadă proastă de îndată ce utilizatorul începe să schimbe zoom-ul browserului sau dimensiunea implicită a fontului.

Iată câteva exemple:

Utilizăm 6 zecimale deoarece anumite browsere nu arată nicio diferență între 2-5.d.p.

Pentru claritate, folosim o dimensiune a fontului de 10px pe corp pentru a face calculele matematice puțin mai clare.

Exemplu 1: Zoom-ul browserului setat la 100%, lățimea browserului setată la 640px

min-width: 64em = Hitmax-width: 63.99em = Missmax-width: 63.999999em = Hitmin-width: 640px = Hitmax-width: 639px = Missmax-width: 639.999999px = Miss

Exemplu 1b: Zoom-ul browserului setat la 100%, lățimea browserului setată la 639px

min-width: 64em = Missmax-width: 63.99em = Hitmax-width: 63.999999em = Hitmin-width: 640px = Missmax-width: 639px = Hitmax-width: 639.999999px = Hit

Atunci nu putem folosi 6dp pentru EM-uri, deoarece lovește ambele media queries.

Exemplu 2: Zoom-ul browserului setat la 110%, lățimea browserului setată la 704px (deoarece 640px * 110% = 704px)

min-width: 64em = Missmax-width: 63.99em = Missmax-width: 63.999999em = Hitmin-width: 640px = Missmax-width: 639px = Missmax-width: 639.999999px = Hit

Exemplu 2b: Zoom-ul browserului setat la 110%, lățimea browserului setată la 705px

min-width: 64em = Hitmax-width: 63.99em = Missmax-width: 63.999999em = Missmin-width: 640px = Hitmax-width: 639px = Missmax-width: 639.999999px = Miss

Deci nu putem folosi 2dp pentru EM-uri. Așadar, tot ce ne rămâne în acest stadiu sunt 6dp pixeli. Acest lucru funcționează cu zoomul browserului. Cu toate acestea…

Exemplul 3: Zoom-ul browserului setat la 100%, dimensiunea fontului browserului setat la 20px, lățimea browserului setată la 800 (deoarece 640 * 125% = 800)

min-width: 64em = Hitmax-width: 63.99em = Missmax-width: 63.999999em = Hit

Deci, din nou, EM-urile de 6dp sunt încă scoase. Și nu putem folosi deloc pixeli pentru media queries, deoarece acestea continuă să se declanșeze la 640px/639px, deoarece ignoră EM-urile/REM-urile.

Atunci, care este soluția?

Din păcate, nu există un răspuns. Până când browserele nu rezolvă problemele de rotunjire, suntem puțin blocați.

Cea mai simplă opțiune acceptabilă, este ca niciodată să nu creăm o suprapunere a lățimii minime și a lățimii maxime în același bloc. Exemplu:

body { @media screen and (max-width: 63.99em) { background: blue; } @media screen and (min-width: 64em) { background: blue; }}

Problema cu cele de mai sus este că există anumite scenarii în care ambele media queries sunt lovite, sau ambele sunt ignorate. Deci, pariul sigur ar fi să scriem ceva de genul:

body { background: blue; @media screen and (min-width: 64em) { background: blue; }}

De ce nu există o soluție reală? Nu cred că le pasă suficient de multor oameni. Orice statistică care spune că oamenii nu-și schimbă dimensiunea implicită a fontului din browser este cu siguranță distorsionată. Opțiunile din Chrome pentru a schimba dimensiunea implicită a fontului este acum foarte îngropată în opțiunile avansate ale browserului.

Capcanele

Există câteva capcane în această abordare:

  • Dacă sunteți obișnuiți să scrieți ambele media queries min-width și max-width în același bloc de cod, va dura mai mult.
  • Crește complexitatea, deoarece va trebui să suprascrieți CSS într-o direcție sau alta, mai degrabă decât să-i spuneți browserului să folosească opțiunea A sau B.
  • Crește dimensiunea fișierului din cauza acestor suprascrieri. Nu cu mult, dar merită luată în considerare.

În funcție de proiect, de cine îl dezvoltă și de diverși alți factori, cum ar fi bugetele proiectului (trebuie să fim realiști aici), pixelii ar putea fi mai ușor și mai rapid. De asemenea, ar putea fi mai ușor și mai rapid să ignori accesibilitatea.

Amintește-ți pentru cine construiești site-uri web.

De asemenea, merită menționat faptul că această postare pe blog este exactă la momentul scrierii, dar cu actualizările constante ale modului în care funcționează browserele, această problemă ar putea deveni un lucru de domeniul trecutului.

.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *