<style> entry in index of elements has not been updated to reflect removal of scoped attribute

[ExplodingCabbage]

This is an exact duplicate of an bug I just reported over on WhatWG's spec; details at whatwg/html#1521.

The non-normative index of elements currently has flow* under "Categories" and "Parents". Unless I'm missing something, both of these have been incorrect since @domenic removed the scoped attribute in #1226. I guess that he missed this because he implemented the removal by reverting 29cf39d and related commits, but the elements index was not added until 3 years after scoped was added (778068c) and so just looking at the commits that added scoped could never reveal this bug.

The current draft of the W3C's HTML 5.2 spec is similarly affected, despite them having removed scoped independently.

In the next few minutes I'm going to push up a PR to fix this on this repo, open an issue about this on the W3C repo linking to this one, and open a duplicate PR on their repo.

_{Aside: the duplication of labour y'all have going on between the two specs is a tragic waste of good people's time and makes me sad.}

Will push a PR to fix it as soon as I've read the contributing guidelines.

[chaals]

Since ancient times (before your sun burned hot and your race was born…) a feature of CSS was that it could be included as flow content in an HTML document, but parsed and rendered as a stylesheet. In modern times that is known as DRY, often presented as a better idea than "hidden metadata".

The current rendering chapter includes a rule style { display:none } which makes sense both for head style {} and style[scoped] but which makes using style that is flow content behave strangely.

PR #517 suggested disallowing style to be flow content, but that would effectively outlaw this ancient technique, which still works reasonably widely but slightly strangely.

It makes more sense to me that we continue to allow this, make body style {display: block} and look into why browsers are dropping some rules apparently unexpectedly but consistently and somewhat interoperably across diffferent rendering engines.

So, what to do?

[ExplodingCabbage]

This seems silly.

Firstly, even if your proposed change to the normative spec were a good idea and likely to happen, that doesn't seem like a reason to reject the change to the non-normative element index that I proposed in #517. The index is there to provide a quick summary of information from the normative part of the spec. Deliberately choosing to have its content remain incorrect in the hope that in future the normative parts of the spec will be changed to match the erroneous element index is unhelpful to anybody seeking to use the element index to understand the current spec.

Secondly, your proposed change to the normative parts of the spec is a patently bad idea. Per your own investigation, the current behaviour of most browsers when encountering a style element in the body is to apply the rules just as if the style had appeared in the head, but not to render the style element as content (unless it is explicitly made display: block or some other non-none value). Website authors have almost certainly depended upon this behaviour despite it having been a spec violation since HTML 3's release in 1997, if not earlier. Making all of those bits of CSS render as text on the page by default, a behaviour that has almost no real use case, would break lots of old pages and provide no real benefit to anybody.

If style elements in the body really are widely supported at present (and they probably are), I guess it could conceivably be useful to modify the normative parts of the spec to acknowledge the current reality, either by changing the content model of body to allow for style elements or by stating somewhere (maybe in the section of the parsing algorithm?) that user agents are required to apply styles contained in a style element in the body despite the existence of such an element being a spec violation. But making body style be display: block by default is insane.

[adanilo]

@ExplodingCabbage makes a good point, style in body should definitely not become display : block. This is related to #544 so a PR or suggested text would be welcome.

[chaals]

Agreed that we shouldn't make style be display: block. Someone who has a use case for that can do it by themselves easily enough.

Browsers seem to handle <style> in the body, and at least Google.com actually uses this. IMHO we should make sure that the spec continues to support that, unless there is a strong reason to outlaw it...

[ExplodingCabbage]

Agreed that we shouldn't make style be display: block. Someone who has a use case for that can do it by themselves easily enough.

👍

IMHO we should make sure that the spec continues to support that

The spec has never supported this. Once again I'll point out that the only suggestion that this is allowed was in the index that I proposed changing in #517, which is non-normative.

It seems like a good idea to me (for the reasons you've given) to change the spec to support <style> in the body, but that's not a continuation of support, its changing the spec to say something that it has never said in any version that has ever existed. I've pointed this out repeatedly and yet you're continuing to talk as though the spec currently permits <style> in the body just because a non-normative index says so.

[chaals]

I think the spec is ambiguous, which probably explains why we differ on whether it is supported. The alternative, and equally plausible explanation, is that I just didn't read something carefully enough.

HTML 5.x says, apparently normatively, that

Metadata is sometimes flow content.
-3.4.2 kinds of content

But style in body doesn't pass the validator.

Anyway, I guess the sensible thing is to find all the places where this is discussed and make them all clarify that <style> is valid in the body, so I'll take that as the assigned task from this issue unless someone else wants to do it.

[AndySky21]

I'm just afraid how authors will perceive the difference between this, and the scoped attribute case.
It could be difficult to accept that a style tag inside an element has effect not only in the element subtree, but throughout the document, above and below the element itself.
Possible subjects for revision:

• <link rel="stylesheet"> being included in body, too
• style element and tag omission: UAs behaviour.

[chaals]

I'm just afraid how authors will perceive the difference between this, and the scoped attribute case.
It could be difficult to accept that a style tag inside an element has effect not only in the element subtree, but throughout the document, above and below the element itself.

Except that this has worked in browsers "forever". And seems not to have broken the web. So authors seem either used to the idea, or to learn it quickly.

After all, <script> behaves like that too.

• <link rel="stylesheet"> being included in body, too

I'd rather not go there, unless there is some pressing reason.

[travisleithead]

Also note that if <style> is restricted to the <head> then shadow dom styling using <style> elements (not in the head) won't work... (and that's all we've got so far...)

[chaals]

Closing this in favour of #544 which seems to correctly summarise what we need to do: make style conforming in body.