HTML vs Body in CSS

Share this:

The difference between <html> and <body> is easy to overlook. It seems to be one of those things that falls into the category of trivial. Admittedly, I have a bad habit of applying all global styles to <body> and, when that falls short, I move to <html> without thinking about it.

There are differences, however, and it's a good idea to be aware of them regardless of whether we're CSS veterans or rookies. We'll go over those in this post and consider some practical applications where styling one over the other might make sense.

How HTML and body are related

The spec defines<html> as the root element of a document, and we can clearly see that in the above example: the <html> element is the very top level of all other elements. The buck stops there because there are no more levels beyond that from which styles can be inherited.

From there, <head> and <body> make up the only two elements that fall directly inside <html>. In fact, the spec defines<body> directly in contrast to <head> since those are the only two elements that need to be distinguished.

So, the bottom line here is that <html> is the root element of a document where <body> is a descendent contained within it. In fact, there is a :root selector in CSS. These target the exact same thing:

:root {
}
html {
}

Except :root has a higher specificity: (0, 0, 1, 0) vs (0, 0, 0, 1).

So we should always put global styles on <html>, right?

It's tempting to think that any styles we want to be inherited across the board should be applied directly to <html> because it is the root element of the document. <html> supersedes <body> in hierarchy, so it follows that it must contain all global styles.

But that's not exactly the case. In fact, inline attributes for the following were originally assigned to <body> in the spec:

background

bgcolor

marginbottom

marginleft

marginright

margintop

text

While these attributes are now considered obsolete, the recommendation is to use CSS instead with their corresponding CSS property:

Given that these CSS properties originated from inline attributes that were written for <body>, it would seem appropriate that they should be applied directly to <body> in the CSS as well, rather than pushing them into the <html> element.

So we should always put global styles on <body>, right?

Well, not exactly. There may be situations where it makes more sense to apply styles to <html> instead. Let's consider a couple of those scenarios.

Working with rem units

The rem unit is relative to the document root. For example, when writing something like this:

.module {
width: 40rem;
}

that rem unit is relative to the font-size of the <html> element, which is the document root. So, whatever is set as the user-default at the root level is what the .module class will scale to.

Quirky background-color

There is a weird thing in CSS where the background-color on <body> floods the whole viewport even if the metrics of the element itself don't cover that whole area. Unless the background-color gets set on the html element, then it doesn't.

If flooding is the goal, it can be smart to just set it on the html element to begin with.

Wrapping Up

Hopefully this sheds some light on the key differences between the use of <html> and <body> in CSS. There are JavaScript differences as well. For instance you don't need to query for either, html is document.rootElement and body is document.body.

We could certainly draw more technical distinctions between the two, but the point here is to level-up our understanding to make better decisions when writing CSS.

Do you have other examples of where it makes more sense to style one over the other? Or perhaps you have a different set of criteria for knowing when when to style one? Let us know in the comments!

Well I feel like a dope. It had never occurred to me to use body as a wrapper. I guess I had always assumed was sacred and should never be used for dirty ol’ styles, and that should only ever hold background and font styles, never margin, etc. I don’t know where I came up with those theories, it’s just one of those things when you never see them utilized otherwise in the wild.

I used to use the body for background color and the main element for wrapping, but then I discovered that the main element should be mapped to the main ARIA role for accessibility. So I moved to using a div.container. I never thought to use body as the wrapper. Interesting…

Unless you make a very basic personal blog and know what you’re doing – using body as a wrapper is crazy awesome. You could even go nuts and start showing the title element as visible page title!

Ok, that second one is over the top and not supported by all browsers.

But, as soon as you move to websites that need more capabilities you will have to move to using a different wrapper element. Unfortunately there are too many issues with for example 3rd party image viewers and html dialogs. Also, what if you need one page where one row has to be full width again?
Trying to fix all that will give a website nobody would want to maintain.

Not sure where document.rootElement is coming from, but it is not returning the <html> element. (I’ve tested in Chrome, Firefox and Spartan.) The standard property rather is document.documentElement (see DOM spec).

@philtune I guess it is kinda sacred because it is a wrapper you cannot remove, so, all your pages must inherit its style. If you throw a .wrapper div in there you may opt out.
But regarding basic styles like background, font style, etc, I agree. That’s what body is for..

Except it’s easy to throw a class on the wrapper itself to differentiate between the needs of different pages. You can apply basic styles to the body element and then make tweaks with classes like .body-home or .body-about.

Setting background color on the html tag seems to apply very early in the rendering process and if you have alot of includes going on in the head section before the body section then your page will render with the background color before the other stuff loads.

There is a weird thing in CSS where the background-color on “ floods the whole viewport even if the metrics of the element itself don’t cover that whole area. (…) If flooding is the goal, it can be smart to just set it on the html element to begin with.

This conclusion seems to contradict the first statement. Am I reading this right, or misunderstanding something?

Perhaps worth mentioning that the background color on html influences the color of the scrollbar in safari for mac. This can be confusing if you have a absolute positioned sidebar with a white background by the scrollbar, while the html background is black. Will render the scrollbar almost invisible (white on white). http://codepen.io/anon/pen/ZGzgPg

I’m confused. You said ‘There is a weird thing in CSS where the background-color on <body> floods the whole viewport … If flooding is the goal, it can be smart to just set it on the html element to begin with.’
???

If you have a BODY element that doesn’t take up all the same space as the HTML element and you set a background-color on the BODY and no background color on the HTML element then that background color will fill the whole page (which presumably is the same dimensions as the HTML element), meaning that this quirk causes the background color set on the BODY element to behave as though it had been set on the HTML element. Soooo… if your BODY element doesn’t take up all the same space as your HTML element but you want one background color to cover everything the HTML element covers then it makes slightly more sense to set the background color on the HTML element rather than relying on the quirk to do the work.

The specs explicitly state that a background on the body element should be propagated to the html element (when no background has been set on html) and therefore there is no need to specify the background-color of the html and indeed it is recommended for authors of html pages that they specify the canvas background for the body rather than html.

I believe that in ‘most cases’ the only properties you want to set on html are font-size, reset margin/padding, box-sizing and occasionally height (for 100% layouts). Other than that simply leave it alone for best results.

Also using the body as a wrapper was historically bad and caused all sorts of problems in ie7 and under and although those browsers aren’t an issue theses days there are still problems with zoom in newer versions of IE so again I think that for the sake of one wrapper element you can avoid all these issues in one fell swoop.

The one thing about using body as a wrapper instead of, say, a div, is that sometimes you want to nest things in the body outside of the main constraints of the document. Content on the margins, for example. If you’re thinning down the body to, say, 75% of the viewport, you can still add content to the margins but it’s going to result in some very ugly code.

Believe it or not, people knew what they were doing when they pushed the sacredness of the body. Using other elements to comprise the main boundaries of the content (I suggest using three or four – header, footer, and article…then, maybe, nav as a fourth or as a part of the header &&/|| footer &&/|| article.

I use <body> for all global styles for one specific reason: I use <html> as a sacred element that I never apply custom styles to, so that I can make calculations based upon it in JavaScript knowing that I’m not messing with its attributes somewhere in the mix of CSS. It’s helped me more than once, but might not be a necessity for some.

This comment thread is closed. If you have important information to share, please contact us.

Related

How do you stay up to date in this fast⁠-⁠moving industry?

A good start is to sign up for our weekly hand-written newsletter. We bring you the best articles and ideas from around the web, and what we think about them.

👋

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress and powered up by Jetpack. It is made possible through sponsorships from products and services we like.