Share
Mediaquery's vormen een vitaal onderdeel van modern webdesign, maar ze zijn niet altijd perfect. In dit artikel bekijken we het idee van "elementqueries"; wat velen beweren is de toekomst van responsief webdesign.
Ethan's artikel over Responsive Web Design veranderde de manier waarop we websites bouwen voor altijd. Zijn artikel inspireerde en werd snel overgenomen door webdesigners en ontwikkelaars. Benaderingen zoals "Mobile First", "Desktop First" en "Device Agnostic" zijn naar voren gekomen, ontwerppatronen zijn inmiddels ontwikkeld, nieuwe standaarden zoals de
We bouwen niet langer websites voor een bepaald schermformaat, browsers of apparaten. In plaats daarvan bouwen we ze, zodat ze net zo leuk zijn op elk apparaat en op elk schermformaat. We doen dit met behulp van 'mediaquery's' - en niet de metatag van de viewport.
Mediaquery's zijn ontworpen om ons in staat te stellen stijlregels te vormen naar een specifieke omgeving. Een van de meest voorkomende toepassingen van mediaquery's is om stijlen binnen een bepaald bereik van viewport-breedten te wijzigen. De volgende code verbergt bijvoorbeeld de zijbalk wanneer de website wordt geopend via een kijkvenster tot 720px breed.
.site-zijbalk weergave: flex; flex: 1 1 320px; @media (max-width: 720px) .site-sidebar display: none;
Mediaqueries evolueerden, samen met de apparaten, met verschillende toegevoegde functies zoals oriëntering en resolutie. Het volgende voorbeeld laat zien hoe we een van deze functies kunnen gebruiken om een grotere afbeeldingsgrootte op een scherm met een hoge resolutie weer te geven.
.site-logo a display: inline-block; achtergrond: url (images / logo.png) no-repeat; @media-scherm en (min-resolutie: 2dppx) background: url (images/[email protected]);
Mediaquery's zijn een nietje component geworden bij het leveren van een responsieve ervaring. Begeef u op de hoogte door het lezen van deze artikelen, zelfstudies en tips over het gebruik van mediaquery's op onze eerdere berichten in Tuts + en op internet.
Mediaquery's zijn niet de perfecte oplossing voor elke situatie in responsief webdesign, het is eigenlijk nooit zo bedoeld.
Tegenwoordig zijn er tal van apparaten op de markt in verschillende grootten en eigenschappen, waardoor de grens tussen "mobiel" en "bureaublad" vervaagt (ik zie u "hybride laptops"). Om deze reden is het onderhouden van de esthetiek van een website, een geweldige gebruikerservaring en prestaties nog nooit zo moeilijk geweest.
Op Google IO 2015 laat Google ontwikkelaars hun website controleren op meer dan 100 verschillende apparaten.En als u eenmaal dingen als advertenties, tabellen en verouderde inhoud aan de mix toevoegt, kan de situatie nog slechter zijn. Binnenkort kom je de "niet zo goede" aspecten van mediaqueries tegen.
Bekijk het volgende voorbeeld. We hebben een UI-component om ons teamlidprofiel te laten zien. We willen dit exacte onderdeel op verschillende plaatsen op onze website gebruiken. Dit voorbeeld laat zien hoe de gebruikersinterface is ingedeeld in a 780px breedte van de viewport.
Op de pagina 'gebruikersprofiel' plaatsen we de gebruikersavatar aan de linkerkant en de gebruikersnaam en de biografie aan de rechterkant.
Lay-out gebruikersprofiel in het profiel "Gebruiker".In de "team" -pagina op onze website verschuift de lay-out echter; de afbeelding van de gebruikersavatar staat nu bovenaan en de gebruikersnaam en de biografie staan eronder. De lettergrootte kan ook iets kleiner zijn.
Lay-out gebruikersprofiel op de pagina "team".Deze situatie kan worden opgelost met mediaquery's. We kunnen bijvoorbeeld de CSS als volgt schrijven:
/ ** * Profiel * / .team-profiel text-align: center; .team-profiel .bio margin-top: 20px; lettergrootte: 14 px; @media (min-width: 480px) .team-profile text-align: left; weergave: flex; .team-profiel .avatar flex: 0 0 120px; .team-profiel .bio font-size: 16px; flex: 0 1 580x; / ** * Profielkaart. * / .team-profile-card text-align: center; .team-profile-card .bio margin-top: 20px; lettergrootte: 14 px; / ** * Waarschijnlijk een aantal opheffingen * / .page .team-profile-card ...
Het is fixeerbaar, zolang we enkele aanvullende identificerende klassen gebruiken: .gebruikersprofiel en .user-profile-card.
Het is echter ook in tegenspraak met het feit dat onze gebruikersinterface een herbruikbaar onderdeel is; een gebruikersinterface die overal op de website kan worden geplaatst, zich kan aanpassen aan zijn omgeving.
In dit voorbeeld willen we dat de lay-out van onze component wordt aangepast wanneer deze wordt verpakt door een kleine container, in plaats van wanneer deze wordt samengedrukt door de viewport van de browser. Dus in plaats van te vertrouwen op de grootte van de browserportal om de lay-out te verschuiven, waarom kunnen we dat dan niet doen in de elementniveau?
Het idee van elementvragen kwam rond het begin van 2012 naar voren; een paar jaar nadat Responsive Web Design de mainstream-methodologie werd. Helaas waren er waarschijnlijk niet veel overtuigende redenen om dit als webstandaard in die tijd naar voren te brengen - de wereld was er nog steeds aan gewend om opnieuw squishy te worden.
@ianstormtaylor ja "element-query's" is af en toe opgekomen
- Paul Irish (@paul_irish) 24 januari 2012
Webgemeenschappen begonnen op eigen initiatief initiatieven. RICG (Responsive Issue Community Group), dezelfde groep die de
Element-query's werken op dezelfde manier als mediaquery's; behalve dat ze luisteren naar de elementgrootte in plaats van het kijkvenster van de browser. Dit stelt ons in staat om een echt modulair UI-systeem met DRY-er-codebasis te bouwen. Op basis van hetzelfde voorbeeld zouden we de stijlen van onze UI-component met EQCSS kunnen herschrijven, als volgt:
.teamprofiel text-align: center; .team-profiel .bio margin-top: 20px; lettergrootte: 14 px; @element ".team-profile" en (min-width: 480px) .team-profile display: flex; .team-profiel .avatar flex: 1 1 120px; .team-profiel .bio text-align: left; lettergrootte: 16px; flex: 1 1 580x;
Hier maakt het ons niet uit wat de breedte van de viewport is. Zoals je hierboven kunt zien, zo lang als de UI is uitgerekt naar 480px of breder, we tonen de .avatar en de .bio zij aan zij. Wanneer de UI-breedte naar beneden krimpt 480px we laten het .avatar en .bio stapel en lijn de inhoud uit met het midden.
Om te verduidelijken, ik zeg niet dat het gebruik van mediaquery's slecht is, helemaal niet. Mediaquery's zijn geweldig en dat hebben we gezien op veel websites die we vandaag hebben gebouwd. Mediaquery's en elementquery's kunnen zeker naast elkaar bestaan. Er zijn echter veel ontwerpscenario's waarbij het gebruik van elementquery's zinvoller zou zijn dan het gebruik van mediaquery's.
Helaas hebben elementvragen nog een lange weg te gaan voordat ze uiteindelijk als webstandaard worden doorgegeven; onze hoop hierop ligt bij alle goede mensen van RICG.
Terwijl we wachten, kunnen we het potentiële potentieel van elementvragen onderzoeken via een JavaScript-bibliotheek zoals EQCSS. En dat is precies wat we in de volgende tutorial gaan doen. Blijf kijken!
Accentsconagua