10

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 --> 
<div>
  <style>
    body { background-color: red; }
    #myText { color: white; }
  </style>

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

A style element inside the body element violates HTML syntax rules. (Except that according to HTML5 drafts, it is allowed in some conditions, if the scoped attributes is present; this attribute is supported by some browsers.) 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.

  • 1
    The first part of your answer isn't necessarily true. – patricksweeney Jan 16 '14 at 19:50
  • 1
    @patricksweeney, I think it’s somewhat theoretical in this context, but a correct observation; answer updated. – Jukka K. Korpela Jan 16 '14 at 20:41
  • I take "browsers don't care" as a positive for my approach. As my pages are partials (Single-Page-Application), i cannot have <head> section, the reason why i am trying to put inside <body> or inside elements in body. – Saran Jan 17 '14 at 5:37
  • 2
    @Galaxy, I don’t see why a single-page application would lack a head element. An HTML page always has one. – Jukka K. Korpela Jan 17 '14 at 5:51
  • @JukkaK.Korpela, I updated code part in my question to answer your question. – Saran Jan 17 '14 at 6:32
6

(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! ;) – lunakid Mar 13 '19 at 22:06
2

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

  • 4
    The w3schools site should not be cited as a reference, or at all; see w3fools.com – Jukka K. Korpela Jan 17 '14 at 7:00
  • 2
    And this does not answer the question. – Jukka K. Korpela Jan 17 '14 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 '14 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.". – Fergus In London Jan 17 '14 at 12:24
1

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.

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