(Dato che siamo qui alla SE.SX, un approccio più strategico potrebbe essere un valido ampliamento alle solite considerazioni tecniche.)
[preambolo] Le specifiche HTML5 sono un obiettivo in continua evoluzione e hanno una politica di follow-up sulla pratica comune consolidata. Hanno caratteristiche obsolete e risuscitate in passato, hanno cambiato il significato degli altri, spostato l'attenzione su raccomandazioni metodiche, ecc. Non è scritto per l'eternità con tutta la saggezza dell'umanità disponibile tutto in una volta. Le specifiche non sono una sacra fonte di verità. È naturale che a volte i browser abbiano ragione. [/ Preambolo]
La situazione dell'OP è in modo schiacciante comune e valido.
Hai un CMS, con il suo tema progettato e installato, tutti i CSS caricati correttamente da HEAD, poi ci sei, l'editor di pagine, lasciato con una scatola WYSIWYG alla moda che puoi (grazie a Dio!) passare a "source" mode "e digita (incolla) nel markup HTML (precedentemente creato altrove, con strumenti più adatti). Fortunatamente puoi persino includere% tag diSTYLE (forse a causa di un'omissione fortuita in un filtro di tag) ... Il giorno viene salvato, da un sacco di lavoro ripetitivo e distruttivo che distrugge l'anima. Ma non hai ancora alcun mezzo per interferire con l'elemento HEAD del sistema da uno scenario di modifica della pagina.
Dovresti derubarti dall'usare il tuo CSS in modo semplice con i tuoi frammenti HTML, solo perché la specifica lo dice?
Oppure, hai un'applicazione AJAX a pagina singola.
Funziona senza ricarica per una lunga sessione, e ci sono contenuti in sindacato provenienti da varie fonti casuali, tutti in stile arbitrario e indipendente. Richiedere che vengano convertiti per la prima volta in modo che utilizzino solo gli attributi inline STYLE invece di venire solo con un elemento STYLE incorporato sarebbe assurdo.
Inoltre: puoi a) incorporare già qualsiasi CSS in BODY , tramite attributi STYLE , quindi il CSS è "teoricamente" legale in ogni caso; e b) puoi già fare qualsiasi cosa tu voglia con qualsiasi stile, ogni volta che vuoi (e più) da Javascript, così anche i CSS possono abusare in modi patologicamente non performanti. E nessuno di noi obietterà mai quelle caratteristiche. Né fa il W3C.
Quindi, cos'è esattamente così male su STYLE elementi in BODY ? Quali sono queste implicazioni extra negative che aggiungerebbero al nostro ampio arsenale di abusi nei costrutti HTML? Più prestazioni scadenti? Probabilmente. A volte.
È una valida ragione per abolire questa pratica incredibilmente utile, supportata da ogni browser per una ragione? Non in un milione di miglia!
Non siamo idioti. Beh, non tutto, o non sempre ...;) Le tecniche con il rischio di scarse prestazioni potrebbero semplicemente essere documentate , piuttosto che proibite. Avevamo le applet Java nei primi giorni del web e siamo sopravvissuti. Le automobili possono essere utilizzate in modo improprio, causando sofferenza, persino il cibo può essere utilizzato in modi inefficienti e inquietanti, ei conducenti che possono mangiare possono essere, in media, ancora più stupidi rispetto al web designer medio. Inoltre, caro W3C, non c'è bisogno di preoccuparsi: le mandrie arrabbiate di tinker HTML che hanno le gambe abbattute con STYLE elementi nella BODY non possono ancora andare dopo il W3C e vendicarsi. Non conoscono l'indirizzo. E non hanno gambe.
Quindi, per favore: fai sentire la tua voce per STYLE diventando legale in BODY ! Citare obbedientemente il testo, ma non fornire una valida alternativa che sia migliore della situazione attuale non è di alcun aiuto. In realtà è una minaccia per questa tecnica di soluzione alternativa.
Ricorda: la specifica HTML5 è chiamata raccomandazione .