Должен ли <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.