Repository navigation
style tag should be allowed in body #1605
Description
Activity
- added a commit that references this issue
on Jul 28, 2016 Thanks, this is nice.
(But I disagree with this being a “half functioning replacement for
<style scoped>”.)I'm just going to point out that the obvious case for a style tag, over using inline styles, would be table cells.
I don't think we should change this.
<link>is very different from<style>, in that the former causes a fetch. As such, in the original bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303, the arguments were about delaying this fetch. They're performance arguments, in other words.<style>in body has a number of negative consequences, such as the famous "flash of unstyled content" (FOUC) and the re-paint and re-layout required. There are good reasons for keeping all styling in the head. For<link>-based styling, it turns out there are even better reasons for allowing it in the body (although doing so would require careful performance measurement). But I have seen no evidence of that for<style>.I'd like to hear from @igrigorik, who initiated the push for
<link>in body.Reacted by Olivier Tassinari, Damian Adams and Joaquin Bravo ContrerasReacted by Sz., Boots Highland, Thomas Güttler, Mark Waterous, Nathaniel Sabanski, Ky Decker, DavidBeh and MayankAlso, just to be very clear: this entire issue is not about changing browser behavior. The spec already requires, and browsers already implement, processing for
<style>in body. It works, albeit with the negative effects I discussed above.This issue is entirely about what conformance checkers like https://checker.html5.org/ will do if you include
<style>in body. Will they tell you that's bad practice and disallowed by the spec's authoring requirements? Or will they let it happen silently?Reacted by Dan Black, Olivier Tassinari, Ted Whitehead, Joaquin Bravo Contreras, Taufiq Muhammadi and Oliver Williams- added a commit that references this issue
on Jul 29, 2016 <style>in body has a number of negative consequences, such as the famous "flash of unstyled content" (FOUC) and the re-paint and re-layout required. There are good reasons for keeping all styling in the head.I strongly agree that if in practice
<style>in body results in significant cases of things that are bad for end users—like FOUC and slower performance—then that should be a sufficient reason to continue to make it non-conforming. Because we want to be helping developers to avoid making authoring mistakes that cause actual bad user experience.That said, I wonder how we can assess how many such cases of FOUC and slowed performance the existing uses of
<style>in body in documents on the Web are causing for users.I added a
<style>-in-body use counter to statistics collected by the W3C HTML checker:https://validator.w3.org/nu/stats.html
I just now added it but the initial results indicate that about 14% of the documents it checks have
<style>in body. [Update 2017-02-07: The long-term data from the use counter indicates that about 17% of documents the HTML checker processes have<style>in body.]Some more well-known sites with
<style>in body that I’ve come across so far in the logs for the checker include www.amazon.com www.pinterest.com www.bing.com/search?q=foo www.ebay.com www.gettyimages.co.uk www.weightwatchers.com www.quora.com & www.google.de www.google.it www.google.pl www.google.co.in www.google.com.hk www.google.bg & other Google search sites.The HTML checker and legacy W3C validator have always reported an error for
<style>in body—for 20 years or whatever now—so if in spite of that we still have 14% of sites being run through the checker that are using<style>in body anyway, that means a lot of developers are just ignoring the error message and not considering it a mistake. So this might be a case where making something non-conforming is in practice not actually having much effect on preventing its use.But it would be good to look at more relatively widely-used sites and see what evidence can be found of FOUC or re-paint/re-layout affecting users of those sites.
In the end not matter what the numbers are, if it seems like keeping
<style>in body non-conforming is the right way to try to ensure the best user experience for users, then I support continuing to make it non-conforming.Reacted by Thomas Güttler and Nathaniel SabanskiReacted by Thomas Güttler and Nathaniel Sabanski@sideshowbarker I think the validators should give out a warning as a potential error and not as an actual error, that is the key difference here.
Just a fun link from stackoveflow, I like the top answer being "Doesn't matter"... http://stackoverflow.com/questions/4803518/why-can-t-style-tags-within-the-html-body-tag-validate-on-w3c
http://stackoverflow.com/questions/1303416/does-style-have-to-be-in-the-head-of-an-html-documentI think standards matter and should not be implemented in a way that promotes them to be ignored.
The w3c validator is seen as an authority and often means that if it says that something is not allowed then it must never be done, and some systems actually penalize you for not having it valid and I find that silly in the case of the
<style>tag in the body because it works reliably and people use it.If the flash is the only issue here, then the validator should warn about it, but not prohibit the usage...
Reacted by Nathan Phillip Brink and Ilya Streltsyn@sideshowbarker I think the validators should give out a warning as a potential error and not as an actual error, that is the key difference here.
My experience in dealing with issue reports from users of the validator is that many or most users don’t actually care about the difference between a validator message flagged as an error and one flagged as a warning. Regardless of what category the message is, they just want it to go away.
I find that silly in the case of the
<style>tag in the body because it works reliably and people use it… If the flash is the only issue here, then the validator should warn about it, but not prohibit the usageThere are a number of existing cases where we have made a particular markup case non-conforming in the spec because even though it can be made to work reliably, it also carries a high risk of being used wrongly and resulting in degraded user experience.
The rationale is to attempt to help prevent developer-authors from shooting themselves in the foot by unknowingly using something that ends up making the user experience of their content worse at least for some portion of users (whether it be users of older browsers, browsers on older devices, screen-reader users, users on networks with very limited bandwidth, etc.)
12 remaining items
Shouldn’t the spec reflect reality?
That's phrased kind of strangely. "reflecting reality" is usually a question about the spec reflecting the reality of browser implementations, in its implementation specifications. It's not a question about the spec sanctioning any bad markup, in its author-facing markup guidelines.
If we just specced any sufficiently-popular markup, we'd do lots of weird things, like speccing
<i>to mean "icon".So I don't think "reflecting reality" is relevant here.
If
<style>in body is as bad as you say, performance-wise, then why do top websites use it anyway? Do the benefits outweigh the disadvantages after all?That's a good question. You'd have to ask them to be sure, but we have to note that in general the top websites are not very good at performance. This leads to lots of railing against them on Twitter by certain devrel people, of course, which is a whole other situation. Often these websites choose to sacrifice performance and user experience for the sake of advertising revenue, or developer experience, or their CMS tooling... you'd have to ask each individual site to see why. In some cases they might have made a calculated business decision that other factors are more important than writing conformant documents. (How many of those websites also pass the other checks on https://checker.html5.org?)
Reacted by Paul and Oliver Williams- Perhaps we could soften the advice from a content-model-level restrictionto a "should not" explaining the pitfalls I agree with this statement, but as I said before, if the spec says that you must not do something and then looks the other way when people do it, then it's the spec at fault here. Let's create some scenarios: 1. Spec says that style in body is forbidden (yet allows to do the same thing with the same re-rendering consequences using other means as mentioned before) - lots of big websites don't comply with the spec - big websites or cms creators use it anyway because the benefits outweigh the drawbacks - evangelists or badly knowledgeable people call the big websites or cms creators stupid, the big websites / cms creators call the spec irrelevant as it works fine anyway. - lots of professionally made cms's or apps don't comply with the spec 2. Spec says that style in body should not be used in general, but it's ok overall. - lots of big websites don't comply with the spec - big websites or cms creators use it anyway because the benefits outweigh the drawbacks - evangelists or badly knowledgeable people call the big websites stupid, the big websites call the spec irrelevant as it works fine anyway. - most of the professionally made cms's or apps almost comply with the spec 3. Spec says that style in body is ok - lots of big websites don't comply with the spec - evangelists or badly knowledgeable people call the big websites stupid, the big websites call the spec irrelevant. - the spec is more consistent with itself and the browsers (think: post-page load style linking, and the browser support/history) - most of the professionally made cms's or apps comply with the spec Because of the above, imho the big websites argument is irrelevant. Don't forget that with ajax styles can be added to pages after the fact a lot more than before, meaning that the re-rendering issue is happening in many more cases which should be handled too to keep things consistent and organized. I personally think that style in body should be allowed with a warning for those that don't know that it causes a refresh, although in today's hardware the refresh is negligible.…On 25 February 2017 at 18:11, Domenic Denicola ***@***.***> wrote: Shouldn’t the spec reflect reality? That's phrased kind of strangely. "reflecting reality" is usually a question about the spec reflecting the reality of browser implementations, in its implementation specifications. It's not a question about the spec sanctioning any bad markup, in its author-facing markup guidelines. If we just specced any sufficiently-popular markup, we'd do lots of weird things, like speccing <i> to mean "icon". So I don't think "reflecting reality" is relevant here. If <style> in body is as bad as you say, performance-wise, then why do top websites use it anyway? Do the benefits outweigh the disadvantages after all? That's a good question. You'd have to ask them to be sure, but we have to note that in general the top websites are not very good at performance. This leads to lots of railing against them on Twitter by certain devrel people, of course, which is a whole other situation. Often these websites choose to sacrifice performance and user experience for the sake of advertising revenue, or developer experience, or their CMS tooling... you'd have to ask each individual site to see why. In some cases they might have made a calculated business decision that other factors are more important than writing conformant documents. (How many of those websites also pass the other checks on https://checker.html5.org?) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1605 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMN7xnSf09Yvel2wtM6T2HOMapmjToCwks5rgGDIgaJpZM4JXKpe> .
I agree with this statement, but as I said before, if the spec says that you must not do something and then looks the other way when people do it, then it's the spec at fault here.
I think we're just going to have to fundamentally disagree here.
Let's look at some of the other things the spec is "looking the other way" on, using the example of
www.amazon.com: https://checker.html5.org/?doc=https%3A%2F%2Famazon.comAs you can see, there are many many pieces of invalid HTML on popular sites. We're not going to say that all of them are valid, just because people do it.
I agree that if we allow link in the body then we should also allow style, especially as using style offers performance improvements over link, and according to w3c it is correct markup and and pretty much supported by every browser on the market.
If you are using a modular or component based approach, it seems reasonable to have a way of attaching any styles and also scripts.
@unilobo I think you may not have read the whole thread. This is not about browser support; and style creates performance problems over link, as attested to by several vendors per the above. See especially the two comments at #1605 (comment).
Hi @domenic, although I get your point, as you admit this has been implemented already by pretty much every browser and is a w3c recommendation. If I have modules or components that sit on my page, I would like to have a way to load any related required styles. It then makes sense to include these inline, as indeed w3c says is possible,
However because wcag objects to this practice it breaks w3c validation.
However as far as i know there is no alternative way of doing this, unless i use link which would cause an additional http request for each file. which would be more sub optimal.
I am open to your suggestion(s) of how best to do this, although I acknowledge putting all styles in the head is the preferred method, in my case that is not really an option unless I postprocess my styles into one file that again would be a suboptimal solution.
I know frameworks like Facebook's React basically inline there styles to make their components atomic. In my case I do not want to go down this route but I would like to componentise or decouple my modules that sit on the page. As WCAG has also objected to the adoption of the scoped attribute, web developers are left in limbo.
If you have another suggestion of how to implement this without using link, i would be keen to hear it?!
I agree that ideally styles should be in the head.
I guess my point is that in certain circumstances, you may want to load the styles inline, and it reasonable that there should be a solution that validates.
The frustration is that there does not appear to be a solution that validates.
Reacted by Martin Janecke, Ken Newman and Ted WhiteheadI kind of understand the position of WHATWG. They acknowledge that there are situations in practice where you need to put
<style>inside<body>, e.g. because of factual limitations of CMS that are not fixed yet and maybe never will. It works and that’s fine. But they also think that it is a bad practice, so they don't want to call it valid, so that people are discouraged from using it. It makes sense from a certain point of view.But this also means that some people like me are educating people that validation does not matter anymore, at least validation concerning WHATWG's HTML standard. It's not very hard to convice people, when they see that ignoring validation provides them the solutions they seek, that it works perfectly and you can show them that huge companies deeply involved in internet technologies like Google ignore the standard with their flagship products deliberately too.
Reacted by Sz., Wout, Nathan Phillip Brink and Cornelius DolMy takeaway is that under ideal circumstances (including a fast network connection and small page), with carefully-crafted markup, style-in-body can be made to work. But in the general case, it is error-prone and likely to lead to expensive restyling, relayout, and repainting. As such we should continue to recommend against it.
Can’t something be valid markup even if it’s a bad practice in certain circumstances? For example, tables are valid even though using them for layout is a bad practice.
Since validation tools like https://validator.w3.org can’t determine if a particular use of
<style>in<body>is a performance or security issue, I think a warning would be better than labeling it invalid. At the very least, adding a link to this thread after the invalidation warning would be nice.Anyway, completely agree that browser support and prevalence on popular sites isn’t a good enough reason to make something valid.
Appreciate all of your replies above, and your work for WHATWG 🙌
I would like to point out fire can be dangerous, so according to case why not to have style in the body, we we should never use fire. Although fire is dangerous, its also very useful.
There are very good cases for doing so. Most of the time people do it with styles that only affect a component that follows the newly added style.
Instead of treating us developers like children, please treat us like consenting adults. There is lighthouse and many tools to help one write better code.
If its really not allowed, then stop supporting it so some other solution can be developed. I think it will never be pulled because a huge portion of the web will break. So instead of pretending can we not make the spec follow what the html parser actually allows.
Reacted by Joe Watkins, Sergiu Cazac, Cornelius Dol, Matteo Canever, Ky Decker, pixel-kat, Ron Martinez, Chris Dennett and tryoxissSorry for continuing this discussion, but I’ve read through the thread, and one important question does not seem to have been answered yet: Do we have proof that
<style>in<body>significantly affects performance on a real website?Reacted by Martin Janecke, Will Skora, Ghaith Zamrik, Cornelius Dol, Danilo Parra Jr, roll, jjorissen52, Ky Decker, mangelozzi, pixel-kat and 3 moreBut in the general case, it is error-prone and likely to lead to expensive restyling, relayout, and repainting.
@domenic If style-in-body would be limited to the upcoming CSS
@scoperule, wouldn’t the performance issues disappear in practice?If so, could the HTML standard get such a rule (style in body allowed if it contains only
@scoperules) or would it need a hint such as ascopedattribute?Reacted by Matt KantorReacted by Oliver WilliamsI also wonder about whether
@scopechanges the situation?@scopeis location dependent so it might be useful to place a<style>tag within the<body>when working with it (although there are also other ways to work with@scope)?The CSS Cascading and Inheritance Level 6 spec itself uses the following example code:
<div> <style> @scope { p { color: red; } } </style> <p>this is red</p> </div> <p>not red</p>
Reacted by Matt Kantor, Ian and Hans BrendeReacted by Mihail Malo and sb3nder@domenic I agree with the above: with
@scopehaving special semantics based on its parent element (implying that it must be a descendant of the<body>for those semantics to matter), it really makes no sense for the spec to continue to say that<style>must not be in the<body>.Should this issue not be re-opened in light of the
@scoperule, which as of March 2026 is supported by all major browsers?Could someone file a new issue for that specific suggestion? That would make it easier to consider than requiring everyone to wade through this entire discussion.
Reacted by Oliver Williams
This is a follow up on the issue on style scoped
We allow
<link rel=stylesheet>in the body, we should allow<style>tags as well.It's already supported in all the browsers and will be in the future, what is the benefit in making it invalid markup if it's often the best or even only solution to a problem and is widely used on many websites and CMS's?
This would also serve as a half functioning replacement for
<style scoped>where you can work around the scoping issue using custom classes.Also, I've seen some people ask, why not use inline styles? like
<span style="color:red"></span>?Well, you can't apply inline styles for hover states or pseudo elements, it also means a lot of repeated css most of the time.
Is it good to use it in the body instead of the head? No if you can help it, yes if you can't.
Edit:
Also many people like the convenience of doing ajax requests that come with html and their own style tags.