Imagine algo como estas pestañas de Transformer como un widget en una columna fluida en un diseño receptivo. Dependiendo del ancho de la ventana del navegador, tal vez este diseño tenga 4, 2 o 1 columna de ancho. Cuando pasa de 4 a 2, es probable que la columna se ensanche temporalmente de lo que era, aunque la pantalla sea más estrecha. Sería preferible al escribir la lógica de consulta de medios para esas pestañas considerar cuánto espacio tiene disponible el widget en lugar de toda la ventana, que podría no estar relacionada en absoluto, especialmente cuando se reutiliza este widget.
Jonathan Neal tiene algunas ideas sobre cómo podría funcionar esto, incluidas las partes complicadas en las que quizás no haya pensado, como cómo el contenido de un widget podría afectar su contenedor principal y causar un bucle infinito.
El sitio de Jonathan está fuera de línea ahora, así que voy a copiar el contenido de esta publicación de blog aquí para la posteridad.
Esta publicación fue inspirada por mi amigo y co-creador de normalize.css, Nicolas Gallagher.
Necesitamos consultas de medios CSS nativas a nivel de elemento/componente/widget, no solo en la ventana gráfica. Hazlo así, internetz.— @necolas
Entonces, sin fanfarria, quiero compartir mis pensamientos sobre las consultas de los medios de elementos y luego abrirlo para discusión en los comentarios.
Pensamiento #1: ¿Cuál sería el margen de beneficio?
Usaríamos una pseudoclase, porque estamos apuntando al estado de un elemento. Algunos ejemplos de pseudoclases son :hover, :focus, y :checked.
No usaríamos un pseudo elemento, ya que no apuntamos a un elemento de sombra dentro del elemento. Algunos ejemplos de pseudo elementos son ::first-letter, ::before, y ::after. No se deje engañar por IE7 y 8, :before no es la sintaxis correcta. De hecho, si no es compatible con IE7 y 8, debe comenzar a usar la sintaxis correcta para liberarse de esta inconsistencia heredada.
[The] :: La notación es introducida por el documento actual para establecer una discriminación entre pseudo-clases y pseudo-elementos. Para compatibilidad con las hojas de estilo existentes, las aplicaciones de usuario también deben aceptar la notación anterior de un punto para los pseudoelementos introducidos en los niveles 1 y 2 de CSS (es decir, :primera línea, :primera letra, :antes y :después).— Borrador de trabajo del W3C de selectores
Nombraríamos la pseudo clase media después de su predecesor, usando paréntesis para envolver las consultas, similar a :not y :contains.
.widget:media(max-width: 30em) {color: tomato;}Múltiples consultas requerirían múltiples paréntesis.
.widget:media((max-width: 30em) and (min-width: 30em)) {color: bisque;}Pensamiento #2: Cómo funcionaría Ems
El tamaño de un em sería relativo al tamaño de fuente del elemento, tal como funciona con los valores CSS existentes. El rem unit se utilizaría para determinar el tamaño de fuente del documento.
html {font-size: 16px;}
.parent {font-size: 12px;}
.parent > *:media(max-width: 30em) {/* applied up to 360px */}
.parent > *:media(max-width: 30rem) {/* applied up to 480px */}Esto plantea un problema con las consultas de medios existentes. Actualmente, cuando definimos el tamaño de fuente de html como 12px, hace @media (max-width: 30em) evaluar a 360px o 480px? Si creemos que @media “vive” de la html elemento, entonces la respuesta es 360px. Por otro lado, si creemos que @media “vive” en algún éter más allá html, entonces la respuesta es 480px. Lamentablemente, la mayoría de los navegadores están de acuerdo con la interpretación posterior. Por lo tanto, como un beneficio adicional a esta discusión de consultas de medios de elementos, debemos especificar que el tamaño de un em en un @media la consulta debe ser relativa al tamaño de fuente del html elemento.
Pensamiento #3: Cómo se manejarían los bucles infinitos
Los bucles infinitos se congelarían en el bloque infractor. Si bien es mucho más probable que ocurran bucles infinitos con las consultas de medios de elementos, este problema ha existido desde :hover. Por lo tanto, una especificación clara sería doblemente útil.
.widget {color: salmon;width: 100%;}
.widget:media(max-width: 320px) {color: whitesmoke;width: 321px;}
/* the infinite loop is stopped, .widget is whitesmoke with a width of 321px */Del mismo modo, esto solucionaría los problemas clásicos de bucles de CSS.
.widget {color: plum;}
.widget:hover {color: orange;display: none;}
/* the infinite loop is stopped, .widget is not displayed, but is otherwise orange */Preguntas y respuestas
En caso de que las consultas de medios de elementos puedan dirigirse a la página, como .widget:media(page-max-width: 30em) y .widget:media(device-max-width: 30em)?
Sí, aprovechar la sintaxis como esta realmente podría mejorar la legibilidad de las hojas de estilo. Puedo imaginar a muchos desarrolladores prefiriendo este tipo de :media consultas de pseudoclase sobre tradicional @media consultas De hecho, muchos desarrolladores ya están tratando de hacer cosas como esta anidando en SASS.
Si el número de consultas en el :media la pseudo clase se agrega al peso del selector, de modo que .widget:media((min-width: 2em) and (max-width: 30em)) se gana .widget:media(max-width: 30em)?
No porque @media las consultas no son selectores y por lo tanto no tienen ningún peso. A diferencia de, *:not(#foo) tiene mas peso que *:not(.foo) porque la pseudo clase está evaluando selectores, y los selectores siempre agregan peso. Por otro lado, @media (min-width: 5em) and (max-width: 500em) no tiene mas peso que @media (max-width: 500em).
inspiraciones
El tuit de Necolas, Chris Coyier sobre CSS Specificity, MediaClass (polyfills element media queries) y una excelente conversación con Ian Hickson, quien me enseñó la diferencia entre : y ::.