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)
Related
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.
This question already has answers here:
What's the difference if I put css file inside <head> or <body>?
(12 answers)
Closed 7 years ago.
I have an old website where about 70 percent webpages have css style sheet inside the body tag.
<body>
<style>
h2 {color:red;}
</style>
<h2> Hello Ladies & Gentelmen</h2>
</body>
As you can see ,the CSS is inside the body of the document.
I have tested these webpages with diffrent web browsers including (Opera, Chrome,IE etc) , They are working fine and there is no problem with the CSS.
So now my question is :-
Is body the right place for CSS or Should I always put the CSS in head section of my webpage?
Even though most (if not all) browsers allow the style element as a descendant of body, it is invalid HTML.
The style element is "Metadata content": http://www.w3.org/TR/html5/document-metadata.html#the-style-element
The body element should contain only "Flow content": http://www.w3.org/TR/html5/sections.html#the-body-element
You should always put any css, whether inline, or external, in the <head> of your website.
The reason the websites work as normal is because the modern browsers realize that sometimes people put css in the body, and they automatically correct the mistake. It it were an older browser you may not get so lucky.
A <style> element's being inside <body> is invalid HTML, although some browsers are able to correct it because it's a common mistake. It belongs in the <head> element because it is metadata. I, however, usually prefer to use linked stylesheets because the browser can cache them for better performance.
Originaly was ok, but that change along time ago, if you put the style in the middle of the body, the browser gonna render the first half without styles, ugly right... and then has to repaint all... so, two things, that was slow, that blinks (givin the sensation of slow or wrong).. because that we put styles on header. That was the reason.
Then, the standard adopt putting style in the header like the way to do things. So, if you put styles in the body, its an invalid html.
Hope it helps.
One thing more, you can have the file css... and that would be cached by the browser. You have style tag and inline style... the priority is, inline, then tag then the file.
As my point of view i prefer puting css in <head> tag and jquery at the bottom of page.
And external css is most preferable for reuse class in different pages.
Does it matter where I declare my CSS styles on my page?
Is this:
<style>
div{
height: 50px;
width: 200px;
}
</style>
<body>
<div>This div</div>
</body>
Different to this?
<body>
<div>This div</div>
</body>
<style>
div{
height: 50px;
width: 200px;
}
</style>
If so, how?
I've seen examples of both and never really noticed any significant changes in how long the styles take to kick in on page load. Although, about 90% of the time, styles are declared at the top of the page.
Personally, I much prefer including a separate stylesheet to avoid adding styles to a page in this fashion.
Place it at start
You should place the STYLE element in the HEAD helps the pages load more quickly because the page can then render as the HTML loads.
When a web browser reads a web page, it reads it in the order that the HTML is written. So when your style sheet comes first, that is what is read first. Then, when the browser gets to the HTML, it already knows how to style it and so doesn’t have to wait to load the CSS before displaying the content.
Why Not Put Style Sheets at the Bottom of the Page
When you place a style sheet at the bottom, this prevents many browsers, especially Internet Explorer, from doing progressive rendering. Internet Explorer even blocks rendering of the page until all the styles are added, so that it doesn’t have to redraw the page. This means that customers will see a blank white page until all the elements and styles have been loaded.
It is best to put stylesheets in head.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<style>
div{
height: 50px;
width: 200px;
}
</style>
</head>
<body>
It is recommended because when you have the CSS declared before starts, your styles has actually loaded already. So very quickly users see something appear on their screen (e.g. background colors). If not, users see blank screen for some time before the CSS reaches the user.
Also, if you leave the the styles somewhere in the , the browser has to re-render the page (new and old when loading) when the styles declared has been parsed.
When you add styles to the html page, they are loaded as the page loads and parsed accordingly in that order. Like in first example, the style loads first and then the elements which is meaningless. In the second one, the elements load first with the default styling and then they are styled.
Adding files to a separate stylesheet waits for the page to load and then displays the styles. In very slow connections or heavy pages, the difference is significant.
You should put your stylesheet in head
<!DOCTYPE html>
<html>
<head>
<style type="text/css">
div {
...
}
</style>
</head>
<body>
<div>
....
</div>
</body>
</html>
The style element should apply to the whole document, wherever it is placed, however it is common practice to always put it in the head element. I would not be surprised if browser handling is a bit flaky if you put it in other places.
Note that html5 allows you to specify the scoped attribute for the style element, which means that it will only apply to the parent element of the style element and all its children.
By the way, usual practice is to put the css in a separate file and use the <link> tag to include the CSS in your document. This way you can share the css across multiple pages.
Only the first alternative, style before body, is valid, according to any CSS specification. No tags are allowed after the end tag </body>, except the end tag </html>.
Although browsers are permissive, there is usually no reason to even think of deviating from the correct order. In some authoring situations, you might be unable to inject a style element where it belongs (the head part), but even then, it should be placed before the end tag </body>.
I need to put an image background for the whole page. I use to do this applying the style to the body tag.
Just wondering if ss good practice to put a style to the html tag
Yea nothing wrong with it.You can put style to html tag.
Reference: http://www.w3schools.com/TAGS/tag_style.asp
http://www.w3.org/TR/REC-html40/present/styles.html#edef-STYLE
Sure. Actually, the html tag can be omitted in html5, so if you have it, you can sure use it for styling if you will. It has hardly any other purpose, so if it saves you from having to add an extra div, I think you should.
I normally add the height-property to the HTML-element, in order to make the background-image as large as possible. Don't forget to set the body's height aswell:
html {
height:100%;
}
body {
height:100%;
background:#000 url(your-image.png);
}
Yes, you can apply style to the HTML element. What's more, it doesn't even have to exist in your original HTML document (as is allowed in HTML5), e.g. this code below is fine:
<!DOCTYPE html>
<title></title>
<style>
html {
/* ... CSS properties go here ... */
}
</style>
The technical reason for this is because the <HTML> element is defined in the W3C specs as an implied element - basically user-agents must assume it is there, and all good UAs will append it to the DOM when rendering the web page.
Abu's answer, with respect, although in the context he is talking about is correct, is a misunderstanding of the question. Abu is referring to applying an inline STYLE attribute to the HTML element within the HTML document itself. I believe this question, on the other hand, is referring to using the html {} selector in an external CSS style sheet.
No its not recommended to use style tags inside HTML as styling should be taken care by CSS.
You shouls avoid it unless there requires a specific scenario where you want to dynamically set the style for some part.
But in that dynamic case also, I would recommend to create a class level style inside a CSS and then just add that class to the element while creation so that the required styles are applied.
I'm generating a page for an upcoming portal site, and I've got an HTML element with some optional content. I'd like the element to not render if it is empty, but adding some padding to it causes it to render. How do I add padding to the content, but only if content is present?
.someElement{padding-top: 5px;}
HTML in question:
<div class="someElement">With padded content</div>
<div class="someElement"><!-- shouldn't render since it has no content --></div>
Basically, I'd like the second element, above, to not take up any space. I'm testing in all major browsers, using XHTML 1.1 doctype.
You can do the trick with the CSS3 pseudo-class :empty
.someElement
{
// your standard style
}
.someElement:empty
{
display:none;
}
Sadly Internet explorer doesn't support that feauture yet. For all the other browsers it shall do just fine...
Give the element an id attribute. You can then use Javascript to check it's innerHTML property once the page has loaded. If innerHTML has a length of zero, then you can set it's display property to none. This page might help if you don't know your javascript.
This is still a mucky way to play. If you know the element shouldn't be rendered before you serve the page it would be better to omit it altogether. If you don't want to omit the element, just hide it, then force it into hiding; style="display: none"
<style>
.someElement{padding-top: 5px; display:table;}
</style>
<div class="someElement">With padded content</div>
<div class="someElement"><!-- shouldn't render since it has no content --></div>
Adding display:table; should do the trick.
Give the empty element a different class (say someHiddenElement) when you are generating the content. Then add someHiddenElement { display: none } to your style sheet.
If it's necessary to have the div.someElement in the HTML, the best CSS/HTML way to do that would be to add an extra div around the added content that has the padding property
.someElement > div{padding-top:5px;}
<div class="someElement"><div>Content</div></div>
Otherwise, do as Pekka says, or take a look at having javascript do it for you.
I can't think of a CSS only way to do that.
I would try to decide whether the element is rendered at the time I know whether there will be any content in it. That is probably the cleanest solution.
Don't use padding on container, use margin on content. Than when there is no content, container remains invisible.
At the point where you populate the optional div, if there is no text to put in it, try changing the CSS display property to none. According to this source (and others), display: none removes the element completely from the document. It does not take up any space, even though the HTML for it is still in the source code.