Mobiilina ja tabletti laitteet tulevat lähemmäksi maailman lopullista ylivaltaa, verkkosivujen suunnittelu ja tekniikka kilpailevat jatkuvasti kasvavan näytön koon mukauttamiseksi. Työkalujen suunnitteleminen tämän ilmiön haasteisiin vastaamiseksi tuo kuitenkin aivan uudenlaisen ongelmakokonaisuuden, ja yksi viimeisimmistä muotisanoista on 'Reagoiva verkko' . Tämä on haaste saada verkko toimimaan useimmilla, ellei kaikilla laitteilla, heikentämättä käyttäjän kokemuksia. Sen sijaan, että suunnitellaan sisältöä sopivaksi pöytätietokoneille tai kannettaville tietokoneille, tietojen on oltava saatavilla matkapuhelimille, tableteille tai mille tahansa verkkoon liitetylle pinnalle. Kuitenkin tämä reagoiva web-suunnittelu evoluutio on osoittautunut vaikeaksi ja joskus tuskalliseksi.
Vaikka tekstitietojen sijoittaminen voi olla melkein triviaalia, hankala osa tulee, kun otamme huomioon sisällön, kuten reagoivat kuvat, infografiikat, videot jne., Jotka on aikoinaan suunniteltu vain työpöytiä ajatellen. Tämä tuo esiin paitsi sisällön oikean esittämisen kysymyksen myös sen, miten sisältöä itse kulutetaan eri laitteilla. Älypuhelinten käyttäjät eroavat työasemien käyttäjistä. Tietosuunnitelmien ja käsittelynopeuden kaltaisia asioita on myös otettava huomioon. Google on alkanut korostaa mobiililaitteille sopivia sivustoja hakutuloksissaan, joidenkin spekuloimalla että se johtaa huomattavaan pagerank-vauhtiin tällaisille sivustoille. Aikaisemmissa ratkaisuissa puututtiin tähän ottamalla käyttöön vain mobiililaitteille tarkoitettuja aliverkkotunnuksia (ja uudelleenohjauksia), mutta tämä lisäsi monimutkaisuutta ja putosi muodista nopeasti. (Kaikilla sivustoilla ei ole varaa tällä reitillä.)
Tässä vaiheessa kehittäjien ja suunnittelijoiden on varmistettava, että heidän verkkosivustonsa kuormitus on optimoitu vastaamaan mobiilisivustoissa olevia käyttäjiä. Yli 20% verkkoliikenteestä on nyt mobiilikäyttäjiä, ja määrä kasvaa edelleen. Kun kuvat ottavat suurimman osan sivun sisältötiedoista, on ensisijaista vähentää tätä kuormitusta. Reagoivan suunnittelukuvan koon muuttamista on yritetty yksinkertaistaa useita, mukaan lukien sekä palvelin- että käyttöliittymäratkaisut. Keskustellaksemme näistä reagoivista kuvaratkaisuista meidän on ensin ymmärrettävä nykyiset kuvan linkittävät puutteet.
-tunnisteessa vain lähde-attribuutti linkittää suoraan kuvaan. Sillä ei ole mitään keinoa määrittää oikean tyyppistä kuvaa ilman lisäosia.
Emmekö voi vain sisällyttää HTML-koodiin kaikkia kuvakokoja ja käyttää display:none
CSS-sääntöjen avulla kaikille paitsi oikea kuva? Se on loogisin ratkaisu täydellisessä loogisessa maailmassa. Tällä tavalla selain voi jättää huomiotta kaikki kuvat, joita ei näytetä, eikä teoriassa ladata niitä. Selaimet on kuitenkin optimoitu yleisen logiikan ulkopuolelle. Sivun hahmontamiseksi riittävän nopeasti selain hakee linkitetyn sisällön valmiiksi, ennen kuin edes tarvittavat tyylitaulukot ja JavaScript-tiedostot ladataan. Sen sijaan, että sivuuttaisimme työasemille tarkoitetut suuret kuvat, lopulta lataamme kaikki kuvat ja tuloksena on vielä suurempi sivulataus. Vain CSS-tekniikka toimii vain taustakuviksi tarkoitetuille kuville, koska ne voidaan asettaa tyylitaulukossa (käyttämällä mediakyselyjä).
Joten mitä verkkosivusto on tehtävä?
Estämällä vain mobiililaitteille tarkoitetut sivustot / aliverkkotunnukset jää jäljelle käyttäjäagentin haistaminen ja sen käyttäminen oikeankokoisten kuvien näyttämiseen käyttäjälle. Jokainen kehittäjä voi kuitenkin todistaa, kuinka epäluotettava ratkaisu voi olla. Uudet UA-kielet tulevat jatkuvasti esiin, mikä tekee kattavan luettelon ylläpitämisestä ja päivittämisestä raskasta. Ja tietysti tässä ei edes oteta huomioon helposti väärennettävien UA-kielien epäluotettavuutta.
Jotkin palvelinpuolen ratkaisut ovat kuitenkin harkinnan arvoisia. Mukautuvat kuvat on loistava ratkaisu niille, jotka haluavat taustan reagoivan kuvakorjauksen. Se ei vaadi mitään erityisiä merkintöjä, vaan käyttää sen sijaan pientä JavaScript-tiedostoa ja tekee suurimman osan raskaasta työstä sen taustatiedostossa. Se käyttää PHP- ja nginx-palvelimia. Se ei myöskään luota mihinkään UA-haistamiseen, vaan tarkistaa näytön leveyden. Adaptive Images toimii erinomaisesti kuvien pienentämisessä, mutta se on kätevä myös silloin, kun suuria kuvia tarvitaan taideohjaus eli kuvan pienentäminen tekniikoilla, kuten rajaus ja kiertäminen - ei vain skaalaus.
Sencha Touch on toinen taustalla oleva reagoiva suunnittelukuvaratkaisu, vaikka onkin parempi kutsua sitä kolmannen osapuolen ratkaisuksi. Sencha Touch muuttaa kuvan kokoa vastaavasti haistamalla UA: ta. Alla on perusesimerkki palvelun toiminnasta:
On myös mahdollisuus määrittää kuvakoot, jos emme halua Senchan muuttavan kuvan kokoa automaattisesti.
Päivän lopussa palvelinpuolen (ja kolmannen osapuolen) ratkaisut vaativat resursseja pyynnön käsittelemiseksi ennen oikean kuvan lähettämistä takaisin. Tämä vie arvokasta aikaa ja puolestaan hidastaa pyyntö-vastausmatkaa. Parempi ratkaisu voi olla, jos laite itse päättää, mitkä resurssit pyytää suoraan, ja palvelin reagoi vastaavasti.
Viime aikoina selainpuolella on tapahtunut suuria parannuksia reagoivien kuvien osoittamiseksi.
Elementti W3C on ottanut käyttöön ja hyväksynyt HTML5-eritelmän. Sitä ei tällä hetkellä ole laajalti saatavana kaikissa selaimissa, mutta ei kauan ennen kuin se on luonnollisesti saatavana. Siihen asti luotamme elementin JavaScript-täytteisiin. Polyfillit ovat myös loistava ratkaisu vanhoille selaimille, joilta puuttuu elementti.
On myös tapaus srcset
määritteen joka on saatavana useille webKit-pohjaisille selaimille
elementti. Tätä voidaan käyttää ilman JavaScriptiä ja se on loistava ratkaisu, jos ei-webKit-selaimet jätetään huomiotta. Se on hyödyllinen pysähdyspaikka parittomassa tapauksessa, jossa muut ratkaisut puuttuvat, mutta sitä ei pidä pitää kattavana ratkaisuna.
Kuvan täyttö on polyfill-kirjasto elementille. Se on yksi suosituimmista kirjastoista reagoivien kuvien mitoitus- ja skaalausongelmien etupään ratkaisujen joukossa. On olemassa kaksi versiota; Picturefill v1 jäljittelee elementtiä span
kun taas Picturefill v2 käyttää elementtiä jo tarjolla olevissa selaimissa ja tarjoaa polyfill-version vanhoille selaimille (esimerkiksi IE> = IE9). Siinä on joitain rajoitukset ja kiertotavat , erityisesti Android 2.3: lle - joka on muuten esimerkki siitä, missä img srcset
attribuutti tulee apuun. Alla on esimerkkikuvaus Picturefill v2: n käytöstä:
Parantaakseen suorituskykyä käyttäjillä, joilla on rajoitettu tietosuunnitelma, Picturefill voi olla yhdistettynä laiskaan kuormitukseen . Kirjasto voisi kuitenkin tarjota laajempaa selaintukea ja käsitellä parittomia tapauksia sen sijaan, että luotettaisiin laastareihin.
Imager.js on kirjasto, jonka on luonut BBC uutiset joukkue suorittamaan reagoivia kuvia erilaisella lähestymistavalla kuin Picturefill. Vaikka Picturefill yrittää tuoda elementin tukemattomiin selaimiin, Imager.js keskittyy lataamaan vain sopivat kuvat samalla kun pidät silmällä verkon nopeutta. Se sisältää myös laiskan lataamisen turvautumatta kolmansien osapuolten kirjastoihin. Se toimii käyttämällä paikkamerkkielementtejä ja korvaamalla ne
: lla elementtejä. Alla oleva esimerkkikoodi osoittaa tämän käyttäytymisen:
new Imager({ availableWidths: [480, 768, 1200] });
Renderoitu HTML näyttää tältä:
new Imager({ availableWidths: [480, 768, 1200] });
Selaimen tuki on paljon parempi kuin Picturefill, sillä se on käytännöllisempi ratkaisu kuin eteenpäin ajatteleva ratkaisu.
Lähteen sekoitus lähestyy reagoivaa kuvaongelmaa hieman eri näkökulmasta kuin muut käyttöliittymäkirjastot. Se muistuttaa jotain 'mobiili ensin' -ajattelukoulusta, jolloin se palvelee oletusarvoisesti pienintä mahdollista resoluutiota. Havaittuaan, että laitteella on suurempi näyttö, se vaihtaa kuvalähteen suurempaan kuvaan. Tuntuu enemmän hakkeroinnilta ja vähemmän täysimittaiselta kirjastolta. Tämä on loistava ratkaisu pääasiassa mobiilisivustoille, mutta tarkoittaa, että työasemien ja / tai tablettien kaksoisresurssien lataaminen on väistämätöntä.
Joitakin muita merkittäviä JavaScript-kirjastoja ovat:
Päivän lopussa kehittäjän on päätettävä kumpi reagoiva web-suunnittelu imago-lähestymistapa sopii käyttäjäkuntaan. Tämä tarkoittaa, että tiedonkeruu ja testaus antavat paremman kuvan lähestymistavasta.
Lopuksi alla olevasta kysymysluettelosta voi olla hyötyä harkita ennen sopivan reagoivan kuvaratkaisun valitsemista.
srcset
attribuutti)display:none
lähestyä!