[Top]
More advice for the full screen mode.
   
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]
To the normal page

8. How to set CSS for backgrounds and borders

Topics

I have divided this page into sections, which handle following topics:

The content as a one big page

Common

Background and border properties are not automatic inherited. Otherwise than HTML 3.2 to HTML 4.0 document background properties, which concerns the whole document can give also HTML, not only to BODY. The only browser, which handles these properties according to the specification is preview-versions of Netscape 6.0. IE 5.0 works so much against the standard that it scarcely ever goes according to CSS specifications.

[Top]

Background properties

Relative simple background definitions are not problematic and they can be defined only to element BODY like in HTML 3.2 documents. Most used background properties are in the following example ([M][S][Pw] - they are commonly expressed as shorthand properties[S][Pw], but now I express them as individual properties and I explain shortly, what they mean):

body
{background-color: white;
background-image: url(./Taulut/kierrevihko.gif); /* this correspond normal HTML 3.2 level background image definition */
background-repeat: repeat-y; /* defines if the image repeats or or not and how it repeats */
background-attachment:fixed; /* defines if the image scrolls along the document or not */
background-position: 2px 0px;} /* defines the position of the image */

The background-color value can be also transparent, when the color of the parent element shine through. Even if some validator services suggest to set always the background-color property if the color property is set, this is not always reasonable. It is enough that the background color of the element BODY works well with used text colors.

Values for background-repeat: repeat (default value), no-repeat, repeat-x, repeat-y (y=repeat in vertical direction; x=repeat horizontal direction).
Background-attachment:fixed or scroll (background don't move / scroll among the document (default)).

Background-position: %, numerical unit or keyword value. Values are counted from the edges of the elements except background-attachment:fixed when values are counted according the viewport (= current window). In percentage and numerical values in first is distance from left and then distance from top. In the next table are keyword and their corresponding percentage values (I have emphasized values, which are marked at the same logic as corresponding percentage values):

top left or left top
top, top center and center top
right top or top right
left, left center and center left
center or center center
right, right center and center right
bottom left and left bottom
bottom, bottom center and center bottom
bottom right and right bottom
0% 0%
50% 0%
100% 0%
0% 50%
50% 50%
100% 50%
0% 100%
50% 100%
100% 100%

Background properties can give to any element - especially a:hover, a:active, a:focus can be very illustrative using background properties. Read about this matter from following pages (all pages don't have return links - use instead alternative windows):

W3C: CSS1: CSS1 Test Suite; CSS2: 14 Colors and Backgrounds; 14.2.1 Background properties[Pw].

My recommendations:

  1. I recommend to set background properties for the whole element both for HTML and BODY elements. Be sure, that between previous mentioned elements is no border, margin or padding. The most lest problems with background is when non-transparent JPG-images has been used.

  2. Images must have high quality. Images should be tested in many applications. If some application can't read images those images should not be used.

  3. If you set background position values, set always two values. I recommend to use pixel or percentage values. Don't use combinations like 10px center.

  4. Don't set background properties for :first-letter and :first-line pseudo-elements.

  5. I don't recommend to use background images for the :hover pseudo-class.

Browser-specific notes:

  1. background-color: transparent doesn't work correctly in all browsers, because some browsers set the background-color according to the BODY-elements in situations, where they should not to do it. Some browsers might need this value to image links with pseudo-classes (a:link img, a:visited img {background-color:transparent}) even if the background color of underlying element should as default shine through. Setting sometimes certain background colors and sometimes transparent color cause also problems and all background-color values don't work.

  2. Background properties for HTML and BODY elements don't always work in MS IE browsers, if pages are inside framesets. In MS IE 4.x for Windows the combination transparent GIF + background color newer work with the HTML element.

  3. Opera doesn't support backslashes (\) in background image path names (for example .\images\image1.gif).

  4. Both beta and official version of Opera 7.x browser can't use some GIF-images as backgrounds (also some other applications like MS Windows XP has problems with them and image, which Opera has problems don't work in Windows XP as thumbnail images). Randomly but quite seldom Opera has also problems with background colors. I handle a special matter in an [S], which handles Opera.

  5. Combinations like background-position: 10px center don't work properly at least in some Mozilla Gecko browsers.

  1. The keyword and percentage values (for example center and 50% 50%) to the background-position property don't work always properly in Opera 5.12. Horizontal percentage values work and they can be used together with vertical pixel values, for example 50% 200px (this bug have been fixed in the Opera 6.x series). Indeed in the CSS1 Test suite these values work with the P element. This matters seems to be element dependent and at least Opera has difficulties with the BODY element. I recommend to use the following kind of definition, which I have used in this page:

    <style type="text/css" media="screen">
    <!--
    div#first {background: white url("../Kuvat/Css/Tree.gif) no-repeat 100px 65px;} /* media types print and projection have their own definitions */
    -->
    </style>
  2. Opera doesn't support background images for dynamic and link pseudo-classes[S] (fixed in Opera 7.0 Beta 2).

  3. If tables or table cells have transparent background images Opera renders only in tables/ table cells the background color of the ancestor element, not the background image of it.

  4. Background properties don't work in Opera 7.x for :first-letter.

  5. Background properties for the :first-line pseudo-element crashes MS IE 5.5 for Windows.

  1. Positioning of the background image might cause that the background goes over other elements in MS IE 4.x for Windows.

  2. If the background image is a GIF-animation, Opera 5.x and older browser version render only the first image, not the whole animation (this matter has been fixed in the newest versions and I have tested this matter with Opera 6.04).

  3. MS IE, Opera, Mozilla Gecko, Safari (Mac) and Konqueror (Linux) support PNG images but MS IE 4.x-6.x and Opera 4.x-5.x don't support transparency of PNG-images. In some Mozilla Gecko Linux-browsers at least partially transparent PNG-images work very bad. In Konqueror some PNG-images work bad.

  4. background-attachment:fixed works only in quite new browsers. In my tests with MS IE it works only for elements HTML and BODY. In Opera 4.x+ and Mozilla Gecko browsers it works wider. Indeed Opera scrolling might cause temporary broken texts. In addition Opera 6.x calculates the position incorrectly according to the container element, not according to the viewport as it should be calculated (fixed in Opera 7.0 Beta 2).

  5. The definitions of the place of the background images don't work in Netscape 4.x browsers.

  6. Netscape 4.x doesn't correctly read relative references. If you want that background images works also with Netscape 4.x read my hints[S][Pw], how you can define relative references to Netscape 4.x.

[Top]

Border properties

Borders can be on every side (top, bottom, left and right) different. You can define different width-values (border-width), colors (border-color) and styles (border-style). Color and width properties can define as to any other properties, but there are also three keywords: thin, medium (the default value which is used, if the border width has not been set) and thick.

Border styles in CSS1 are dotted, dashed, solid, double, groove, ridge, inset, outset and the value none (it gives to the border width value 0). CSS2 have also property hidden, which is like previous, but takes the space like border: hidden 5px;.

If you want visible borders, the width and color are not necessary to define. If the border color has not been defined browsers should use the text color of the bordered element. Browsers need however the style of borders, because the initial value is none, which means that elements don't have any borders.

W3C: CSS2: CSS2 8 Box model; 8.5.3 Border style[Pw].

Here is an example of border definitions to the element BLOCKQUOTE (all definitions are not necessary reasonable, but however fully working ([M][S][Pw])):

blockquote
{padding:10px; /* padding to the text, which is inside the block quote (you can use also use to padding and margin values as shorthand properties according to the model, which is in the following examples); margin can have negative values, but negative values to padding are not allowed */
border: olive 5px solid; /* common shorthand properties to borders, which can later define another time; It is not possible to give different values to all side in this definition; They can be defined only by using following sub-definitions */
border-style:inset; /* in this example all side have the same style; this definition replace the value solid in the previous definition - each of the three following definitions replace always the previous definition */
border-style:inset outset; /* here the first value concerns top and bottom borders and the second left and right border */
border-style:inset outset inset; /* here the first value concerns top border, the second left and right border and the third bottom border */
border-style:inset outset inset outset; /* here the first concern top border, the second right border, the third bottom border and the fourth left border (the clockwise order) */
border-width: 10px 5px 10px; /* values works at the same logic as border-style properties and the last give value replace the first given value */ }

You can also look at some example from the page How to put CSS into Web pages[S][Pw].

Generic notes:

  1. Borders are like frames, which are set outside the elements. The only intrinsic dimensions, which they have are the thickness of them. How borders are taken account calculating dimensions of elements is depending on the width attribute or property.

  2. Borders can in theory define also with the outline property (for example butoutline:#660033 1px solid;). All edges are similar. The basic level difference with the property outline defined borders compared to the border property is the fact, that outline should not change the position of any element and it is not counted to any dimensions. It can go over all content of the document. I refer to this property also in the page 6[S].

  3. Because all kind of borders concern presentational features of element, the task of CSS2 is to able to delete all kind of borders or change their presentations. Concerning images (<IMG border=""...>) there is no basic level problems. Because browsers use by HTML defined borders as if initial properties, the type of borders is not necessary to define with CSS. <TABLE border> the situation is more complicated. CSS2 have special rules, how borders are handled in tables (I handle border-related matters in tables in the the page 10[S]).

  4. In theory CSS should be able to alter also borders of all form elements, but CSS2 doesn't have enough properties to define correct presentation for them (I handle forms later).

Browser-specific notes:

  1. MS IE interpret keyword-values thicker than Opera and Netscape (there is no instruction values and IE don't proceed against the specification). If you want exact the same width with all browsers, you must use numeric values.

  2. Styles dotted and dashed don't work with MS IE Windows browsers earlier versions than 5.5.

  3. Opera 3.51+ supports all visible borders. Newer versions support also the value hidden like Mozilla Gecko browsers.

  4. If the border colors have not been set MS IE use in tables a shade of light gray as the border colors. It is another of the colors, which the border attribute sets for table element.

  5. Outset and inset don't work with black in MS IE 5.x. The result is always different, because MS IE use more shades than Opera and Netscape. The reason is presumably that MS IE use for the TABLE element proprietary attributes, for example bordercolorlight="#eeeeee" bordercolordark="#1111111".

  6. The property outline has been worked in my tests only in some Netscape 6.x preview-versions and in Opera 7.x. I refer to the property also in the page 6[S] and CSS notes[S].

[Top]

Backgrounds and borders for forms and frames

To apply CSS onto gathering form elements (FORM and FIELDSET) are free from problems because they fit to the existing box model of CSS2 (these elements are clear block level elements).

I had an e-mail conversation with a worker of Mozilla org. According to an e-mail response it is totally questionable to apply CSS for form control elements (BUTTON, ISINDEX, LABEL, LEGEND INPUT, OPTION, OPTGROUP (the element is supported only in new Netscape/Mozilla browsers), SELECT and TEXTAREA) because they don't conform to the CSS box model. Form controls cannot currently be described in the language of CSS (what display type, for example, would a button get?). Attempts to hack styling onto form controls are usually problematic because there is no standard how to do.

My personal opinion is that all properties, which are not depending on certain box model browsers should be able to apply to form control elements. Then at least text and font style properties should be able to use in them. At this point of view all modern browsers work fine.

The difference can be partially explained, how bordered form control elements (for example SELECT) should be overall interpreted. They are exceptional elements. They can be interpreted as if embedded objects, like the element IFRAME, which has as default frame borders. Browsers don't replace frame borders with CSS. They can be taken off only by defining frameborder="0". The style of frame borders resemble the borders of form control elements when for example the borders of the element SELECT can in principle interpret so, that it has as if frameborder="1", which can't be redefined. In this case CSS-borders becomes outside of normal borders and the element gets double borders. Because most form control elements have in HTML natural borders unlike TABLE and IMG elements, which can define borders with an attribute, borders are exceptional attributes of form elements.

Elements FRAME and FRAMESET should have borders like IFRAME.

Because CSS-borders remove or replace by HTML defined borders for TABLE and IMG elements, the replacing principle is also logical, but in this case form control elements are understood differently - more like ordinary elements, not like embedded special objects. At this way the generic principle of CSS (I have mentioned it in the page 1b[S] can be implemented better.

A member of the working group of CSS in W3C said, that browsers should have to right to use so-called widget libraries, because the usage of widget libraries is much faster. Form control elements can be borrowed from the platform, when it is not possible to change the borders of them. I would however reasonable to give for Web-authors change border, but then browsers can't anymore borrow form control elements from the platform. Because the usage of CSS might overall increase download times of Web-pages, the author should be always responsible, if he wants to create slower working pages by using CSS. The browser should not make the decision instead of the author! Missing features will be added into the CSS3[S], when form control elements can be implemented at standard ways. When the CSS3 will be ready, W3C should oblige browser designers to follow it.

W3C: User Interface for CSS3.

My recommendations:

  1. I recommend that you would define for form control elements just font-related properties and widths.

  2. If INPUT elements have been used as buttons, don't define for them border and background properties. I regard defining borders for any form control element quite qestionable.

  3. Don't define for INPUT elements heights with CSS. It would be also reasonable to avoid using the padding property.

  4. Don't change the presentation of conventional frames with CSS.

Browser-specific notes:

  1. Older versions of Opera (4.x and older) and Netscape don't support even all these text properties for form control elements.

  2. According to an e-mail Mac browsers handle form control elements totally differently. For example Mac IE 5.0 SELECT resemble a button and it is not rectangular.

  3. Form buttons look in many browsers better without background and border properties by using CSS. MS IE for Windows XP, MS IE for Mac use rounded form buttons. Also some skins of Opera 7.x use nice rounded form buttons.

  4. Opera (until the 6.x series) doesn't support background properties for form control elements.

  5. The functionality of CSS-borders is extremely bad in Netscape 4.x, because applying CSS-border onto the SELECT element destroys the functionality of the element.

  1. Until 6.x series Opera adds borders to elements SELECT, OPTION and TEXTAREA outside of the original borders. Opera interprets previous mentioned form control elements as if embedded objects borrowing them from the platform. Starting from Opera 7.x Opera renders forms exect radio buttons and OPTION-element like Mozilla Gecko browsers. It is not possible to set for OPTION-elements different color and background properties than for the SELECT-element and background images don't work for OPTION-elements.

  2. MS IE for Windows, Mozilla Gecko and Opera 7.x+ browsers CSS replace original borders with the element INPUT in certain circumstances (<INPUT type="text">) and with the element TEXTAREA (in Opera 7.x+ and Mozilla also with the element SELECT but MS IE doesn't support CSS-borders for this element).

  3. Dynamic pseudo-classes work with form control elements only in Opera 7.x+ and Mozilla Gecko browsers.

  4. Opera 7.0 Beta 1is the only browser, which renders correctly the BUTTON element. In newer Opera brossers don't work display:block. In Mozilla Gecko browsers don't work the text-align property.

  5. Among Mozilla Gecko browsers dimension calculation principle are different for form control element. In order to get as exact result as possible -moz-box-sizing:border-box or -moz-box-sizing:content-box should be added (into CSS3 has been added the property box-sizing, which I handle in an [S]).

  1. Mozilla Gecko browsers give proposals how form control elements could be rendered with a browser, which supports CSS3. I took a screen capture[S] from Mozilla 0.7. If you can, test the example form below with Opera 5.x+, MS IE and Netscape 6.x+ browsers ([M][S][Pw]):

    *{font-family:Verdana, Arial, sans-serif; font-size:14px}
    form {border:1px solid black; background-color:aqua; padding:10px;}
    fieldset, isindex {border:1px solid black; padding:2px; margin:2px; width:100%}
    fieldset#first {background-color:white}
    fieldset#second {background-color:olive;}
    fieldset#third {background-color:lime;}
    legend, label {font-weight:bold; color:red; border:1px solid red; background-color:white}
    select, input, textarea {border:2px outset red; background-color:#ffc; width:200px; font-weight:bold}
    optgroup#two {background:aqua url(./Css/Kuvat/pallo.gif) no-repeat; padding-left:16px;}
    option, textarea, input {background:#ffc url(./Css/Kuvat/pallo.gif) no-repeat; padding-left:16px}
    button {background-color:#ccc; border:3px outset gray; padding:10px; width:200px} input[type="radio"]{height:15px;}

    The aim of CSS is to replace presentational features of HTML as far as possible. Concerning <INPUT type="radio"> it is open question, if according to CSS3 the radio button should have additional rectangular borders around it or should CSS-borders replace the original border.

  1. Even if Netscape 6.x+ can alter the presentation of all form elements, if forms are used in XML-documents, CSS2 doesn't have enough rules and properties to express all natural properties of form element. For example official CSS-specification don't handle at this moment rounded borders, which are used in radio buttons. Indeed Netscape/Mozilla use proprietary CSS to define presentational features in /res/forms.css, when in principle it could implement presentational features of forms in XML. I handle proprietary features of Mozilla in my CSS How to set CSS for table elements(form-related pseudo-classes[S] and outline[S]).

  2. Opera 7.x+ support outline, but it doesn't work properly with form control elements.

  3. Width and height properties of form control elements are in MS IE 6.0 DTD-dependent[S]. Defining heights might cause remarkable different results in different browsers.

  4. CSS works with FRAME and FRAMESET elements only in MS IE in situations, where the framesets have actual contents. Mozilla Gecko browsers hide normally defined CSS behind the defined or imaginary frame documents. If the defined documents can't be found with Mozilla 1.1a it is possible to define border and background properties for FRAME and FRAMESET elements (with some older versions it is only possible to get visible border properties for the FRAMESET element).

[Top]

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]

Special problems

Topics

Inline and block level elements

CSS2 defines quite complex rules for different element types. This matter cause many problems.

Ordinary non-replaced inline level element (for example STRONG) should not get width and height properties. Instead replaced elements, for example IMG, can get them. Non-replaced text elements can get the line-height property and they can affect to the line height also by the font-size property because vertical margin and padding-values should not affect to vertical space, which elements should take. Concerning ordinary positioning and line height values replaced inline elements should behave like non-replaced inline elements.

Possible border and background properties for non-replaced elements may cause the situation that rows overlap each others. With replaced elements positive margin, padding and border values should increase the line height so that they always fit to the line.

Vertical margins normally collapse, which cause for example that the same bottom and top margin value for two block level elements cause single single margin value, not double margin.

W3C: CSS1 Test Suite: sec42.htm and sec44.htm; CSS2: 8.3.1 Collapsing margins.

In HTML 3.2 encoding the positioning of inline and block elements are poor defined by using align and valign attributes. Sometimes they define the positioning of inline elements and other contents inside some block element. Sometimes they define the position of the block element itself in relation to the surrounding parent element.

Concerning horizontal positioning these two matters are totally separated from each others. The property text-align concerns all inline-level contents, which are inside block elements. Then text-align:center means the centralization on inline elements and inline-level content. This property should not affect to the positioning of block-level elements and it has no effect to inline-level elements.

The definition margin:auto should cause centralization of block-level elements in the horizontal direction but not vertically.

The vertical alignment has the property vertical-align (possible values are: baseline, top, bottom, middle, sub, super, text-top, text-bottom + positive and negative percent or pixel units (the latter doesn't belong to the CSS1 values). It affects normally inside block boxes to the vertical alignment of inline level elements. Inside table cells it has the same task as the valign attribute (only values top, middle and bottom can be used). By setting for an individual cell/entire table some height and a cell the valign attribute or the vertical-align property it is possible to center elements vertically. If for the BODY and TABLE elements have been set as the value of the height 100% or a little bit less the element can approximately set vertically to the center of the page. Indeed the CSS2 specification itself[S] has the problem that vertical centering doesn't work for any block level element.

Below is an example of a block element with some comments ([M][S][Pw]):

p.special
{border:1p solid blue;
text-indent: 3em; /* indents the first row */
margin:10px; /* this is related to the containing block (normally it is the parent element, but not in cases, where elements are absolute or fixed positioned (I handle at that way positioned elements in the page 11[S])), which have the paragraph; Negative values are allowed; Remember also shorthand properties to margin and padding! */
padding:10px; /* padding to the text, which is inside the paragraph; negative values are not allowed */
text-align:justify; /* horizontal alignment of the text; Other values are: left; center and right */
vertical-align: top;
/* this value isn't inherited and it affects to the respective vertical alignment of text and other elements in blocks */
font: normal small-caps 120%/120% fantasy;

Authors may use inline elements incorrectly and put inside inline elements block level elements. Be careful to use correctly inline elements if you want that all blocks are displayed properly. Don't put block level elements inside inline level elements (I handle the usage of elements also in an extra page[S]).

The only elements, which according to (X)HTML specifications you can use both as inline and block level elements are INS and DEL. But you can't used them at the same time as inline and block-level elements.

Browser-specific notes:

  1. If inline level elements have been used outside blocks MS IE shows CSS for those kinds of elements in most cases like for blocks. But setting CSS-properties for new Netscape/ Mozilla Gecko browsers must be careful. I have found that incorrect usage of inline elements cause extra line breaks and CSS-properties don't work as they are intended.

  2. Implementations vertical-align vary very much. I recommend to test especially the functionality in different browsers using the CSS1 Test Suite. It works relative well at least in new Mozilla Gecko, Opera 4.x+ and MS IE 5.5+ for Windows browsers.

  3. I don't recommend to use to the TD element vertical-align:middle, because it cause problems to some browsers. Vertical centering using tables doesn't work in Opera 7.2x browsers.

  1. Because Mozilla Gecko browsers give for images (IMG) in the standard mode[S] according to the CSS2-specification as default vertical-aling:baseline, lonely images inside table cells have empty space around them. It is possible to get rid of this problem in some cases by defining vertical-aling:bottom for images. Because other browsers use different default value, this problem is not in other browsers.

  2. MS IE 4.x-5.0 for Windows have a serious implementation deficiency in inline elements, because borders don't in normal cases work with non-replaced inline elements. If the author set the height property, the browsers renders borders but incorrectly (look some example from the error page[S][Pw]; You can look also some example from the page, which handles illegal definitions and hints to avoid problems[S][Pw]).

    MS IE 5.5+ works correctly, if the height property is not defined. The property height works with ordinary inline level elements in MS IE 6.0 for Windows in the standard-compliant mode[S] only if they have display:inline-block, when the browser behaves according to CSS3 (I handle the display property in the page 11[S]).

  1. Netscape 4.x renders borders but the same kind of error behavior as MS IE 5.5 with the height property.

  2. text-align affects in MS IE 4.x for Windows the positioning of the table elements. text-indent might cause extra left marginals with MS IE 5.0 for Windows. Text-align:justify worked in my tests correctly only MS IE 5.x+ for Windows and new Mozilla Gecko browsers (Opera makes some errors, if block elements include some inline elements, which don't fit into the same line, but normally it works fine). Netscape 4.x can display only in very simple documents.

  3. Browsers implement at various ways collapsing margins incorrectly. I have a test case for this[S].

  4. margin:auto work according to my tests properly only in Opera 4.x+, new Mozilla Gecko, MS IE 6.0 for Windows and Konqueror for Linux browsers (and on the base of a screen capture also in Safari for Mac). In order to center horizontally block level elements in elder MS IE browsers it is reasonable to set one CENTER arond them. Because some Opera and Mozilla Gecko browsers might ignore the effect of the CENTER element, margin-left:auto; margin-right:auto is also necessary.

[Top]

Dimensions of block boxes

It is in many situation reasonable to define height and width properties to block boxes, which have borders. This has some problems.

The first problem might be due because of the fact that in HTML specifications width and height attributes have been counted sometimes differently as in in CSS2. In CSS previous mentioned properties are always content dimensions, which don't include possible padding, border or margin values. Sometimes in HTML width and height attributes include paddings and borders - the dimensions of the whole block box.

The content width means a reservation box for some concrete content, for example and image, which has certain width. For example into a block, which has width:200px should fit following elements:

<IMG src="..." alt="..." width="200" border="0">
<DIV style="width:200px; border-width:0; padding:0; margin:0">...<DIV>
W3C: CSS2: 8 Box model, 8.1 Box dimensions[Pw], 10.2 Content width: the 'width' property[Pw].
Other sites: Web Design group: CSS Properties[Pw].

This dimension problem can partially solve by using an extra element level or extra element levels. The outer element level defines the total dimensions and to the inner block is defined margin, padding and border properties. At this way at least the width is the same in all common used new browsers. In tables this can be done so, that table cells don't have padding values an the content of the cells is always inside some block element. In tables it is possible to give padding with the cellpadding attribute, which can override with CSS.

Below is a code example of both cases ([M][S][Pw] - in the end of the page is a new test block):

td, th, div.containerBlock {padding:0; margin:0; border-width:0; width:200px} /* padding:0 eliminates the effect of cellspacing="10" */
div.containerBlock div, th div, td div {margin:10px; padding:10px; border:10px solid black}

<div class="containerBlock"><div>
Content.</div></div>...

<table summary="A content example" cellspacing="10">
<tr><td><div>
Content.</div></td></tr>
</table>

CSS3 offer the possibility to choose the best algorithm (I handle this matter in the page, which handles problems of the specification[S]).

 

The second problem is that how strict dimensions should be interpreted. With HTML attributes defined tables dimensions are the minimum value. At this way can't do in ordinary blocks. If the content doesn't fit to the given value, rest of the content goes over the borders - in worst case over the other content.

In CSS2 this problem can be solved with min-height, max-height, min-width and max-width. The alternative way is to define overflow:scroll or overflow:auto, when the content, which doesn't fit inside the block can be scrolled.

Instead of huge quantity of layers, it is simpler to set basic CSS for most browser so, that pages work relative well without JavaScript. Browser-specific CSS is just for browsers, which really need it (look at as a model the source code of this page). The need of special CSS is all browsers different because browsers have different bugs.

In addition of matters, which I have explained, users might have toolbars on the right and left. If they have 800x600 monitor, the usable width of the viewport (window) is about 730 pixel.

My recommendations:
  1. Don't give padding and border properties for elements, which you want to set exact width values (one pixel wide borders are in most cases harmless).

  2. If you use a DIV-element as the main container block set for child-elements horizontal margins (it is necessary to set for tables in order to set in nested tables margins only for the outermost table levels).

  3. If you want that the main content is in the center of the page in all browsers define for the main container block margin-left:auto; margin-right:auto and add around it a CENTER element without any dimensions.

  4. Avoid using exact vertical dimensions. If you want to set for elements minimum height do it at the following way:

    div.someClass {height:...px} /* for such browsers, which interpret height as minimum heights */
    div[class="someClass"] {height:auto !important; min-height:...px} /* for such browsers, which interpret height and min-height as different properties */
  5. Define the width for the content so that it fits to the 800x600 display. In the example below the width has been set for a DIV element as the basic block:

    body, html {padding:0; margin:0}
    div.basicBlock {margin:10px; width:710px} /* the formula is 730 pixel - margin for the main container block */
    p, h1, h2, ... {margin-left:20px; margin-right:20px} /* it is not necessary to set dimensions for other blocks, just margins */

Browser-specific notes:

  1. MS IE for Windows browsers calculate the width and height properties incorrectly (they include also possible paddings and borders) until MS IE 6.0 for Windows, if the browser doesn't work in so-called. standard-compliant mode[S]. MS IE 6.0 for Windows like MS IE 5.x for Mac has the "DTD-switch". MS IE 6.0 works quite correct except concerning the element TABLE and the value 100% doesn't work. For example body.CssSite {width:100%; border-width:0; margin:0; padding:0} cause sometimes the horizontal scroll bar even if it should not cause it! In MS IE 5.x for Mac the DTD-switch works properly also in tables (I handle dimension problems of tables in the page 10[S]).

  2. MS IE 5.x Windows counts the box dimension more incorrect, if the block box and the margins to the block box are set with percentage values. I tested margin:33%; width:67%. MS IE 5.x Windows counts the width of the block according the available space, when the left margin is taken off, not from the content width of the parent element. This calculation style might cause to Opera and Netscape browsers horizontal scroll bars, if pages are optimized according to MS IE 5.x Windows -versions. I took two screen captures:

  1. Dimension problems can try to solve by using attribute selectors, which MS IE doesn't support. these properties for generic block level elements. (compare box dimensions to the "measurer sticks" besides the blocks - they show the correct dimensions ([M][S][Pw]):

    div.nav, div.nav2 {padding:10px; border: 10px solid black} /* note, that in principle borders and padding values should increase the size of the whole block box! */
    div.nav {height:180px; width:180px;} /* height works as the minimum height of the whole block box in MS IE even if it should not do at that way; If the browser doesn't support attribute selectors, the box dimensions should be 220x220 pixel */
    div[class="nav"] {height:auto; min-height:160px; max-width:160px;} /* because the content doesn't necessary fit to the previous height value for Opera 4.x+ and Netscape 6.x+ have been given new properties with an attribute selector, which MS IE doesn't understand; height:auto eliminates the effect of height:180px; Note, that I have taken off the padding values from width and height dimensions! */
    div.nav2 {height:160px; width:160px}
    /* a comparison block, which should have equal dimensions */

    I got following results, which following screen capture images shows:

    • Mozilla 0.6[S] - exactly correct.
    • Opera 5.01[S] - renders horizontal dimensions correct, but the min-height is the same as the minimum height of the whole block box; It behaves normally like in MS IE 5.x Windows the property height.
    • MS IE 5.5[S] - total dimensions of both block boxes are too small. With the used DTD MS IE 5.0 for Mac and MS IE 6.0 for Windows browsers should render blocks, which are on the right side of the main test blocks correct.
  1. Widths and heights, which use percentage values don't work neither properly with positioned elements (I handle problems of absolute positioned elements in the page 11[S]).

  2. MS IE interprets height loose and to MS browsers height means the minimum height, which can be exceeded, if the content doesn't fit to the given value. But Opera and Netscape 6.x interpret them in ordinary blocks strict.

  3. Properties min-height, max-height, min-width and max-width work for generic block elements only in Opera 4.x+, Mozilla Gecko, Konqueror (Linux) and (on the base of a screen capture) Safari (Mac). Because I want to that the user can use this site in a narrow window, I don't have given fixed width value. Fixed width values are in my mind harmful. I hope, that MS IE could some day support max-width etc., because they are the ideal way to control the dimensions of basic structures.

  4. overflow:scroll and overflow:auto don't work in Opera 6.x browsers. They work at least but only in MS IE 4.x+, Mozilla Gecko and Opera 7.x+ browsers.

  5. The height property has also a problem, which I have explained, when I handled inline and block level elements.

  6. Mozilla Gecko browsers cause a problem, which I handle in the page Lists[S].

  7. It is possible to create for MS IE browsers by using JavaScript encoding functionality, which resembles max-width (I explain this matter in another extra page[S]).

  1. When I tested this with percentage values (div.doc {width:99%}) with MS IE 5.0, the browsers doesn't rendered all content if images don't have pixel values.

  2. Because with to the BODY and HTML don't work in all browsers, it is recommended to use a DIV (or a TABLE) element as the basic block box.

  3. Because browsers might have default padding or margin values to the element BODY, the padding and margin values must be defined.

  4. In the last note of the previous section I handled margin:auto problems.

The next page handles lists. It is also important to know, how to define CSS to list elements in avoid to serious problems.

[Top]