(Dado que estamos aquí en SE.SX, un enfoque más estratégico puede ser un aumento valioso de las consideraciones técnicas habituales).
[preámbulo] La especificación HTML5 es un objetivo en constante movimiento, y tienen una política de seguimiento de la práctica común establecida. Obtuvieron características obsoletas y resucitadas en el pasado, cambiaron el significado de los demás, cambiaron el enfoque de las recomendaciones metódicas, etc. No está escrito para toda la eternidad con toda la sabiduría de la humanidad disponible de una vez. La especificación no es una fuente sagrada de la verdad. Es natural que a veces los navegadores tengan razón. [/preámbulo]
La situación de OP es abrumadoramente común y válida.
Tiene un CMS, con su tema diseñado e instalado, todo el CSS se cargó correctamente desde HEAD, luego ahí está, el editor de páginas, con un cuadro WYSIWYG de moda que puede (¡gracias a Dios!) Cambiar al "modo fuente" y escriba (pegue) en marcado HTML (previamente creado en otro lugar, con herramientas más adecuadas). Afortunadamente, incluso puede incluir STYLEetiquetas (tal vez debido a una omisión fortuita en un filtro de etiquetas) ... El día se salva, de un montón de trabajo gruñido repetitivo que destruye el alma. Pero aún no tiene medios, en absoluto, para interferir con el elemento HEAD del sistema desde un escenario de edición de página.
¿Debería eso evitar que use su CSS de manera directa con sus fragmentos HTML, solo porque la especificación lo dice?
O bien, tiene una aplicación AJAX de una sola página.
Se ejecuta sin recarga durante una sesión larga, y hay contenido sindicado proveniente de varias fuentes aleatorias, todas con un estilo arbitrario e independiente. Requerir que se conviertan primero para usar solo STYLEatributos en línea en lugar de solo venir con un STYLEelemento incrustado sería absurdo.
Además: puede a) incrustar cualquier CSS en cualquier lugar del BODY, a través de STYLEatributos, por lo que CSS es "teóricamente" legal de todos modos; yb) ya puede hacer lo que quiera con casi cualquier estilo, siempre que lo desee (y más) de Javascript, por lo que CSS también es posible usar de manera inadecuada patológicamente. Y ninguno de nosotros objetaría esas características. Tampoco el W3C.
Entonces, ¿qué es exactamente tan malo acerca de los STYLEelementos en el BODY? ¿Cuáles son esas implicaciones adversas adicionales que agregaría a nuestro amplio arsenal de abuso a las construcciones HTML? ¿Más bajo rendimiento? Probablemente. Algunas veces.
¿Es esa una razón válida para abolir esta práctica increíblemente útil, respaldada por cada navegador por una razón? ¡No en un millón de millas!
No somos idiotas Bueno, no todos, o no siempre ...;) Las técnicas con el riesgo de un bajo rendimiento podrían simplemente documentarse , en lugar de simplemente prohibirse. Solíamos tener applets de Java en los primeros días de la web, y sobrevivimos. Los autos pueden ser mal utilizados, causando miseria, incluso los alimentos pueden usarse de maneras perturbadoras e ineficientes, y los conductores que pueden comer pueden ser, en promedio, incluso más estúpidos que el diseñador web promedio. Además, querido W3C, no hay de qué preocuparse: los furiosos rebaños de manipuladores de HTML que tienen sus piernas disparadas con STYLEelementos en el BODYtodavía no pueden perseguir al W3C y vengarse. No saben la dirección. Y no tienen piernas.
Entonces, por favor: ¡haz que se escuche tu voz por STYLEser legal BODY! Citar el texto de manera obediente, pero no proporcionar una alternativa viable que sea mejor que la situación actual no ayuda. En realidad, es una amenaza para esta técnica de solución de último recurso.
Recuerde: la especificación HTML5 se llama recomendación .