Коротка відповідь
Відповідно до поточної специфікації, так, styleелементи завжди повинні бути в head. Винятків немає (за винятком styleелемента всередині templateелемента , якщо ви хочете це порахувати).
Це не завжди було так історично. Якщо ви дбаєте про деталі специфікації та її історію, продовжуйте читати.
Незалежно від того , що говорить специфікація, використовуючи styleелементи в body робить більш-менш роботу у всіх основних браузерах. Однак це вважається поганою практикою як через те, що воно порушує специфікацію, так і тому, що це може спричинити небажані наслідки, такі як погіршення продуктивності рендерингу або "спалах невмілого контенту".
Історія спец
styleелементів не існувало в HTML 2 . Вони були введені в HTML 3.0, де вони були включені до списку елементів, які могли б бути включені до головного елемента , але не були включені до списку елементів, які можуть бути присутніми в елементі тіла . Таким чином, в момент, коли елемент був вперше прорисований, він міг бути включений лише до head.
Це залишалося так (хоч і виражалося з використанням різних формулювань) до HTML 5, який ввів scopedатрибут (з моменту вилучення) для styleелементів. Цей атрибут, якщо він присутній, мав на меті дати можливість styleелементу розміщуватись в елементі в тілі, щоб стилізувати лише його нащадків. Однак ця функція ніколи не переходила в будь-який реальний веб-переглядач (принаймні, не вимагаючи включення через прапор розробника), і була видалена як із специфікацій W3C, так і з WhatWG, "через відсутність інтересу до програми" . Після цього styleелементи були дозволені лише в контекстах, які дозволяють вміст метаданих, який є лише заголовком. Таким чином, ми повернулися до тих же правил, що й до HTML 5.
Однак через помилку, допущену обома спецорганізаціями, ненормативний покажчик елементів, включений як додаток до обох специфікацій, не був належним чином оновлений для відображення видалення scoped, що робить його невідповідним нормативним специфікаціям. Я вказав на це і на WhatWG, і на W3C , і тим самим мимоволі запускав події, що призвели до розбіжності двох специфікацій.
Рішення WhatWG щодо невідповідності між нормативним специфікацією та ненормативним індексом полягало в тому, щоб прийняти мій виправлення, виправляючи ненормативний індекс.
W3C, з іншого боку, відхилив мій еквівалентний патч на користь замість того, щоб оновити нормативну специфікацію, щоб дозволити використання styleелементів у програмі body, одночасно вказуючи це на зауваження, що це може спричинити проблеми і слід робити "обережно". Причина цієї зміни полягала в тому, щоб примірник узгоджувався з поведінкою в реальному житті.
Таким чином, з березня 2017 року випадок офіційної відповіді на це питання залежав від того, яку організацію зі стандартів ви обрали для прослуховування. Якщо ви перерахували до (загалом більш поважних) специфікацій WhatWG, то styleелемент не був дозволений у body. Якщо ви перерахували специфікацію W3C, це було дозволено, але не рекомендується.
Цей дурний стан речей було закінчено (можливо, як і багато інших подібних невідповідностей) мирним договором у квітні 2019 року між W3C та WhatWG , який погодився, що специфікація WhatWG стане єдиним справжнім живим стандартом HTML, і W3C просто випустить знімки з нього як пронумеровані. Специфікації HTML замість того, щоб паралельно розробляти конкуруючу специфікацію. Таким чином, зміна з 2017 року на вилку W3C, яка дозволила styleелементам у body, більше не є частиною жодної поточної специфікації; це просто цікавість історії.
Отже, сьогодні нам потрібно лише звернутися до специфікації WhatWG, щоб визначити, що дозволено офіційно. Це має сказати:
4.2.6. styleелемент
Вміст метаданих .
Там, де очікується вміст метаданих .
У <noscript>елементі, який є дочірньою частиною <head>елемента.
CTRL-Fing через односторінкову специфікацію виявляє, що єдиним елементом, модель вмісту якого містить вміст метаданих, є headелемент.
Ненормативний індекс елементів, про який я згадував фіксуючи раніше, також підтверджує, що єдиними допустимими батьками для styleелемента є headабо noscriptелемент.