Share
Medieforespørsler er en viktig del av moderne webdesign, men de er ikke alltid perfekte. I denne artikkelen tar vi en titt på ideen om "elementspørsmål"; Det mange argumenterer er fremtiden for responsivt webdesign.
Ethans artikkel om Responsive Web Design endret måten vi bygger nettsteder på, for alltid. Hans artikkel ble inspirert og ble raskt vedtatt av webdesignere og utviklere. Tilnærminger som "Mobile First", "Desktop First" og "Device Agnostic" har dukket opp, designmønstre har siden blitt utviklet, nye standarder som
Vi bygger ikke lenger nettsteder for en bestemt skjermstørrelse, nettlesere eller enheter. Vi bygger i stedet dem slik at de er like morsomme på en hvilken som helst enhet, og på hvilken som helst skjermstørrelse. Vi gjør det ved å bruke "medieforespørsler" - ikke å glemme visnings-metataggen.
Medieforespørsler er utformet slik at vi kan støpe stilregler til et bestemt miljø. En av de vanligste bruken av medieforespørsler er å endre stiler innenfor et visst antall visningsbredder. Følgende kode, for eksempel, skjuler sidefeltet når nettsiden er tilgjengelig gjennom et visningsport opp til 720px bred.
.side sidebar display: flex; flex: 1 1 320px; @media (maksimal bredde: 720px) .site-sidebar display: none;
Media spørringer utviklet, sammen med enhetene, med flere ekstra funksjoner som orientering og Vedtak. Følgende eksempel viser hvordan vi kan bruke en av disse funksjonene til å betjene en større bildestørrelse på en høyoppløselig skjerm.
.site-logo a display: inline-block; bakgrunn: url (images / logo.png) no-repeat; @ media skjerm og (min oppløsning: 2dppx) bakgrunn: url (images/[email protected]);
Medieforespørsler har blitt en fast komponent når de leverer en responsiv opplevelse. Få deg raskere ved å lese disse artiklene, veiledningene og tipsene om å utnytte medieforespørsler på våre tidligere innlegg i Tuts +, så vel som over hele Internett.
Medieforespørsler er ikke sølvkulen til enhver situasjon i lydhurt webdesign, faktisk var det aldri ment å være det.
I dag finnes det et stort utvalg av enheter på markedet i forskjellige størrelser og trekk, og slører linjen mellom "mobile" og "desktop" (jeg ser på deg "hybrid bærbare datamaskiner"). Av denne grunn, å opprettholde et nettsteds estetikk, en god brukeropplevelse og ytelse har aldri vært tøffere.
På Google IO 2015 lar Google utviklere kontrollere deres nettsted på over 100 forskjellige enheter.Og når du legger til ting som annonser, tabeller og eldre innhold i blandingen, kan situasjonen bli enda verre. Snart nok vil du løpe inn i "ikke så gode" aspekter av medieforespørsler.
Vurder følgende eksempel. Vi har en UI-komponent for å vise vår lagmedlemsprofil. Vi ønsker å bruke denne eksakte komponenten på et par forskjellige steder på vår nettside. Dette eksemplet viser hvordan brukergrensesnittet er lagt ut på en 780px visningsbredde.
På siden "brukerprofil" legger vi brukerens avatar til venstre, og brukernavnet og biografien til høyre.
Brukerprofiloppsett i "Bruker" -profilen.På "lag" -siden på vår nettside skifter layoutet imidlertid; Brukerens avatar er nå plassert øverst, og brukernavnet og biografien er under. Skriftstørrelsen kan også være litt mindre.
Brukerprofiloppsett på «lag» -siden.Denne situasjonen kan løses med medieforespørsler. Vi kan for eksempel skrive CSS, som følger:
/ ** * Profil * / .team-profil text-align: center; .team-profil .bio margin-top: 20px; skriftstørrelse: 14px; @media (min bredde: 480px) .team-profil text-align: left; display: flex; .team-profil .avatar flex: 0 0 120px; .team-profil .bio font-size: 16px; flex: 0 1 580x; / ** * Profilkort. * / .team-profil-kort text-align: center; .team-profile-kort. bio margin-top: 20px; skriftstørrelse: 14px; / ** * Sannsynligvis overstyrer noen * / .side .team-profil-kort ...
Det kan repareres, så lenge vi bruker noen andre identifiserende klasser: .brukerprofil og .brukerprofil-kortet.
Det går imidlertid også mot at brukergrensesnittet vårt er en gjenbrukbar komponent; et brukergrensesnitt som kan plasseres hvor som helst på nettstedet, kan tilpasse seg omgivelsene.
I dette eksemplet vil vi at utformingen av komponenten skal tilpasses når den pakkes inn av en liten beholder, i stedet for når den klemmes av nettleservisporten. Så i stedet for å stole på nettleserens visningsstørrelse for å skifte layout, hvorfor kan vi ikke gjøre det på elementnivå?
Ideen om elementspørsmål dukket opp rundt begynnelsen av 2012; et par år etter at Responsive Web Design ble den vanlige metoden. Dessverre var det sannsynligvis ikke mange overbevisende grunner til å oppnå dette som en nettstandard på den tiden - verden ble fremdeles vant til å gå i klemme igjen.
@ianstormtaylor ja "element spørringer" har kommet opp nå og igjen
- Paul irsk (@paul_irish) 24. januar 2012
Nettsamfunnet begynte på egenhånd. RICG (Responsive Issue Community Group), den samme gruppen som startet
Elementforespørsler fungerer på samme måte som medieforespørsler; bortsett fra at de lytter til elementstørrelsen i stedet for nettleservisporten. Dette gjør at vi kan bygge et virkelig modulært brukergrensesnitt med DRY-er-kodebase. Gitt det samme eksemplet, kunne vi omskrive stilene til brukergrensesnittkomponenten med EQCSS, som følger:
.team-profil text-align: center; .team-profil .bio margin-top: 20px; skriftstørrelse: 14px; @ element ".team-profil" og (min bredde: 480px) .team-profil display: flex; .team-profil .avatar flex: 1 1 120px; .team-profil .bio text-align: left; skriftstørrelse: 16px; flex: 1 1 580x;
Her bryrer vi ikke hva visningsbredden er. Som du kan se over, så lenge som UI er strukket til 480px eller bredere, viser vi .avatar og .bio side ved side. Når brukergrensesnittet krymper ned nedenfor 480px vi la .avatar og .bio stable og juster innholdet til midten.
Bare for å avklare, jeg sier ikke å bruke media spørringer er dårlig, ikke i det hele tatt. Media spørringer er fantastiske, og vi har sett det på mange nettsteder bygget i dag. Media spørringer og element spørringer kan sikkert eksistere. Men det er mange designscenarier hvor bruk av element spørringer ville være mer fornuftig enn å bruke medieforespørsler.
Dessverre har elementspørsmål fortsatt en veldig lang vei å gå før de endelig overgår som en webstandard; vårt håp på dette hviler med alle de gode menneskene på RICG.
Mens vi venter, kan vi utforske elementets spørres potensial gjennom et JavaScript-bibliotek som EQCSS. Og det er akkurat det vi skal gjøre i neste opplæring. Følg med!
Accentsconagua