Share
Elementquery's (of "containerquery's" als dat nodig is) blijven hun weg vinden in gesprekken tussen responsieve webontwerpers, maar hun insluiting in een spec en het huidige landschap is onduidelijk. In dit artikel bespreken we welk elementquery's zijn en waar community-consensus zich momenteel bevindt tussen ontwikkelaars en standaardwerkgroepen.
Met elementquery's kunnen elementen "reageren" op hun eigen beperkingen, ongeacht de beperkingen van de schermgrootte. Dit is het belangrijkste detail dat je moet begrijpen. Mediaquery's zoals we ze kennen, zijn 100% voor een responsieve lay-out, maar een responsieve lay-out is niet 100% @media queries. Modules, componenten, interface-elementen zullen altijd groeien en krimpen met het scherm, maar reageren nooit alleen en daarom @media is niet de volledige oplossing voor onze problemen.
Bekijk deze ruwe demo van elementqueries met eqcss:
Veel mensen die oplossingen zochten voor elementgebaseerde breekpunten, begonnen CSS-in-JS te implementeren met behulp van frameworks zoals React. Hoewel er vooruitgang is geboekt op andere gebieden, heeft dit de oplossingen gebroken die ontwikkelaars ontwikkelden van algemeen gebruikte oplossingen voor CSS of JavaScript in meerdere raamwerkspecifieke bibliotheken. Hoewel de resultaten variëren, zijn de belangrijkste functies die deze hulpprogramma's bereiken vaak erg vergelijkbaar. In de toekomst zou een standaardisatie van deze diverse technieken een aanpak van dit type responsief ontwerp kunnen stollen om op elke website of een ander hulpmiddel te worden toegepast.
Tijdens mijn besprekingen over dit onderwerp met Tommy Hodgins (een voorstander van elementquery's en maker van eqcss) lijkt het erop dat mensen zich nog steeds bewust zijn van zowel "elementqueries" als het afzonderlijke concept van "containerqueries". De consensus lijkt op te splitsen in een paar verschillende gebieden:
Hier is nog een voorbeeld waarbij ik de CSS kan veranderen op basis van de breedte van de video. Helemaal niet gerelateerd aan de viewport-grootte. pic.twitter.com/O6lbDBJvFf
- Wes Bos 🔥 (@wesbos) 6 oktober 2017
Ik wil Houdini. Ik denk dat het ons concepten laat maken die browsers kunnen gebruiken om native te worden.
- Snook (@snookca) 6 oktober 2017
Wil je een plons maken in de web-dev-wereld? Wees degene die een werkende implementatie van containerverzoeken uitvoert met Houdini. 🤹🏼♂️
- Chris Coyier (@chriscoyier) 10 oktober 2017
Dus wat staat er op de verlanglijst voor ontwikkelaars?
Stel je voor dat je een plug-in zou kunnen schrijven die meer als een browserpatch dan als een JavaScript-plug-in fungeert. Wat als u toegang had om uw eigen logica in te voegen in hoe een browser pagina's parseert, schildert en rendert? Welke dingen zou je de browser kunnen "leren" in plaats van te vertrouwen op logica bovenaan de pagina om te berekenen?
Momenteel zitten we vast aan de manier waarop een browser CSS verwerkt, maar met Houdini is de hoop dat we de mogelijkheid hebben om opnieuw te ordenen en prioriteiten te stellen, zodat we waarden kunnen berekenen met behulp van intelligente benaderingen, of de weergave kunnen besturen om tekortkomingen te verbergen. JavaScript- en CSS Object Model API's geven CSS dezelfde toegang, controle en macht die JavaScript en DOM API's aan HTML geven. Volgens Tab Atkins gebruikt Houdini ook typed OM en Parser API-logica en dit zijn de onderliggende technieken voor aangepaste At-regels waarmee u Element Query-regels kunt opgeven in uw stylesheet en deze kunt laten bewerken door JavaScript.
Er is een site die zich uitsluitend richt op het volgen van de voortgang op ishoudinireadyyet.com, maar laten we in de tussentijd enkele andere mogelijke oplossingen overwegen.
Het gebruik van iframes om elementen te wikkelen is een slimme benadering, maar helaas is het nog steeds geen echte oplossing voor het probleem; meer een creatieve hack. Lees meer over deze truc op de blog van Tab Atkins.
Hoewel niet gestabiliseerd in specificatievorm, is deze eigenschap bedoeld als nuttig op pagina's die veel onafhankelijke widgets bevatten. De documenten claimen dat het kan worden gebruikt om te voorkomen dat de CSS-regels van een widget andere op de pagina veranderen. Een eigenschapswaarde van streng suggereert dat het veel van de problemen van containervragen kan voorkomen, maar dit is niet de volledige oplossing; slechts een stukje van de puzzel.
Een belangrijk probleem met betrekking tot vragen over containers is dat de kinderen en hun inhoud kan hebben een effect op de grootte van de container. Dit kan in theorie worden voorkomen door CSS-insluiting te gebruiken, maar laten we eens kijken naar het feitelijke probleem dat deze afhankelijkheid tussen elementen veroorzaakt.
Kijk eens naar de volgende toespraak van Dan Tocchini (begin misschien met video vanaf 10:00 nadat Vimeo geen tijdstempels toestaat).
Waarom kan een element niet reageren op zijn grootte? Cyclische afhankelijkheden. Hier is een grafische weergave van de bovenstaande video om te verduidelijken:
Elk vak is afhankelijk van de beperkingen van de bijbehorende box (breedte in dit geval), en dit is waar de cyclische afhankelijkheden verschijnen. Er is een constante relatie tussen deze gebonden elementen die van nature voorkomt. Dit type gedrag bestaat ook bij
: hover gebeurtenissen zoals Tommy Hodgins uitlegt in deze video.
Cyclische afhankelijkheden is waar een groot deel van de mensen die de term 'containerquery' gebruiken vastloopt omdat:
Het goede nieuws is dat browsers enig bewijs van het werken rond deze problemen beginnen te vertonen, zoals eerder besproken met Houdini.
Er is toevallig een CSS Element Queries (droom) -specificatie van Tommy Hodgins; en hoewel het maar een droomspecificatie is, is het zeer indrukwekkend hoe lang het duurt om woorden en suggesties daadwerkelijk in het gesprek te plaatsen. Hij heeft ook een site samengesteld met ontwikkelaars die werken aan containerquery's met de juiste naam: "Who is Working on Container Queries".
Na al mijn onderzoek vraag ik me nog steeds af waarom de meerderheid van onze community niet op deze manier bouwt als we dat kunnen? We hebben het vermogen om op deze manier voor CSS te bouwen @media werd ondersteund in de browser, maar het lijkt erop dat we op een zijspoor kwamen. We hebben geen idee gekregen van "responsive best practices", om te ontdekken hoe verschillende resultaten kunnen worden bereikt met @media; en dat verspreidde zich als een lopend vuurtje. Artikelen over "Media Query-free responsive layout" met slimmere displaymodellen zoals Flexbox en Grid illustreren dat we het moeilijk hebben om responsieve lay-out te scheiden van mediaquery's.
Bekijk deze presentatie van Eric Portis (Contain Your Excitement) waarin hij datzelfde punt bespreekt; met zoveel wegversperringen, hoe kunnen we het webplatform als geheel vooruit helpen?
Hier zijn een paar veel voorkomende soundbites die je hoort over elementqueries:
niet 👏 u durft 👏🏼 af te rekenen 👏🏽 voor 👏🏾 javascript 👏🏿 containervragen
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6 oktober 2017
Ik denk dat intl-oplossingen op basis van JS zijn en die API's met alleen CSS zullen informeren. We moeten tmp-oplossingen niet negeren alleen omdat ze JS vereisen.
- Phil Walton (@philwalton) 6 oktober 2017
Het voelt alsof Houdini soms een manier kan zijn om te zeggen "we kunnen niet de moeite doen om onze tijd hieraan te verspillen, dus laten we * hen * het uitzoeken"
- Sara Soueidan 🐦 (@SaraSoueidan) 6 oktober 2017
Zoals ik in mijn loopbaan heb meegemaakt, hebben ontwikkelaars zelden problemen met JavaScript gemeld om ondersteuning aan toe te voegen @media met IE8 omdat we JavaScript nodig hadden om stylingkracht toe te voegen waar browsers aan ontbrak. Gebruikt u JavaScript echter al in de browser om CSS te verbeteren? Dat is ketterij voor velen; zelfs enkele van degenen die helemaal gelukkig zijn met JavaScript om HTML te verzamelen.
De ideeën die in de vorige paragrafen worden genoemd, stellen ontwikkelaars zeker in staat om aan hun eigen ideeën te werken, maar we moeten vaker samenkomen, notities vergelijken, een standaardaanpak vinden en deze vergrendelen. In mijn persoonlijke mening zullen we niet in staat zijn om scheiden JavaScript van CSS als het gaat om elementquery's, dus we moeten het omarmen. Iedereen die wacht op een pure CSS-aanpak kan nog vele, vele jaren in het treindepot zijn.
Gebruik je elementqueries in je eigen werk? Zijn elementvragen een verloren oorzaak vanwege de zeer eigenwijze gezichtspunten? Ik hoop dat deze discussie ertoe zal bijdragen dat JavaScript aan de slag gaat, zodat we uitzonderlijk flexibele componenten voor het steeds veranderende internet kunnen bouwen. Zoals altijd, post je je gedachten in de comments sectie en happy coding.
Een grote dank aan Tommy Hodgins voor zijn tijd en waardevolle kennis over dit onderwerp en ook voor al zijn werk om dit gemeenschapsgevoelige onderwerp bij te houden.
Accentsconagua