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.
Related
This link comes very close to my question, but seems to apply to syntax more than to actual rendered output:
I see that image height and width can be defined in the actual html img tag, in fact the way I read it it should be defined there. However, I am wondering about what matters when it actually comes to how the image is displayed. If I insert the following code
<img src="images/academia_vs_business.png" width="740" height="382" alt="" />
with no css stlying applied to the image, will it be rendered at it's native width and height?
If I do add css styling to that image, as in
img {
width: 400px
}
Will it overrule the width attribute of the html?
If I do not specify the height and width of an image in the html, is the only problem that I am not conveying the actual image size to a non-visual user agent or are there other problems (such as the browser can't allocate space for the imgs during page load).
Isn't specifying size in the html tags redundant if the css is going to change image size anyway?
I guess this all could be summed up as the best practice to place and size images and I would love to hear others techniques.
From the W3C website:
The UA may choose to honor presentational attributes in an HTML source document. If so, these attributes are translated to the corresponding CSS rules with specificity equal to 0, and are treated as if they were inserted at the start of the author style sheet. They may therefore be overridden by subsequent style sheet rules. In a transition phase, this policy will make it easier for stylistic attributes to coexist with style sheets.
See this answer to this question for more details
I have used
html, body {
background-image: something;
}
in my CSS for many years. Now I can't remember why really..
Is that method even necessary/beneficial or is body {} enough?
If you're applying a background, selecting body is usually enough; the browser will know to paint the background over the entire viewport regardless of the body dimensions. The details of how a browser is expected to behave are covered in the spec (CSS2.1, CSS3 module). Even the CSS2.1 spec recommends it (although it doesn't mandate it for reasons mentioned later in the prose):
For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element.
The only situation in which you would apply a background to both elements is when you want to layer one background over a different one; you could either use the CSS3 syntax of layered backgrounds on just the body element, or have body's background overlay that of html. Even then, the only reason I can think of for choosing the latter is if you need compatibility with older browsers that don't support the CSS3 syntax. I cover both methods in-depth in my answer to this related question.
I can actually set the background-color of the html tag. I didn't know it was possible and I don't understand if it's logically correct, I thought the body was the only one responsable to contain and the "first" rendered tag. I thought html tag was just a wrapper but it looks different. So,
What exactly represents the html tag?
Why can I set it's background-color?
Will it give me problems?
I resized body to a 1024 x 768 size and want to set its background color to white, while html page to black, it's quite nice in this way... I would like to know if I must use div for this (I hate a lot of divs!!!)
A browser will render it that way. Styles on the actual HTML element are perfectly fine. In fact, the default style sheet for HTML 4 sets the <html> element to be display: block. It is a visible element and it can be stylized.
Adding styles to the root element doesn't change its semantic meaning, only how it's displayed. As long as you're not altering the semantic meaning of elements, you're fine. Style away.
Sometimes I see people apply global css styles to html, sometimes I see them apply them to body, with both raw css and javascript.
Are there any differences between the two? Which is the standard to make a global css style? Is there anything I should know when picking between them?
I'm assuming that "global page styling" here refers to things such as fonts, colors and backgrounds.
Personally, I apply global page styling, for the most part, to body and the simple element selectors (p, h1, h2, h3..., input, img, etc). These elements are more closely related to the presentation of content of an HTML page to the user.
My rationale for this is simple: the presentational attributes bgcolor, background, text, topmargin, leftmargin and others were given to the body element, not the html element. These attributes are now converted to their respective CSS rules with extremely low precedence in the cascade:
The UA may choose to honor presentational attributes in an HTML source document. If so, these attributes are translated to the corresponding CSS rules with specificity equal to 0, and are treated as if they were inserted at the start of the author style sheet.
Most if not all implementations I'm aware of will convert these to CSS rules on body, based on their HTML equivalents. Others such as link, alink and vlink will become a:link, a:active and a:visited rules respectively.
Of course, it should be noted that CSS itself doesn't really have any semantics to it per se, as it's a styling language in itself which is completely separate from the content structure of an HTML document. Although the introduction to CSS2.1 covers the basics of styling an HTML document, note that the section calls itself non-normative (or informative); this means it doesn't set any hard and fast rules for CSS implementers to follow. Instead, it simply provides information for readers.
That said, certain styles may be applied to html to modify viewport behavior. For example, to hide the page scrollbars use:
html {
overflow: hidden;
}
You can also apply rules to both html and body for interesting effects; see the following questions for details and examples:
What's the difference in applying CSS to html, body, and *?
Applying a background to <html> and/or <body>
Note that html is not the viewport; the viewport establishes an initial containing block in which html is situated. That initial containing block cannot be targeted with CSS, because in HTML, the root element is html.
Note also that, technically, there is no difference between applying properties to html and body that are inherited by default, such as font-family and color.
Last but not least, here is an excellent article that details the differences between html and body in terms of CSS. In summary (quoted from its first section):
The html and body elements are distinct block-level entities, in a
parent/child relationship.
The html element's height and width are controlled by the browser window.
It is the html element which has (by default) overflow:auto, causing
scrollbars to appear when needed.
The body element is (by default) position:static, which means that
positioned children of it are
positioned relative to the html
element's coordinate system.
In almost all modern browsers, the built-in offset from the edge of the
page is applied through a margin on
the body element, not padding on the
html element.
As the root element, html is more closely associated with the browser viewport than body (which is why it says html has overflow: auto for scrollbars). Note however that the scrollbars are not necessarily generated by the html element itself. By default, it's the viewport that generates these scrollbars; the values of overflow are simply transferred (or propagated) between body, html, and the viewport, depending on which values you set. The details of all this are covered in the CSS2.1 spec, which says:
UAs must apply the 'overflow' property set on the root element to the viewport. When the root element is an HTML "HTML" element or an XHTML "html" element, and that element has an HTML "BODY" element or an XHTML "body" element as a child, user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.
The last bullet point probably has its roots in the aforementioned topmargin and leftmargin attributes of the body element.
If you want to style only the content that'll be displayed, targeting the <body> element saves the style rules an unnecessary level of cascading.
Is there a reason you'd want to apply styles to the <title>, <meta>, <script> etc... tags? That would happen by targeting <html>.
Can anyone explain to me why can we style the element html?
What are differences between it and body?
I usually see tutorials and multiple websites using body and never html, I only found about it when using YUI 3: CSS Reset since changing the background in body didn't work.
Edit: Actually, I still haven't found the problem regarding that, when I add the reset.css the background gets white, when I remove it returns to normal. Yet Chrome inspector says that the background is the normal one. Btw, this is getting off topic. :p
Edit 2: The culprit was the doctype. Somehow it made the html style in the css-reset render after the body style in my stylesheet. Maybe I should open a question regarding this.
Doctype: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Quite often you'll find people styling the HTML element since it does have an affect on the way the page is rendered.
The most notable style you're likely to see is
html,body{
min-height:101%;
}
This is used to ensure that the scroll bars in browsers like Firefox, always show on the page. This stops the page shifting left and right when changing between long and short pages.
The reason we're allowed to style the html element is because it is a DOM element like any other. All DOM elements can be styled to be something they are not, like a container. Take this example:
<html><body>This is my page.</body></html>
Using CSS to limit the body to 80% width, setting borders on the body and giving the html a different background color (creating an "off page" effect) would be perfectly acceptable, keeping the semantics of the markup intact without resorting to div clutter.
Here's a technique I discovered for centering containers (vertically and horizontally) on the screen without using tons of divs or tables, or even having to know the size of the centered container.
html {
display:table;
width:100%;
height:100%;
}
body {
display:table-cell;
vertical-align:middle;
}
body > div {
# "shrink wraps" the div so you don't have to specify a width.
# there's probably a better way to do precisely that, but this works.
display:table;
margin:0 auto; # center the div
}
You can style the html element (heck you can head, title { display: block; } if you like), but browser support is a bit weak (IIRC, Internet Explorer <8 has issues).
Offhand, I would say: <html> is not a visible element per se, and it contains sections for semantic (e.g. <head>) and presentation data (<body>).
On the other hand, <body> is a block for visible elements, so it can be given a presentation style.
But people do apply styles to the <html> element for a couple cases: (a) because all of its child elements will inherit that style, and (b) in special cases like the scrollbar trick that Jamie Dixon mentioned.
I don't believe you can, but styling <body> should work for you
html is the containing element for the whole document, it contains the <body> which is what is rendered by the browser and <head> which contains meta information on the page/document you are viewing. It has actually no use to be able to style the html element since it isn't rendered by the browser.
It can however be used to build you css selectors with (html div.dataView { color: red } for example)