Share
Las consultas de elementos (o "consultas de contenedor" si es necesario) continúan abriéndose camino en las conversaciones entre los creadores de diseño web sensibles, pero su inclusión en cualquier especificación y el panorama actual no está claro. En este artículo, analizaremos qué son las consultas de elementos y dónde se encuentra actualmente el consenso de la comunidad entre los desarrolladores y los grupos de trabajo de estándares..
Las consultas de elementos permiten que los elementos "reaccionen" a sus propias restricciones, independientemente de las restricciones de tamaño de la pantalla. Este es el detalle más significativo que uno debe entender. Las consultas de medios como las conocemos son 100% para un diseño sensible, pero un diseño sensible no es 100% @medios de comunicación consultas Los módulos, componentes, elementos de la interfaz siempre crecerán y se reducirán con la pantalla, pero nunca reaccionarán por sí mismos, por lo que @medios de comunicación No es la solución completa a nuestros problemas..
Eche un vistazo a esta demostración aproximada de consultas de elementos utilizando eqcss:
Muchas personas que buscaban soluciones para puntos de interrupción basados en elementos comenzaron a implementar CSS-in-JS utilizando marcos como React. Si bien se han logrado avances en otras áreas, esto fracturó las soluciones que los desarrolladores creaban a partir de soluciones de uso general para CSS o JavaScript en múltiples bibliotecas específicas del marco. Si bien los resultados varían, las características principales que alcanzan estas herramientas son a menudo muy similares. En el futuro, una estandarización de estas técnicas variadas podría consolidar un enfoque para este tipo de diseño sensible que se aplicará a cualquier sitio web o herramienta..
Durante mis discusiones sobre este tema con Tommy Hodgins (un defensor de las consultas de elementos y creador de eqcss) parece que la gente todavía está al tanto de las "consultas de elementos" y del concepto separado de "consultas de contenedores". El consenso parece estar dividido en algunas áreas diferentes:
Aquí hay otro ejemplo donde puedo cambiar el CSS según el ancho del video. Totalmente sin relación con el tamaño de la ventana gráfica. pic.twitter.com/O6lbDBJvFf
- Wes Bos 🔥 (@wesbos) 6 de octubre de 2017
Quiero a Houdini. Creo que nos permitirá crear conceptos que los navegadores pueden usar para ser nativos..
- Snook (@snookca) 6 de octubre de 2017
¿Quieres hacer un chapoteo en el mundo de desarrollo web? Sea quien realice una implementación de trabajo de consultas de contenedor con Houdini. 🤹🏼♂️
- Chris Coyier (@chriscoyier) 10 de octubre de 2017
Entonces, ¿qué hay en la lista de deseos para los desarrolladores??
Imagina que podrías escribir un complemento que actuara más como un parche del navegador que un complemento de JavaScript. ¿Qué pasaría si tuviera acceso para inyectar su propia lógica en cómo un navegador analiza, pinta y representa las páginas? ¿Qué cosas podría "enseñar" el navegador en lugar de confiar en la lógica en la parte superior de la página para calcular??
Actualmente estamos atascados con la forma en que un navegador procesa CSS, pero con Houdini, la esperanza es que tendremos la capacidad de reorganizar y priorizar para que podamos calcular valores utilizando enfoques inteligentes o controlar la representación para ocultar fallas. Las API de modelo de objetos de JavaScript y CSS otorgan a CSS el mismo tipo de acceso, control y potencia que las API de JavaScript y DOM a HTML. De acuerdo con Tab Atkins, Houdini también usa la lógica de la API del analizador y el OM mecanografiado, y estas son las técnicas subyacentes para las reglas at At personalizadas que le permiten especificar las reglas de consulta de elementos en su hoja de estilo y que JavaScript las maneje..
Hay un sitio dedicado exclusivamente a rastrear su progreso en ishoudinireadyyet.com, pero mientras tanto consideremos algunas otras soluciones potenciales.
El uso de iframes para envolver elementos es un enfoque inteligente sin duda, pero desafortunadamente todavía no es una verdadera solución al problema; más un hack creativo. Lee más sobre este truco en el blog de Tab Atkins..
Aunque no está estabilizada en forma de especificación, esta propiedad está destinada a ser útil en páginas que contienen muchos widgets independientes. Los documentos afirman que se puede usar para evitar que las reglas de CSS de un widget cambien a otros en la página. Un valor de propiedad de estricto sugiere que puede evitar muchos de los problemas de las consultas de contenedor, pero esta no es la solución completa; solo una pieza para el rompecabezas.
Un problema importante con respecto a las consultas de contenedores es que los niños y su contenido puede Tiene un efecto sobre el tamaño del contenedor. Esto se puede evitar en teoría usando la contención de CSS, pero veamos el problema real que causa esta dependencia entre los elementos..
Echa un vistazo a la siguiente charla de Dan Tocchini (es posible que desees comenzar el video desde las 10:00 hs ya que Vimeo no permite sellos de tiempo).
¿Por qué un elemento no puede responder a su tamaño? Dependencias cíclicas. Aquí hay un gráfico recreado del video de arriba para aclarar:
Cada caja depende de las restricciones de su caja que contiene (anchura en este caso), Y aquí es donde aparecen las dependencias cíclicas. Hay una relación constante entre estos elementos unidos que ocurre naturalmente. Este tipo de comportamiento también existe con
:flotar Eventos como lo explica Tommy Hodgins en este video..
Las dependencias cíclicas son donde una gran parte de las personas que usan el término "consulta de contenedor" se atascan porque:
La buena noticia es que los navegadores están comenzando a mostrar cierta evidencia de que han solucionado estos problemas como se comentó anteriormente con Houdini..
Sucede que hay una especificación de CSS Element Queries (sueño) de Tommy Hodgins; y aunque solo es una especificación de ensueño, es muy impresionante el esfuerzo que se requiere para poner palabras y sugerencias en la conversación. También compiló un sitio que enumera a los desarrolladores que trabajan en consultas de contenedores apropiadamente titulados "Quién está trabajando en consultas de contenedores".
Después de toda mi investigación, todavía me pregunto por qué la mayoría de nuestra comunidad no está construyendo de esta manera cuando podemos. Hemos tenido la capacidad de construir de esta manera antes de CSS @medios de comunicación fue soportado en el navegador, pero parece que nos desviamos. Pasamos de no tener idea de las "mejores prácticas de respuesta", a descubrir cómo lograr varios resultados usando @medios de comunicación; y que se extendió como un reguero de pólvora. Los artículos que discuten el "diseño sensible sin necesidad de consultas de medios" utilizando modelos de pantalla más inteligentes como Flexbox y Grid ilustran que estamos teniendo dificultades para separar el diseño sensible de las consultas de los medios..
Echa un vistazo a esta presentación de Eric Portis (Contain Your Emitement) en la que habla sobre ese punto; Con tantos obstáculos, ¿cómo avanzamos la plataforma web en su conjunto??
Aquí hay algunos fragmentos de sonido comunes que escuchará con respecto a las consultas de elementos:
no te atrevas a resolver consultas de contenedor de javascript
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6 de octubre de 2017
Creo que las soluciones intl se basarán en JS y esas serán informativas de las API solo para CSS. No debemos ignorar las soluciones tmp solo porque requieren JS..
- Phil Walton (@philwalton) 6 de octubre de 2017
Parece que a veces Houdini puede ser una manera de decir "no podemos molestarnos en gastar nuestro tiempo en esto, así que dejemos que * ellos * lo resuelvan"
- Sara Soueidan 🐦 (@SaraSoueidan) 6 de octubre de 2017
Como he experimentado a lo largo de mi carrera, los desarrolladores rara vez expresaron problemas utilizando JavaScript para agregar soporte para @medios de comunicación con IE8 porque requerimos JavaScript para agregar poder de estilo donde los navegadores carecían. Sin embargo, utilizando JavaScript ya en el navegador para mejorar CSS? Eso es una herejía para muchos; incluso algunos de los que están totalmente contentos usando JavaScript para ensamblar HTML.
Las ideas mencionadas en secciones anteriores ciertamente permiten a los desarrolladores trabajar en sus propias ideas, pero debemos comenzar a reunirnos con más frecuencia, comparar notas, encontrar un enfoque estándar y encerrarlo. En mi opinión personal, no podremos Divida el JavaScript de CSS cuando se trata de consultas de elementos, por lo que debemos adoptarlo. Cualquiera que esté esperando un enfoque de CSS puro puede estar en el depósito de trenes durante muchos, muchos años por venir..
¿Estás utilizando consultas de elementos en tu propio trabajo? ¿Son las consultas de elementos una causa perdida debido a los puntos de vista altamente opinados? Espero que esta discusión ayude a generar una consideración que permita a JavaScript tener un lugar en la mesa para que podamos construir componentes excepcionalmente flexibles para la web en constante cambio. Como siempre, publique sus pensamientos en la sección de comentarios y feliz codificación.
Un gran agradecimiento a Tommy Hodgins por su tiempo y valioso conocimiento sobre este tema y también por todo su trabajo para mantenerse al tanto de este tema sensible a la comunidad..
Accentsconagua