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?