Share
Elementforespørsler (eller "containerforespørsler" hvis du må) fortsetter å komme seg inn i samtaler blant lydhøre webdesignere, men deres inkludering i noen spesifikasjoner og det nåværende landskapet er uklart. I denne artikkelen vil vi diskutere hvilke elementsspørsmål som er, og hvor fellesskonsentrasjonen for tiden befinner seg blant utviklere og standardarbeidsgrupper.
Elementforespørsler tillater elementer å "reagere" til sine egne begrensninger, uavhengig av begrensningene for skjermstørrelsen. Dette er den viktigste detaljene man må forstå. Media spørringer som vi kjenner dem er 100% for responsive layout, men responsiv layout er ikke 100% @media spørringer. Moduler, komponenter, grensesnittelementer vil alltid vokse og krympe med skjermen, men reagerer ikke alene, noe som er grunnen til @media er ikke hele løsningen på våre problemer.
Ta en titt på denne grove demoen av elementet spørringer ved hjelp av eqcss:
Mange som søker løsninger for elementbaserte breakpoints, begynte å implementere CSS-in-JS ved hjelp av rammer som React. Selv om det er gjort fremskritt på andre områder, brøt dette løsningen utviklerne skaper fra generell bruksløsninger for CSS eller JavaScript til flere rammeverksspesifikke biblioteker. Mens resultatene varierer, er kjernevennene disse verktøyene oppnår ofte svært like. I fremtiden kan en standardisering av disse ulike teknikkene styrke en tilnærming til denne typen responsiv design som skal brukes på ethvert nettsted, eller et hvilket som helst verktøy.
Under diskusjonene om dette emnet med Tommy Hodgins (en talsmann for elementspørsmål og skaperen av eqcss) ser det ut til at folk fortsatt er klar over både "element spørringer" og det separate begrepet "container spørringer". Konsensus ser ut til å være delt inn i noen få forskjellige områder:
Her er et annet eksempel der jeg kan endre CSS basert på videoens bredde. Helt urelatert med viewport størrelse. pic.twitter.com/O6lbDBJvFf
- Wes Bos 🔥 (@wesbos) 6. oktober 2017
Jeg vil ha Houdini. Jeg tror det vil la oss lage konsepter som nettlesere kan bruke til å gå innfødt.
- Snook (@ snookca) 6. oktober 2017
Vil du lage et splash i web dev verden? Vær den som gjør en arbeidsmessig gjennomføring av containerforespørsler med Houdini. 🤹🏼♂️
- Chris Coyier (@chriscoyier) 10. oktober 2017
Så hva er på ønskeliste for utviklere?
Tenk deg at du kan skrive et plugin som virket mer som en nettleseroppdatering enn en JavaScript-plugin. Hva om du hadde tilgang til å injisere din egen logikk inn i hvordan en nettleser analyserer, maler og gjør sider? Hvilke ting kan du "lære" nettleseren i stedet for å stole på logikk på toppen av siden for å beregne?
For tiden er vi fast i måten en nettleser behandler CSS på, men med Houdini håper vi at vi får muligheten til å omorganisere og prioritere slik at vi kan beregne verdier ved hjelp av intelligente tilnærminger, eller kontrollere gjengivelsen for å skjule feil. JavaScript og CSS Object Model APIer gir CSS samme type tilgang, kontroll og kraft som JavaScript og DOM APIer gir til HTML. Ifølge Tab Atkins bruker Houdini også Typed OM og Parser API logikk, og disse er de underliggende techs for tilpassede At-Rules, slik at du angir Element Query-regler i stilarket ditt og har dem håndtert av JavaScript.
Det er et nettsted som er dedikert til å spore fremdriften på ishoudinireadyyet.com, men i mellomtiden la oss vurdere noen andre potensielle løsninger.
Bruke iframes å pakke elementer er smart tilnærming helt sikkert, men dessverre er det fortsatt ikke en sann løsning på problemet; mer en kreativ hack. Les mer om dette trikset fra bloggen til Tab Atkins.
Selv om det ikke er stabilisert i spesifikasjonsform, er denne egenskapen ment å være nyttig på sider som inneholder mange uavhengige widgets. Dokumenterne hevder at det kan brukes til å hindre en widgets CSS-regler fra å endre andre på siden. En eiendomsverdi av streng antyder at det kan unngå mange av problemene med containerforespørsler, men dette er ikke hele løsningen; bare et stykke til puslespillet.
Et stort problem med containerforespørsler er at barna og deres innhold kan har en effekt på beholderens størrelse. Dette kan unngås i teorien ved hjelp av CSS-inneslutning, men la oss se på det aktuelle problemet som forårsaker denne avhengigheten mellom elementene.
Ta en titt på følgende snakk av Dan Tocchini (du vil kanskje starte video fra klokken 10:00 da Vimeo ikke tillater tidsstemmer).
Hvorfor kan ikke et element være lydhør overfor størrelsen? Sykliske avhengigheter. Her er en grafikk gjenskapt fra videoen ovenfor for å klargjøre:
Hver boks avhenger av begrensningene i den inneholder boksen (bredde i dette tilfellet), og det er her de sykliske avhengighetene dukker opp. Det er et konstant forhold mellom disse binde elementene som oppstår naturlig. Denne typen oppførsel eksisterer også med
:sveve hendelser som Tommy Hodgins forklarer i denne videoen.
Sykliske avhengigheter er hvor en stor del av folkene som bruker begrepet "containerforespørsel", blir fast fordi:
Den gode nyheten er at nettlesere begynner å vise noen bevis på å jobbe rundt disse problemene som diskutert tidligere med Houdini.
Det skjer en CSS Element Queries (drøm) spec av Tommy Hodgins; og mens bare en drømmespesifikasjon, er det veldig imponerende at lengden er tatt for å faktisk sette ord og forslag til samtalen. Han har også samlet et nettsted som viser utviklere som arbeider med containerforespørsler med riktig tittel "Hvem jobber med Containerforespørsler".
Etter all min forskning er jeg fortsatt igjen og lurer på hvorfor flertallet av samfunnet vårt ikke bygger slik når vi kan? Vi har hatt muligheten til å bygge denne måten før CSS @media ble støttet i nettleseren, men det ser ut til at vi ble sidetracked. Vi gikk fra å ha ingen anelse om "responsive best practices", for å finne ut hvordan man oppnår ulike resultater ved å bruke @media; og det spredte seg som en brann. Artikler som diskuterer "Media Query-Free Responsive Layout" ved hjelp av smartere skjermmodeller som Flexbox og Grid, illustrerer at vi har et vanskelig tidsskilt responsivt layout fra medieforespørsler.
Sjekk ut denne presentasjonen av Eric Portis (Contain Your Excitement) der han diskuterer det veldig poenget; med så mange veisperringer, hvordan går vi videre på nettplattformen som helhet?
Her er noen få vanlige lydbiter som du vil høre om elementspørsmål:
ikke dum 👏🏼 sett deg 👏🏽 for 👏🏾 javascript 👏🏿 container spørringer
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6. oktober 2017
Jeg tror at intl-løsninger vil være JS-baserte, og de vil informere CSS-only APIs. Vi bør ikke ignorere tmp-løsninger bare fordi de krever JS.
- Phil Walton (@philwalton) 6. oktober 2017
Det føles som om Houdini noen ganger kan være en måte å si "vi kan ikke plage å kaste bort vår tid på dette så la oss la dem * finne ut det"
- Sara Soueidan 🐦 (@SaraSoueidan) 6. oktober 2017
Som jeg har opplevd i løpet av karrieren min, har utviklere sjelden uttrykt problemer ved hjelp av JavaScript for å legge til støtte for @media med IE8 fordi vi krevde JavaScript for å legge til styling strøm der nettlesere manglet. Men bruker du JavaScript allerede i nettleseren for å forbedre CSS? Det er kjetteri for mange; selv noen av dem som er helt glade med JavaScript for å samle HTML.
Ideene nevnt i tidligere seksjoner tillater at utviklere kan jobbe med egne ideer, men vi må begynne å komme sammen hyppigere, sammenligne notater, finne en standard tilnærming og låse den inn. I min personlige visning vil vi ikke kunne Skilsmisse JavaScript fra CSS når det gjelder element spørringer, så vi må omfavne det. Alle som venter på en ren CSS-tilnærming, kan være på togdepotet i mange, mange år framover.
Bruker du elementspørsmål i ditt eget arbeid? Er elementspørsmål en tapt sak på grunn av de høyt oppfattede synspunkter? Jeg håper denne diskusjonen bidrar til å gnage overveielse som gjør det mulig for JavaScript å ha et sete ved bordet slik at vi kan bygge svært fleksible komponenter for det stadig skiftende web. Som alltid, vennligst legg inn dine tanker i kommentarfeltet og lykkelig koding.
En stor takk til Tommy Hodgins for sin tid og verdifulle kunnskap om dette emnet, og også for alt arbeidet hans som holder opp på dette fellesskapssensitive emnet.
Accentsconagua