style and script tags in HTML body... why not?
Asked Answered
S

7

45

[This is related to this question, but not since it's not about email.]

In many cases -- especially when working with a CMS or someone else's framework, it's much easier to embed <style> tags and <script> tags in the <body> than in the <head>. This seems to work in IE6, IE7 (Windows), Firefox 3.x and Safari (OS X).

Strictly speaking, is this wrong? And if it is, what negative consequences might it cause... aside from being completely ignored in some clients?

Note: Glad everybody wants to talk about DRY and centralizing styles. Imagine for a second that I want to use style tags within a document because they ARE NOT GLOBAL and that I DO NOT HAVE ACCESS TO THE HEAD ON A PER-PAGE BASIS. For whatever reason, be it that the site differs on a page-by-page basis, or a per-paragraph basis or whatever. I'm not interested in it being hard to track down and change. I'm worried about possible consequences of using style in the body.

You centralize stuff that's central. Everything else is bloat in the central stylesheets.

Spirituous answered 1/9, 2009 at 11:46 Comment(1)
See #1213781Whelm
D
28

Although the specs explicitly state style tags are not permitted in the body tag, specs aren't all that matters. Style tags are supported in the body by every major browser, and that's ultimately how users see your site.* While there has long been a drive for better standards and standards support in the browser industry, there's also long been a general push to render broken documents as well as can be.

Google, who leads the HTML5 spec effort, simultaneously maintains google.com which violates specs to save bytes, by leaving the quotes out of its attribute values, using selector hacks against the CSS spec, including script tags with no type or language, and link tags with no type. A purist could argue one of the most used sites on the internet is violating the specs and in serious danger of being horribly misrendered. Or, we can reason that no browser will enter popular use that can't render such widely used hacks on the spec.

So, the question is more of which way the browser industry is going - which again is one of both better specs, but also doing their best to honor the intent of pages that violate those specs. My bet is style tags will keep working in the body for a long time to come.

*As of this writing, style tags in the body are supported with an HTML5 doctype in Firefox 3+, IE6+, Safari 2+, Chrome 12+. Support likely goes back farther but those browsers are rarely seen on the interwebs.

Disfeature answered 12/6, 2012 at 1:53 Comment(4)
While I agree this is the most relevant answer, I think it's worth pointing out that quotes are optional on all attributes as long as the value contains no whitespace/illegal characters.Kerril
Good point - the prev specs didn't allow this. It took a ton of digging (why do they wait till Section 8 to just define what an attribute is?), but here it is in the spec: w3.org/html/wg/drafts/html/master/syntax.html#unquoted Meaning that even in the spec now this is perfectly legal: <a href=://blah.com/blah.gif>Disfeature
The previous specs did allow this, just not XHTML: W3 explains differences between XHTML1 and HTML4Kerril
Yes, the web went HTML4 -> XHTML -> HTML5 - I was referring to XHTML as the previous spec.Disfeature
D
16

The contexts in which the <script> and <style> tags can be used depends on the doctype you're using. For instance, I'll assume you're using the HTML5 doctype:

<!DOCTYPE html>

The script tag has three contexts under the HTML5 doctype:

  1. Where metadata content is expected.
  2. Where phrasing content is expected.
  3. Where script-supporting elements are expected.

The style tag has a slightly more complicated context-structure under the HTML5 doctype:

  1. If the scoped attribute is absent: where metadata content is expected.
  2. If the scoped attribute is absent: in a noscript element that is a child of a head element.
  3. If the scoped attribute is present: where flow content is expected, but before any other flow content other than inter-element whitespace and style elements, and not as the child of an element whose content model is transparent.

Essentially, this states that you can place the style tag and the script tag in the body, since the body is where we place flow content, and phrasing content.

As always, consult the spec for the doctype you're using.

Dubbing answered 1/9, 2009 at 11:50 Comment(0)
W
10

The short answer:


The detailed answer:

STYLE is defined to be in head.misc:

<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements -->

And elements of head.misc are only allowed to be children of the HEAD element. So STYLE is only allowed to be child of the HEAD element.

SCRIPT is defined to be in head.misc and in special:

<!ENTITY % special
   "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">

And special is defined to be in inline:

<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

Additionally SCRIPT is also allowed to be child of the BODY element. So SCRIPT is allowed in the HEAD element nad wherever inline is allowed.

Whelm answered 1/9, 2009 at 12:21 Comment(3)
so what does it mean that most browsers parse in the body? That it should not be used anyway?Spirituous
@yar: Yes, it’s not part of the standard and thus should not be used although it may work in most browsers.Whelm
Note this answer references the HTML4 spec while @Sampson's references the HTML5 spec --- hence the small differences.Smear
B
3

Two possible answers for style in the body:

  1. Use inline styling. True, you'll lose the advantages of internal and external styling, but if you don't have access to the header, then you don't have access to the header.

  2. Use the scoped attribute in the style element. This is new to HTML5, but the idea is to limit the scope of the CSS to a part of a page, for example to a single div. The bad news is that it is not yet supported (as of July 2011), nor is it backwards compatible. But there is (allegedly) a JQuery plugin that can help. For more info:

Bilabiate answered 15/7, 2011 at 13:40 Comment(1)
I was close to crying when I saw "The attribute has been removed from the current specification" - see caniuse.com/#search=scoped - so apparently they won't be officially introduced any time soon. STILL, since every browser was preparing for this to come, it's perfectly safe to use <style> tags in the middle of nowhere.Chemoprophylaxis
C
2

Well, you have the problem of directly embedding styles and scripts into your content. The primary mantra here is the DRY (Don't Repeat Yourself) Principle. You may use a script or particular style in multiple places. When that style or script requires modification, you now get to go on a scavenger hunt for all the places where that code exists. Keeping your styles and scripts in a common place is ideal.

On the other hand, if it is a minor style issue (pixel pushing or something related to just that one view), it's probably okay.

Clarissaclarisse answered 1/9, 2009 at 11:53 Comment(1)
true, obviously we're talking about one-offs. Things that are used in more than one place are centralized.Spirituous
V
1

But why would you have style-tags in the body? The styles are global anyways, so i can't find any logical reason to do so.

To simplify and separate things even more you should use external stylesheets too.

Scripts are allowed, and is there for a reason: They might give output, they should be run at specific times and other reasons.

Varian answered 1/9, 2009 at 11:57 Comment(7)
Some MVC developers load specific stylesheets into the content of their views, which may plant them somewhere in the middle of a template, and thus in the body.Dubbing
Then you should either put everything into one stylesheet (or one set of stylesheets) that is always included, or generate one style sheet depending on the view you're at. If you need separate stylesheets for every view, you've just misunderstood one of the basic principles of CSS. It's always been done with a fixed (set of) stylesheet(s) - why can't it be done so now?Varian
We should limit this conversation to whether you can do it or not, I think. I might, on a certain sight, have particular styles that are NOT global but rather on a per paragraph basis, or a per page basis. Using style is somewhat more readable than using style="" attribute.Spirituous
That is why have class-selectors :-) You might also add an ID-attribute to the body-element, and change things accordingly. Silly example: body#about p { font-weight: bold; }Varian
Totally, but if it's only in one place in your system ever, then it shouldn't be in the central stylesheet: then it's just bloat. Example: 1px movements to get stuff to look right in IE. Then you have #thinger .ie and #thinger.Spirituous
you don't know if you need a style until you are deep into formatting a document. example: some pages include code samples deep inside nested tables and some don't -- should they all have the styles for code samples and every other possible style for the entire web site?Resistant
If you have code samples "deep inside nested tables" you probably struggle with far worse things than style tags inside the body :-). Fact is, style inside body is not "allowed" by the spec, and if you truly need to have it there for whatever reason, it's time to re-architect your front end in my opinion. Style in body is just "the easy way out" for that one moment it might seem convenient.Varian
D
0

The biggest problem, in my opinion, is convenience. If you want to change the style of a page, it's much easier to do so if all the style and script information is in one area. It's possible for style/script information to be in a <style> node, in the style attribute of a node (i.e. <body style='...'>) or in an external file (i.e. <link rel='stylesheet' type='text/css' href='style.css' />). It's much easier to use a consistent location than to try to hunt down all the places that a style could occur.

It's also worth noting that saying, "aside from being completely ignored in some clients" is akin to saying "aside from exploding when you hit it from behind" or "aside from flying off-course and landing in a civilian neighborhood". That's severe enough a problem in itself to warrant using the standard practice.

Different answered 1/9, 2009 at 11:57 Comment(1)
I disagree, re: last point. HTML and CSS is so unpredictable, IMO, that if I don't know about a certain client, ignoring my styling might be a lot safer than respecting it in an unknown way.Spirituous

© 2022 - 2024 — McMap. All rights reserved.