Web on visuaalinen väline. Valtaosa tästä visuaalisesta maisemasta on kuvatiedostojen ansiosta. Vaikka paljon CSS: llä ja inline-SVG: llä voidaan saavuttaa, useimmat sivustot tarvitsevat edelleen kuvatiedostoja.
Keskimäärin otettiin huomioon kuvat yli puolet sivun koko viime vuonna ja vuosi vuodelta kuvakoko kasvaa; siellä oli 21% kasvu kuvakoossa yksin vuonna 2014.
Samaan aikaan verkossa käytettävien laitteiden määrä ja monimuotoisuus kasvavat edelleen. Ratkaisut vaihtelevat nyt missä tahansa välillä 72ppi (vähemmän yleisesti) ja yli 600ppi.
Kuvan luominen mille tahansa laitteelle riittävän laadukkaan näyttö on yksinkertainen: tallenna se 1000ppiin ja soita se päiväksi. Tuloksena oleva kuva on terävä jopa korkeimmilla hi-res-laitteilla. Mutta laadun ollessa korkea, niin myös tiedostosi. Sivun latausaikana a keskeinen tekijä UX: ssä meidän on varmistettava, että sivustot toimitetaan käyttäjillemme nopeasti. Kun kuvat ovat niin korkealaatuisia, että ne kestää kymmenkunta sekuntia ladata laajakaistayhteyksiin, puhumattakaan mobiiliyhteyksistä, silloin ne ovat tehokkaasti käyttökelvottomia.
Herkkien kuvien tavoite ei ole tuottaa korkealaatuisempia kuvia näytöille, jotka voivat näyttää sen (jota voimme tehdä helposti). Tavoitteena on tuottaa korkealaatuista kuvaa eikä mitään muuta.
Tämä opas on suunniteltu opettamaan sinulle, mikä toimii, missä ongelmat ja haitat ovat edelleen, ja miten voit käyttää reaaliaikaisia kuvia verkkosivustoilla.
Minusta tuntuu tarve, nopeuden tarve
Miksi nopeus on väliä? Tietenkään kukaan ei enää ole 3G-yhteydellä? Kukaan ei käytä puhelinverkkoa. Jos asiakkaasi kohderyhmä asuu Manhattanin kaupungeissa, miksi sinun pitäisi välittää maaseudun Lesothosta? Tosiasia on, että se on myytti, että olemme kaikki erittäin nopea laajakaista, jonka myydään yrityksille, jotka hyötyvät haluamisesta yhä nopeammin.
Useimmat ihmiset viettävät vähintään kaksi tuntia päivässä huonompaan yhteyteen. Minulla on usein eniten aikaa selata liikkumiseen, kun jopa luotettava 3G-yhteys kuulostaa jonkin kaukana unelmalta.
Huhtikuussa Google ilmoitti että matkaviestinnän ystävällisyyttä käytetään ranking-tekijänä laitteilla suoritetuille hauille, joita hän pitää "mobiilina". Ennen sitä, nopeus oli tekijä sivun sijoituksessa - sekä nimenomaisesti osana Googlen laskutoimituksia että epäsuorasti vaikuttavana tekijänä poistumisprosenttiasi.
Kahdessa identtisesti sijoittuvassa sivustossa ylimääräinen 1 kilotavun voi laskea sinut kolmannesta sijasta Googlessa, neljäs tai viides. Se voi jopa pudottaa sinut 10.-11. - toisin sanoen sivulta 1 - sivulle 2 - kaikki siihen liittyvät vaikutukset asiakkaasi tuloihin.
Tarvitsetko todella kuvan?
Eniten optimoitu kuva on, ei kuvaa ollenkaan. Jos sinulla on viisi kuvaa sivustossasi ja pudotat yhden, olet tallentanut itsesi 20%, ehkä tärkeämpää, olet tallentanut itse http-pyyntö. Jos pudotimme kaikki kuvat sivustoistamme, olisimme säästäneet itsemme 100% ja kaikki viisi http-pyyntöä. Joten miksi et tee sitä?
Emme pudota kuvia sivustoistamme, koska ne kommunikoivat tehokkaammin kuin tekstin lyhyellä aikavälillä. Ne luovat emotionaalisen yhteyden, joka vetää käyttäjien sisältöön.
Tiedämme sen käyttäjät eivät lue verkkosivuja . Hyvin harvat lukivat syvällistä sisältöä verkossa. Kuvat antavat meille mahdollisuuden yhdistää, viestiä ja vahvistaa tuotemerkkiä murto-osassa tekstin hallinnan ajankohdasta.
Kuvat voivat olla suuria ja vaikeasti ladattavia, mutta selaimessa tehtyinä ne ovat paljon tehokkaampia kuin tekstin luominen käyttäjän sitoutumiseksi ja tuotemerkkiviestin vahvistaminen.
Reagoivat kuvat auttavat meitä varmistamaan, että emotionaalisten yhteyksien kuvien rakentaminen ei häviä, kun kärsimätön käyttäjä osuu takaisin-painikkeeseen.
Entä SVG?
SVG (Scaleable Vector Graphics) on yksi Webin todenmukaisista uraauurtavista tekniikoista. Se on kauempana käyrää, että useimmat suunnittelijat eivät ole vielä tunnistaneet todellista potentiaaliaan.
SVG - kuten nimi tarkoittaa - on vektoripohjainen. Tämä tarkoittaa, että SVG-grafiikka on rakennettu pisteistä, kulmista ja etäisyyksistä. SVG on - kuten nimestä käy ilmi - skaalautuva, joten se näkyy yhtä hyvin 5k iMac- tai Android-älypuhelimella ilman laadun heikkenemistä ja tiedostojen koon muuttamista.
Jos sinulla on tasainen kuva, kuvake, logo, lähes kaikki, joka voidaan näyttää SVG: nä, niin SVG on tapa lähteä.
Useimmat Webissä olevat kuvat ovat bittikarttoja. Yleisesti ottaen bittikartan toiminnot kuvaavat jokaista pikseliä yksi kerrallaan, sen väri (RGB - punaiset, vihreät ja siniset arvot) ja joissakin tapauksissa sen läpinäkyvyys. Jos sinulla on 100px 100px: n mittainen kuva, sinulla on 10 000 pikselin kuva; jos jokaisella pikseleellä on 4 arvoa kuvaamaan sitä, niin kuvaan liittyy 40 000 bittiä. Kuulostaa paljon, eikö niin? Joskus se on pienempi kuin vektorigrafiikka.
Harkitse 1px 1px kuva; joka vaatisi 4 bittiä dataa bittikarttaan (punainen, vihreä, sininen ja alfa-arvot). Tarkastellaan nyt samaa neliöpistettä, joka on kirjattu vektoriksi; joka vaatisi suorakulmion x, y, leveyden ja korkeuden RGBA-arvojen lisäksi.
Ne ovat raaka esimerkkejä, mutta ne ovat tarkkoja. Usein kuvion vektori-versio - jos meillä on jopa yksi käytettävissä - ylittää vastaavan bittikartan tiedostokoot ja sitten bittikartta on ainoa järkevä valinta.
(Mis) JavaScriptin avulla
Kuten useimmat elämän ongelmat (jos elämäsi on verkossa), reagoivat kuvat voidaan ratkaista JavaScriptin avulla. Itse asiassa useiden vuosien ajan JavaScript oli ainoa tapa ratkaista ongelma. JavaScript voi testata käyttäjäagentin kykyjä, määrittää millaisen selain on, ja kirjoittaa tavallisen HTML-kuvakkeen, joka sisältää sopivan kuvan.
Web-suunnittelijat, jotka vastustavat JavaScriptiä, tekevät yleensä sen, koska jotkut ihmiset sammuttaa sen . Tämä ei kuitenkaan ole enää totta, etenkään mobiilisivustossa, mutta on olemassa joitakin pysyviä asioita: kuvan kirjoittaminen JavaScriptin avulla tarkoittaa sitä, että hakukoneen robotteja ei jäsennetä kuvaan, ja se tekee vain skriptin jälkeen kuten ajoa.
Suurin ongelma JavaScriptin käytön suhteen on se, että se on väärinkäyttö JavaScriptin ydintoiminnossa. HTML sisältää tietoja, CSS käsittelee esitystä, JavaScript käsittelee toiminnallisuutta. Kun poistamme näistä jäsennellyistä rooleista, kohtaamme ongelmia, jotka vaativat hakkereita korjata ne. Kuvat ovat tietoja, joten niitä pitäisi käsitellä HTML-muodossa.
Ongelma selaimissa
Koska RWD oli ensin ajateltu, kuvat ovat olleet suurin kompastuskivi. Mutta nyt olemme alkaneet löytää keinoja ratkaista eri ongelmat. Tekniikat, jotka ovat taistelussa kovettuneita ja riittävän menestyksekkäitä, jotta niitä voidaan pitää parhaimpana käytäntönä. Ominaiset kehittäjät ovat luopuneet aikastaan hallita WC3: tä virallisiin ratkaisuihin, ja nyt ensimmäistä kertaa reagoivat kuvat ovat käytännöllisiä.
Herkkien kuvien avain on, että ne on suunniteltu täysin tietoisiksi verkon puutteista. On huolehdittava siitä, että reagoivat kuvasovellukset eivät riko nykyisiä selaimia, joten myös selaimissa, jotka eivät tue herkkiä kuvia, koodi häviää hiljaisesti ja ei-herkästi, oletuskuvat näkyvät.
Tässä artikkelissa tarkastelemme kahta virallista reagoivaa HTML-elementtiä: srcset ja kuva.
Tällä hetkellä Edge, Safari ja iOS Safari tukevat vain srcset- määrityksen osajoukkoa. Firefox, Chrome, Opera, Android-selain ja tulevat Safari- ja iOS-versiot tukevat sitä täysin. (Me keskustelemme alla olevista eroista.)
Tällä hetkellä kuvan elementtiä tukee täysin Firefox, Chrome, Opera ja Android-selain. Edge, Safari ja iOS Safari eivät tue sitä, eivätkä ne ole ilmoittaneet aikataulua sen toteuttamisesta.
Jopa sellaisten selainten joukossa, jotka tukevat uutta koodia, esiintyy epäjohdonmukaisuuksia, sillä eri selaimen valmistajat tulkitsevat W3C-määrityksiä eri tavoin. Esimerkiksi, kun määrität kuvan pienen ja suuren kuvan muutoksen katselukokoon perustuen, jotkut selaimet siirtyvät suurelle kuvalle, kun näkymä on 1px suurempi kuin pienikokoisen kuvan koko, muut siirtyvät suurikokoiseen kuvaan vain silloin, kun näkymäportti Suuri kuva edustaa täysin vastaavaa.
Yhteenvetona selaimet jaetaan kahteen leiriin: ne, jotka suosivat laadukkaampia kuvia mahdollisuuksien mukaan, ja ne, jotka suosivat pienempiä latauksia, jos mahdollista. Selainvalmistajat silti näyttävät tätä ulos, lopulta joku toteutus osoittautuu suosituimmaksi - henkilökohtaisesti toivon, että se on jälkimmäinen, koska kuten yllä todettiin, suorituskyky on ratkaisevan tärkeä käyttäjien kokemukselle.
Nyt paras vaihtoehto web-suunnittelijoille on noudattaa määrittelyä ja älä yritä arvata selaimella. Selaimen oletuskokemus (parempi laatu tai nopeampi lataus) on osa sitä, mitä käyttäjä valitsee oletusselaimen, joten jos käyttäjä on tietoinen erilaisista lähestymistavoista, selaimen etusija on todennäköisesti käyttäjän etusija myös .
Vastuullinen kuva parhaasta käytännöstä (2015)
Koko Web-historian aikana olemme käyttäneet yhtä elementtiä kuvaamaan kuvaa, img- elementtiä. HTML5: ssä img- elementti on hiukan muuttunut roolistaan, joka on suunniteltu ottamaan käyttöön reagoivat kuvat: img- elementti ei enää edusta kuvaa, vaan se on nyt paikkamerkki kuvasta.
Tämä erottelu on tärkeä, koska vaikka img- elementissä aiemmin oli yksittäinen kuvatietojoukko eli se bittikartta tai vektori, nyt kuva voi sisältää useita datajoukkoja.
Img- elementti (joka kerta kaikkia ei-koodereita varten) näyttää tältä:
Img- elementin reagoiva kuvaversio näyttää tältä:
Tuskin mitään muutosta lainkaan. Kun katsot tätä koodia, huomaat tärkeän asian: koodi on taaksepäin yhteensopiva. Jos selaimessa tapahtuu, joka ei ymmärrä srcset- attribuuttia, se yksinkertaisesti jättää sen huomiotta ja tekee kuvan alkuperäisen vuoden 1993 eritelmän mukaan.
Tämä tarkoittaa sitä, että voimme nyt käyttää herkkiä kuvia merkinnöissämme ilman tarvetta ominaisuuden havaitsemiseen.
Uudessa reagoivassa img- elementissä src käytetään ensisijaisesti oletuskuvana ja selaimille, jotka eivät tunnista srcset-arvoa, kun taas srcset sisältää kaikki käytettävissä olevat korkeatasoiset kuvatiedostot kyseiselle paikanvaraajalle.
Kun img- elementti tehdään, selain määrittää itselleen, mikä kuvatiedosto on sopivin.
Käyttämällä srsettiä
Nyt kun tiedämme, että srcset epäonnistuu hiljaisesti selaimissa, jotka eivät tue sitä, voimme lisätä lisäkuvan:
Tällöin minkä tahansa selain, joka tukee srcset-tiedostoa , näyttää image-b.jpg ja kaikki selain, joka ei tue srcset-tiedostoa , näyttää image-a.jpg.
On tärkeää huomata, että selain lataa vain kuvan, jonka se päättää haluavansa näyttää, mutta se ei lataa kahta kuvaa ja valitse sitten yksi.
Valitettavasti tämä ei vie meitä kovin pitkälle, koska ellet näytä srcset- tukea, mikään käytännöllinen sovellus ei voi vaihtaa kuvia, jotka perustuvat srcset- tukeen yksin.
Ratkaisu on antaa selaimelle lisätietoa siitä, minkä kuvan pitäisi valita. Jotta voisimme tehdä tämän, meidän on toimitettava tietoja käytettävissä olevasta tilasta tai pikselitiheydestä.
Käyttämällä x-kuvaajaa
X-kuvaaja kertoo selaimelle, kuinka tiheä kuvassa olevat pikselit ovat.
Jos esimerkiksi haluat tarjota verkkokalvotyyppisen kuvan kahdella pikselimäärällä kuin tavallinen kuva, määrität verkkokalvon kuvan srsetissa, jonka jälkeen seuraa välilyönti ja sitten avainsana "2x".
Meillä on kuva:
Selaimen retina-vaihtoehdon lisäämiseksi lisätään seuraava srcset:
Tässä tapauksessa on kolme mahdollista tulosta:
jos selain ei tue srcset, se käyttää src- attribuutissa määritettyä kuvatiedostoa;
jos selain tukee srcset-tietokonetta ja siinä on kaksoisresoluutioinen näyttö, se käyttää srcset-attribuutissa määritettyä kuvaa;
jos selain ei tue srcset-tiedostoa, mutta sillä ei ole suurta resektiä , se käyttää src- attribuutissa määritettyä kuvaa (kun srcset- attribuutissa ei ole "1x" -kuvaa , src- attribuutin oletetaan olevan kyseinen kuva vaihtoehto).
Selaintuki on hyvä ja paranee nopeasti. Yhdellä ominaisuudella olemme ratkaisseet reagoivien kuvien hämmennystä, yay us!
Viimeinen asia, joka huomataan x-kuvaajasta: kuormitettavan kuvan valinta riippuu pikselitiheydestä, joten jos käyttäjä pienentää selaimensa 200%: iin (halkaisemalla kuvakoon ja kaksinkertaisesti pikselitiheyden) 2x kuva latautuu. Tällä voi olla haitallinen vaikutus esteettömyyteen - emme todellakaan halua nähdä sivustoja, jotka leviävät hitaammin näkövammaisille yksinkertaisesti siksi, että he haluavat zoomata selaimensa.
Käyttämällä w-kuvaajaa
W-kuvaaja on hieman kehittyneempi kuin x-kuvaaja.W-kuvaaja toimii kertomalla selaimelle, kuinka monta todellista pikseliä on olemassa tietyn kuvamäärän x-akselilla (leveys).
Edge, Safari ja iOS Safari eivät tue kirjoitushetkellä w-kuvaajaa , joten sen hyödyllisyys on jonkin verran vähentynyt.
Palataan alkuperäiseen kuvaamme:
Jos tämä kuva on luonnostaan 1600 pikseliä leveä ja jos haluamme lisätä verkkokalvon kuvan, kuten edellä mainitun x-kuvaajan kanssa , olisimme määrittäneet kuvan srcset- attribuuttiin, joka on 3200 pikseliä leveä:
W-kuvaajaa on yksi suuri hakuteos : vaikka src- attribuuttia pidetään oletuksena määritettäessä kuvia x-kuvaajalle, sitä ei kuitenkaan lainkaan huomioida selaimilla, jotka tukevat srcset-arvoa, jos käytät w-kuvaajaa. Kun käytät w-kuvaajaa, meidän on määriteltävä oletusarvoisesti nimenomaisesti lisäämällä toinen srcset- kuva-asetus, jolla on oma w-kuvaaja ja erottamalla ne pilkulla:
Mikä johtaa meidät siististi ...
Useiden kuvien käyttäminen
Pystymme määrittelemään teräväpiirto-kuvamoodin selaimelle aivan HTML-koodissamme on aivan cool, mutta kuten olet luultavasti arvannut, se saa jopa viileämpää, kun määritämme useita kuvia.
Reagoivien kuvien tavoite on tuottaa parasta laatua olevaa kuvaa, jota käyttöjärjestelmä voi käyttää, mutta ei mitään muuta. Niin yksinkertaisesti verkkokalvon kuvan toimittaminen ei ole riittävää, meidän on toimitettava kuvia esimerkiksi 1x, 1.5x, 2x, 2.5x ja 3x.
Jälleen kerran tässä on alkuperäinen kuvamerkintä:
Tällöin selaimella on lisävarusteena retina-asteinen kuva:
Täällä on tällä kertaa ylimääräisiä vaihtoehtoja srcsetissa, erotettuina pilkulla:
Koska avainsanat merkitsevät erilaisia asioita eri ihmisille, mielestäni on suositeltavaa nimetä kuvat x-kuvaajan mukaan , johon he kuuluvat, niin henkilökohtaisena muistinavustuksena, että eri koko on selkeä muille tiimin jäsenille:
Muista, ettemme kerro selaimelle, mitä kuvaa näytetään, annamme sen tietoon käytettävissä olevat vaihtoehdot ja sallimme sen valita itselleen. Selain lataa vain yhden näistä kuvista.
Yksi hauska useista kuvista: älä koskaan määritä srcet- attribuutin kaksi kuvaa vastaavan x-kuvaajan ja w-kuvaajan kanssa, esimerkiksi:
Kokoominaisuus on eritoten mielenkiintoinen lisäys määrittelyyn, koska koon attribuutti ottaa sen arvot suhteessa näkymään, ei kuvan.
Käyttämällä vw (näkymän leveys) -arvoa määritämme kuva-alueen suhteessa selaimen leveyteen - muista, että img- elementti on nyt tehokkaasti vain paikkamerkki, joten emme täsmää kuvan todellista kokoa. kuvan sisältävän paikanvaraajan koko.
100vw on 100% näkymän leveydestä, 50vw on 50% näkymän leveydestä, 25vw on 25% näkymän leveydestä jne.
Jos halusimme asettaa img- leveyden puoleen selaimen leveydestä, käytämme:
Tämä ei ole erityisen hyödyllinen, ennen kuin yhdistämme sen median kyselyihin ...
Median kyselyiden käyttäminen
Kokoominaisuus on paljon tehokkaampi, kun yhdistämme sen median kyselyihin. Voimme erottaa useita näkymän leveyksiä pilkuilla ja kertoa selaimelle, jota käytetään CSS-tyyppisen mediakyselyn avulla.
Kuvittele esimerkiksi, että haluamme, että kuva muodostaa 80% leveydestä katselukulmasta useimmille laitteille, mutta pienille laitteille (kuten puhelimille), joiden leveys on 380px tai vähemmän, haluamme hyödyntää suurimman osan laitteista tilaa, joka on 100% leveydestä, kirjoittaisimme näin:
Tämän logiikan mukaisesti kaikki selaimet, joiden katselupiste on 380px tai vähemmän, määrittävät kuvan leveyden 100% katselupisteeseen. Jokainen muu selain aiheuttaa median kyselyn virheelliseksi ja selain siirtyy seuraavaan arvoon, joka on koon määrite, joka tässä tapauksessa on 80vw.
Yleisenä sääntönä olen epämiellyttävää käyttää mediakyselyitä HTML: ssä. Aivan kuten reaaliaikainen kuvatieto kuuluu HTML: ään (ei JavaScript), mediakyselyt kuuluvat CSS: ään (ei HTML: ään). Vaihtoehto on kuitenkin sinulle, jos tarvitset sitä.
Responsive image best-practice (2016?)
En tiedä sinusta, mutta olen innoissani srcsetin mahdollisuuksista . Se on yksinkertainen ratkaisu vaikeaan ongelmaan, ja näyttää toimivan kaiken tarvitsemamme.
Mutta kuten linja-autojen, odotat 20 vuotta virallisen ratkaisun reagoiviin kuviin, ja sitten kaksi ilmestyvät kerralla. Img- elementin srcset- attribuutin lisäksi meillä on myös kuva- elementti.
Kuvan elementti on toinen paikkamerkki, vaikkakin perinteisempi. Se on suunniteltu jäljittelemään video- ja ääniohjelmia HTML5: ssä, joten sen syntaksi on useimmiten tuttu. Kuvan elementti on tarkoitettu käytettäviksi, kun tarvitset enemmän valvontaa kuin srcset voi tarjota.
Valitettavasti kuvan elementillä on paljon vähemmän selainta kuin srcset ja se ei aina häviä hiljaa.
Kuvan elementin käyttäminen
Tässä on alkuperäinen kuvaelementti:
Tässä on kuva, joka on sisäkkäinen kuvan elementin sisällä:
Voimme myös määrittää kuvan elementin sisältämän img- elementin srcsetin :
Lähde-elementin käyttäminen
Kuvan elementti ei ole elossa, ennen kuin lisätään lähde- elementti:
Kun valitset käytettävän tiedoston, selain aloittaa ensimmäisen lähdekoodin ja siirtää elementtien läpi, kunnes se löytää sellaisen, jonka mediaattribuutti ratkaisee olevan totta, se käyttää sitten kyseisen lähdekoodinsrcsetin.
Voimme esimerkiksi määrittää erilaisia kuvia pysty- ja maisemamuotoihin:
Voimme myös määrittää useita kuvia käyttämällä x-kuvaajaa ja w-kuvaajaa:
Kuten käytettäessä media-kyselyjä koon määrityksessä, olisin kyseenalaista viitevyyden kuvamallien ohjaamisessa tyylin perusteella merkitsemällä tyylitaulukon sijaan. Median ominaisuuden käyttäminen on kuitenkin olemassa, jos tarvitset sitä.
Tyypin käyttäminen
Kuvan elementti todella tulee omaan käyttöön, kun sitä käytetään erilaisten kuvien vaihtamiseen.
Kuvittele, että meillä on tavallinen PNG-tiedosto, mutta haluamme käyttää sitä WebP-tiedosto, joka on tyypillisesti 26% pienempi. Muista, että herkät kuvat ovat parhaan mahdollisen kuvanlaadun ansiosta pienimmissä koossa, mutta tällä hetkellä Chrome, Opera ja Android-selain tukee niitä. Meidän on käytettävä tyyppiominaisuutta määriteltäessä, onko WebP: tä tuettu:
Tällöin selaimessa tarkistetaan, onko WebP-kuvamuotoa tuettu. Jos se on, se määrittää, onko näytöllä tarpeeksi pikselitiheyttä näyttämään verkkokalvo-image.webp -kuvan, ellei se näytä image.webp- kuvaa. Jos WebP: ää ei tueta, selain siirtyy suoraan img- elementtiin ja toimii srcset- ja src- vaihtoehtojen kautta jo tuttuun tapaan.
Tyyppimerkintä tarkoittaa, että voimme tarjota paljon pienempiä kuvamuotoja, joissa tuetaan, mikä johtaa pienempään tiedostokoon.
Tunnetut ongelmat
IE9 on tunnettu ongelma, joka estää kuvan elementin menemästä hiljaa. IE9: n käsittelemiseksi sinun täytyy temppuilla IE9 ajatella, että lähdeelementit ovat osa video- elementtiä:
< !—[if IE 9]>< ![endif]—>
Se on ruma ratkaisu, mutta parempaa kuin missään tapauksessa. Voimme vain toivoa, että Windows 10: n julkaiseminen nopeuttaa IE9: n kuolemaa, koska Edge ei vielä tue kuvan elementtiä, mutta se ei tue sitä oikealla tavalla (jättäen sen huomiotta).
On polyfills joka voi auttaa sinua tukemaan kuvan elementtiä IE: ssä, mutta omat mieltymykseni on välttää niitä. Epäilyttää ongelmien korjaamista JavaScriptin kanssa, se vaikuttaa suorituskykyyn ja johtaa vähemmän ylläpidettävään koodiin.
Tästä syystä suosittelen, että kuva- elementti vältetään nyt. Ellet käytä laajamittaista verkkokauppasivustoa, WebP-formaatin tarjoamien ylimääräisten latausaikojen säästäminen ei todennäköisesti ole suurempaa kuin koodin ja ohjelmiston korjaamisen haitta.
Kun IE9 laskee alle yhden prosentin, mikä pitäisi tapahtua jossain vaiheessa ensi vuonna, kuvan elementti tulee elinkelpoiseksi. Jos luet tätä vuonna 2016, olet todennäköisesti hyvä mennä.
Herkkien kuvien luominen
Toisin kuin SVG, bittikartat eivät skaalaudu ylöspäin. Strategiamme niiden käsittelyä varten, olipa kyseessä sitten srcset tai kuvan elementti, on tarjota erilainen kuva selaimen ominaisuuksiin perustuen. Jotta voimme käsitellä tätä, meidän on toimitettava erilaisia kuvakokoja.
Useimmat kuvankäsittelysovellukset ovat automatisoineet yksittäisten kuvien useiden versioiden vientiä. Ei ole väliä, mitä sovellusta käytät, edellyttäen, että pääset useisiin kuvakohtiin ilman manuaalista kokoa ja tallennusta.
Adobe Photoshop on de facto bitmap-editori. Se ei ole hyvä valinta suunnittelutyölle, mutta sen kuvankäsittelyn työnkulku on sileä ja luotettava. Useiden kuvaresoluutioiden luominen Photoshopissa on suhteellisen yksinkertaista:
Avaa kuva, jonka haluat luoda useita versioita ja aseta se omalle tasolle.
Nimeä kerros uudestaan nimellä luodun tiedoston nimi (mukaan lukien laajennus).
Valitse Tiedosto> Luo> Kuvatietue ja kansio, jossa uusi kuva tallennetaan PSD: n rinnalla.
Nimeä kerros uudestaan ja anna jokaisen kuvan, jonka haluat luoda, edeltää aiotulla asteikolla. Sinun ei tarvitse toistaa vaiheessa 3, kun nimetät kerroksen, kuvat luodaan automaattisesti.
Luotettava kuva meneePhilip Collier.
Lisätietoja kuvien tuottamisesta Photoshopissa, Katso tästä.
Näiden kuvien perusteella voimme tarjota selaimelle viisi eri vaihtoehtoa:
johtopäätös
Img- elementti on tullut pitkälle 20 vuoteen. Tai tarkemmin sanottuna img- elementti oli riittämätön 18 vuotta, ja sitten juoksi viivaa kahden viime vuoden aikana siihen pisteeseen asti, että se on nyt suhteellisen kehittynyt.
Tärkeää on, että pääsimme ratkaisuun.
Kaksi käytettävissä olevaa vaihtoehtoa, srcset ja kuva, edellinen on eniten tuettu. Jos rakennat 95% sivustoista, niin srcset- attribuutin ylivoimainen tuki ja yksinkertaisempi toteutus ovat paras vaihtoehto.
Jos sinulla on suuri verkkokauppasivusto, jossa on tuhansia tuotekuvia, WebP-formaatin palvelemiseen tarvittava ylimääräinen työ voi olla hyödyllinen varsinkin, kun kuvan elementti kasvaa seuraavan parin vuoden aikana.
Nykyisten vaihtoehtojen suurin heikkous on se, että selaimilla ei tällä hetkellä ole mahdollisuutta valita kuvaa niiden yhteydenopeuden perusteella. Meidän on pakko luottaa siihen, että paremmat laitteet ovat myös ylivoimaisia yhteyksiä.
Viime kädessä voimme lopulta palvella korkealaatuisia kuvia käytännöllisesti katsoen pienimmän koon mukaan. Tämä merkitsee parempaa kokemusta lyhyemmässä ajassa, mikä voi olla vain omaksua jotain.
Esillä oleva kuva käyttää,vuoren kuvajalaitteen kuvakautta Shutterstock.
