Element Queries y el porqué de la eterna espera 29.6.14
Qué son las nonatas element queries de Css y el porqué de que no existan (aún).
Element Queries y el porqué de la eterna espera
Por si el término Element Queries en el ámbito de Css te resulta extraño (cosa extraña a estas alturas) lo primero sería dejarlo claro, ¿no?.
La idea es simple y semejante a las medias queries
de Css. Como éstas, se trata de poder aplicar unas declaraciones u otras a un elemento en función del valor que tenga cierta propiedad del propio elemento (o su ancestro) en vez del viewport o pantalla como pasa con las @media queries.
Dicho de otro modo, las element quieries son 'medias queries' pero acotadas al ámbito de un elemento por el valor del propio elemento.
.elemento:min-width(450px) > .hijo {
/* Tu css muuuuu chulo */
}
Sencillo, eficiente y con una potencialidad tremenda.
Para ayudar a comprenderlo mejor. Imagina que creas un "módulo" o "componente cualquiera para mostrar cierta información. A la hora de estilizalo, tú como autor, no sabes los detalles, especialmetne el tamaño o anchura, donde se mostrará tu creación.
Y seguro que estarías encantado de poder diseñarlo para que fuese igual de molón mostrándolo en un elemento estrecho (como un sidebar) o con anchura generosa.
Hoy por hoy prever y cubrir las posibles variaciones es tedioso, trabajo e inútil intentarlo hacer en base a las @medias queries. Y ni con los llamados "mixin" de cualquier preprocesador tienes el éxito garantizado.
Circularidad: el pecado original del Element Query
Todo el mundo las busca y todo el mundo las espera y sin embargo las element quieries no llegan. La causa es de la circularity o dependencia circular.
Tab Atkins Jr explica y ejemplifica este peligro de forma clara. Imagina el siguiente código:
.container {
float: left;
}
.child {
width: 500px;
}
.container:min-width(450px) > .child {
width: 400px;
}
La anchura del elemento container depende de su contenido al estar flotado. De entrada su hijo es 500px de ancho. Pero la regla con la 'element query' indica que si el padre tiene una anchura de 450px o más su hijo deviene a 400px.
¿Ves la dependencia circular o el bucle?. ¿No? Pues sigue el proceso anterior. El hijo, por la 'element query' ahora tiene 400px, esto hace que ya no aplique la "EQ" y vuelve a medir sus 500px iniciales (y su padre también) por lo que la "EQ" vuelve a aplicarse y de nuevo... vuelta a empezar y así hasta el infinito y más allá.
Y ahí está la propuesta de las element quieries esperando a que se resuelva y puedan evitarse de forma satisfactoria los bucles o referencias circulares.
Lecturas
Si conoces este blog seguro que habrás echando de menos algún enlace a algún documento del consorcio que recoja y exponga las element quieries.
La razón de su ausencia: las element quieries no existen. La idea de las EQ´s fue expuesta por Tab Atkins Jr hace cosa de 1 año. Y como él mismo reconoció hace nada, nada ha cambiado desde entonces.
Este artículo de filamentgroup.com ayudará a comprender mejor la potencialidad de las EQ´s.
Así que este aspecto sólo es posible, hoy por hoy, abordarlo con otros lenguajes como javascript. Hay varias soluciones al respecto. Y si estás interesado en hallar alguna de ellas sólo tienes que preguntar a google. Por ejemplo: elementqueries.com una realización css a través de js
Kseso
the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso
A mí me parece que el problema tiene solución, aunque hay que cambiar el enfoque.
ResponderEliminarHablamos de esto alguna vez, pero no recuerdo el artículo donde estaba, o si fue en la comunidad, o quizá en un mail; a mi edad ya no estoy para recordar semejantes detalles ...
Un punto básico, de los que ya se mencionaron, es la diferencia que tienen los estilos y los escripts para interactuar con el usuario; es cierto que detrás de un CSS siempre hay un programa, porque así funcionan los navegadores, pero en la última línea antes de la pantalla podemos definir sus comportamientos diciendo que un (por ejemplo) javascript se maneja con eventos, y el CSS se maneja con estados.
Esto puede ser un poco complicado hasta que vemos un ejemplo conocido. Con ':hover' vamos a cambiar el formato de un elemento al ponerle el puntero encima, pero en realidad lo que "ve" el CSS es el estado del elemento con respecto al puntero : si están encimados, aplica un estilo, y si no lo están, otro. En javascript (por seguir con el ejemplo) para conseguir el mismo efecto debemos usar un evento como el que asigna el atributo 'onMouseOver' puesto en algún elemento, que dispara un cambio al momento de entrar el puntero en él; pero si retiramos el mouse (ratón) el cambio se queda, no vuelve a su estado original; para eso debemos agregar otro atributo 'onMouseOut' que detecte cuando el cursor salga de nuestro elemento.
Esta diferencia de criterio es la que permite que con un escript sea tan fácil ajustar formas dependiendo del tamaño de la ventana, y que con CSS sea una tragedia. Es evidente que si medimos con JS no hay loop.
Para el caso descripto por Tab Atkins Jr., el documento 'container' al cargarse tiene 500px. Al aplicar el cambio su hijo pasa a tener 400px y arrastra así el tamaño del padre a 400px.
Y allí se queda hasta que disparemos un 'onLoad' o un 'onResize' o cualquier otro evento que hayamos escrito para que vuelva a ejecutar un cambio.
Como las hojas de estilo monitorean el documento todo el tiempo, la salida digna sería cambiar las 'queries' por pseudoclases que se ejecuten una sola vez. Algo como 'html:load{}' no puede repetirse y solamente va a funcionar al cargarse el documento -todo el documento-, ajustaría los tamaños en ese punto y no debería volver a hacerlo hasta que se cargase la página de nuevo.
El redimensionado puede ser un problema, porque dura en el tiempo (el tiempo que tardamos en arrastrar un nodo) y durante ese lapso el navegador estaría recalculando y aplicando (o intentando aplicar) los formatos previstos, lo que exige mucho a la máquina, inutilmente. Supongo que la mejor solución para un 'body:resize{}' es que sea leído solamente al detener el arrastre por 100ms, y como después no se está arrastrando más, el loop se termina justo ahí.
Pero no tienen que volver a su estado original. Y ésa es la nueva "lógica" difícil de resolver.
O no, porque siempre se pueden hacer excepciones.
;-)
Yo en estos temas no los abordo desde "la máquina bajo la piel"
EliminarPara mi este tema de "las dependencias circulares" por un mal uso no es cuestión de ser solventado por el navegador en su implementación ni de los editores del documento Css que lo desallorra.
El ejemplo para mi es una típica situación que ocurre en otras muchas ocasiones. Pero repito, es una mala praxis de quien escribe el código. Nada más.
Un ejemplo similar es si alguien declara:
.elmt {
/*css muuuuchulo*/
}
.elmt:hover {
display: none;
}
Ahí tenemos un bonito intermitente y baile de todos los elementos siguientes en el DOM
Y a nadie se le ocurre pensar que sea un fallo de la pseudoclase :hover
Pero bueno, somos de las provincias del imperio y no hablamos su idioma xD
Totalmente de acuerdo. De hecho, hace unas semanas hice un par de ..."editores" que generaban código CSS prehecho, y ni quise ponerles validadores ni cartelitos de aviso de error, ni nada de eso; porque la idea es que quien se meta a trabajar con esto debe entender lo que hace, y no puede escribir un código incongruente. El que no entienda será porque es un paracaidista que cayó en las páginas web de metido, sin una preparación necesaria. Y ningún profesional o idóneo debe facilitarles el trabajo más allá de los límites del manual técnico.
EliminarQuizá una pequeña diferencia para estos casos de los que hablamos en el artículo es que si el navegador se tilda al inicio, solamente por cargar la página, no hay mucho qué hacer más que cerrarlo; y eso es un problema serio que nos puede aparecer en el apuro por escribir código, o lo podemos poner a propósito para joderle la vida al prójimo. Entonces se lo va a exponer como un bug y quedará como una afrenta para los desarrolladores del estándar, que no lo previeron.