Должен ли <STYLE> быть в <HEAD> документа HTML?


136

Строго говоря, styleтеги должны быть внутри headHTML-документа? Стандарт 4.01 подразумевает это, но это прямо не указано:

Элемент STYLE позволяет авторам размещать правила таблицы стилей в заголовке документа. HTML допускает любое количество элементов STYLE в разделе HEAD документа.

Я говорю «строго говоря», потому что у меня есть приложение, которое помещает элементы стиля в тело, и все браузеры, с которыми я тестировал, похоже, используют элементы стиля. Мне просто интересно, если это на самом деле законно.


1
Если вы сомневаетесь, валидатор разметки W3C всегда помогает :) http://validator.w3.org/
Lazlo

Единственным исключением из правила 'put <style> in <head>' является html email, так как многие службы веб-почты просто удаляют любые элементы head, что означает, что ваши стили исчезли.
user132837

1
Спецификации требуют поддержки браузеров styleв body, так что это достаточно хорошо для меня, независимо от того, что подразумевается в разделах руководства автора.
WraithKenny

Ответы:


104

styleпредполагается включить только в headдокумент.

Кроме того, точки проверки, один нюанс , который может заинтересовать вас при использовании styleна bodyэто вспышка контента без стилей . Браузер получит элементы, которые будут стилизованы после их отображения, заставляя их смещаться по размеру / форме / шрифту и / или мерцанию. Это вообще признак плохого мастерства. Как правило, вы можете сойти с рук, положив styleкуда угодно, но старайтесь избегать этого, когда это возможно.

HTML 5 ввел scopedатрибут, который позволял styleвключать теги повсюду в теле, но затем они снова его удаляли.


6
На сегодняшний день кажется, что только Firefox поддерживает этот scopedатрибут, см. Caniuse.com/#feat=style-scoped .
Хайме Хаблутцель

2
Связанная статья исчезла в ссылке до конца, так что вот последняя доступная заархивированная версия: web.archive.org/web/20150525042412/http://bluerobot.com/web/css/…
Захари Мюррей

@ZacharyMurray спасибо за головы! Я обновил ссылку в теле на веб архивную.
Эстебан Кюбер

1
Спецификация требует соответствующих браузеров для поддержки styleтегов, bodyпоэтому, несмотря на авторскую часть спецификации, я считаю стили тела корректными. github.com/whatwg/html/issues/1605#issuecomment-235961103
WraithKenny

19

Короткий ответ

  • Согласно текущей спецификации, да, styleэлементы всегда должны быть в head. Нет никаких исключений (кроме styleэлемента внутри templateэлемента , если вы хотите это посчитать).

  • Это не всегда имело место исторически. Если вы заботитесь о деталях спецификации и ее истории, продолжайте читать.

  • Независимо от того , что говорит спецификация, используя styleэлементы в body делает более-менее работу во всех основных браузерах. Однако это считается плохой практикой как из-за того, что оно нарушает спецификацию, так и из-за того, что может привести к нежелательным последствиям, таким как ухудшение производительности рендеринга или «вспышка нестандартного содержимого».


Спек история

styleэлементы не существовали в HTML 2 . Они были введены в HTML 3.0, где они были включены в список элементов, которые могут быть включены в элемент Head , но не включены в список элементов, которые могут присутствовать в элементе Body . Таким образом, в тот момент, когда элемент был впервые обнаружен, он мог быть включен только в head.

Это сохранялось (хотя и выражалось в разных формулировках) до HTML 5, в котором scopedдля styleэлементов был введен атрибут (поскольку он был удален) . Этот атрибут, когда он присутствует, предназначался для того, чтобы позволить styleэлементу быть размещенным внутри элемента в теле, чтобы стилизовать только потомков этого элемента. Однако эта функция никогда не была доступна ни одному реальному браузеру (по крайней мере, без необходимости включения через флаг разработчика) и была удалена из спецификаций W3C и WhatWG «из-за отсутствия интереса со стороны разработчика» . После этого styleэлементы были разрешены только в тех контекстах, которые допускают содержание метаданных, то есть только заголовок. Таким образом, мы вернулись к тем же правилам, что и до HTML 5.

Однако из-за ошибки, допущенной обеими организациями спецификаций, ненормативный индекс элементов, включенный в качестве приложения в обе спецификации, не был должным образом обновлен для отражения удаления scoped, что делает его несовместимым с нормативной спецификацией. Я указал на это как на WhatWG, так и на W3C , и при этом невольно включил события движения, которые вызвали расхождение двух спецификаций.

Решение WhatWG для несоответствия между нормативной спецификацией и ненормативным индексом состояло в том, чтобы принять мой патч, исправляющий ненормативный индекс.

W3C, с другой стороны, отклонил мой эквивалентный патч в пользу того, чтобы вместо этого обновить нормативную спецификацию, чтобы разрешить использование styleэлементов в body, при этом отметив это примечанием, что это может вызвать проблемы и должно быть сделано "с осторожностью". Причиной этого изменения было приведение спецификации в соответствие с реальным поведением браузера.

Таким образом, начиная с марта 2017 года, официальный ответ на этот вопрос зависел от того, какую организацию по стандартам вы выбрали для прослушивания. Если вы указали в спецификации WhatWG (как правило, более уважаемой), то styleэлемент не был разрешен в body. Если вы указали в спецификации W3C, то это было разрешено, но не рекомендуется.

Это глупое положение вещей было положено конец (возможно, как и многие другие подобные несоответствия) мирному договору от W3C и WhatWG , заключенному в апреле 2019 года , который согласился с тем, что спецификация WhatWG станет единственно верным живым стандартом HTML, а W3C просто выпустит снимки из него в виде номера. HTML-спецификации вместо параллельной разработки конкурирующей спецификации. Таким образом, переход с 2017 года на форк W3C, который позволял styleэлементам в, bodyбольше не является частью текущей спецификации; это просто любопытство истории.

Итак, сегодня нам нужно только обратиться к спецификации WhatWG, чтобы определить, что официально разрешено. Он имеет это сказать:

4.2.6. styleэлемент

Категории :

Содержание метаданных .

Контексты, в которых этот элемент может быть использован :

Где ожидается содержание метаданных .
В <noscript>элементе, который является дочерним <head>элементом элемента.

CTRL-Fing в одностраничной спецификации показывает, что единственным элементом, модель содержимого которого включает в себя содержимое метаданных, является headэлемент.

Ненормативный индекс элементов, о которых я упоминал ранее, также подтверждает, что единственными допустимыми родителями для styleэлемента являются a headили noscriptelement.


18

Хотя другие ответы верны, я удивлен, что никто не объяснил, где стандарты запрещают стили за пределами head.

Это на самом деле в разделе об headэлементе (и в DTD ):

<!-- %head.misc; defined earlier on as "SCRIPT|STYLE|META|LINK|OBJECT" -->
<!ENTITY % head.content "TITLE & BASE?">

<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head -->

Да, я знаю. DTD трудно читать.

Это единственное место, где STYLEвстречается элемент, поэтому неявно он недопустим в другом месте.


6
Я так растерялся.
dav_i

1
Теперь следует использовать HTML5, в котором IIRC не имеет DTD. То, что говорит одна спецификация HTML5, это то, что есть или нет.
Ян Кью Пеблик,

14

Они не должны выходить за пределы головы, но они все равно работают; хотя вы можете заметить быстрое мерцание. Сайт не должен проверяться тегом style вне головы, но имеет ли это значение? Кроме того, теги ссылок работают и вне головы, хотя и не должны.


5
Сказать «они работают» немного сложно. В лучшем случае вы можете сказать, что большинство современных браузеров по-прежнему будут отображать стили, но в этой ошибке нет ничего, что просто «работает». Это не могло работать в любой будущей версии любого браузера, и они не будут делать ничего плохого.
Чак

6
IMO, стили оказываются = работает; ничего сложного. последнее предложение необходимо переписать; это не имеет никакого смысла. я упомянул, что это «неправильно», когда я сказал, что это не будет подтверждено, поэтому я не должен понимать, что вы имели в виду под этим предложением.
geowa4

Проблема заключается в том, что даже если они будут оформлены, вы будете иметь некоторое мерцание на содержание , если эти styles удар в.
Эстебан KUBER

2
если тег стиля не будет первым в теле
geowa4

Не пытайтесь делать это дома.
TechNyquist

3

Как и в других ответах говорится, что на самом деле не должно быть там. Тем не менее, это не будет проверять. Это может иметь или не иметь значения в этом случае, но имейте в виду, что рендеринг html полностью зависит от браузеров. Из того, что я знаю, все используемые сегодня браузеры будут поддерживать его вне головы, но вы не можете гарантировать это для будущих браузеров и будущих выпусков браузеров.

Придерживайтесь стандарта, и вы в большей безопасности. Насколько безопаснее спорить.


3

HTML5.2 Рекомендация W3C, 14 декабря 2017 (не ранее проект упомянутого выше) теперь говорит , что вы можете включить <style>.

«В теле, где ожидается поток содержимого». (раздел 4.2.6)


Хотя в настоящее время, W3C официально государство , что WHATWG спецификации Obsoletes все предыдущие спецификации, и WHATWG спецификации не позволяет styleв body, поэтому мы вернемся к этому быть однозначно запрещено. Смотрите мой ответ, если вас интересует извилистый путь, по которому мы сюда попали.
Марк Амери

2

Тег стиля где угодно, но внутри <head>, не будет проверяться правилами W3C.


2

Согласно этому сайту, HTML5.1 (в черновике) и WHATWG позволяют <style>помещать тег в тело:

http://www.html.am/tags/html-style-tag.cfm

Похоже, что это поддерживается браузерами довольно долгое время. Согласно этому ответу StackOverflow, Firefox 3+, IE6 +, Safari 2+ и Chrome 12+ поддерживают его:

https://stackoverflow.com/a/10989663/297793



-1

Вы можете использовать тег style внутри раздела head или body, а также вне тега html (внешний html не рекомендуется). В проектах реального времени много раз вы можете видеть, что они используют тег style вне html-тега.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.