HTML pentru începători: Istoria imaginilor digitale, formate de imagini și imagini responsive

Am ajuns la una din părțile mai vizuale ale cursului nostru, și azi discutăm despre imagini, formate de imagini și imagini responsive. Intrăm în detaliu în privința formatelor de imagine raster și vector, despre evoluția culorilor digitale și la final îți arăt modul ideal de a crea imagini responsive, adică imagini care se adaptează la ecranul vizitatorilor. Codăm în VSCode, așa că dacă ești aici să înveți, deschide-l și hai să-ncepem!

Formate de imagini simple

Îl știi deja. Am mai discutat despre el în acest video și în acest articol. Tag-ul <img> ar putea fi considerat printre cele mai utile tag-uri din perspectiva comunicării în HTML, pentru că, nu-i așa? – o imagine face cât 1000 de cuvinte.

Recapitulare

Îți reîmprospătez memoria și-ți aduc aminte că img vine de la image în engleză, adică de la imagine. Tag-ul a apărut prima dată prin 1993, adică acum 30 ani, în browser-ul Mosaic (o să vedeți imediat de ce asta e foarte interesant în câteva minute) și a fost adăugat în specificația oficială a HTML-ului în 1995. Tu îi specifici o sursă a imaginii prin atributul src, un text alternativ în caz că imaginea nu se poate downloada sau afișa prin atributul alt, și niște dimensiuni aproximative care se pot schimba ulterior din CSS dar care sunt importante ca să se încarce rapid pagina, prin proprietățile width de la lățime și height de la înălțime. Apoi, treaba browser-ului e să încarce cât mai repede imaginea în interiorul paginii tale HTML.

Evoluția tehnologică de-a lungul vremii a făcut ca în interiorul tag-ului img să se poată introduce din ce în ce mai multe formate de imagini, hai să le explorăm puțin împreună. Dar înainte de asta, vreau să-ți explic pe scurt diferența dintre două categorii de formate de imagine.

Raster versus vector și evoluția culorilor digitale

Imaginează-ți un tabel în Excel sau Google Docs, în care fiecare celulă reprezintă câte o culoare. Iată niște exemple foarte interesante în articolul ăsta. Monica Dinculescu (un front end developer de elită care lucrează la Google) are un proiect pe GitHub care transformă orice imagine într-un astfel de „tabel de culori” (bonus: la ea culorile vin și cu emoji). Genul ăsta de compoziție a unei imagini se numește grafică raster, sau grafică în care fiecare pixel e descris cu ajutorul culorii pe care o are. Observați, că seamănă cu un… mozaic. :) La fel ca browser-ul care a implementat prima dată tag-ul de imagine.

Acum imaginează-ți că există în ziua de azi imagini 8K, cu rezoluția de 8192px x 4320px și dacă înmulțim valorile vom constata că o astfel de imagine are 35,389,440 pixeli pătrați, adică 35 de MEGA pixeli. Iată că așa se explică termenul folosit foarte des când evaluezi calitatea unei camere foto sau unui ecran. Asta înseamnă și că în formatul unei imagini de dimensiunile astea trebuie să se stocheze 35,389,440 de valori reprezentând culoarea fiecărui pixel. Acest format , care e printre cele mai NEoptimizate formate de imagine existente pentru că are în compoziție fiecare culoare repetată de foarte multe ori, se numește format raster, care vine din engleză dar în română înseamnă același lucru. O matrice, un tabel mare de tot de valori aliniate ca să compună rândurile și coloanele de pixeli ale unei poze. Așa cum probabil e evident, un astfel de format ar presupune ca o poză să aibă 35 de milioane de elemente care descriu culoarea.

Evoluția tehnologică a ecranelor a fost sincronă cu evoluția formatelor de culoare folosite. Primele ecrane construite vreodată aveau exact 2 culori: „pornit” și „oprit”. Inițial, asta însemna verde și negru pe tuburile catodice antice. Apoi, asta a însemnat „alb” pe „negru”, iar pe măsură ce tehnologia a avansat, fiecare pixel putea conține mai mult de un bit de informație (adică 0 sau 1, oprit sau pornit). Printre primele formate populare presupuneau ca fiecare pixel să descrie folosind 2 biți una din 4 culori (reprezentând alb, negru și 2 nuanțe de gri). Apoi folosind 3 biți se descriau una din 8 culori (alb, negru și culorile primare). Apoi cu 4 biți una din 16 culori (alb, negru și 14 nuanțe de gri sau alb, negru și 14 culori primare sau secundare) și așa mai departe. Astăzi se folosesc în general pe ecranele comerciale 24 biți reprezentând 16.7 milioane de culori, și în plus există și sisteme specializate care folosesc chiar mai multe. Dar hai să ne oprim la 24 biți. 24 biți pentru fiecare pixel, ca să descrie una din 16.7 milioane de culori. Dacă ne întoarcem la calculul inițial, aveam 35 megapixeli, adică 35,389,440 pixeli pătrați, fiecare cu 24 biți de informație. Înmulțind, ne ies 849,346,560 de biți pentru o imagine 8k, adică nici mai mult nici mai puțin de 101.24 Mega Bytes. Foarte, foarte, foarte mult. Imaginați-vă o pagină web cu 2-3 astfel de imagini. E un format foarte ineficient, și de-asta a evoluat în timp.

Au existat, așa cum vom vedea, multe încercări de optimizare a formatului raster, folosind tehnici de compresie, care sunt în realitate niște formule matematice care prezic locația culorilor folosind ecuații cu două variabile (lățime și înălțime, adică x și y) sau chiar cu mai multe. N-o să intrăm în detalii algebrico-geometrice, însă lupta asta continuă pentru optimizare a condus la apariția mai multor formate de imagine raster, dar și la ceva ce se cheamă imagine vectorială.

Imaginile vectoriale sunt imagini generate folosind EXCLUSIV formule matematice care descriu primitive geometrice (puncte, linii, cercuri, curbe și forme) care se compun și intercalează folosind diferite culori pentru a compune o formă apropiată de ce-și dorește creatorul ei.

Partea bună a imaginilor vectoriale e că indiferent cât de mari sau mici vrei să le afișezi, ele nu-și pierd niciodată calitatea, apărând permanent la fel de clare. Dacă te gândești la bannerele de pe magazinul Unirea, o parte din ele care arată mai bine folosesc aproape exclusiv imagini vectoriale ca să fie clare la dimensiunile enorme la care sunt afișate.

Partea proastă a imaginilor vectoriale e că în general sunt niște forme mult simplificate față de complexitatea cromatică și stilistică a unei imagini raster, în care fiecare pixel are libertatea de a avea orice culoare indiferent de vecinii lui, pe când în imaginile vector, pixelii sunt colorați folosind exclusiv formula matematică aferentă formei geometrice în care se încadrează pixelul respectiv.

Formatele raster și vector sunt diametral opuse atât la nivel de flexibilitate cât și la nivel de complexitate vizuală și implicit optimizare de mărime. Indiferent cât de mult ar fi optimizat un format raster, el n-o să fie niciodată la fel de mic în kilobytes precum un format vectorial. Asta-nseamnă că pentru multe cazuri în care grafica folosită implică forme simple, culori predictibil distribuite și un stil mai „curat”, vectorii sunt mai buni decât imaginile raster – spre exemplu în iconițe, logo-uri sau grafică în stil minimalist, însă ei nu pot surprinde niciodată complexitatea unei imagini „reale”, care are foarte multe contexte în care se poate folosi în design-urile Internetului modern. Asta-nseamnă că ambele standarde vor coexista de acum încolo, pe perioadă nedeterminată.

Evoluția istorică a formatelor de imagine

Vom trece în revistă foarte repede, în ordine cronologică, formatele cele mai populare de imagini pe care le-au putut afișa browserele de-a lungul vremii:

1. Au existat foarte multe formate de imagine pe care astăzi nu le mai folosim deloc, și doar le voi menționa, ca să nu spuneți că n-ați auzit de ele:
   1. NAPLPS cu extensia .nap,
   2. BSAVE cu extensiile .bsv și .pic,
   3. PCX cu același format – .pcx,
   4. Tagged Image File Format cu extensia .tif și .tiff,
   5. ILBM IFF cu extensia .iff,
   6. TARGA cu extensia .tga,
   7. RIPscrip cu extensia .rip,
   8. Bitmap cu extensia .bmp,
   9. VRML cu extensiile .wrl și .wrz sau
   10. Wireless Bitmap cu extensia .wbmp.
   11. Microsoft Icon cu extensia .ico sau .cur (încă folosit pe alocuri pentru favicon-uri de site-uri și cursoare definite în CSS).
       Mai multe detalii despre formatele astea găsiți în articolul ăsta.
2. JPEG sau JPG vine de la Joint Photographic Expert Group și e încă unul din cele mai populare formate, și printre primele apărute. El folosește formule matematice și bucăți de imagine raster pentru a optimiza formatul raster clasic, și de-a lungul vremii a primit diverse upgrade-uri care l-au făcut mai optimizat și mai practic. Spre exemplu, a devenit progresiv, adică varianta inițială se încarcă blurată, neclară și pe măsură ce se descarcă mai mult din poză, ea se „clarifică”.
3. GIF vine de la Graphics Interchange Format și a fost primul format de imagine care a introdus două concepte esențiale pentru o reprezentare completă a imaginilor: ideea de „transparență” reprezentată ca și culoare de sine stătătoare (practic, pixelii respectiv sunt „goi” și se vede fundalul în care e pusă imaginea) și… animația. GIF-urile animate sunt folosite destul de des astăzi în special în aplicații de chat în care sunt prezente animații scurte, de câteva frame-uri. Din păcate, formatul GIF, prin construcția sa, nu suportă decât 256 de culori, adică 8 biți de informație per pixel. Asta-l face să nu devină prea mare în kilobytes când imaginile sau animațiile generate în formatul ăsta ajung să fie foarte mari.
4. PNG vine de la Portable Network Graphics și perfecționează în toate privințele formatul GIF la capitolul transparență, compresie fără pierderea informațiilor cromatice și optimizare. El suportă un număr variabil de biți de informație în funcție de formatul ales, însă varianta cea mai complexă are mai mult de 16.7 milioane de culori pentru că pe lângă culorile „clasice” mai include și variante de culori cu transparență variabilă. Formatul PNG e cel mai des folosit când e nevoie să folosești imagini de calitate foarte bună, fără pierderi, opțional inclusiv cu transparență. E ceva mai mare decât ultimele variante de JPG în kilobytes, deci dacă n-ai nevoie de transparență sau calitate fără pierderi, atunci JPG e mai OK. Mai nou, formatului PNG i s-a alăturat mai nou și formatul APNG care vine de la Animated PNG și adaugă și animații în ecuație.
5. SVG vine de la Scalable Vector Graphics și reprezintă grafică vectorială descrisă într-un format de fișier non-binar, ba chiar compatibil XML și implicit și HTML. De-asta poți include conținutul unui SVG direct într-un HTML, sau indirect, prin tag-ul <img>. E singurul format care permite lucrul ăsta, și e unul din cele mai utile formate în Internetul de astăzi când vine vorba de includerea iconițelor, logo-urilor și altor imagini vectoriale.
6. WEBP vine de la Web Picture format și AVIF vine de la AV1 Image File format – cele mai noi și moderne formate de imagini, suportă transparență și calitate care rivalizează cu PNG-ul dar cu metode de compresie mult superioare și deci cu mărimi de fișiere cu până la 80% mai mici față de PNG sau JPG, cu număr mai mare de culori reprezentate și cu posibilitatea includerii animațiilor. WebP e mai bine suportat decât AVIF, care are compresie mai bună dar e mai intensiv din perspectiva procesării la afișare. AVIF e și open source.

Păi bun, și tu, ca front end developer, ce format ar trebui să folosești?

Răspunsul, ca orice răspuns la o întrebare cu complexitate mare, este „depinde”. :)

Pe scurt, în orice context în care ai de inclus o imagine într-un site, inițial ar trebui să răspunzi la întrebarea: poate fi vector sau nu? Dacă răspunsul e „da”, atunci e simplu: SVG. Dacă răspunsul e „nu”, atunci răspunsul este: WEBP sau AVIF, cu fallback (sau variantă alternativă pentru browsere vechi) în PNG (dacă ai nevoie de transparență sau calitate maximă), JPG (dacă n-ai nevoie de transparență sau calitate maximă) sau chiar GIF (dacă ai nevoie de animații).

Și cum implementăm acest „fallback”, această variantă alternativă? În același fel cum adaptăm imaginile pe mai multe direcții artistice, rezoluții sau contexte, prin imagini responsive.

Imagini responsive

De ce există imagini responsive?

Știm cu toții că vizitatorii unui site pot intra pe acel site de pe orice dispozitiv cu acces la Internet și un browser încorporat. Asta-nseamnă că lățimea rezoluției variază între 240px (sau 320px dacă suntem realiști) și 8192px.

Să presupunem că vrem să încărcăm pe fundalul unui site o imagine care să acopere toată lățimea fundalului. Așa cum am discutat deja, imaginile vectoriale pot „scala”, adică se pot mări proporțional la orice rezoluție și n-au nevoie de ajutor, pentru că-și păstrează calitatea datorită naturii geometrice și matematice a felului cum e gândit formatul vectorial.

În schimb, îți imaginezi ce s-ar întâmpla dacă ai pune o poză de 4096px x 2160px (care e standardul 4K) să se mărească de 4 ori ca suprafață până la 8192px x 4320px? Îți spun eu, ar arăta pixelat și nasol.

Dar dacă aceeași poză 4K s-ar încărca pe un ecran de 320px lățime și ar avea în final dimensiunea de 320px x 169px, adică ar fi de 163 de ori mai mică în suprafață decât originalul? Îți spun eu: s-ar încărca o poză de 10MB pe un dispozitiv mobil cu conexiune mai slăbuță la Internet și putere de procesare infimă față de un laptop sau desktop, și ar dura o eternitate.

Redimensionările imaginilor raster așa încât să se adapteze mai multor contexte în care e logic să-și schimbe dimensiunile e unul din motivele pentru care există imagini responsive. Pe lângă asta, te poți gândi că o imagine care să umple un ecran desktop landscape ar trebui să aibă formatul 16:9, iar o imagine care să umple un ecran mobile portrait ar trebui să aibă formatul invers: 9:16. Ăsta e un alt motiv pentru care există imagini responsive: faptul că în anumite contexte e posibil să fie nevoie să schimbi cu totul proporțiile imaginii, felul cum e tăiată sau chiar imaginea cu totul (da poți face asta, vei vedea un exemplu imediat).

Și dacă mai ai nevoie de un exemplu de motiv pentru care imaginile responsive sunt o idee excelentă, am discutat de faptul că unele formate de imagine mai noi nu sunt compatibile chiar cu toate browserele, mai ales cele mai vechi. Formatul de imagini responsive are un efect secundar foarte util, prin care poți avea un „default”, adică o valoare implicită a imaginii, care să fie compatibil cu absolut toate browserele, și dacă browserul e totuși mai nou, să folosească varianta mai nouă de format de imagine. Proprietatea asta minunată face parte din tehnicile despre care am mai discutat și în trecut, și pe care le vom explora cu mai multă atenție în viitor, numite tehnici de „progressive enhancement”, care vine din engleză și-nseamnă îmbunătățire progresivă.

Toate astea sunt posibile datorită felului cum a fost gândit standardul de responsive image, și anume principiul conform căruia în spațiul dedicat unei imagini responsive ar trebui să se încarce întotdeauna o singură imagine, cea ideală dedusă de browser din condițiile pe care i le descrii pentru fiecare variantă pe care o ai pentru imaginea respectivă. Asta optimizează încărcarea resursei celei mai bune pentru contextul curent, însă decizia legată de definirea condițiilor optime e integral responsabilitatea web developer-ului, adică a TA! Așadar, hai să vedem exact cum se folosesc imaginile responsive, creând un exemplu care folosește toate ideile discutate deja:

Exemple de imagini responsive

Acum trecem în sfârșit la codat.

Vom implementa trei exemple astăzi. Unul pentru o imagine simplă, unul pentru o iconiță și unul pentru o animație. Și vom folosi câteva elemente noi care să ne ajute să descriem atât structura responsive a unei imagini cât și semantica ei în contextul unei pagini.

Dacă o imagine simplă se creează folosind structura:

<img src="sursa.jpg" width="640" height="480" alt="Descrierea textuală a imaginii" />

o imagine responsive are în inima ei, în miezul ei, un tag complet img pe care-l folosește ca fallback, ca variantă alternativă. Practic, acest img va fi afișat în cazul în care orice alt format mai nou de imagine (sau chiar structura pentru imagini responsive din HTML5 în sine) nu sunt suportate de browserul curent. Browserele foarte vechi vor ignora orice altceva mai scriem în plus față de ce avem acum în cod, și vor afișa exclusiv acest img, deci e important ca img-ul să respecte două principii: să fie adaptat pentru cea mai mică dintre rezoluțiile suportate de pagina pe care-o construim (sugestia mea e să fie la 320px lățime) pentru a minimiza timpul de descărcare și numărul de kilobytes folosiți pentru imagine, și să fie într-un format de imagini mai vechi, mai „clasic”, cum sunt JPG, PNG sau GIF în funcție de context. GIF pentru animații, JPG pentru calitate normală fără transparență, PNG pentru calitate mai mare cu transparență.

Imagini vectoriale

Există și excepții la regula prin care img-ul trebuie musai să fie format mai vechi. Dacă target-ul de audiență al site-ului pe care-l construiești ia în calcul oameni care au browsere măcar din 2010 încoace, iar imaginea pe care vrei s-o introduci în cod este de tip vectorial, deci SVG, poți ignora ce urmează mai departe dacă nu ai nevoie să variezi SVG-ul în funcție de rezoluție sau alți parametri. Poți deci lăsa img-ul ca singur tag, și sursa o poți defini în format SVG și atât. Sau, și mai bine, dacă iconița ta nu mai e folosită altundeva pe pagina curentă, îi poți introduce codul SVG direct în HTML. Hai să vedem un exemplu:

<svg class="Icon" xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
    <path d="M20.285 2l-11.285 11.567-5.286-5.011-3.714 3.716 9 8.728 15-15.285z" />
</svg>

Codul de mai sus definește o imagine SVG de 24px x 24px care are forma unui semn de „văzut” sau „checkmark” în engleză. Fiind direct în HTML, poți face mai multe lucruri cu codul, inclusiv să-l convingi să preia culoarea textului din contextul în care este, folosind proprietatea fill și valoarea currentColor, așa:

<svg class="Icon" xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="currentColor">
    <path d="M20.285 2l-11.285 11.567-5.286-5.011-3.714 3.716 9 8.728 15-15.285z" />
</svg>

fie să-i dai tu o culoare anume, spre exemplu:

<svg class="Icon" xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="magenta">
    <path d="M20.285 2l-11.285 11.567-5.286-5.011-3.714 3.716 9 8.728 15-15.285z" />
</svg>

Dacă faci asta, vei include în HTML direct SVG-ul și browserul nu va mai trebui să downloadeze un alt fișier cu extensia SVG de pe serverul tău de statice, ceea ce va face încărcarea paginii mai rapidă. Partea proastă a tehnicii ăsteia e că dacă ai 5-10-20 de iconițe identice în aceeași pagină, dacă le adaugi pe toate inline în HTML așa, HTML-ul tău va fi mai mare și mai anevoios de încărcat și procesat de browser, pe când dacă incluzi SVG-ul într-o declarație externă prin tag-ul img, browserul va salva în memoria cache imaginea SVG și nu va face niciun alt efort de procesare și randare când mai întâlnește prin cod cele 5-10-20 de alte instanțe ale aceluiași SVG. Asta-nseamnă că e responsabilitatea ta să decizi când și dacă e nevoie să pui SVG-urile în HTML sau să le lași în fișiere separate. Și aici mai am o mențiune: SVG-urile în fișiere separate încărcate cu tag-ul img nu vor mai putea prelua culoarea textului din contextul unde sunt folosite, deci valoarea currentColor a atributului fill devine irelevantă, și trebuie să-i definești o culoare concretă în fișier, culoare pe care o va folosi în toate instanțele în care apare img-ul.

Imagine simplă

Acum hai să explorăm o imagine responsive uzuală. Structura ei, construită în jurul miezului format din tag-ul img, e următoarea:

<figure>
    <picture>
        <source type="image/webp" media="(min-width: 1600px)" srcset="poza-1600w.webp" />
        <source type="image/webp" media="(min-width: 640px)" srcset="poza-640w.webp" />
        <source type="image/webp" srcset="poza-320w.webp" />
        <img src="poza-320w.jpg" width="320" height="240" alt="Chris standing up holding his daughter Elva" loading="lazy" decoding="async" />
    </picture>
    <figcaption>Text descriptiv pentru imagine care e afișat de browser sub imaginea curentă, și care complementează sau extinde textul din tag-ul alt al img-ului.</figcaption>
</figure>

Tag-ul <picture> definește formatul imaginilor responsive. În el, tag-ul <img> definește imaginea de „fallback”, pe care browser-ul o încarcă dacă e suficient de vechi încât să nu știe ce înseamnă restul tag-urilor de deasupra, adică <source>-urile. Imaginea asta ar trebui să fie la cea mai mică rezoluție (e.g. pentru mobile) și în funcție de unde e poziționată, ar trebui să includă proprietățile loading="lazy" și decoding="async" pentru ca browser-ul să deseneze bounding box-ul tag-ului <img> fără să-l descarce imediat ce parsează HTML-ul respectiv, și să amâne downloadarea imaginii abia când utilizatorul ajunge cu scroll-ul aproape de imagine. Asta înseamnă că browser-ul va ști exact cât de mare va fi imaginea finală (în funcție de parametrii width și height care NU sunt opționali, și de CSS-ul aplicat între timp peste document) și o va downloada și randa doar când e nevoie de ea.

Tag-urile <source> definesc progresiv lucruri din ce în ce mai „drăguțe”, mai „nice to have” care pot îmbunătăți experiența utilizatorului în funcție de anumiți parametri. Fix ăsta e principiul „progressive enhancement” în care pe măsură ce îți dai seama că ai resurse suficient de multe, poți încărca lucruri mai bune care îmbunătățesc UX-ul paginii. Primul astfel de parametru este formatul imaginii. Formatele noi sunt mult mai bine optimizate, așa cum am discutat, deci WEBP are calitate mai bună decât JPG, și deci dacă browser-ul suportă formatul ăsta (judecând după proprietatea type="image/webp"), va ignora src-ul img-ului și va folosi src-ul definit în srcset-ul primului <source>.

Apoi, dacă browser-ul decide că viewport-ul (sau fereastra folosită de browser) e mai mare de 640px, atunci intră în vigoare al doilea <source> care bifează condiția min-width: 640px și automat înlocuiește src-ul img-ului cu srcset-ul propriu, adică o imagine de tip WEBP care are 640px lățime. Partea interesantă e că acest responsive image e responsive tot timpul, adică răspunde indiferent ce faci în timpul folosirii paginii. Spre exemplu, dacă redimensionezi fereastra browser-ului de la 320px cât ar fi un ecran de mobil la 700px (adică puțin peste limita de 640px definită cu acest <source>) imaginea se va schimba automat de la cea mică de 320px la cea medie de 640px în mod dinamic. Și cea mai bună parte e că dacă dai un hard refresh în pagină, o să vezi că browser-ul downloadează exclusiv o singură imagine din cele 3 definite până acum – și anume pe cea mai potrivită pentru contextul curent. De aici vine numele conceptului de „imagine responsive”, care satisface principiul de „progressive enhancement”. Pe dispozitivele slabe sau mici încărcăm imagini mici ca să salvăm kilobytes transmiși către dispozitiv și să asigurăm încărcarea rapidă, însă dispozitivele mari și browserele noi primesc formate de imagini mai mari, adaptate la estetica contextului în care sunt folosite.

Că tot vorbim de dispozitive mari, la viewport-uri care depășesc 1600px lățime, adică în ferestre de browser foarte mari, posibile doar pe ecrane mari, avem luxul să decidem că încărcăm un alt src al img-ului original, și anume unul cu o imagine de 1600px lățime, care ocupă MULT mai mulți kilobytes decât variantele anterioare, dar fiind un dispozitiv mare se presupune și că are conexiune la Internet mai bună, prin cablu, și deci are viteza suficient de bună să descarce asemenea imagini mari care fac și design-ul site-ului să arate mult mai bine.

Apropo de design, trebuie să discutăm puțin și de ideea de „art direction” – când schimbi formatul cu alt <source> nu te limitează absolut nimic să ai exact aceeași imagine redimensionată la altă lățime și atât. Poți schimba cu totul imaginea. Îi poți schimba și formatul, de la pătrată pe mobil la înaltă (portrait) pe tabletă și lată (landscape) pe desktop spre exemplu. Sau poate să-și păstreze proporția însă conținutul să fie complet diferit.

Asta e frumusețea imaginilor responsive, că poți adapta complet experiența utilizatorului de la un <source> la altul. Trebuie doar să înțelegi că tag-ul aplică primul <source> din listă care e compatibil cu cerințele din restul atributelor (type, media, etc). Ăsta e motivul pentru care e bine să scrii condițiile de la cel mai complex / greu / generos la cel mai puțin complex, la cel mai simplu. Și poți adăuga oricât de multe <source>-uri dorești: spre exemplu, poți adăuga un <source> pentru tablete cu următoarele caracteristici:

<source type="image/webp" media="(min-width: 1024px)" srcset="poza-1024w.webp" />

Condițiile astea se numesc „breakpoints” – cuvânt care vine din engleză și înseamnă ad literam „punct de rupere”, adică punct în care se schimbă design-ul în contextul de față.

Vom discuta mult mai multe despre imagini responsive și le vom folosi des în curs de acum încolo, dar am vrut să trec în revistă cele mai importante aspecte ca să înțelegi lucrurile de bază. Recomand să te uiți la video ca să vezi cum arată lucrurile despre care tocmai am discutat, fiindcă sunt destul de spectaculoase!

Recapitulare și temă

Felicitări, ai mai parcurs un video din curs! Azi am învățat despre formate de imagini simple, imagini raster versus vector, evoluția istorică a formatelor de imagine și imagini responsive, cu exemple.

Ăsta e momentul perfect să îți dau o temă pentru acasă.

• În fișierul în care ai creat tema din video-ul trecut cu poeziile, adaugă pentru fiecare poezie câte o iconiță reprezentativă în format SVG înainte de titlu (fie inline, fie block) și câte o imagine responsive cu câte 3 variante de rezoluție (320px, 768px, 1280px lățime) pentru fiecare din poezii.
• Apoi adaugă din nou fișierul în repository-ul tău cu git add ., git commit -m “feat: imagini responsive” și git push și dă-mi în comentarii numele repository-ului folosind regula discutată în video-ul trecut: fără https://github.com/

Resurse adiționale

Dacă vrei să aprofundezi noțiunile prezentate în articolul curent, poți citi următoarele resurse utile (în engleză):

• Istoria formatelor de imagine
• Istoria imaginilor în general
• Tipuri de formate de imagine
• Transformarea imaginilor în pixel art
• Emojilate – un proiect care transformă imaginile într-un grid de pixeli care seamănă cu ele plus sursa de pe GitHub
• Specificațiile tipurilor de imagini de pe MDN
• Ce este arta vectorială?
• Standarde video (schiță SVG)
• Formate de culoare RGB și monocrome
• Gradul de adopție al tehnologiei SVG în browsere de pe CanIUse
• Specificația tehnică a formatelor de imagini din standardul HTML
• Dimensiunea paginilor web – o evoluție în timp
• Grafic de evoluție a mărimii paginilor web
• Standardul de pe MDN al imaginilor responsive și diversele feluri de a le folosi

Toate cursurile de Front End Development pentru începători pe care le-am scris până acum

1. Modulul 1: Noțiuni introductive
   • Introducere în Front End
   • Ce este și cum funcționează un calculator?
   • Ce este Internetul?
   • Cum funcționează Internetul?
   • Introducere în tehnologiile Web: HTML, CSS și JavaScript
   • Arhitectura informațională, baza UX-ului și a HTML-ului
   • Pregătește-te să codezi: software pentru Front End
   • Bazele GIT și GitHub
2. Modulul 2: HTML pentru începători
   • Introducere și istoria HTML-ului
   • Elemente și structură de bază
   • Block vs inline, link-uri și semantica textului
   • Istoria imaginilor digitale, formate de imagini și imagini responsive (articolul curent)
   • Decoratori și elemente de design
   • Mai multe în curând…
3. Modulul 3: CSS pentru începători
   • În curând…
4. Modulul 4: HTML pentru avansați
   • În curând…
5. Modulul 5: CSS pentru avansați
   • În curând…
6. Modulul 6: JavaScript pentru începători
   • În curând…
7. Modulul 7: Alte noțiuni utile
   • În curând…

Scrie-mi mai jos în comentarii cum ți se pare cursul până acum și ce alte module ai vrea să mai adaug pe viitor!