Share
Le query di elementi (o "query di contenitore" se è necessario) continuano a farsi strada nelle conversazioni tra i responsabili del web design reattivo, ma la loro inclusione in tutte le specifiche e il panorama attuale non è chiara. In questo articolo discuteremo su quali elementi sono le query e dove il consenso della comunità si trova attualmente tra gli sviluppatori e i gruppi di lavoro degli standard.
Le query sugli elementi consentono agli elementi di "reagire" ai propri vincoli, indipendentemente dai vincoli della dimensione dello schermo. Questo è il dettaglio più significativo da comprendere. Le query multimediali così come le conosciamo sono al 100% per il layout reattivo, ma il layout reattivo non è al 100% @media interrogazioni. Moduli, componenti, elementi dell'interfaccia cresceranno sempre e si restringeranno con lo schermo, ma non reagiranno mai da soli, ecco perché @media non è l'intera soluzione ai nostri problemi.
Dai un'occhiata a questa demo approssimativa delle query sugli elementi usando eqcss:
Molte persone alla ricerca di soluzioni per i breakpoint basati su elementi hanno iniziato a implementare CSS-in-JS utilizzando framework come React. Nonostante i progressi siano stati fatti in altre aree, questo ha danneggiato le soluzioni che gli sviluppatori stavano creando da soluzioni generiche per CSS o JavaScript in più librerie specifiche del framework. Mentre i risultati variano, le caratteristiche principali di questi strumenti sono spesso molto simili. In futuro, una standardizzazione di queste tecniche assortite potrebbe consolidare un approccio a questo tipo di design reattivo da applicare a qualsiasi sito Web oa qualsiasi strumento.
Durante le mie discussioni su questo argomento con Tommy Hodgins (un sostenitore delle query di elementi e creatore di eqcss) sembra che le persone siano ancora consapevoli sia delle "query di elementi" sia del concetto separato di "query di container". Il consenso sembra essere suddiviso in alcune aree diverse:
Ecco un altro esempio in cui posso modificare il CSS in base alla larghezza del video. Totalmente estraneo alla dimensione del viewport. pic.twitter.com/O6lbDBJvFf
- Wes Bos 🔥 (@wesbos), 6 ottobre 2017
Voglio Houdini. Penso che ci consentirà di creare concetti che i browser possono utilizzare per diventare nativi.
- Snook (@snookca) 6 ottobre 2017
Vuoi fare un tuffo nel mondo del web dev? Sii quello che realizza un'implementazione funzionante delle query sui container con Houdini. 🤹🏼♂️
- Chris Coyier (@chriscoyier), 10 ottobre 2017
Quindi cosa c'è nella lista dei desideri per gli sviluppatori?
Immagina di poter scrivere un plug-in che si comporta più come una patch del browser che come un plugin JavaScript. Che cosa succede se si ha accesso a inserire la propria logica nel modo in cui un browser analizza, dipinge e esegue il rendering delle pagine? Quali cose potresti "insegnare" al browser invece di fare affidamento sulla logica in cima alla pagina per calcolare?
Attualmente siamo bloccati dal modo in cui un browser elabora i CSS, ma con Houdini la speranza è che avremo la possibilità di riorganizzare e stabilire le priorità in modo da poter calcolare i valori utilizzando approcci intelligenti o controllare il rendering per nascondere i difetti. Le API del modello a oggetti JavaScript e CSS conferiscono ai CSS lo stesso tipo di accesso, controllo e potenza che le API JavaScript e DOM attribuiscono all'HTML. Secondo Tab Atkins, Houdini utilizza anche la logica API Typed OM e Parser e questi sono i tech sottostanti per le regole At-custom che consentono di specificare le regole di Query elemento nel foglio di stile e di gestirle da JavaScript.
C'è un sito dedicato esclusivamente al monitoraggio dei suoi progressi su ishoudinireadyyet.com, ma nel frattempo consideriamo alcune altre potenziali soluzioni.
Usare gli iframe per avvolgere gli elementi è certamente un approccio intelligente, ma sfortunatamente non è ancora una vera soluzione al problema; più un trucco creativo. Leggi di più su questo trucco dal blog di Tab Atkins.
Sebbene non sia stabilizzato nel modulo delle specifiche, questa proprietà è pensata per essere utile su pagine che contengono molti widget indipendenti. I documenti affermano che può essere utilizzato per impedire che le regole CSS di un widget modificino le altre nella pagina. Un valore di proprietà di rigoroso suggerisce di evitare molti dei problemi delle query sui contenitori, ma questa non è l'intera soluzione; solo un pezzo del puzzle.
Uno dei principali problemi relativi alle query sui contenitori è che i bambini e il loro contenuto può avere un effetto sulla dimensione del contenitore. Questo può essere evitato in teoria usando il contenimento dei CSS, ma esaminiamo il problema reale che causa questa dipendenza tra gli elementi.
Dai un'occhiata al seguente intervento di Dan Tocchini (potresti voler iniziare il video a partire dal marchio delle 10:00, dato che Vimeo non consente i timestamp).
Perché un elemento non può rispondere alle sue dimensioni? Dipendenze cicliche. Ecco una grafica ricreata dal video qui sopra per chiarire:
Ogni scatola dipende dai vincoli della sua scatola di contenimento (larghezza in questo caso), ed è qui che compaiono le dipendenze cicliche. Esiste una relazione costante tra questi elementi legati che si verifica in modo naturale. Questo tipo di comportamento esiste anche con
: hover eventi come spiega Tommy Hodgins in questo video.
Le dipendenze cicliche sono dove una grande fetta di gente che usa il termine "query di contenitore" si blocca perché:
La buona notizia è che i browser stanno iniziando a mostrare alcune prove su come aggirare questi problemi come discusso in precedenza con Houdini.
Capita di essere una speculazione degli elementi CSS (sogno) di Tommy Hodgins; e sebbene sia solo una specifica per i sogni, è davvero impressionante la lunghezza impiegata per mettere effettivamente parole e suggerimenti nella conversazione. Ha anche compilato un sito che elenca gli sviluppatori che lavorano alle query sui contenitori in modo appropriato intitolato "Who is Working on Container Queries".
Dopo tutte le mie ricerche, mi viene ancora chiesto perché la maggior parte della nostra comunità non stia costruendo in questo modo quando possiamo? Abbiamo avuto la possibilità di costruire in questo modo prima dei CSS @media era supportato nel browser, ma sembra che siamo diventati sviati. Siamo passati dall'assenza di indizi su "best practice reattive", alla scoperta di come ottenere vari risultati usando @media; e quello si diffuse a macchia d'olio. Gli articoli che parlano di "layout reattivo libero da media query" utilizzando modelli di visualizzazione più intelligenti come Flexbox e Grid illustrano che stiamo attraversando un momento difficile per separare il layout reattivo dalle query sui media.
Dai un'occhiata a questa presentazione di Eric Portis (Contain Your Excitement) in cui discute proprio questo punto; con così tanti posti di blocco, come avanzare la piattaforma web nel suo insieme?
Ecco alcuni suoni comuni che sentirai riguardo alle query sugli elementi:
non 👏 puoi 👏🏼 👏🏼 accontentarti 👏🏽 per 👏🏿 query javascript 👏🏿
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6 ottobre 2017
Penso che le soluzioni intl saranno basate su JS e quelle informeranno le sole API CSS. Non dovremmo ignorare le soluzioni di tmp solo perché richiedono JS.
- Phil Walton (@philwalton), 6 ottobre 2017
Sembra che Houdini a volte sia un modo per dire "non possiamo preoccuparci di sprecare il nostro tempo su questo, quindi lascia che * loro * lo capiscano"
- Sara Soueidan 🐦 (@SaraSoueidan) 6 ottobre 2017
Come ho vissuto durante la mia carriera, gli sviluppatori hanno raramente espresso problemi utilizzando JavaScript per aggiungere supporto @media con IE8 perché avevamo bisogno di JavaScript per aggiungere potenza stilistica laddove mancavano i browser. Tuttavia, utilizzando JavaScript già nel browser per migliorare i CSS? Questa è eresia per molti; anche alcuni di quelli che sono totalmente felici di usare JavaScript per assemblare HTML.
Le idee menzionate nelle sezioni precedenti stanno certamente permettendo agli sviluppatori di lavorare sulle proprie idee, ma dobbiamo iniziare a venire insieme più spesso, confrontare le note, trovare un approccio standard e bloccarlo. Nella mia visione personale non saremo in grado di divorzio JavaScript dai CSS quando si tratta di query di elementi quindi dobbiamo abbracciarlo. Chiunque sia in attesa di un approccio CSS puro potrebbe trovarsi nel deposito dei treni per molti, molti anni a venire.
Stai usando query di elementi nel tuo lavoro? Le query sugli elementi sono una causa persa a causa dei punti di vista altamente motivati? Spero che questa discussione contribuisca a stimolare la considerazione che consentirà a JavaScript di avere un posto al tavolo così da poter costruire componenti eccezionalmente flessibili per il web in continua evoluzione. Come sempre, si prega di postare i vostri pensieri nella sezione commenti e felice codifica.
Un grande ringraziamento a Tommy Hodgins per il suo tempo e le preziose conoscenze su questo argomento e anche per tutto il suo lavoro al passo con questo argomento sensibile alla comunità.
Accentsconagua