In below code i placed internal style sheet with in body tag, instead of having in head. For Single-Page-Application I am considering to do this for styles that is only applicable to that page alone, rather than having separate pagespecific.css file.

Is there a scenario where this has downside as i am not putting the same in head section?

<!-- myPartial.html starts here --> 
<!-- Like to keep styles unique to this html right here in this file --> 
    body { background-color: red; }
    #myText { color: white; }

  <span id='myText'>Hello</span>
<!-- myPartial.html ends here --> 

4 Answers 4


A style element inside the body element violates HTML syntax rules. On the other hand, browsers don’t care. The division into head and body elements is theoretical.

Yet, you gain nothing by using the invalid syntax, as opposite to placing style inside head. The only excuse would be technical limitations, in some authoring environments, that might prevent you from putting anything into the head part.

The issue of using a style element vs. an external stylesheet via link is completely orthogonal to this question.

Historical note: Some HTML5 drafts, a style element inside the body element was allowed in some conditions, if the scoped attributes is present. The intent was to make it possible to apply some rules inside a particular element only. This was supported by some browsers. But the idea was rejected later.

  • 1
    The first part of your answer isn't necessarily true. Jan 16, 2014 at 19:50
  • 1
    @patricksweeney, I think it’s somewhat theoretical in this context, but a correct observation; answer updated. Jan 16, 2014 at 20:41
  • 3
    @Galaxy, I don’t see why a single-page application would lack a head element. An HTML page always has one. Jan 17, 2014 at 5:51
  • 1
    @Galaxy, it does not answer the question, and if you expect the style element apply inside the div only, you are mistaken. If you want certain styling to be applied only in some states of a single-page application, you need to do that with suitable CSS selectors and/or scripting. (Especially since the scoped attribute does not work across browsers.) Jan 17, 2014 at 6:59
  • 1
    this is no longer true as of now Feb 26, 2020 at 16:44

(Since we are here at SE.SX, a more strategic approach may be a valuable augmentation to the usual technical considerations.)

[preamble] The HTML5 spec is a continuously moving target, and they have a policy to follow-up on established common practice. They obsoleted and resurrected features in the past, changed the meaning of others, shifted the focus of methodical recommendations etc. It's not written for all eternity with all the wisdom of humankind available all at once. The spec is not a sacred source of truth. It's only natural that sometimes the browsers are right. [/preamble]

OP's situation is overwhelmingly common and valid.

You have a CMS, with its theme designed and installed, all the CSS loaded properly from HEAD, then there you are, the page editor, left with a fashionable WYSIWYG box that you can (thank God!) switch to "source mode" and type (paste) in HTML markup (previously crafted elsewhere, with more suitable tools). Fortunately you can even include STYLE tags (perhaps due to a serendipitous omission in a tag filter)... The day is saved, from a lot of repetitive soul-destroying grunt work. But you still have no means, whatsoever, to interfere with the HEAD element of the system from a page edit scenario.

Should that rip you from using your CSS in a straightforward way with your HTML fragments, just because the spec says so?

Or, you have a single-page AJAX application.

It's running without reload for a long session, and there are syndicated content coming from various random sources, all arbitrarily and independently styled. Requiring them to be first converted to use only inline STYLE attributes instead of just coming with an embedded STYLE element would be absurd.

Moreover: you can a) already embed any CSS anywhere in the BODY, via STYLE attributes, so CSS is "theoretically" legal there anyway; and b) you can already do whatever you want with just about any style, whenever you want (and more) from Javascript, so CSS is also already possible to misuse in pathologically non-performant ways. And none of us would ever object those features. Nor does the W3C.

So, what exactly is so evil about STYLE elements in the BODY? What are those extra adverse implications that it would add to our wide arsenal of abuse to HTML constructs? More poor performance? Probably. Sometimes.

Is that a valid reason to abolish this incredibly useful practice, supported by every browser for a reason? Not in a million miles!

We are not idiots. Well, not all, or not always... ;) Techniques with the risk of poor performance could simply be documented, rather than just forbidden. We used to have Java applets in the early days of web, and survived. Cars can be misused, causing misery, even food can be used in disturbing, inefficient ways, and drivers who can eat may be, on average, even more stupid than the average web designer. Besides, Dear W3C, no need to worry: the angry herds of HTML tinkerers having their legs shot off with STYLE elements in the BODY still can't go after the W3C and take revenge. They don't know the address. And they have no legs.

So, please: do make your voice heard for STYLE becoming legal in BODY! Obediently citing the text, but failing to provide a viable alternative that's better than the current situation is of no help. It's actually a threat to this last-resort workaround technique.

Remember: the HTML5 spec is called a recommendation.

  • Update: the specs finally caught up: STYLE is now valid in BODY! ;)
    – Sz.
    Mar 13, 2019 at 22:06
  • 1
    Update 2: The specs un-caught-up because they changed their mind (click through on lunakid's link, it was updated). Feb 4, 2020 at 18:33
  • @MaximillianLaumeister Where is "lunakid's link"?
    – MrWhite
    Aug 26, 2021 at 23:58
  • 1
    @MrWhite The user was renamed to "Sz." - this link is the one I was talking about. Aug 27, 2021 at 0:27
  • @MaximillianLaumeister thank you, I came late to my own party. :)
    – Sz.
    Aug 29, 2021 at 13:32

There are a few technical reasons for having your css in a file vs a style tag:

  • The ability to use a css minifier (I don't believe minifiers work on style tags)
  • To have the css file be able to cached by the browser.

Some opinion based reasons to use a file:

  • You can use a wonderful css preprocessor like Sass (Compass) or Less.
  • You are maintaining two ways to add css to your application.

My personal preference is to use Compass to keep separate files for each page and then use it to compile them all into one file. That single file would be included by every page. If down the road the files need be separated for whatever reason they always can be but it is not worth the hassle in the meantime.


The html specification states that

A style element without a scoped attribute is restricted to appearing in the head of the document.

The scoped attribute is a boolean value indicating that it should be applied to just the sub tree rooted at the style element's parent element.

At this time only Firefox supports the scoped attribute. http://www.w3schools.com/tags/att_style_scoped.asp

  • 5
    The w3schools site should not be cited as a reference, or at all; see w3fools.com Jan 17, 2014 at 7:00
  • 2
    And this does not answer the question. Jan 17, 2014 at 7:01
  • 1
    Thanks @JukkaK.Korpela it was the first link I found citing scoped attribute browser support. The other comment provides a much better citation. +1 your answer -1 your less than constructive comments.
    – crad
    Jan 17, 2014 at 7:04
  • +1 for pointing towards the spec as well as noting lack of support for scoping (which is required to adhere to the spec). I think you should've read the answer before jumping the gun there @JukkaK.Korpela, very poor. You can't really get more trustworthy than the spec, and it answers the question perfectly. "Will it be a wrong idea to have style in body" - according to the spec "Yes it will be.". Jan 17, 2014 at 12:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.