CSS tiene un valor para el atributo de visualización llamado run-in. Es como esto:
h3 {
display: run-in;
}El punto es permitir que un encabezado se encuentre con el texto debajo de él, sin sacrificar la semántica o encontrarse con los problemas que podría tener al intentar forzarlo con otras técnicas de diseño.
Miremos más de cerca.
Pero por qué no __________?
Pero, ¿por qué no hacerlo flotar hacia la izquierda? Los encabezados de pozo suelen tener un tamaño de fuente más grande que el tipo de cuerpo. Entonces, si hace flotar el encabezado hacia la izquierda, es posible que capte más de una línea.
Pero, ¿por qué no convertirlo en un elemento en línea? Porque el siguiente texto podría estar (en realidad, es probable que esté) dentro de una etiqueta de párrafo. Las etiquetas de párrafo están a nivel de bloque y, por lo tanto, se dividirán en una nueva línea si siguen a un elemento en línea y no se logrará el efecto. Podría insertar la etiqueta
dentro de la etiqueta
, pero eso tiene preocupaciones semánticas y, lo que es más importante, preocupaciones de mantenimiento a largo plazo. ¿Y si este efecto pasa de moda?
Pero, ¿por qué no usar el bloque en línea? Mismo problema que el anterior. El efecto no se logrará a menos que meta el encabezado en el siguiente párrafo, lo cual es problemático.
¿Cómo funciona entonces?
Si un elemento de ejecución precede a un elemento de nivel de bloque, el elemento de ejecución se comportará estructuralmente como si se hubiera convertido en el primer elemento secundario en línea de los elementos de nivel de bloque.
Compatibilidad con navegador
¿No has oído hablar mucho de esto? Bueno, podría ser porque el soporte del navegador es un poco raro.
Se rumorea que Mozilla no es feliz con la especificación Firefox no lo admite en absoluto, incluidas las versiones beta 4.
La familia WebKit (Safari y Chrome) lo admiten, así como Opera e IE 8. Sin embargo, existen algunas diferencias en la forma en que estos navegadores manejan las cosas. Los informes dicen que las versiones anteriores de WebKit y Konqueror permitían que los elementos de ejecución se encontraran con elementos en línea sucesivos, lo cual es incorrecto.
¿Problemas en la especificación?
En mi propia lectura de la especificación, lo encuentro un poco confuso.
Si un cuadro de bloque hermano (que no flota y no está absolutamente posicionado) sigue al cuadro de entrada, el cuadro de entrada se convierte en el primer cuadro en línea del cuadro de bloque.
Eso tiene sentido y parece ser así como funciona, pero ¿”se convierte en el primer cuadro en línea” significa que el cuadro de ejecución debe convertirse en un descendiente del cuadro de bloque? En WebKit, el elemento de rodaje conserva su solidez.
Un run-in no puede ejecutarse en un bloque que ya comienza con un run-in o que en sí mismo es un run-in.
¿Significa eso que no puede haber dos encabezados, ambos de entrada, que coincidan con un párrafo a continuación? Así es como yo lo interpretaría, pero creo que la implementación de WebKit en la que ambos se incluyen tiene más sentido. Opera e IE 8 siguen la especificación en el sentido de que la primera ejecución se convierte en bloque y la segunda va en línea.
Entonces dice:
De lo contrario, el cuadro de ejecución se convierte en un cuadro de bloque.
De lo contrario es una gran palabra, pero las implementaciones han sido bastante buenas aquí. ¿Tres roces seguidos dentro de un padre sin otros hermanos? Todos van a bloquear. ¿Un encuentro intercalado entre dos elementos en línea? Va bloque. Avance > posición absoluta > bloque, el avance va a bloque. Alucinante, lo sé, pero los navegadores modernos actuales funcionan bien aquí.
Si el elemento de ejecución contiene algo a nivel de bloque, se convierte en nivel de bloque. Todos los navegadores parecen estar de acuerdo con eso.
Población
Aquí está mi propia página de demostración simple. También hay una demostración súper hardcore (que tiene más de 10 años).