Nagu mobiilne ja tablett seadmed jõuavad maailma lõpliku domineerimise saavutamisele lähemale, veebidisain ja -tehnoloogia on võidujooks, et mahutada järjest kasvavat ekraani suurust. Tööriistade väljatöötamine selle nähtuse väljakutsetele vastamiseks toob aga kaasa täiesti uue probleemide komplekti, kusjuures üks viimaseid ilmuvaid moesõnu on „Reageeriv veeb” . See on väljakutse, kuidas panna veeb toimima enamikus, kui mitte kõigis seadmetes, ilma et see kahjustaks kasutaja kogemust. Sisu kujundamise asemel, et see sobiks laua- või sülearvutitele, peab teave olema kättesaadav mobiiltelefonide, tahvelarvutite või mis tahes veebiga ühendatud pinna kohta. Kuid see tundlik veebidisain evolutsioon on osutunud keeruliseks ja mõnikord valusaks.

Ehkki tekstiteabe mahutamine võib olla peaaegu tühine, on keeruline osa siis, kui võtame arvesse sisu, näiteks tundlikud pildid, infograafikud, videod jne., Mis kunagi olid mõeldud ainult töölaudu silmas pidades. See tõstatab mitte ainult sisu õigesti kuvamise küsimuse, vaid ka selle, kuidas sisu ennast erinevate seadmete abil tarbitakse. Nutitelefonide kasutajad erinevad lauaarvutite kasutajatest. Samuti tuleb arvestada selliste asjadega nagu andmekavad ja töötlemiskiirus. Google on hakanud esile tõstma mobiilisõbralikud saidid oma otsingutulemites, mõned spekuleerivad et see toob sellistele saitidele märkimisväärse pageranki tõuke. Varasemad lahendused lahendasid selle ainult mobiilseadmetele mõeldud alamdomeenide (ja ümbersuunamiste) juurutamisega, kuid see muutis keerukamaks ja langes kiiresti moest. (Igal saidil pole võimalust seda marsruuti endale lubada.)

Reageerivate veebipiltide otsimise kohta

kuidas kasutada sass css-i

Siinkohal peavad arendajad ja disainerid tagama, et nende veebisaidi koormus oleks optimeeritud, et kohtuda mobiilseadmete saitidel olevate kasutajatega. Üle 20% veebiliiklusest on nüüd mobiilikasutajad ja arv kasvab endiselt. Kui pildid võtavad lehe sisuandmete suurima osa, on selle koormuse vähendamine esmatähtis. Reageeriva kujunduspildi suuruse muutmise lihtsustamiseks on tehtud mitmeid katseid, sealhulgas nii serveripoolseid kui ka esiotsa lahendusi. Nende reageerivate pildilahenduste arutamiseks peame kõigepealt mõistma praegust pilti, mis seob puudusi.

märgendil on ainult allika atribuut, mis lingib otse pildi endaga. Sellel pole ilma lisandmooduliteta võimalik määrata õiget pilditüüpi.

Kas me ei saa HTML-i lisada lihtsalt kõiki pildisuurusi ja kasutada display:none CSS-reeglite kasutamist kõigi jaoks, välja arvatud õige pilt? See on täiuslikus loogilises maailmas kõige loogilisem lahendus. Nii saab brauser ignoreerida kõiki kuvamata pilte ja teoreetiliselt neid alla laadida. Kuid brauserid on optimeeritud väljaspool tavalist loogikat. Lehe piisavalt kiireks renderdamiseks tõmbab brauser lingitud sisu enne, kui isegi vajalikud stiililehed ja JavaScripti failid on täielikult laaditud. Selle asemel, et ignoreerida lauaarvutitele mõeldud suuri pilte, oleme lõpuks kõik pildid alla laadinud ja tulemuseks on veelgi suurem lehelaadimine. Ainult CSS-i tehnika töötab ainult piltide jaoks, mis on mõeldud taustapiltideks, kuna neid saab seada stiililehes (meediumipäringute abil).

Niisiis, mida veebisaiti teha?

Reageerivad pildiskaala lahendused

Ainult mobiilseadmetele mõeldud saitide / alamdomeenide keelamine jääb meile kasutajaagendi (UA) nuusutamiseks ja selle abil õiges suuruses piltide kasutajale tagasi toomiseks. Iga arendaja saab aga kinnitada, kui ebausaldusväärne see lahendus olla võib. Uued UA-stringid ilmuvad pidevalt, muutes põhjaliku loendi hooldamise ja ajakohastamise pingeliseks. Ja loomulikult ei võta see kõigepealt arvesse isegi kergesti võltsitavate UA-stringide ebausaldusväärsust.

Kohanevad pildid

Mõni serveripoolne lahendus on siiski kaalumist väärt. Kohanevad pildid on suurepärane lahendus neile, kes eelistavad tagantjärele reageerivat pildiparandust. See ei vaja erilist märgistamist, vaid kasutab selle asemel väikest JavaScripti faili ja teeb suurema osa raskest tööst oma tagafailis. See kasutab PHP ja nginx seadistatud serverit. Samuti ei tugine see ühegi UA nuusutamisele, vaid kontrollib ekraani laiust. Adaptive Images sobib suurepäraselt piltide vähendamiseks, kuid on mugav ka suurte piltide jaoks kunsti suund , st piltide vähendamine selliste tehnikate abil nagu kärpimine ja pööramine - mitte ainult skaleerimine.

Sencha puudutus

Sencha puudutus on veel üks tagantjärele reageeriv kujunduspildi lahendus, kuigi parem on sellele viidata kui kolmanda osapoole lahendusele. Sencha Touch muudab pildi suurust vastavalt, nuusutades UA-d. Allpool on toodud näide teenuse toimimisest.

kuidas teha arvutikeelt

Samuti on võimalus määrata pildi suurused, juhul kui me ei soovi, et Sencha muudab pildi suurust automaatselt.

Päeva lõpuks vajavad serveripoolsed (ja kolmanda osapoole) lahendused ressursse päringu töötlemiseks enne õige pildi tagasi saatmist. See võtab palju aega ja aeglustab omakorda päringu-vastuse reisi. Parem lahendus võib olla see, kui seade ise otsustab, milliseid ressursse otse taotleda, ja server reageerib vastavalt.

Eesmised lahendused

Viimasel ajal on reageerivate piltide aadressil brauseri poolel tehtud suuri edusamme.

Element on W3C kasutusele võtnud ja HTML5 spetsifikatsioonis heaks kiitnud. Praegu pole see kõigis brauserites laialdaselt saadaval, kuid kaua aega enne selle loomulikku kättesaadavust. Seni toetume elemendi JavaScripti polüfillidele. Polüfillid on ka suurepärane lahendus pärandbrauseritele, millel puudub element.

On ka juhtumit srcset atribuut mis on saadaval jaoks mitme veebikomplekti põhise brauseri jaoks element. Seda saab kasutada ilma JavaScripti ja see on suurepärane lahendus, kui mitte-webKiti brausereid eirata. See on kasulik peatuspaik paaritu juhtumi korral, kui muud lahendused jäävad puudu, kuid neid ei tohiks pidada terviklahenduseks.

Pilditäide

Pilditäide on elemendi jaoks polüfill-teek. See on üks kõige populaarsemaid raamatukogusid reaalajas piltide suuruse ja skaleerimise probleemide esilahenduste seas. Neid versioone on kaks; Piltitäide v1 jäljendab elementi, kasutades span samal ajal kui Picturefill v2 kasutab elementi juba pakutavate brauserite hulgas ja pakub päranditele polüfilli (näiteks IE> = IE9). Sellel on mõned piirangud ja probleemid , eriti Android 2.3 puhul - mis on muide näide img srcset atribuut tuleb appi. Allpool on näidismärgistus Picturefill v2 kasutamiseks:

Piiratud andmepakettidega kasutajate toimivuse parandamiseks võib Picturefill olla koos laiskade laadimistega . Siiski võiks raamatukogu pakkuda laiemat brauserituge ja lahendada paarituid juhtumeid, mitte tugineda plaastritele.

Imager.js

Imager.js on raamatukogu, mille on loonud BBC uudised meeskond, et teha reageerivaid pilte teistsuguse lähenemisviisiga kui Picturefill. Kui Picturefill üritab elementi toeta brauseritesse, keskendub Imager.js ainult asjakohaste piltide allalaadimisele, hoides samal ajal silma võrgu kiirustel. See hõlmab ka laiskat laadimist, tuginedes kolmandate osapoolte raamatukogudele. See töötab, kasutades kohatäite elemente ja asendades need elemendid. Allpool toodud näidiskood näitab seda käitumist:

kuidas c++

new Imager({ availableWidths: [480, 768, 1200] });

Renderdatud HTML näeb välja selline:

new Imager({ availableWidths: [480, 768, 1200] });

Brauseritugi on Picturefilli omast palju parem, selle pragmaatilisema lahenduse arvelt kui edasiviiv lahendus.

Allika segamine

Allika segamine läheneb reageeriva pildi probleemile veidi erineva nurga alt kui ülejäänud esiotsa teegid. See sarnaneb mõttega „kõigepealt mobiilne”, kusjuures see teenib vaikimisi võimalikult väikest eraldusvõimet. Kui tuvastate, et seadmel on suurem ekraan, vahetab see pildiallika suurema pildi vastu. See tundub rohkem häkkimise ja vähem täieõigusliku raamatukoguna. See on suurepärane lahendus peamiselt mobiilsete saitide jaoks, kuid see tähendab, et laua- ja / või tahvelarvutite topeltallalaadimine on vältimatu.

Mõned muud märkimisväärsed JavaScripti teegid on:

• HiSRC - JQuery pistikprogramm tundlike piltide jaoks. JQuery sõltuvus võib olla probleem.
• Mobify.js - Üldisem tundliku sisuga teek, sealhulgas pildid, stiililehed ja isegi JavaScripti. See 'hõivab' DOM-i enne ressursside laadimist. Mobify on võimas tervikraamatukogu, kuid võib olla üle jõu käiv, kui eesmärk on lihtsalt reageerivad pildid.

Kokkuvõte

Päeva lõpuks on arendaja otsustada, kumb tundlik veebidisain pilt lähenemine sobib kasutajaskonnale. See tähendab, et andmete kogumine ja testimine annab lähenemisviisist parema ettekujutuse.

Kokkuvõtteks võib olla kasulik alltoodud küsimuste loetelu enne sobiva reageeriva pildilahenduse otsustamist.

• Kas vanad brauserid on probleem? Kui ei, kaaluge kaasaegsema lähenemisviisi kasutamist (nt: Picturefill, srcset atribuut)
• Kas reageerimisaeg on kriitiline? Kui ei, siis minge kolmanda osapoole või taustalahenduse poole.
• Kas lahendused peaksid olema majasisesed? Kolmandate osapoolte lahendused on ilmselgelt välistatud.
• Kas saidil on juba palju pilte, mis üritavad reageerivatele piltidele üle minna? Kas valideerimise või semantiliste siltide (või pigem mitte-semantiliste siltide) pärast on muret? See nõuab pildilahenduste suunamiseks näiteks Adaptive Images sarnast lahendust.
• Kas kunsti suuna on probleem (eriti suurte piltide puhul, kus on palju teavet)? Raamatukogu nagu Picturefill on sellise stsenaariumi jaoks parem lahendus. Samuti toimib mis tahes taustalahendus.
• Kas on muret JavaScripti puudumise pärast? Mis tahes esiotsa lahendus ei tule kõne allagi, mis jätab UA-i nuuskamisele tuginevad tagumise osa või kolmanda osapoole valikud.
• Kas mobiiltelefoni reageerimisaegade prioriteet on töölaua reageerimisaegade ees? Sobivam võib olla selline raamatukogu nagu Source Shuffling.
• Kas on vaja pakkuda reageerivat käitumist saidi igas aspektis, mitte ainult piltides? Mobify.js võib töötada paremini.
• Kas täiuslik maailm on saavutatud? Kasutage ainult CSS-i display:none lähenemine!