Share
Les requêtes d'élément (ou «requêtes de conteneur» si vous devez) continuent de faire leur chemin dans les conversations entre les responsables de la conception Web réactifs, mais leur inclusion dans les spécifications et le paysage actuel n'est pas claire. Dans cet article, nous verrons quelles sont les requêtes sur les éléments et où le consensus de la communauté se trouve actuellement parmi les développeurs et les groupes de travail sur les normes..
Les requêtes d'élément permettent aux éléments de "réagir" à leurs propres contraintes, quelles que soient les contraintes de taille d'écran. C'est le détail le plus important qu'il faut comprendre. Les requêtes multimédia telles que nous les connaissons concernent à 100% la mise en page réactive, mais la mise en page réactive n'est pas à 100% @médias requêtes. Les modules, composants et éléments d'interface s'agrandissent et se rétrécissent toujours avec l'écran, mais ne réagissent jamais seuls, c'est pourquoi @médias n'est pas la solution complète à nos problèmes.
Jetez un coup d’œil à cette démo approximative de requêtes d’éléments utilisant eqcss:
De nombreuses personnes à la recherche de solutions pour les points d'arrêt par élément ont commencé à implémenter CSS-in-JS à l'aide de frameworks tels que React. Bien que des progrès aient été accomplis dans d'autres domaines, les solutions que les développeurs créaient à partir de solutions d'usage général pour CSS ou JavaScript étaient désormais fractionnées dans plusieurs bibliothèques spécifiques à l'infrastructure. Bien que les résultats varient, les fonctionnalités essentielles de ces outils sont souvent très similaires. À l'avenir, une standardisation de ces techniques assorties pourrait solidifier une approche de ce type de conception sensible à appliquer à n'importe quel site Web ou outil..
Lors de mes discussions sur ce sujet avec Tommy Hodgins (défenseur des requêtes d'éléments et créateur de eqcss), il semble que les gens soient toujours au courant des «requêtes d'éléments» et du concept distinct de «requêtes de conteneur». Le consensus semble être divisé en plusieurs domaines différents:
Voici un autre exemple où je peux changer le CSS en fonction de la largeur de la vidéo. Totalement indépendant de la taille de la fenêtre. pic.twitter.com/O6lbDBJvFf
- Wes Bos (@wesbos) 6 octobre 2017
Je veux Houdini. Je pense que ça va nous permettre de créer des concepts que les navigateurs peuvent utiliser pour devenir natifs.
- Snook (@snookca) 6 octobre 2017
Voulez-vous faire sensation dans le monde du développement Web? Soyez celui qui effectue une implémentation fonctionnelle des requêtes de conteneur avec Houdini. 🤹🏼♂️
- Chris Coyier (@chriscoyier) 10 octobre 2017
Alors, qu'est-ce qui est sur la liste de souhaits des développeurs?
Imaginez que vous puissiez écrire un plugin qui ressemble plus à un patch de navigateur qu’un plugin JavaScript. Et si vous aviez le droit d'injecter votre propre logique dans la façon dont un navigateur analyse, peint et rend les pages? Quelles choses pourriez-vous «apprendre» au navigateur au lieu de vous fier à la logique en haut de la page pour calculer?
Nous sommes actuellement coincés dans la manière dont un navigateur traite les CSS, mais avec Houdini, nous espérons pouvoir réorganiser et hiérarchiser afin de pouvoir calculer des valeurs à l'aide d'approches intelligentes ou de contrôler le rendu pour masquer les défauts. Les API de modèle d'objet JavaScript et CSS confèrent au CSS le même type d'accès, de contrôle et de puissance que le JavaScript et les API DOM donnent à HTML. Selon Tab Atkins, Houdini utilise également la logique des API typées et des analyseurs syntaxiques. Ce sont les techniques sous-jacentes aux règles At personnalisées vous permettant de spécifier des règles de requête d'élément dans votre feuille de style et de les faire gérer par JavaScript.
Il existe un site exclusivement dédié au suivi de ses progrès sur ishoudinireadyyet.com, mais en attendant, considérons d’autres solutions potentielles..
Utiliser des iframes pour encapsuler des éléments est une approche intelligente, certes, mais malheureusement, ce n’est toujours pas une vraie solution au problème; plus un hack créatif. En savoir plus sur cette astuce sur le blog de Tab Atkins.
Bien que non stabilisée sous forme de spécification, cette propriété est censée être utile sur les pages contenant de nombreux widgets indépendants. Les documents affirment qu'il peut être utilisé pour empêcher les règles CSS d'un widget de changer les autres sur la page. Une valeur de propriété de strict suggère que cela peut éviter beaucoup des problèmes de requêtes de conteneurs, mais ce n'est pas la solution complète; seulement une pièce du puzzle.
Un problème majeur concernant les requêtes sur les conteneurs est que les enfants et leur contenu pouvez avoir un effet sur la taille du conteneur. Ceci peut être évité en théorie en utilisant le confinement CSS, mais examinons le problème réel qui cause cette dépendance entre les éléments.
Regardez l'intervention suivante de Dan Tocchini (vous pouvez commencer la vidéo à partir de 10h00, car Vimeo n'autorise pas l'horodatage).
Pourquoi un élément ne peut-il pas être sensible à sa taille? Dépendances cycliques. Voici un graphique recréé à partir de la vidéo ci-dessus pour clarifier:
Chaque case dépend des contraintes de sa case contenant (largeur dans ce cas), et c’est là que les dépendances cycliques apparaissent. Il existe une relation constante entre ces éléments liés qui se produit naturellement. Ce type de comportement existe aussi avec
:flotter les événements comme l'explique Tommy Hodgins dans cette vidéo.
Les dépendances cycliques sont le point de blocage d’un grand nombre de personnes qui utilisent le terme «requête de conteneur» pour les raisons suivantes:
La bonne nouvelle est que les navigateurs commencent à montrer des preuves de la résolution de ces problèmes, comme cela a été discuté auparavant avec Houdini..
Il se trouve qu’il existe une spécification CSS Element Queries (dream) de Tommy Hodgins; et bien qu'il ne s'agisse que d'une spécification de rêve, les efforts déployés pour mettre des mots et des suggestions dans la conversation sont vraiment impressionnants. Il a également compilé un site qui répertorie les développeurs travaillant sur des requêtes de conteneur intitulées «Qui travaille sur les requêtes de conteneur».
Après toutes mes recherches, je me demande encore pourquoi la majorité de notre communauté ne construit pas de cette façon quand nous le pouvons. Nous avons eu la possibilité de construire de cette façon avant CSS @médias était pris en charge par le navigateur, mais il semble que nous ayons été déroutés. Nous n’avions aucune idée des «meilleures pratiques réactives» pour découvrir comment obtenir divers résultats en utilisant @médias; et qui se répandent comme une traînée de poudre. Des articles traitant de «présentation réactive sans requête multimédia» à l'aide de modèles d'affichage plus intelligents tels que Flexbox et Grid illustrent la difficulté que nous rencontrons en ce qui concerne la présentation réactive des requêtes multimédia..
Regardez cette présentation d'Eric Portis (Contain Your Excitement) dans laquelle il discute de ce point précis; avec autant de barrages routiers, comment pouvons-nous faire progresser la plate-forme Web dans son ensemble?
Voici quelques phrases courantes que vous entendrez concernant les requêtes d'éléments:
ne pas oser régler des requêtes de conteneur javascript
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6 octobre 2017
Je pense que les solutions intl seront basées sur JS et qu'elles informeront les API uniquement CSS. Nous ne devrions pas ignorer les solutions tmp simplement parce qu'elles nécessitent JS.
- Phil Walton (@philwalton) 6 octobre 2017
Il me semble que Houdini peut parfois être une façon de dire: «Nous ne pouvons pas perdre notre temps à cela, alors laissez-les * comprendre *.»
- Sara Soueidan 🐦 (@SaraSoueidan) 6 octobre 2017
Comme je l'ai constaté au cours de ma carrière, les développeurs ont rarement exprimé des problèmes d'utilisation de JavaScript pour intégrer la prise en charge de @médias avec IE8 car nous avions besoin de JavaScript pour ajouter une puissance de style là où les navigateurs manquaient. Cependant, en utilisant JavaScript déjà dans le navigateur pour améliorer CSS? C'est une hérésie pour beaucoup. même certains de ceux qui sont totalement heureux en utilisant JavaScript pour assembler HTML.
Les idées mentionnées dans les sections précédentes permettent certes aux développeurs de travailler sur leurs propres idées, mais nous devons commencer à nous rapprocher plus fréquemment, à comparer les notes, à trouver une approche standard et à la verrouiller. À mon avis, nous ne pourrons pas divorce JavaScript de CSS quand il s'agit de requêtes d'éléments, nous devons donc l'accepter. Quiconque attend une approche CSS pure peut rester dans le dépôt de train pendant de très nombreuses années..
Utilisez-vous des requêtes d'éléments dans votre propre travail? Les requêtes d'éléments sont-elles une cause perdue à cause des points de vue très controversés? J'espère que cette discussion contribuera à susciter une réflexion qui permettra à JavaScript de s'asseoir à la table afin que nous puissions créer des composants exceptionnellement flexibles pour le Web en constante évolution. Comme toujours, postez vos commentaires dans la section commentaires et codez-les avec plaisir.
Un grand merci à Tommy Hodgins pour son temps et ses précieuses connaissances sur ce sujet, ainsi que pour tout son travail de suivi sur ce sujet sensible à la communauté.
Accentsconagua