According to the spec:
It is recommended that authors of HTML documents specify the canvas background for the BODY element rather than the HTML element.
But it doesn't say what advantages it has. Why does the spec recommend this?
P.S. It crossed my mind when I saw Extra scrollbar when body height is 100vh: isn't it better to simply give the background to the html element instead?
Prior to CSS, backgrounds were specified by adding the background and bgcolor attributes to the body element in HTML (along with the likes of text, link, alink, vlink, leftmargin, marginwidth, topmargin and marginheight).
CSS-compliant browsers convert these presentational attributes into the appropriate style rules, placed as author-level presentational hints with just less precedence than author-level * rules. More on this in css-cascade-3 and HTML. Namely, the background and bgcolor attributes are converted to background-image and background-color declarations respectively, for the body element.
So, the recommendation that authors specify the canvas background for the body element and not the html element was made to ease migration of legacy HTML documents from presentational attributes on the body element to CSS. Normally if you have control of both the markup and CSS the first thing you'd probably want to do is get rid of the presentational attributes. But you don't have to do so right off the bat; you can just add a background declaration specific to the body element, and it will seamlessly replace the entire page background (as described in the spec link in the question) as specified by the presentational attributes, with no further action necessary:
/* The bgcolor attribute is equivalent to a
body {
background-color: #FFFFFF;
}
rule at this position in the stylesheet,
except with less precedence than a * rule.
The following rule will override it as a
normal part of the cascade. */
body {
background-color: yellow;
}<body bgcolor=#FFFFFF>
<h1>Hello world!</h1>
<p>This page was once white...
<p>... now it's yellow!If you add it to the html element instead, you'll end up with two backgrounds:
/*
body {
background-color: #FFFFFF;
}
*/
html {
background-color: yellow;
}<body bgcolor=#FFFFFF>
<h1>Hello world!</h1>
<p>This page was once white...
<p>... wait, what?If you're aware of the body element having a bgcolor attribute, this does have the advantage of serving as a visual reminder to you to get rid of the attribute. But if that doesn't occur to you right away, you'll probably be left flummoxed.
Of course, if you're authoring new documents then this simply becomes a matter of tradition (which ties in to the whole "ease of migration" thing). There's nothing stopping you from applying backgrounds to both html and body for interesting effects, though even that has largely been superseded by the ability to add multiple background layers to one element and is only really necessary if you need to support older browsers. More on this in the link above.
It is a matter of preference actually, this is why it is recommended rather than being forced as a strict rule.
The body tag being a descendant of the html tag overrides the html properties - being background otherwise.
However, since all browsers give a margin to body by default, creating a border between the body and the browser window (although we are used to resetting this margin to 0), I guess this ...border was meant to be visible, so using a background on the HTML would make this border invisible to users. Given this fact and since all content is contained inside the body tag, the recommendation was provided by spec.
However, nowadays the body tag is usually reset to 0 by almost everyone so using it on either html or body tag makes no difference and each case provides no advantages compared to the other.
My answer will be quicker, because BoltClock's one and the spec explain it minutely.
It is a matter of efficiency.
If you think about the fact that the UA should "[use the] values of that BODY element's background properties are their initial values", it makes sense to assign these values to the body tag. If you use the html tag, UA may use a kind of fallback to display it, which is time consuming. Of course, it's nothing for nowadays computers, but what about mobile devices, displaying let's said a background image with a cover background-size?
Furthermore, the order of html tags is a logical one, the link tags are defined in the head, in order to be used for the body and his childrens that come after. But if you apply a css rule to the html tag, the UA may go backward... And then forward.
So what are the advantages of specifying the canvas background for the BODY element? Quite nothing, for you, but some microseconds for the user, some microwatts for the client and the servers, but small streams make big rivers.
The w3c may have decided to do the opposite, it will have been ok too, it's just the purpose of a standard, that you make what a browser expects of you.
What? iOS does not respect the rules? (they can, they are apple). Don't change the correct way to do that, use media queries.
