Set background on body instead of html?

[thierryk]

Setting a background color on html instead of on body may confuse people as it will make the latter "shrink" vertically--as this demo shows.
May be better/safer to style body.

[FabianBeiner]

Alternative suggestion: Removing the $html-background-color variable. I’m not really sure if that’s really needed, because I think people wanting something else than a white background will set that on their body anyway.

[thierryk]

"Back in the day", we used to always set background/foreground colors for the page as it was easy for the user (in Internet Explorer at least) to change the page's background color. Back then, authors could not assume white was the "default" background color...

[FabianBeiner]

Yeah, that’s still possible. But only if you force it. And if someones forces it, your setting in the CSS won’t matter anyway.

[thierryk]

No, this was (is?) not the same as styles from a user styles sheet, this background setting was overwritten by a simple:

body {
    background: <whatever>;
}

There was no need for !important there.

[FabianBeiner]

This has nothing to do with a user stylesheet, it's an accessibility feature (by Internet Explorer). For example, http://dabblet.com/gist/d0f8d05938464a257e8d shows a beautiful red. If I enable "Ignore colors specified on webpages" (under Accessibility), the colors defined under "Colors" is used.

[thierryk]

This has nothing to do with a user stylesheet, ...

Isn't exactly what I said?

If I enable "Ignore colors specified on webpages" (under Accessibility), the colors defined under "Colors" is used.

And if the author's styles sheet does not define any color, then the color set via "Internet Options > Colors > Background" is used--which is exactly what I'm saying here.

[tigt]

Not setting a background color also has issues if the site is ever put in an <iframe>; they're transparent by default.

[FabianBeiner]

And if the author's styles sheet does not define any color, then the color set via "Internet Options > Colors > Background" is used--which is exactly what I'm saying here.

Which defaults to Use Windows colors, and that defaults to white. No matter which background color you set on your Windows Desktop or so. (At least I didn't find a way to change the background color white via any setting on Windows here.)

If you remove this option, yes, the default white background is gone. It's probably like 1 of 100k - and he might want it. But who am I to judge, right?

Anyway, the iframe issue changes everything. I can't remember the last time I had to use an iframe for my page, but in this case I'd go with the color on body.

[thierryk]

Which defaults to Use Windows colors, and that defaults to white. [...] If you remove this option, yes, the default white background is gone.

Yes, we are talking about custom settings here, meaning the user would change that option to get the background of her choice.

Anyway, the iframe issue changes everything.

Yeah, that's a good call by @tigt

[kukagg]

+1 for removing $html-background-color

[jonathantneal]

This is done to enforce contrast. Anytime the YIQ contrast might change due to changing the text color, then the background-color should also be defined.

This is a better standard. The overflow of the body background is buggy and legacy-ridden. As seasoned developers, we get used to these quirks, as well as other markup quirks with head and body, but that’s not a good enough reason to make the quirky behavior the standard.

If I switch to CSS4, perhaps I could define a custom element like :--page and let developers decide whether it applies to html or body.

[thierryk]

The overflow of the body background is buggy and legacy-ridden

This is not buggy/legacy-ridden, this is per spec. 3.11.2. The Canvas Background and the HTML Element says:

For documents whose root element is an HTML HTML element [HTML401] or an XHTML html element [XHTML11]: if the computed value of ‘background-image’ on the root element is ‘none’ and its ‘background-color’ is ‘transparent’, user agents must instead propagate the computed values of the background properties from that element's first HTML BODY or XHTML body child element.

In other words, user agents must propagate the background of body through the viewport if html is not styled with a background. Meaning if html is styled with a background then the background of body will be only painted within the body's boundaries.

What's wrong with setting background-color and color on body?

[jonathantneal]

A custom element could allow developers to choose, rather than possibly turning this into a tabs vs spaces thing. As far as the spec is concerned, sometimes it is just there to document legacy behavior.

[thierryk]

What are the advantages of styling html (with background-color and color) instead of body?

[jonathantneal]

Styling the entire canvas color of a page is a job for :root.

Normalize did this for some time before Necolas determined it might not be possible to safely address the problem that it was trying to avoid.

This is due to a great misunderstanding of body.

body does not mean the whole visible page. html does. body only means its contents, just like a div. For legacy reasons, we all know the one great exception — as long as certain properties are avoided (like height, border) and as long as no background it put on the root element, then body backgrounds do push through to the root. It’s really quirky behavior. So quirky that most of us were taught (even by the w3c with no explanation) to follow this quirk rather than understand it. Before Normalize did this, Yahoo did this as well. It almost seems like a right of passage at this point to get it right before people file bugs because they rely on the quirk.

Could you imagine if we had let font-size on body also change the rem unit?

[thierryk]

Styling the entire canvas color of a page is a job for :root.

Why? What's wrong with using body for color and background-color?

This is due to a great misunderstanding of body. body does not mean the whole visible page. html does. body only means its contents.

Not when it comes to its background and section 3.11. Backgrounds of Special Elements is very clear about this.

If we consider content to be within body then it makes sense to set color on body rather than on html. And because it is good practice to set color and background-color together it makes sense to style body with both. Knowing that—per spec— the background will propagate to the viewport.

Before Normalize did this, Yahoo did this as well

Yahoo was wrong. I opened a bug there and the background declaration was supposed to be moved to body... but then YUI was dropped and the "fix" was never implemented.

Could you imagine if we had let font-size on body also change the rem unit?

Sorry, I don't see the relevance here...

Anyway, feel free to close this issue as you really seem to be opposed to the idea.

[jonathantneal]

I’m actually considering changing it, but you did ask me to present my case. I think the spec comes across rather confused on this subject.

The document canvas is the infinite surface over which the document is rendered.

An inspector tool seems to indicate this is html aka :root in HTML.

Since no element corresponds to the canvas...

Well, no explicit element...

CSS propagates the background of the root element

And :root is probably that root element.

(or, in the case of HTML, the <body> element) as described below

What? Okay, let’s understand this 180 in the description below.

---

For documents whose root element is an HTML element

That’s us. :root is html.

If the computed value of ‘background-image’ on the root element is ‘none’ and its ‘background-color’ is ‘transparent’

Okay, if no background is assigned to :root...

user agents must instead propagate the computed values of the background properties from that element's first HTML BODY.

Got it. If html is unset, use body as though it were html for backgrounds.

The used values of that BODY element's background properties are their initial values, and the propagated values are treated as if they were specified on the root element.

Again, seems pretty straight forward. It’s like we are forwarding body backgrounds to :root.

It is recommended that authors of HTML documents specify the canvas background for the BODY element rather than the HTML element.

What? This feels like another 180.

And then I find no explanation. It’s concerning.

---

Your argument, @thierryk, is the best and strongest I’ve heard.

1. The spec recommends it.
2. We consider all visible content to exist within body.

Unless a spec author validates my theory that the spec recommendation is out of place because it addresses legacy behavior, I’ll change this soon. I certainly won’t leave a long window open for this.

Somewhat related; if and when I change it, would this be considered a major or minor change to Sanitize? I find semver to be tricky business with CSS.

[thierryk]

would this be considered a major or minor change to Sanitize?

I agree about semver and CSS as "base" styles sheets dictate more or less the styles found in authored styles sheets. Meaning almost any change in a "base" styles sheet has the potential to break a page.

In our case, things will break if authors have customized (overwritten) the background of their page by styling html as the page background will show as white once body is styled as white.

[jonathantneal]

I know how to resolve this issue, at least for those using the cssnext version.

/* sanitize.css */
@custom-selector :--root :root;

:--root { /* sanitize.css styles */ }

/* user stylesheet */
@custom-selector :--root body;

I will make this part of the next release.

[thierryk]

For what it is worth, I think this should not be labelled as a enhancement but as a bug since it goes against best practice.

[jonathantneal]

We’re not styling background or color for the page, so we don’t need to worry about this anymore.