Share
Elementfrågor (eller "behållarfrågor" om du måste) fortsätter att göra sig in i konversationer bland lyhörda webbdesigners, men deras inkludering i någon spec och det nuvarande landskapet är oklart. I den här artikeln kommer vi att diskutera vilka elementfrågor som är och där gemenskapsöverenskommelse för närvarande befinner sig bland utvecklare och standardgrupper.
Elementfrågor tillåter element att "reagera" till sina egna begränsningar oavsett begränsningar av skärmstorlek. Detta är den viktigaste detalj som man måste förstå. Mediefrågor som vi känner dem är 100% för responsiv layout, men responsiv layout är inte 100% @media frågor. Moduler, komponenter, gränssnittselement kommer alltid att växa och krympa med skärmen, men reagerar aldrig på egen hand, vilket är anledningen till det @media är inte hela lösningen på våra problem.
Ta en titt på denna grova demo av elementfrågor med hjälp av eqcss:
Många som söker lösningar för elementbaserade brytpunkter började implementera CSS-in-JS med hjälp av ramar som React. Även om det har gjorts framsteg på andra områden, bröt det lösningarna utvecklare skapade från lösningar för allmänt bruk för CSS eller JavaScript i flera ramsspecifika bibliotek. Även om resultaten varierar är de kärnfunktioner som dessa verktyg uppnår ofta mycket lika. I framtiden kan en standardisering av dessa olika tekniker stärka ett tillvägagångssätt för denna typ av responsiv design som ska tillämpas på vilken webbplats som helst, eller vilket verktyg som helst.
Under mina diskussioner om detta ämne med Tommy Hodgins (en förespråkare för elementfrågor och skapare av eqcss) verkar det som om folk fortfarande är medvetna om både "elementfrågor" och det separata begreppet "containerfrågor". Samförståndet verkar splittras i några olika områden:
Här är ett annat exempel där jag kan ändra CSS baserat på videoens bredd. Helt orelaterad med viewport storlek. pic.twitter.com/O6lbDBJvFf
- Wes Bos 🔥 (@wesbos) 6 oktober 2017
Jag vill ha Houdini. Jag tror att det låter oss skapa koncept som webbläsare kan använda för att gå inbyggda.
- Snook (@ snookca) 6 oktober 2017
Vill du göra ett stänk i web dev världen? Var den som utför en fungerande implementering av behållarfrågor med Houdini. 🤹🏼♂️
- Chris Coyier (@chriscoyier) 10 oktober 2017
Så vad finns på önskelistan för utvecklare?
Tänk dig att du kan skriva ett plugin som fungerade mer som en webbläsare än en JavaScript-plugin. Vad händer om du hade tillgång till att injicera din egen logik i hur en webbläsare analyserar, målar och gör sidor? Vilka saker kan du "lära" webbläsaren istället för att förlita sig på logiken ovanpå sidan för att beräkna?
För närvarande håller vi fast vid hur en webbläsare behandlar CSS, men med Houdini är hoppet att vi ska kunna omorganisera och prioritera så att vi kan beräkna värden med hjälp av intelligenta metoder eller kontrollera rendering för att dölja brister. Javascript- och CSS-objektmodell API låter CSS samma typ av åtkomst, kontroll och kraft som JavaScript och DOM API ger till HTML. Enligt Tab Atkins använder Houdini även Typed OM och Parser API logik och dessa är de underliggande techs för anpassade At-Rules så att du anger Element Query-regler i ditt stylesheet och hanterar dem med JavaScript.
Det finns en webbplats som är avsedd att spåra dess framsteg på ishoudinireadyyet.com, men under tiden får vi överväga några andra potentiella lösningar.
Att använda iframes att byta element är smart inställning säkert, men tyvärr är det fortfarande inte en sann lösning på problemet; mer en kreativ hacka. Läs mer om detta trick från Tab Atkins bloggar.
Fastän den inte stabiliseras i specifikationsform, är den här egenskapen avsedd att vara användbar på sidor som innehåller många oberoende widgets. Dokumenterna hävdar att det kan användas för att förhindra att en widgets CSS-regler ändrar andra på sidan. Ett fastighetsvärde av sträng föreslår att det kan undvika många problem med containerfrågor, men det här är inte hela lösningen. bara en bit till pusslet.
En viktig fråga om containerfrågor är att barnen och deras innehåll kan har en effekt på behållarens storlek. Detta kan undvikas i teorin genom att använda CSS-inneslutning, men låt oss undersöka det faktiska problemet som orsakar detta beroende mellan element.
Ta en titt på följande prat av Dan Tocchini (du kanske vill börja video från 10:00-märket eftersom Vimeo inte tillåter tidsstämplar).
Varför kan ett element inte lyssna på dess storlek? Cykliska beroenden. Här är en grafik som återskapas från videon ovan för att klargöra:
Varje låda beror på begränsningarna i dess innehållande låda (bredd I detta fall), och det är här de cykliska beroenden uppträder. Det finns ett konstant förhållande mellan dessa bundna element som uppträder naturligt. Denna typ av beteende finns också med
:sväva händelser som Tommy Hodgins förklarar i den här videon.
Cykliska beroenden är där en stor bit av folket som använder termen "containerfråga" fastnar eftersom:
Den goda nyheten är att webbläsare börjar visa några bevis på att arbeta kring dessa problem som diskuterats tidigare med Houdini.
Det råkar vara en CSS Element Queries (dröm) spec av Tommy Hodgins; och samtidigt som en drömspecifikation är det väldigt imponerande hur lång tid det tar att faktiskt lägga ord och förslag till konversationen. Han har också sammanställt en webbplats som listar utvecklare som arbetar med containerfrågor med titeln "Vem arbetar med containerfrågor".
Efter all min forskning lämnas jag fortfarande kvar och undrar varför majoriteten av vårt samhälle inte bygger på detta sätt när vi kan? Vi har haft möjlighet att bygga detta sätt före CSS @media stöddes i webbläsaren, men det verkar som vi blev sidospårade. Vi gick från ingen aning om "responsiva bästa praxis", för att upptäcka hur man uppnår olika resultat med hjälp av @media; och det spred sig som ett eldsvamp. Artiklar som diskuterar "Media Query-Free Responsive Layout" med hjälp av smartare visningsmodeller som Flexbox och Grid illustrerar att vi har svårt att skilda tidigt skiljande layout från mediafrågor.
Kolla in den här presentationen av Eric Portis (Contain Your Excitement), där han diskuterar just denna punkt. med så många vägspärrar, hur går vi framåt på webbplattformen som helhet?
Här är några vanliga soundbites som du kommer att höra om elementfrågor:
inte 👏 du 👏🏻 våga 👏🏼 lösa 👏🏽 för 👏🏾 javascript 👏🏿 containerfrågor
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6 oktober 2017
Jag tror att intl-lösningar kommer att vara JS-baserade och de kommer att informera CSS-only APIs. Vi bör inte ignorera tmp-lösningar bara för att de behöver JS.
- Phil Walton (@philwalton) 6 oktober 2017
Det känns som om Houdini ibland kan vara ett sätt att säga "vi kan inte bry sig om att slösa bort vår tid på detta så låt oss låta * dem * räkna ut det"
- Sara Soueidan 🐦 (@SaraSoueidan) 6 oktober 2017
Som jag har upplevt under min karriär uttryckte utvecklarna sällan problem med JavaScript för att lägga till stöd för @media med IE8 eftersom vi krävde JavaScript för att lägga till styling power där webbläsare saknade. Men använder du javascript redan i webbläsaren för att förbättra CSS? Det är kätteri för många; även några av dem som är helt nöjda med att använda JavaScript för att samla HTML.
De idéer som nämns i tidigare avsnitt tillåter visserligen att utvecklare ska arbeta med sina egna idéer, men vi måste börja komma ihop oftare, jämföra anteckningar, hitta en standardinriktning och låsa in den. Enligt min personliga uppfattning kommer vi inte att kunna skildra JavaScript från CSS när det gäller elementfrågor så vi måste omfamna det. Vem som helst som väntar på en ren CSS-strategi kan vara på tågdepositionen för många, många år framöver.
Använder du elementfrågor i ditt eget arbete? Är elementfrågor en förlorad orsak på grund av de mycket uppfattade synpunkterna? Jag hoppas att den här diskussionen hjälper till att sparka överväganden som tillåter JavaScript att sitta vid bordet så att vi kan bygga exceptionellt flexibla komponenter för det ständigt föränderliga nätet. Skriv alltid dina tankar i kommentarfältet och glatt kodning som alltid.
Ett stort tack till Tommy Hodgins för hans tid och värdefull kunskap om detta ämne och också för allt sitt arbete att hålla upp på det här samhällskänsliga ämnet.
Accentsconagua