[Top]
More advice for the full screen mode.
   
Sivut toimivat riittävän hyvin MS IE 4.0+, Opera 5.x+, Netscape 6.0+/ vast. Mozilla ja Konqueror 3.x selaimilla. Yleisesti ottaen sivut toimivat parhaiten uusimmilla Opera selaimilla. Sivujen toimivuus vanhemmissa selaimissa on heikko, erityisesti Netscape 4.x kohdalla.

I list below all topic groups, which I have done according to subjects, which they handle. You can return to this topic group by using this menu and the link Table of topic groups on the top of the each page.
 
 
Search:
[Help]
Table of topic groups > Front page of CSS-guide > Guide pages > 8. How to set CSS for backgrounds and borders > Backgrounds and borders for HTML and BODY elements (section 4/6)

Backgrounds and borders for HTML and BODY elements

Especially using nested frame sets, it is reasonable to use borders to the actual content of the document as I have done. But it causes problems in short pages. This can in principle be accomplished to the element BODY at the following way:

body {border: 1px #603 solid;}

When you use borders to the whole document, it is also remarkable to set margin and padding at the following way, if the purpose is to get as many browsers as possible to display documents quite same way:

body {border: 1px #603 solid; padding: 10px; margin: 0px;}

At the sight of CSS the BODY element doesn't however differ from the DIV element. Concerning background properties in HTML 3.2 bgcolor and background attributes are for the whole canvas but in CSS the HTML element represents the whole canvas. Even if the whole available canvas has not been used, background properties for the HTML (or any other root element) element concerns the whole available canvas. Browsers are however free to set the default dimensions of BODY so that that BODY concerns the whole canvas.

Setting borders and background properties for the BODY element causes problems in short pages. The problem is, that without setting the height according to the standard working browsers border and background properties might end just after the end-tag </BODY>. If pages are short the place of the bottom border might vary with some browsers in every page. With background image(s) the result is ugly, because the background image(s) might continue after the bottom border! Concerning just borders the result is nicer, if borders have been set for the HTML element and the element has also height:100%. In long pages the problem is that according to the CSS-specification working browsers border are not necessary in every side of the page because they scroll among the page.

For shot pages might need to define an additional DIV element for the whole document and for it height with percentage values (for example height: 97%) in order to get rid of this problem (alternatively the height value can be set also for the BODY element). If the element DIV has some top and bottom margins scrolling borders are not very big visual disadvantage.

Browser-specific notes:

  1. Without padding values for the element BODY Opera "glues" borders to the text of the document (or to the borders of the inner block box). This is as such correct because CSS doesn't define default behavior for the BODY element (UA style sheets might define it). So-called default browser offset can be either like padding or margin values.

  2. In short pages some Opera and Mozilla Gecko browsers might set the bottom border immediately after the </BODY> but don't cut background images at the same place. That is incorrect because excluding the root element background should not go outside the borders of the element.

  3. MS IE 4.x can't render borders for the element HTML (MS IE 5.0+ Windows, Opera 3.6x+ and new Mozilla Gecko browsers render them). With some tricks CSS can be defined so, that MS IE 4.x for Windows reads borders for the element BODY, but other browsers, which use the same style sheet has borders for the element HTML (I explain the principle to the trick in the extra page, which handles MS IE problems[S]).

  4. Any MS IE doesn't render margins for HTML outside border like new Opera and Mozilla Gecko browser do. Older version ignores margins and borders and newest render margins inside borders (a model page[S]).

  5. Netscape 4.0x is so bad that it must pass by using the import rule, because it might crash by defining borders to the whole document.

  1. MS IE 4.x-5.5 for Windows "solves" all border problems by acting against the CSS2 standard (MS IE 6.0 for Windows behaves at the same way if it is not in the standard-compliant mode[S])! It defines borders, which are set to HTML or BODY elements according the viewport. It seems that MS handles individual pages like the element FRAME and sets that's why background and border properties to HTML and BODY according to the edges of the viewport. MS IE doesn't however handle elements BODY or HTML as the element FRAME (MS IE doesn't however handle element BODY or HTML as the element FRAME because frames and frameset can get own CSS).

    The result is nice, because the border is always in each sides of document, if the border is set to all sides (Opera and Mozilla Gecko browsers scroll borders along the document and whenever some side have no border). If fact the solution Microsoft is less problematic than the strict CSS2-implementation.

    In Mozilla Gecko browsers borders can be set for the viewport by using the proprietary :-moz-canvas/:canvas pseudo-element. ::canvas and/or ::viewport pseudo-elements could be good also in the selector module the official CSS3 specification and I send a proposal concerning this matter.

  1. This solution cause however background problems. MS IE counts the possible fixed background image from the outlines of borders and not from the edges of the viewport as it should. This cause positioning difference compared to Opera 3.62+ and Mozilla Gecko browsers. If pages have wide borders, the difference is great. I made a test page[S] - note that the width on the screen must be wide, when you visit in the test page). I took some screen capture images from the top of the viewport and I got following test results:

    • Opera 5.01[S] - positioning of elements is correct. I got an e-mail message, where was told that MS IE 5.0 for Mac rendered the test page correctly.
    • Mozilla 0.6[S] - all exact defined positions are correct, but floated block (I handle them in the page 11[S]) cause a white "stripe" (this matter is fixed in Mozilla 0.9). In my mind the floated blocks could be in the same row.
    • MS IE 5.5[S] - background image positioning and positioning of fixed blocks (position:fixed; I handle this definition in the page 11[S]) are incorrect.
    • MS IE 6.0 preview[S] - background image is positioned correctly, but the positioning of fixed blocks are incorrect.
  2. The behavior of the BODY element has been fixed in the 6.0 versions and it behaves like a DIV element. Elements HTML and BODY can create two level background for the actual content.

It is just now impossible to define borders (and sometimes also background images) so, that all modern browsers would show them at the same way.

I made a proposal, which could solve at standard way the problem which are related with borders for the BODY element. It is in the page CSS and HTML in the future[S][Pw]. The solution can't however always used because it has two limitations:

  1. Background to the whole document can't be in two level like it can be in the Netscape 6.x+ and in Opera 4.x+. This site use two level background (different background colors to HTML and BODY elements), which doesn't work in MS IE. A screen capture of two level background colors[S].

  2. It is impossible to define the root element with same CSS to different XML-based languages, for example to XHTML and SMIL (S yncronized M ultimedia Integration Language): html, smil {width:500px; margin:auto; border:10px solid black; background: #603 (someBackgroundImage.gif) center center no-repeat fixed;}.

[Top]