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.

Gathering 1

(This gathering includes the short content, preface and 1-12 numbered guide pages. This gathering is primary for printing (about 150-155 pages) and reading the printed document offline.)
Start page

Table of contents

The longer version

Page classifications

General info pages


Index pages


Guide pages

  1. What are basic structures of HTML and XML documents (CSS2 2)
  2. How to put CSS into Web pages (CSS2 1, 3-4)
  3. What are color, units and keywords in CSS (CSS2 4)
  4. What are selectors, classes and id-attributes (CSS2 5-6)
  5. What is the processing order of CSS (CSS2 3, 5-6)
  6. How to set CSS for texts and different media types (CSS2 7, 13, 15-16, 18)
  7. How to set CSS for anchors and links (CSS2 5)
  8. How to set CSS for backgrounds and borders (CSS2 8, 14)
  9. How to set CSS for list elements (CSS2 12)
  10. How to set CSS for table elements (CSS2 17)
  11. What is the visual formatting model of CSS2 (CSS2 9-11)
  12. What other special features CSS has (eg. CSS2 19, CSS3 UI)

Extra pages

  1. What are purposes of Web standards
  2. Which problems are the CSS2 specification
  3. What conceptual schemes and term trees relate with CSS
  4. What are semantics of (X)HTML elements
  5. What kind of non-standard (proprietary) CSS browsers support
  6. Some advice how to design CSS files
  7. What JavaScript tricks can be used with CSS
  8. What CSS-features I have used in my pages
  9. How to design dynamic menus
  10. What are user style sheets
  11. How to use CSS with XML documents
  12. What is the situation of XML and XSL today
  13. What kind of problems WAP has
  14. What CSS-implementation errors are in browsers
  15. What CSS-implementation errors are in MS IE browsers
  16. What CSS-implementation errors are in Netscape/Mozilla browsers
  17. What CSS-implementation errors are in Opera browsers
  18. What CSS-editors and application are available
  19. What are some speacial advances using CSS



Practice pages


Preface and important information



Originally my CSS-pages have been Finnish CSS-teaching pages (CSS-opetussivut) and I have called them as CSS-Teaching pages. Today they are rather a generic guide into CSS and my purpose is to develop these pages more and more as a guide. I have called them also Introduction to CSS but my CSS-pages are more than just introduction because they handle CSS quite deeply.

My CSS-pages have been linked from the CSS site of W3C. I have got good estimation about the contents of my English CSS-pages but several bad estimations from the language. Below are some examples:

The English is poor (which is understandable since English is not your first language). For example, you have "Block elements should not put inside in-line elements", which should be "Block elements should not be put inside in-line elements". "Remark that in the end-tag is the forward slash" should be "Note that in the end-tag is the forward slash". There are so many small English errors like these that the text is difficult to read.
The contents are good and I have no doubt that the Finnish version is an excellent resource, but the English version is still very hard to read. Every sentence is close to being correct, but not quite. It makes reading very slow, because you have to constantly correct the grammar in your head... Nearly all sentences have errors in the word order in the correspondence between verb and subject or they have words that are close in meaning, but not normally used in that context.
... They are the most comprehensive tutorials I have ever found on the 'Net ... I have stopped reading at section 4 because it was getting too difficult ... many of your English sentences in are quite unenglish. Some I can figure out by the context, but others take several seconds each. Their accumulation hinders the reading too much ... But I think your tutorial deserves a wide audience. Working on the language would be a big step in such direction.

I have corrected informed errors, but I have still much errors. I have got assistance to get better language to some pages. I hope that gradually the language could be better in all pages.

Finnish visitors excluding one person have given good estimation about the content of this site. The best estimation concerning the presentation is following, which is translated approximately following:

The smartest site in the Internet, if we take account how much information it has...

Today I have only link to the Finnish version (Some non-English resources: > Finnish: tutorial).

These pages are intended for both people, who are newer before used CSS (and hardly knows anything about HTML) and professionals, who are searching for new tricks. If you are not familiar to CSS, don't try to do everything in the first trials. I try to learn you at the grass-root level so, that you could climb from bottom to the top of the tree. Put your mind just the three, because I tell you about a tree in this site!


One of the aims is also to promote fair play[S] in developing new browsers and web sites.

Pages are translations of my Finnish CSS teaching pages. That's why some file and anchor names are in Finnish and some in English. Every page have a link to the Finnish version (En) and the Finnish page to the English version (En).

This site includes also practising tasks page[S], which has some related files like the teachers' test page[S] and collected.css[S] (I have validated the file, but I have not added last made CSS to it). Save them, learn to create CSS and enjoy your own style sheets!

I have made all my drawings with Expression 2, which is a new generation vector drawing tool. You can look at the possibilities of this application from my site Art (you find it from the link books or use this link). The handling of lines is fantastic! (The prize for new users is 139$ and it is reasonable from such a fine application.)

Other sites: Creature House Home Page.


Important information

W3C: CSS: Cascading Style Sheets, level 2 CSS2 Specification (Zip-file), CSS-validator.
Other sites: HTML-Kit Home Page[Pw], CSS Enhancements in Internet Explorer 6 Public Preview, Webstandards.


1. What are basic structures of HTML and XML documents



It is easy to make HTML-pages. There are many applications, with which you can do pages even if you don't understand just nothing about the code structure of HTML. Those application view pages almost as you see them in a browser window. These kinds of programs are called as WYSIWYG-applications (What You See Is What You Get).

A Web-document

This level of making pages is not enough, if you want effectively use CSS. It is at least at some level necessary to understand the structure of HTML- and XML-documents in code level. Section 1-4 give common introduction to HTML and CSS. I handle in these sections primary HTML-encoding and in the last section XML-encoding. If you are familiar with HTML, you can skip some sections and continue directly from HTML 4.0 + CSS and the aims of CSS. I recommend however, that you read some behavioral notes from the page Help for TM CSS menu.


Generic about elements and the basic idea of HTML

The basic structural parts of all HTML and XML documents (I explain later, what XML means) are elements. The main task of elements is to create clear structure, but they have also other tasks. The meaning of the structure you can understand by comparing following two pages:
Text without any structure:[M][S][Pw].
Text with a simple structure:[M][S][Pw].

In order to separate elements from the content of the document, they need some special encoding, which are called as tags. Tags mark the beginning and (in most cases also) the end of elements (I write about start-tags and end-tags or I use other corresponding words like starting tag, closing tag and termination tag). Because they mark elements, they are exactly written element tags.

HTML base on SGML (Standard Generalized Markup Language). SGML is a generic language to describe the structures of used document languages. It have tools to define individual document types (I handle later closer different document types). SGML is not as such a markup language but a meta language to define markup languages, which are both machine and human readable.

Gentle Introduction to SGML.

In the SGML documentation is written about tags following (I emphasized some parts of the text):

Markup that describes the structure and other attributes of a document in a non-system specific manner, independently of any processing that may be performed to it. In particular, SGML descriptive markup uses tags to express the element structure.

They are called as descriptive markup because they describe, where documents have elements. Tags are the most important markup codes in HTML documents (HTML and XML has also some other markup codes and tags, which I list in the Footnote 1[S][Pw]).

The name of the element is called as the generic identifier of the element and it means different matter as tag as you can see from the following cites of SGML and modularization documentations (I emphasized some parts of the text):


Generic identifier (GI) = A name that identifies the element type of an element

Modularization of XHTML (Terms and Definitions)
Descriptive markup delimiting the start and end (including its generic identifier and any attributes) of an element.
W3C: CSS2: 4 CSS2 syntax and basic data types, 4.1.3[Pw].
Modularization of XHTML.

Indeed the name of the element together with delimiters works to the browser as an element identifier (what are delimiters can be seen from a conceptual scheme[S][Pw]), where I use in the example the element HTML). It is however incorrect to say, that the whole tag is an identifier, because the start-tag may have several identifiers (I handle this matter later)

In SGML elements don't have any specific tasks, but in HTML they have defined tasks. The main task is however the same as in SGML to express the structure of documents. The name HTML comes partly from the idea, that starting and termination tags mark areas - that's we speak and write about a markup language.

In fact tags are like stamps, which are hit among the content to the start and possible also to the end of elements in order to certainly separate elements from other code. I hope, that you could understand this matter also from the animal metaphor. This animal has normally some tags. Not however just these tags, which I have drawn to this picture! Let's think that the name of our document is Cow.html.

A cow, which have HTML element tags

The another main task of elements in HTML is to create links. HTML was original designed to be extremely simple language to create documents, which have hyper links (they are either links inside the document or links between documents). That's why we talk also about hyper text and HTML (Hyper Text Markup Language - originally HTML included only text links). In the early HTML-documents other than linking elements were primary as assistance codes, which made the text more readable and clear organized ([M][S][Pw]).

Elements, which can get both start- and end-tags can work as element containers to other elements and contents. These elements can be as parent elements to child-elements (elements, which are inside the start and end tags of the parent element without any other element levels between them; I handle this point of view more thoroughly later in this site). Parent elements can have content models (corresponding an element, which is a child-element of some other element, can have parent models).

Some elements can't have closing tags, because they don't mark any areas. They are called as "empty elements".

An example of usage of elements P (paragraph) and BR (forced line break), which look out following, if you watch at it from the source code ([M][S][Pw]):

<P>This text is inside starting<BR>
and termination tags,<BR> but it does have some BR-elements,
<BR> which create forced line breaks.</P>

Footnote 1. An example of standard document definition file is http://www.w3.org/TR/REC-html40/loose.dtd. DTD-file includes following declarations (... = the content of the declaration):

W3C: loose.dtd (HTML 4.01).

Elements, <!ELEMENT ... >
Attribute lists, <!ATTLIST ... >
Parameter entities, <!ENTITY % ... "..." >. They are so-called DTD-macros, which collect in DTD-files used values, attribute or elements, for example <!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">. I explain the usage of them in two pages (Help for HTML All[S] and Help for TM wappush[S]).
Common entities/ general entities, for example <!ENTITY amp "&#38;">. In standard DTD-files they are either listed or referred with addresses. They are needed in order to display certain characters, which are used in the source code. For example displaying this sign < on the screen. The sign begins with &, in the middle is the text lt and ends with ;. Accented characters should mark as entities, for example ä = ä (used for example in Finnish and Swedish texts) and ç = ç (a Spanish/Portuguese character). Text, where entities are converted into certain characters is called as PCDATA (Parsed Character Data; look at also the reference #PCDATA[S]).

Common entities are one of the other markup codes, which I have referred.
Markup codes = element tags, comment tags, common entities. In addition XML use markup codes and ]]> to exchange the parsing mode. All, which is inside them are read as literal (CDATA = Character Data). In HTML 2.0 and HTML 3.2 this was accomplished with some obsolete elements[S].


Block and inline level elements

Besides the classification elements to normal and empty elements, HTML-encoding has another main classification. The document body has two main element types, block-level elements and inline-level elements. The previous create surrounds as if an invisible rectangular box and line break before and after the element.

Block elements can be classified into some sub-classes. Common block elements are H1-H6, P, BLOCKQUOTE, OL, UL and TABLE. Block elements can usually include other block elements (there is however some exceptions, which I don't handle) and inline elements. For example this text is inside a block element! The primary task of block level elements is to work as structural, grouping and organizing elements of the content of the document.

There is two kinds of inline elements. First those kinds of inline level elements, which affect some way to the text. For example B and I belong to them and they are called as inline presentational elements. Most of these kinds of elements have certain semantic meaning. Previous elements can be expressed also with semantic elements EM (emphasized) and STRONG - this kind of elements are called as inline phrasal elements. These inline elements can be nested with each others without any limitations.

W3C: Modularization of XHTML (used terms).

These kinds of inline level elements don't create round them rectangular boxes like block-level elements. They look like a phrase in a line. The text can wrap from line to line and it might broke from different places. Inline elements, which affect to the text are commonly used to highlight some parts of the contents.

When I was in the university, some students used a thick yellow felt-tip pen in order to mark their books. I use at the same way the element CODE, which I mark as blue only those markup codes, which can be seen only from the source code - note, that the highlighted texts in this sentence have been marked with inline-level elements (CODE and STRONG).

An image of an element markup

Also the special linking element A (from the word Anchor) belongs to inline elements. It behaves like elements, which affect to the text, but is has the limitation, that links should not be nested.

Other kind of inline elements are those, which create rectangular boxes round them but however behave (unlike block elements) like a phrase in a line. These kind of elements could call according to the behavior as inline block elements. Some empty elements are as their characteristic inline elements and they behave at this way (for example IMG).

In general inline level elements should be used inside block-level elements. Some HTML versions allow to use them also stand alone, but it is not recommended to use them at that way.

It is important to set block and inline level elements correctly. The misuse is common and browsers tolerate it at some level. But it can also cause unexpected error behavior and crash the user agent. You can learn to use correct block and inline elements by reading notes to different specifications[S] and How to set CSS for table elements[S]. I defined to this site a special semantics[S] and you can learn also from that page something, how to use use elements correctly.


The document tree

Elements create to the document the document tree. The document has one root element, which in HTML-documents is just HTML (in XML document the root element can be different). Inside the root element is the invisible part of the document, which have as the main element the element HEAD.

In this case the metaphor is the human (or Animal) body. All of us have a head. Some elements has also a foot-part (like TFOOT = the (optional) foot-part (footer) of the table). Note that in metaphors the document is looked from bottom to top or direct from the front.

Elements inside the element HEAD contain for example some hidden information and possible parts of programming code, which affects some way in the document body. The element TITLE is the only visible element inside the element HEAD. The title of the document can be seen in the document window.

The main part of the document is inside of the element BODY. Elements in the document body, which have both start- and end-tags can create complex nested structures. They are like "branches" of the document tree (now you must think about the body as the stem of the tree). At this way the tree symbolizes the essence of documents.

A tree

I give next an example of a document tree, which document body has some basic block elements. I have presented the tree also with indented codes, which you can see how elements are nested with each others:


- META  (non-necessary (implied) element, which contain hidden information primary for search engines)
-TITLE (required element)

- BODY  - H1 (main header, which might have some inline-level font styles)
- P (first paragraph, which can include inline-level elements)
- P (second paragraph)
- BLOCKQUOTE (indented block level quotation, which can include other block-level or inline-level elements (B etc.)
- OL (an ordered list, which is a special sub-class of block elements)
- LI (an individual list element)
- LI (an another list-element; list elements can have many level of sub-lists)


There is also a model page of this document tree:[M][S][Pw].

W3C: CSS2: 3 Conformance: Requirements and Recommendations[Pw].


Total structure of documents


Attributes, declarations and comments

Elements can commonly have attributes, which are inside the start-tag of elements. Attributes have many tasks. For example they define the presentation of elements. Hyperlinks are primary done with the element A with some special attributes (href, id and name).

Because empty elements don't work as element containers, they can have some kind of content only by defining attributes. In some cases the element itself is replaced with the referred content. For example IMG elements are replaced with the images, which the attribute src refer (these kinds of elements are called as replaced inline (level) elements and other are of course non-replaced inline level elements).

Individual attributes have values. In a HTML 3.2 document the element P can have for example the attribute align="center", which means center this paragraph ([M][S][Pw]):

<P align="center">Here is an example of a paragraph, which have the attribute align="center".</P>

In order to better separate elements and attributes I write elements in upper case (like BLOCKQUOTE) and attributes (like style=" ... ") in lower case characters.

There is however two exception. The document type declaration is in upper case letters because of the common style. That doesn't belong actually to the structure of documents. It is not necessary to the browser. If the declaration has file name, it gives however to the browser the possibility to download the file into the memory of the computer. This information is however necessary for validator services and applications.

The declaration have the exclamation mark in the open delimiter (<!DOCTYPE ... >). W3C has created to standard document types DTD-files (Document Type Definition), where are declared all used attributes and elements, and where are also defined allowed element structures (as I have earlier explained, the definition language in HTML-documents is SGML).

It is like the ear-tag of a cow. The cow doesn't need an eartag, but the owner (and the authorities) needs it. Browsers know them without the declaration, but in principle just the document type declares the language, which the documents has been written.

A cow, which have eatags

XML documents might need document type declarations, because the author might made his own declarations. In XML-document is used another declaration (<?xml version="1.0"?>), which correspond the eartags of cows. When I refer to XML-elements I use always lower case characters.

Comments use following syntax, which I have also used in my examples (look at the conceptual scheme[S][Pw]):

/* this is a CSS-comment, which should be green with browsers, which can understand CSS-definitions */

Meaning of particles of documents

A simple HTML document consists of only elements, attributes and contents. I mean it primary ordinary text, which have own markup codes for certain characters (read the Footnote 1[S][Pw], if you want to know more about this matter).

Particles give to the document following basic meanings (I handle them in the priority order, which in my mind they had in the first HTML documents):

  • Content
  • Structure
  • Linking
  • Semantics
  • Presentation

The original idea of HTML is that it is primary semantics and structural language, not a presentation language even if some elements can be understood as presentational. The next section handles a little bit history of HTML.


From pre-HTML until HTML 3.2

First Internet documents were quite simple without just at all presentational features. Those kinds of document can be called as "pre-HTML" documents because they don't have any official specification.

First Web-documents

Look at first Internet documents from the introduction (Document types) of the page Help for HTML All[S].

W3C: HTML Home page[Pw].
Other sites: Dmitry Kirsanov.

Gradually people wanted more and more features, similar to what was available in word processors like Word and WordPerfect. This required additional elements and attributes, which can be seen in HTML 3.2.

In HTML 3.2 all attributes were inside elements and inside of the document BODY, as in previous versions of HTML. Content, structure, and presentations were combined in the same document except for linked images and embedded elements (for example, so-called Java-applets). It was quite easy to build these sorts of documents. The problems lay with static structure and presentation - once such a site has been built, changes made to the site's formatting are difficult to make, especially if there are much elements and attributes, which describe the presentation of documents.

HTML 3.2 lead the usage of HTML into a wrong track. Web authors tried to use HTML as a some kind of layout language, which it is not original designed and which it fits bad. HTML 3.2 was an intermediate solution, which was not intended to be so popular as it became.

Indeed if the site is automatic generated (for example with Java-servlets or Perl) and the content comes from a database, HTML 3.2 works quite well, because a link list needs only one template. It is not however possible to create with HTML 3.2 everything, which can be done with CSS. In most cases it is possible to create less code by using CSS, when pages are rendered faster.

The biggest advance with CSS is handwritten large teaching sites like this site. The second biggest advance is sites, which are partially handwritten and partially automatic generated. Someone can program the automatic generated part, some other person can create the handwritten part and third person can create with CSS the common presentation.


HTML 4.0 + CSS and the aims of CSS

With HTML 4.0 and CSS, the basic idea is to separate presentation from content. CSS works to assist the display of HTML. CSS means the following (I handle terms in logical order):

  1. Style = special style declarations and rules used to specify the presentation of elements (I handle them later thoroughly).
  2. Style Sheets = style declarations and rules are collected into sheets. A single style sheet is the location of one or more real or logical rules. These rules specify the presentation of a document (the specifications have some inaccurate definitions, which I handle in the Footnote 1[S][Pw]).
  3. Cascading = style sheets can be connected and cascaded - thus the reference to Cascading Style Sheets. Look at the logo of CSS - it shows the basic idea of CSS!
    CSS-logo - get it!
Cascading Style Sheets

CSS combines style declarations and rules from different sources. That's why the term is constructed as a plural (sheets). Styles have different weights compared to each others.

CSS is not however an independent language, because it can only be used to assist other languages (primarily HTML, XML and XSL). The term "formatting" refers primarily to visual formatting, but CSS can be used to format documents in other ways as well. CSS exists solely for the formatting of documents.

CSS is similar to scripting languages like JavaScript and ECMAScript, in that it can be used as small fragments inside the main document. Also, CSS syntax has some similarities to these scripting languages even if CSS is not a programming language.

CSS1 is a simple style sheet mechanism that allows authors and readers to attach style (e.g. fonts, colors and spacing) to HTML documents. It is not an actual layout language but rather very limited formatting language.

Instead CSS2 can be call as an almost fully featured layout language, because it can create most layout features, which are needed in web documents. Indeed CSS2 has some missing features. These are added into CSS3[S]).

If a browser were to have full implementation of CSS2, it would at change the character of HTML documents at a fundamental level because the formatting features of most HTML elements could be redefined. Then HTML itself would not be used just at all as a formatting language. CSS cannot, however, exchange the real order of elements (it can hide elements from the screen or reposition them - how it happens, I will explain later).

With it's methods of formatting and layout, CSS aims to:

  1. separate presentation from content.

  2. partially separate structure from content. CSS doesn't separate these two completely, because CSS can't exchange the real order of elements.

  3. give a more exact and much richer presentation to elements as was done in HTML 3.2.

  4. assist in making files more degradable.

  5. give basic documents simple structure.

  6. allow one document to have a different presentation in different devices. It is even possible to make aural style sheets for speech synthesizer and raised letter versions to braille and emboss device and create tactile media.

  7. be used in a variety of documents, including XML documents.

HTML 4.0 with CSS offers the possibility to return to the original idea of HTML - to go back to the roots! Extreme HTML 4.0 documents don't have any presentational attributes. All elements and attributes concern structure and linking and possibly embedded elements. Elements and attributes, which only describe presentation are not used (for example, elements FONT, B, I, U and attributes align, bgcolor). Some of them (for example B) are allowed, but not recommended, because the meaning of elements is primary to describe the structure and semantics, not the presentation.

All possible definitions that affect document presentation are commonly linked into separate files using format <LINK rel="stylesheet" type="text/css" href="stylesheet.css"> as in this example document ([M][S][Pw]):

<LINK rel="stylesheet" type="text/css" href="stylesheet.css">
Title text</TITLE>
The header</H2>
The first paragraph</P>
Second paragraph. <A href="html_document.html">Link</A >. The only necessary attributes are href and possible linked objects like images.</P>

In the style sheet stylesheet.css is a description of how the element H2 should display. This document (the one you are reading) also uses a style sheet.

CSS is a powerful way to replace HTML 3.2 presentational attributes while offering a richer presentation than HTML 3.2 could ever create. This is achieved simply, with a little code included in the document. CSS documents load quickly, but can be made very attractive when displayed on CSS-compliant browsers. The display is poor, however, on browsers which don't understand CSS. Old browsers, for example Netscape 3.x see pages almost like the first Internet browsers. That means HTML 4.0 strict!

Even if structure is described primarily in the document, it can be affected with CSS. Because declarations of element presentation are kept primarily in external files, the presentation of the whole site is easy to change!

It is however possible to make loose, HTML 4.0 transitional documents. They can have HTML 3.2 level elements and attributes, which are not used in HTML 4.0 strict. In fact some HTML 3.2 attributes are easier to use as to define corresponding CSS. Normal documents, which I write are always transitional documents.

This document almost strict, because I have used in the actual content of this page primary those elements and attributes, which are mentioned in HTML 4.0 strict.dtd (instead in individual links and links sets I have used such elements and attributes, which don't belong to the strict document types including the attribute target to the link element A; you read about the last mentioned attribute from the Footnote 2[S][Pw]). How old browsers can display this document depends on the default settings of the browser and exchanges, which the user has made to them. Test the difference! Compare a file with style sheets ([S][Pw]) and without it ([S][Pw]). The latter is like a HTML 2.0 document.

Note. HTML 4.01 (the fixed version of HTML 4.0) and CSS2 specifications are designed as implementable. Browsers should work as far as possible so, that specification, which they support can be implemented. We must however remember that specifications are under development and between them must be some kind of priority order.

If there are some conflicts between specifications, browsers should work according the newest specification, which they support. Older specification are supported as far as they can be implemented without causing conflicts with newer ones.

Because the basic idea of CSS is the possibility to define presentation elsewhere (for example from separate files), CSS must have priority to the relation with HTML, if both HTML and corresponding CSS has been given or if some HTML-element or HTML-attribute overall handle with some way the same presentational features as CSS.

In this site, I try to explain the following matters:

  1. What style sheets are (this page).

  2. Where style sheets can be defined (page 2). I give some practical examples how to create simple style sheets.

  3. Possible units and color values (page 3).

  4. When user agents (commonly Web browsers) handle style sheets in the rendering process (pages 4-5).

  5. Page layout details (fonts, anchors, links, backgrounds, borders and lists; pages 6-9).

  6. How to control document structures (pages 10-11).

  7. A glimpse to the future (page 12).

The last section handles after HTML 4.01 published XHTML-specifications and and XML. If you don't write XHTML or XML-documents you can skip the page and go directly to the page 2.

John Allsop: The key ideas of CSS[Pw].


Footnote 1. These definitions in CSS1 and CSS2 specifications are inaccurate:

a collection of rules
A set of statements that specify presentation of a document.

A single style sheet doesn't need to have many rules (a collection of rules (the same as a rule set) or a set of statements). It can have only one rule or not at all an actual rule like style="color:blue". But also those kind definitions create logical rules. The definition in CSS2-specification is true, when we interpret words a set of statements at the following way:
A set of statements = one or more actual or logical rules.

Footnote 2. Strict doesn't allow to use refers into frames. A member of W3C said, that frames are not well defined enough in order to belong into the strict definition. I removed one link in order to get this document accepted as HTML 4.0 strict. This document was for a while HTML 4.0 strict. Because I need necessary target-attributes in linking to other pages, I just can't create HTML 4.0 strict documents. I don't even regard as reasonable, that the strict definition doesn't allow the attribute target. Just target-attributes are used in opening new windows (people use normally target="_blank" and I use in this site target="new").





XML has been born from the special needs of commercial companies. HTML-elements are limited and they don't often describe the matter itself. In XML documents can use HTML-elements or create own elements, which are self-describing like <BOOK-CONTENTS>.

Would you like to create XML-documents?

Especially the purpose of Microsoft is to create large world-wide databases, which have the possibility to use elements and element patterns as searching criterion. Also mathematical science, chemistry could use own elements. Because there is no limits of possible elements, XML is extensible (eXtensible M arkup Language).

HTML documents have predefined presentations to elements. XML elements don't have any default presentation. Undefined XML element is just nothing! A way to give presentation to XML elements is CSS. If XML-documents use same elements as HTML-documents, the same CSS-file can be used in HTML and XML-documents (I made extra page about this matter[S]).

Another way is XSL (eXtensible Stylesheet Language), which have more possibilities to affect to the structure of XML-document. Microsoft favors it. It gives the possibility to set elements in another order with more powerful way than CSS. It is however remarkable, that favoring XSL is partially derived from the truth that the CSS implementation in Microsoft Internet Explorer is not ready. CSS can't give proper presentation to XML document using MS IE browsers.

If the implementation would be better, the case would be different. Shortly - the CSS-implementation of MS IE doesn't fulfil XML-requirements. It is possible to create good presentation to XML documents for example for Netscape 6.x+ and Opera 4.x+ browsers. I handle MS IE 5.5+ in extra page[S]).

The compatibility of XML-documents towards HTML 3.2 capable browsers is depending of the author of the XML document. In the worst case XML-document is to old browsers stick text with some special encoding (read the footnote 1[S][Pw], if you want to know, what I mean with special encoding) - in practice impossible or extremely difficult to read. In fact the author can create his own HTML resemblance language - XML is ideal language to "do-it-yourself " people! XML-document can however be quite readable to old browsers, when all or most elements are same as in the HTML-documents (they don't need however to behave at the same way in XML-capable browsers).


An XHTML (eXtensible Hyper Text M arkup Language) document is a special XML-document, which use primary the same elements as HTML-documents. It can be declared either as a HTML or XML document. But XHTML-document must always made according to XML rules, which are in some matters more strict than in HTML documents. First of all documents must be well-formed - it is not allowed to make as much encoding errors as before! Between ordinary HTML-documents and XHTML-documents are for example following differences:

  1. Documents might have the XML-declaration (<?xml ...?>), but it is not required. HTML-documents don't have at all corresponding declaration. Like HTML-documents XHTML-documents must declare as XHTML-document with standard DTD-information, for example <!DOCTYPE HTML PUBLIC "-//w3c//dtd xhtml 1.0 transitional//en" "http://www.w3.org/TR/xhtml1/"/dtd/transitional.dtd"> (in the strict DTD-document type is a tiny error - read the footnote 2[S][Pw]).

  2. The root element is always html and there is XML namespace declaration: <html xmlns="http://www.w3.org/TR/xhtml1/">.

  3. All HTML-elements and attributes are written in lower case characters. All elements are in XML-documents case sensitive. This kind of combination is illegal in XML-documents even it is valid in HTML-documents: <BODY>... </body>. If attributes have standard values, they must write with lowercase characters (for example align="center").

  4. All attribute values including those, which have only numeric values must be inside quotations. The attribute width=3 is not valid in XHTML-document. It must be width="3".

  5. Values for id-attributes are case sensitive (in addition it is worth to know that if for example for an A element have been set an identifier it is not enough to set just a name-attribute but instead or in addition of a name-attribute must use also an id-attribute, which has exactly the same value as the name-attribute).

  6. Elements are divided more strictly into normal and empty elements. Empty elements don't need in ordinary HTML-documents any kind of closing tags. This is not however valid procedure in XML-documents. Also empty elements needs some kind of clear termination. The termination is marked before the > -sign, for example <br /><img scr="image.gif" /> (when before the forward slash (/) is left a single space, all browsers can read the tag correctly). Then the opening tag is at the same time the termination tag. In HTML-document elements P and LI don't need necessary termination tags even if they are allowed (it is even recommended to give the termination tag for the element P - I use always termination tags to this element). This is illegal in XHTML-documents. It is also illegal to use in XML-documents <p />      or <li />, because those elements are not as their nature empty elements.

Below is an example of very simple XHTML-document ([M][S][Pw]):

<!DOCTYPE HTML PUBLIC "-//w3c//dtd xhtml 1.0 transitional//en"
<html xmlns="http://www.w3.org/TR/xhtml1/">
      <meta name="keywords"
      content="Opera,Mozilla,Netscape,Internet Explorer,CSS" />
      <title>An example XHTML document</title>

      <h1>The main header</h1>
      <br />
      <blockquote>Text inside a block quote</blockquote>
         <li>Text in a list.</li>
         <li>Text in a list.</li>

Pages of this CSS-guide are today XHTML 1.0 documents except model pages. It is easy to convert HTML-files into XHTML-files using the HTML Tidy utility, which is HTML-Kit (freeware). If you want to use same CSS-files in HTML, XHTML and XML-document, it is sensible to write names of elements always with lower case characters. I have tried to create my examples so, that they could be used also in XHTML-documents. To use scripts is however problematic, but I have used them like in normal HTML-pages.

W3C: XHTML 1.0 (4.8 Script and Style elements and C.4 Embedded Style Sheets and Scripts), Namespaces in XML[Pw].
Other sites: HTML-Kit Home Page[Pw]

The next page handle basic methods, how to use style sheets.


Footnote 1. DTD-files, which are used with XML-files are primary created according to the same principles as in HTML-files. Own common entities[S] (commonly abbreviations) must be declared. It is recommended to use CDATA sections[S] instead of common entities to express special encoding on the screen. If the author creates his own entities, the document is at some parts an-readable to old browsers. Old browsers can't know what own entities mean.

Footnote 2. In the XHTML 1.0 Strict DTD-file is an erroneous parameter entity declaration ( ), because it doesn't match to the attribute list of element A like it does in the DTD-file for HTML 4.0 loose (target %FrameTarget; #IMPLIED -- render in this frame --).


2. How to put CSS into Web pages


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

The content as a one big page


Sections two and three should be inspected through the main philosophy of HTML and CSS. The basic idea of HTML 4.0 is to separate presentation and contents so, that the whole site would be easy to modify afterwards.

Cascading Style Sheets

CSS can use three special attributes. The attribute style(style="...") is for direct style definitions. Attributes class (class="...") and id (id="...") are for external (linked) and embedded style sheets. I handle in this connection closer only the usage of the attribute style because I handle in this page just basid method to use CSS.



Style sheets are like collections of presentational attributes. In that mean CSS works at attribute level. The purpose of CSS is the same as HTML 3.2 presentational attributes in spite of the method how the presentation of the elements have been defined.

Presentational definitions inside style sheets are not however called as attributes but properties.

One CSS-property can replace several HTML-attributes. There is also situations, where replacing one HTML-attribute must define several CSS-properties even so, that they must define for several elements. If the HTML-attribute and CSS-properties handle the same presentational features, this matter doesn't have in the principle level any decisive meaning. The basic task of CSS is to be able to take off or change the effect of any presentational HTML-element or HTML-attribute. The only relevant matter is, if CSS can be overall applied to the situation.

Properties create declarations, which means one property with its value or a value set. An individual property definition inside a declaration has the following form: a property name followed by a colon (:) and a value or list of values. But you can define at the same time innumerable quantity of properties, but individual properties and their values must separate with semicolons (;), for example:

color:#660033; background-color:yellow;

Declarations are commonly inside so-called declaration-blocks, which use curly brackets ({}) as their delimiters. Below is the conceptual scheme of the declaration block (the author can set as much whitespace between curly brackets, semicolons and colons as he wants):

property value
{ color : #660033 }

The author of the page can define properties in most cases with two ways. He can define individual properties or use so-called shorthand properties, where he combines several properties together. It is common habit to use in backgrounds shorthand properties like this ([M][S][Pw]):

body {background: white url(background_image.gif) repeat-y 2px 0px;}

In the previous example the declaration-block contains only one declaration. You can give the same properties and their values also by using several declarations like in the next declaration-block (I don't explain in this connection, what those properties' mean):

{background-color: white;
background-image: url(background_image.gif);
background-repeat: repeat-y;
background-position: 2px 0px;}

All properties can't show as shorthand descriptions, but if they can, the principle is quite simple:
In shorthand properties all values are put one after another using a space and the section is closed with a semicolon. Also sub-properties can sometimes have shorthand descriptions like in this example:

body {border-top: 1px #660033 solid;}

/* compare it to the following declaration-block */

body {border: 1px #660033 solid;}

Style sheets inside style attributes

If style sheets have been used inside elements, thy have been defined inside style attributes. In this connection declaration blocks don't have curly brackets. Below is an example:

<TD style="border:1px solid #660033">

This method doesn't differ essential from HTML 3.2 attributes. This method is called also as using inline style sheets or just inline styles (this is a little bit problematic term, read the Footnote 1[S][Pw]). If you want to exchange afterwards CSS, which are inside elements, you must search them among other code as you must do in HTML 3.2 level attributes! This kinds style sheets could be called as element-level style sheets. Most elements can get them, but they can't be defined in HTML to the root element, because it can get in HTML 4.01 only language attributes.

Even if that style attributes are limited to element level, the usage of the style attributes have some some basic level differences to presentational HTML 3.2 attributes:

  1. CSS-definitions can be much richer. HTML 3.2 presentational attributes (there are also other kind of attributes) can have only single value at a time but CSS doesn't have this limitation.
  2. You can give to a certain element a limited quantity of attributes. This limitation is not in CSS-properties. They are not element dependent like HTML 3.2 attributes, but in certain circumstances some properties are discarded (I handle these kinds of situations in other pages in individual connections).

Even if style attributes are the less powerful way to use CSS-properties they are however useful for example in situations, when the author wants to define into a certain element the absolute position. Following properties give to the image 120 pixel position from the top of the HTML-document. You can add more properties into the style attribute or use HTML 3.2 presentational attributes in order to give more adjuncts to the element ([M][S][Pw]):

<IMG src="../Kuvat/Css/omakuvaIso.gif" style="position:absolute; top:120px;">

Use style attributes with consideration! Think first, if you really need them or could you still use some other method.

Browser-specific notes:.

  1. Netscape browsers don't tolerate curly brackets inside style attributes (this matter is not however so simple and I handle problems in the Footnote 2[S][Pw]).

  2. Direct CSS can be read by all CSS-capable browsers and that's why it is non-recommended way to use CSS. Netscape 4.x has serious problems and it should have an own CSS. I handle in a separate page[S][Pw], how to pass it reasonably.


Footnote 1. The problem of the term inline style sheets (or rather inline styles) is that the word inline is commonly used as opposite to the word block. Both describe the natural behavior of elements. If the term could be consistent with this use of the word inline, inline style sheets should be used only as inline-level elements, for example from the element EM. It could fit best to the element SPAN, which is particularly designed to inline-level style and language passing.

In this case the term inline styles the word inline doesn't describe the behaviour of elements. It means simple style sheets, which are inside the document body in style attributes (style sheets are embedded to the source code). When I asked about this matter, I got the following answer:

Yes, inline has two meanings: something can be inline in the source or in the output... An inline style is a style that is embedded in the source, an inline element is an element that will look like a phrase in a line on output... Most people talk about "inline style" or "style attribute",...

The expression inline styles sounds relative good. Indeed for the people like me, who don't speak English as their native language, the different usage of the word inline might cause confusion. I write also about element-level style sheets.


Footnote 2. There has been disagreement what it is the correct syntax of declarations, which are inside style attributes. Some applications accept style="{}", which tells much better, that style attributes includes embedded declarations. But this is against the normal HTML attribute syntax, and Netscape accepts only style="". According to David Baron this is correct. But if I think about this matter deeper, I disagree. It is only an agreement, that the dominating syntax is normal HTML attribute syntax. Today style-attribute has the same kind of syntax as so-called javascript, which use also ";" as the separation mark like onClick="uusikkunaa(); if(browser) nayta(10, 'b')".


Linked and embedded style sheets


External style sheets

In my mind it is always sensible to create external CSS-files, if you have three or more documents, where you want to use CSS-properties. Define to the separate file basic styles, which you want to use in your whole site!. Then we can speak about site-level style sheets.

Properties in external files have the same function as style attributes. For example p {color:blue; border:1px solid blue;} has the same effect as <P style="color:blue; border:1px solid blue;">. The latter definition is not however given directly to the element, but indirectly using an external file. If not otherwise especially defined p {color:blue;... concerns all paragraphs in the document (I explain later in this site what is the purpose of definitions, which are before the declaration-blocks). Properties inside a style attribute concerns only one element ([M][S][Pw]).

The effects are in both case quite the same as some HTML 3.2 presentational attributes. Using external CSS-files it however possible do the same effects as HTML attributes without using any attribute in the body parts of HTML-documents.

When you use external files, give to the file name like basic_stylesheet.css and link it to your HTML-document. Below is an example of the format of the link relation:

<LINK rel="stylesheet" type="text/css" href="styleSheetFile.css">

The code must be in the HEAD-part of the document. You can link to your own folders by using relative references or use for example core stylesheets of W3C. Below is an example of a link one of those style sheets:

<LINK rel="stylesheet" type="text/css" href="http://www.w3.org/stylesheets/Core/Modernist">

External style sheets should not have any HTML-encoding! Don't put any HTML tags or comments to them. Below is an example of very simple external CSS-file:

/* Don't use HTML-comments. Use instead of them CSS-comments. */
body {color:#333333; background-color:aqua}

I recommend that you validate CSS-files with the W3C CSS-validator. It can be installed also as an offline version to HTML-Kit but I have found, that it doesn't work properly.

W3C: CSS validator.
Other sites: HTML-Kit Home Page[Pw].

It is possible to refer external style sheets also by using the import (at-)rule. I explain in the next section of this page, how to use it. I give you also some examples, how to use external linked style sheets.


Embedded style sheets + the import rule

Embedded style sheets mean sheets, which are "embedded" to the same document before the element BODY between <HEAD></HEAD> tags using the element STYLE. We can call them as document-level style sheets.

I recommend to put into those definitions properties, which you use only in one document. You can override properties in external CSS-files. If you for example want to use in a certain document different background-color and background-image properties, define only them. You don't need to define another time all values. They stay in use, because the browser handles first the linked style sheet.

Following examples gives to the document yellow background with a new background image, which is in the center of the document and which doesn't repeat (you can see in this example also the right position of the element STYLE and it does have also a link relation to the external style sheets, where the document gets other definitions ([M][S][Pw]):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<LINK rel="stylesheet" type="text/css" href="external_stylesheet.css">
<STYLE type="text/css">
<!-- /* these definitions are inside HTML comments that's why that old browsers could pass them */
body {background: yellow url(new_image.gif) no-repeat center;} /* I explain in other connection, how to define background properties */

By using embedded or external style sheets it is possible to use the the import rule (@import; It belongs to at-rules, which I handle later in this site). In the first example you can see, how the import rule is used with the STYLE element ([M][S][Pw]):

<LINK rel="stylesheet" type="text/css" href="stylesheet.css">
<STYLE type="text/css">
@import url(external_stylesheet.css); /* note that at the end of the rule is the sign ; - without this sign the browser doesn't handle further definitions */

/* definitions, which belongs only to one document */
{font-family: Verdana, Arial, Helvetica, sans-serif; font-size:x-small;
padding-top: 10px;
padding-left: 32px;
padding-right: 10px;
padding-bottom: 10px;
margin: 0px;}
{color: #660033;font-family:Verdana, Arial, Helvetica, sans-serif;} /* remember, that this definition doesn't cancel imported definitions in other parts than again definite properties */
{font-family: Verdana, Arial, Helvetica, sans-serif; font-size:x-small;}

The other way to use the import rule is to put it in the beginning of external style sheets like in this example:

/* external_stylesheet.css - this is the main stylesheet; it is good habit to put a short description to the beginning of the style sheet about the contents of the style sheet */
@import url(another_external_stylesheet.css);
body {...} /* other definitions as usually */

Remember always, when you use the import rule, that the import rule is handled before other definitions. If there are several import rules they are handled in order starting from top. The basic idea of the import rule is that the browser reads imported style sheets as if they have been directly written in the place, where the import rules exist.

Browser-specific notes:

  1. The import rule doesn't work in Netscape 4.x browsers.

  2. MS IE for Windows browsers, which are older than 6.0 and also MS IE 6.0 if it doesn't work in the standard-compliant mode[S] it reads also import rules, which are after other definitions. Don't put import rules into incorrect places! Test the model page - in that page should not be exchanges made by the style sheet ([M][S][Pw]).

  3. The import rule has many serious problems, if the purpose is to create media decent CSS. I handle those problems in the page How to set CSS for texts and different media types[S].

  4. In MS IE Windows browsers (at least until MS IE 6.0) has the limitation of 30 embedded of linked style sheets.

  5. Because MS IE 3.02 understand only the last style sheet defined by LINK or STYLE elements, it creates its own problem, which I don't handle closer.

John Allsop: Managing Style at Large Sites[Pw]; Microsoft: BUG: 30 Style Sheet Limitation in Internet Explorer.

Alternative style sheets

Somebody might ask, why there is two ways to link to external style sheets (the import rule and using the LINK element). The basic difference between them is, that in principle the LINK element offers the possibility to change style sheet by defining alternate style sheets (rel="alternate stylesheet"). In order to give the possibility to choice between style sheets, it is necessary to use the title attribute.

W3C: HTML 4.01: 14.3.1 Preferred and alternate style sheets.

Browser-specific notes:

  1. Alternative style sheets work only in Mozilla Gecko, Opera 7.x+ and in the file explorers of Linux at least in Konqueror 3.1, which might use incorrect CSS-file. Because browsers don't keep them when going next pages they are in practice useless. Set alternate style sheets with cookies.

  2. Opera and MS offers the possibility to set user style sheets. Especially Opera 4.x+ gives very fast way to change between user and author defined style sheets. I explain this matter in an extra page[S].

I handle in the next page which kinds of values CSS-properties can get.


3. What are color, units and keywords in CSS


Units and keywords

In the size definitions of CSS-properties use either numeric units or certain keywords, which replace numeric units. Keywords are different to various properties and I handle in this page only common units and and keywords to font definitions.


In HTML 3.2 documents is only one exact unit and that is pixel on the screen like width="300" - the unit is not mentioned because it is always the same. Texts have relative units, because it must be scalable. Following keywords xx-small, x-small, small, medium, large, x-large, xx-large (for example small {font-size:x-small;}) have the same task as HTML 3.2 level size values (for example <FONT size="3">) and they can be used only to font sizes.

Font-related elements like other elements can use numerical units. As the possible decimal delimiter in numerical values is used dot. Numerical values need almost always the unit (otherwise as HTML 3.2 attributes) if values are somehow related with width and height values (the numerical value can express also some other matters, when they don't have units). The only exceptions are the line-height property (it is enough to put for example line-height:1.2) and the value 0.

Some properties can get a web address as their values. Values can be inside quotation marks, but it is not necessary (url("gif.gif") or url(gif.gif)). Quotation marks (' or ") are necessary, if names have spaces (for example font-family: "Times New Roman") and properties, which can have strings as their values (content: "this is a string";).

Concerning numerical units, some of them are relative and some absolute. The unit em is relative to the default font size of the surrounding element (it is so-called parent element; I handle this matter in other connection, but also this matter base on the position of the element in the document tree[S][Pw]).

The same kind of unit is ex, which the specification says:

ex: the 'x-height' of the relevant font.

It is also possible to use percentage values like big {font-size:120%} to almost any element.

The problem of relative values is, that they are an-exact. The advance of relative units is that the user can increase or decrease the font size. That's why it is recommend to use relative units in basic font definitions. Look at a model[S][Pw], where I have used several relative units).

It is possible to get better control by using absolute units. Following units are according to the CSS2 specification absolute (possible decimals are separated with a dot):

  • in = inches
  • cm = centimeters
  • mm = millimeters
  • pt = points - 1 point = 1/72 inch = 0,353 mm (printed, but not necessary on the screen, where it might be for example 1/96 depending the platform and screen resolution).
  • pc = pica - 1 pica = 12 points = 4,24mm

The specification tells, that px (= pixel) is relative to the viewing device (in the previous model was one paragraph, which use this unit). It is in principle relative unit concerning printing but absolute unit on the screen. The CSS2 specification recommends that browsers would count pixels also in printing as absolute values and browsers do so.

Pixels are reasonable in certain situations, when the font size must be fixed. For example link lists, which are made in table cells or narrow frames need absolute font sizes.

Absolute units are best in pages, which have special style sheets for printing (needs supporting of the media rule[S]). The printed version can be drastically different as the screen version. The unit pt is intended just for printing. The equal rendering can be guaranteed by using in, cm an mm values to all browsers, which support printed media.

Browser-specific notes:

  1. All browsers don't require units for height or width properties. In some browsers this matter is DTD-dependent[S].

  2. The default font size might be different in browsers, which might cause different result rendering relative font sizes.

  3. Keywords xx-small-xx-large don't exactly correspond with the attribute size and the interpretation of browsers vary very much. Small is the smallest recommended usable font size. With new Netscape/ Mozilla and with certain document types also the behavior of MS IE 6.0 for Windows for previous mentioned font sizes is DTD-dependent[S]. I have made a comparison page[S][Pw], which show differences between browsers.

  4. Some browsers can scale absolute font sizes, but most browsers can't scale them (Opera can scale everything).

  5. Browsers round percentage values a little bit different ways and relative size differences might vary.

  6. From font size definitions should newer forget the unit, because in addition that Netscape 4.x ignores the invalid value it ignores also all properties, which are defined after the invalid font size! I put to the bottom of the Model page an invalid definition ([M][S][Pw]).

Zeffrey Zeldman and Brian Platz: A List Apart.



It is possible to give colors with many ways. I recommend to use those two methods, which are also used in HTML-attributes (for example <BODY bgcolor="white" text="#3f3f3f" link="#3f3f3f"> - CSS supporting browsers use them if corresponding CSS-properties are not defined):

  1. Named colors as keywords (for example strong {color:red;}). Remember however that even common used 16 color names (aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white and yellow) are platform dependent.
  2. So-called hexadecimal values (= numbers 0-9 + characters a-f), which have in front of the definition sign # like p.special {color:#070e0e;} ([M][S][Pw]). Six digits' hexadecimal values correspond 24 bits (about 16,7 million colors) RGB-values (red-green-blue). Hexadecimal values can be expressed also shorter with three digits like {color:#00e;} (same as {color:#0000ee;}) , but then it is possible to use less colors.

Some people would however like to use RGB-values. In the following example all declarations mean the same color ([M][S][Pw]):

em {color: rgb(255,0,0) } /* RGB colors 0-255, it is possible to use always three digits, in this case 255,000,000 */
em {color: rgb(100%,0%,0%) } /* RGB colors 0-255 with nearest percentage values - note, that this system is not as exact as previous method */
em { color: red; } /* corresponding keyword */
W3C: CSS2: 4 CSS2 Syntax and basic data types, 4.3.6 Colors[Pw].

Browser-specific notes:.

  1. The CSS2 specification allows to use proprietary keyword color values. Opera 5.x series supports the 140 Netscape named colors palette, but many Opera browsers don't. I have listed color keywords[S] with corresponding hexadecimal and RGB-value in a separate page. In order to avoid incompatibilities use hexadecimal or RGB-values so, that main color values belongs to the web safe colors palette.

  2. New Netscape/ Mozilla use in the UA CSS[S] files some special color values (for example invert), which are intended as the internal usage of the browser. They could be however used generally in intranet solutions, which use Netscape/ Mozilla browsers. I refer to them in the CSS Notes 2[S].

  3. Some browsers accept incorrectly hexadecimal color values without the # sign (for example color:334455). In MS IE 6.0 for Windows and new Netcape/ Mozilla browsers this matter is DTD-dependent[S].


Special units

CSS specification has brought to the use of hearing defected people so-called aural style sheets and special units for aural devices (angles, times & frequencies). I'm not familiar with them, because in my mind they are today as future visions. They might be used with ordinary style sheets, when it is possible to exploit sound cards.

W3C: CSS2: 4 CSS2 syntax and basic data types, 4.3 Values[Pw], 17 Tables, 7.7 Audio rendering of How to set CSS for table elements[Pw], 19 Aural style sheets[Pw].


Error handling

In some cases browsers or other applications, which handle style sheets meets errors or unknown CSS. For example give property values can be invalid. User agents (UA) should follow certain rules to pass errors. Browsers should be able to skip properties, which are against the CSS1 and CSS2 specifications.

W3C: CSS2: 4.2 Rules for handling parsing errors[Pw].

Browser-specific notes.

  1. Especially MS IE 4.01-5.5 for Windows browsers tolerate much errors, which browsers should ignore. When MS IE 6.0 for Windows works in the so-called standard-compliant mode[S] it doesn't tolerate them much.

  2. Errors concern for example in units and keywords, which I handle in the next.

The next page handles selectors.



The basic method on CSS is to apply CSS-properties to elements according to certain principles. The browser must be able to identify elements. Excluding direct style attributes, the browser creates from element identifiers like patterns. That's why in CSS is written about pattern matching. In CSS and and documents, which use CSS must have matching pairs.


If the CSS is defined in external style sheets, they work like some kind databases (they correspond handwritten databases). To get CSS from external style sheets can compare situations, where the content comes from from databases.

CSS makes possible dynamic presentation updating. In embedded CSS the "database" goes with the document. It doesn't fulfil the idea of dynamic presentation updating in other way than the embedded CSS gets from server-side scripts from some external file.

In order to find pairs in the "CSS-database" and the current document, the browser needs so-called selectors. They select, what element or elements get defined CSS-properties. I introduce you in these pages into basic CSS2 selectors (like universal selectors, (element) type selector and class selector) and pattern matching rules.

W3C: CSS2: 5 Selectors; 5.1 Pattern matching[Pw].

In this page I handle also attributes class (class="...") and id (id="..."), because some selectors use them.

Selectors have different weights compared to each others, so they create the cascading order. I handle in this page that aspect introductory. In the page 5[S][Pw] I handle some selectors (first-child What are selectors, classes and id-attributes and adjacent sibling What are selectors, classes and id-attributes), because it is easier to process them in another connection. I collect in that page matching rules. I handle also deeper, in which order the browser should read CSS-definitions (what should be in the practise the cascading order). These two pages belong close to each others and I present matters a little bit different order as the official specification.


Basic selector types and grouping


Universal What are selectors, classes and id-attributes

Using the universal selector means, that defined properties are applied to any element. The browser doesn't try to find any specific element from the document. It just finds all possible elements, which CSS can be applied. Universal selectors have the lowest priority from the selectors.

A remembrance. As I have mentioned earlier whole tags are not identifiers, but something, which are inside tags work as identifiers. Concerning universal selectors, the identifiers are just names of the elements (generic identifiers) = tags without open and close delimiters and attributes. For example P or B work as identifiers (look at the term tree of the word identifier ([S][Pw]).

The bare universal selector is the most common way to select something. In the following examples is some other ways to use the universal selector in HTML-documents ([M][S][Pw]):

*{color:red;} /* the first sign is so-called wildcard, which is in this connection necessary; it is common habit to use wild cards (* and ?) in computer applications */
*.other {color:blue;} /* in this case the wild card in not necessary, because there is a separation dot and after the dot is so-called class selector, which I explain later */
.other {color:blue;} /* this is equal to the preceding way */

As you can see, selectors are connected into declaration-blocks (the explanation[S][Pw]). When a declaration-block has been affiliated into an announcement of some selectors, it is a rule. This is a very simple rule:

{font-family: Verdana, Arial, sans-serif;
font-size: 10pt;

The following conceptual scheme illustrates the relationships of different terms (the * means the universal selector or any other possible selector; The declaration-block can have multiple declarations):

selector property value
* { font-family : Verdana, Arial, sans-serif; }

Rules are called also as rule sets and statements. Exactly written rules are statement-blocks (or block-statements look at also the Footnote 1[Pw]). Simple rules and complex rule sets always 1) identifies the elements in a page that it affects and 2) tell the browser how to draw these elements (what are the properties of the selected elements).

Element type What are selectors, classes and id-attributes

The most common way is often too covering and in practice the universal selector has always some specifier. Element type selectors have the next higher priority. In fact the pattern matching principle begins really work from element type selectors, because the browser must search for individual targets. That's why the basic selector can be regarded a simple element type selector or just a type selector.

In this case the identifier is the name of an element. The following rule concerns the element H2 ([M][S][Pw]):

h2 {color:#660033; background-color:#ff3; border:#660033 1px solid; font-size:17px}

The element type name in the CSS-rule and the corresponding name inside start-tags create matching pairs.

Remember, that in XML element identifiers are always case sensitive. In XML the element type names in the CSS-rules and in the target documents must have the same cases.

Browser-specific notes:

  1. Into CSS3 has been added more XML namespace depending selectors (for example *|*, |* and ns|*, where ns is the XML namespace, which elements CSS should be applied). At least the universal selector related rules are supported in new Mozilla Gecko (for example Netscape 6.x+) and Opera 7.x browsers.

  2. MS IE 5.x+ support with non-standard way XML namespaces (ns\element).

W3C: CSS3 module: W3C What are selectors, classes and id-attributes (W3C Working Draft 26 January 2001).


So that same declaration-blocks should not be repeated to many elements, it is possible to use grouping. In a group can be called any type of selector with different combinations (I explain later, what some individual rules might mean). In this connection is elementary only to know, that individual members in the group are separated with commas. Here is some example of possible groups ([M][S][Pw]):

h1,h2,h3,h4,h5,h6 {color:red; background-color:yellow; border:red 1px solid;} /* in this group is only simple type selectors, which instead of separate definitions are defined at the same time; repeated commas are allowed and the list should not end with a comma */
h1, p.red {color:red;background-color:yellow;border:red 1px solid;} /* in this group the second member has class-specifier - I explain next the usage of it */
ol li, ol li li li {color:red;background-color:yellow;border:red 1px solid;} /* in this group is some matching patterns (I explain the usage of them in other connection) */

Footnote 1. The difference between statement and rule is, that statement has wider scope. Besides rules, which are connected to selectors, it includes also so-called at-rules (the list of at-rules[S]). CSS and HTML has also comments, which can be call as comment statements.

John Allsop: Statements[Pw].


Class selector, attribute selectors and id selectors


Common about class, attribute and id selectors

The matching criterion can be specified by using class and id (= identification) attributes and corresponding selectors: class selector or id selector. According to the CSS2 specification the names inside class and id attributes work as identifiers to elements.

The class selector is designed to many elements in the same document. The basic idea of using class selectors is to give the possibility to avoid the limitation of element type identifiers (element names). Using class selectors you can create as many "new elements" as you need.

Class and id selectors (like attribute What are selectors, classes and id-attributes, which I handle later) have higher weight as bare element type selectors. According to the HTML specification the name of the id attribute should be document-wide unique. The id attribute has been called also as the fragment identifier. In principle an id-attribute works as as an unique identifier of some fragment of a web page.

It is however remarkable that CSS-capable browsers accept in CSS the same value of the id-attribute in several places in a document. In practise id selectors could be used (against HTML-specifications) in several places in the same document together with class selectors. In this case classes would define common properties and an id selectors would specify exceptional properties. Indeed the problem is that if documents are intended to check with some validator services, they complain errors. The same result can however be achieved by using for the same element several classes (I give an example further).

  • The name must start with a normal letter (a-z,A-Z). Accepting the underscore (_) has been afterward added into CSS2.
W3C: Errata in REC-CSS2-19980512.
  • You can use also number + hyphen, but you can't start with them.
  • Names are case-insensitive in HTML and case-sensitive in XML.
  • If you want to use special character, you must put the escape character \ (backslash) before them like w\?. In theory it is also possible to use ISO 10646 characters 161 and above as a numeric code. It is possible to use character references inside style attributes (like style="voice-family: D&#252"), but these don't work in external files or inside the element STYLE (they need escaped characters with backslashes).

Browser-specific notes:

  1. Browsers accept illegal names. MS IE 5.x for Windows accepts them most. This matter has been fixed in MS IE 6.0 for Windows in the standard-compliant mode[S]. Also most Netscape and Opera browsers accept illegal names but less than MS IE 5.x for Windows. I have a a model page[S][Pw]in order to test this matter.

  2. Some browsers handle always the values of the class as case-sensitive, but some browsers don't. Use is rules, which refer class or id attributes in name the same cases, which are in the actual documents.

  3. I don't recommend to use any special character, because according my tests they work (at least partial) in Netscape 6.x+ and MS IE 6.0 Windows browsers.

Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.


Class and attribute What are selectors, classes and id-attributes


Class selector

In the following example is the element P, which have a certain CSS class-attribute. In the document body might be CSS class-attribute class="red" ([M][S][Pw]):

<P class="red">The text in this paragraph is red.</P>

This attribute has matching pair in the beginning of the HTML-document or in a separate CSS-file. Class="red" match to an element, which have the same class name. In CSS-encoding it is connected to other selectors with a dot like in this example:

p.red {color:red;} /* after the dot is CSS class-attribute */

In fact in this way the element has always two or more identifiers. First the element type name (P) and second the class name red. These two identifiers are combined together. If the class is connected to the universal selector, in practice the element can be identified from the class name (the universal selector doesn't select any specific element).

.red {color:red;}

This rule can be used (almost) into any element by putting class="red" to the start-tags of elements. Remark however, that syntactical the class selector is always connected into another identifier and rule.

In a way class selectors are attribute selectors, which use dots as separation marks (I give some examples later). CSS2 gives the possibility to use pure attribute-based selection method by using generic attribute What are selectors, classes and id-attributes, which can be understand as actual attribute selectors. In principle any attribute and its value(s) work as identifiers. Because class is in the semantic meaning an attribute, it should be able to express like any other attribute. I handle next attribute selectors.

It is possible to give for same elements several classes by adding spaces (for example class="a b c"), for example:

<blockquote class="code"> .a {color:black; border:1px solid black; blackgroud-color:white}
.special {color:red}
<div class="a special">

I don't however regard that kind of practise as very good. Properties might be contradictory. Browsers get additional work and the author of the CSS might get easily confused. If they are intended to use, the author must be especially careful.

Browser-specific notes:

  1. Class selector can be combined with another class selectors, if in the class attribute is space-separated list of classes, for example <th class="a b c">. MS IE browsers don't support properly combined class selectors. For example th.a.b.c should match with <th class="a b c"> but not with <th class="c"> as it does in MS IE browsers. Among class names a, b and b should be mentioned but MS IE takes account only the last name of in the list in the rule. MS IE behaves as if th.a.b.c == th.c. The actual name of the class can be in arbitrary place inside the class attribute, for example class="x b c a"). According to Erich Mayer combined class selectors don't work in MS IE for Mac.
  2. Netscape 4.x and MS IE 4.x forWindows doesn't support multiple classes for the same element (I tested class="noPrint b" and Netscape 4.79 didn't rendered a text as bold on the base of .b {font-weight:bold}).

Attribute What are selectors, classes and id-attributes

Generic attribute selectors are primary designed for XML-documents in order to ensure that CSS can be used with any XML-based language (some language require supporting of them). According to CSS2 rules like *.red {color:red;} and p.red {color:red;} are intended to use only in HTML-documents. In XML-document should not use these kinds of connected rules. In XML-document should be used universal selectors, element type selectors, attribute selectors and combinations of them.

Because XML is a meta language elements and attributes (except some basic XML-attributes) don't have any default behavior or task. Elements and attributes must be able to identify as such. Even if rules like .class {} and #id {} (I handle the latter rule type further) don't belong to strict XML-based languages browsers, which support XHTML are expected to support them. In XML-languages rules, which have the formats .class {} and #id {} should not be automatic accepted. The same concerns also the CSS, which is inside style attributes. They should work only if the used document type supports id, class and style attributes at the same way as in HTML.

Attribute selectors use brackets ([]). Attribute selectors use attribute names and attribute values as identifiers. They work together with other selectors like in these examples ([M][S][Pw]):

[href] {color:blue} /* according to this example all elements, which have the attribute href got blue color; only the attribute name is used as the identifier */
[class="example"] {color: blue;} /* every element, which have the class-attribute example got blue color; In this case the attribute name and the exact value is used as identifiers */
[class~="red"] {color:red;} /* every element, which have the class-attribute red, got red color; ~-sign is not necessary in this case; it can be used if class attributes have space separate list of values, for example class="green red" (the rule in this example concerns also this attribute) */
*[src] {background-color:blue} /* every element, which have the attribute src, get background-color blue; Note, that I have put in this case the universal selector (*) even if it is not in principle necessary */
span[class="example"] {color: blue;} /* the SPAN element, which have the class-attribute example get blue color; - Note that, the element type selector is attached to the attribute selector; Space between them exchange the meaning of the rule to this: SPAN elements, which follow an element, which has as an attribute class="example", got blue color (I explain later more carefully these kinds of rules) */
p[class~="red"] {color:red;} /* those P elements, which have as a class-attribute red got red color */

If class selectors are expressed as attribute selectors, they should have the same specificity. If there is two kind of definition, just the order of rules should matter like in these cases:

.test {color:red}
*[class="test"]{color:blue} /* this rule has the same priority as the previous rule, but it is after it and then overrule it; Some MS IE browsers understand this as an universal selector */
p.test {color:olive} /* this rule overrule the previous rule, because this is more specific */
p[class="test"]{color:green} /* this rule has the same priority as the previous rule, but it is after it and then overrule it */

You can look at more examples from the error page, how browsers should work[S][Pw].

Browser-specific notes:.

  1. MS IE browsers don't support attribute selectors, which are primary designed for XML-document.

  2. Attribute selectors work at this moment only in Mozilla Gecko, Opera 4.x+, Safari for Mac and Konqueror for Linux browsers. In 0pera 4.x-6.x they must be explicitly together with element type or universal selectors, for example a[target="new"] {...} or *[target="new"] {...}.

  3. The format *[...] {...} cause error behavior to some MS IE browsers. Use rather the format a[...] {...}.

  4. Attribute selectors can use also the | mark, for example th[class|="a"], when the class attribute has hyphen-separated list of values, which start with certain word. In combined rules, which use the | (for example td[class|="a"][id="a"]) Opera ignored the latter attribute selector (the previous mentioned rule should not match with <td class="a-b-c" id="b"< like it does in Opera).

  5. Mozilla Gecko browsers support attribute selectors for some fictional attributes - it could be said that they support "pseudo-attribute selectors" (look at CSS notes 1[S]).

  1. MS IE and Opera accepts rules, which are intended only to HTML-document. Both MS IE and Opera violate seriously the main principles of XML. They create to CSS-related attributes in XML automatic HTML-resembling default task, which they should not to do.

  2. The usage of attribute selectors is however reasonable, because I have remarked, that in some situations it possible to give the correct result to MS IE and Mozilla Gecko or Opera only by giving with attribute selectors a little bit different property values. It would be even desirable, that MS IE will never support attribute What are selectors, classes and id-attributes

  3. Mozilla Gecko browsers use the proposed @namespace at-rule in XML in order to identify, if HTML CSS-principles are used. These browsers define HTML-setting in /res/html.css file. It has in the beginning @namespace url(http://www.w3.org/1999/xhtml);. If the document has matching xmlns information (xmlns="http://www.w3.org/1999/xhtml"), they interpret CSS according to HTML-principles and they work because in XHTML 1.0 previous mentioned attributes are supported at the same way as in HTML. Without the matching namespace attribute, they interpret CSS according to general XML-principles, when attributes class, id and style work only with actual attribute selectors.


Id selector

In order to separate it from other identifiers, the name is in the element inside the attribute id. In CSS-encoding it use the character #. It can be immediately connected to other selectors without a dot. If it is connected to the universal selector, the format is *#some-id. This is however unnecessary, because they don't need explicit to connect any element type selector. At this matter they work like attribute selectors. An example of using id What are selectors, classes and id-attributes ([M][S][Pw]):

The id selector match only to element H1</TITLE>
<STYLE type="text/css">
h1#z98y {letter-spacing: 0.5em } /* remark the # sign, which express that this is an id selector; It doesn't use a dot; If you put a space, you get an another rule */
<H1 id="z98y">
Wide text</H1>

Id-selectors have higher weight than than attribute selectors. Then for example #p123 {...} is more specified than [id="p123"] {..} even if they match to the same place in the body of the document like <P id="p123">) like style="color:#660033; background-color:yellow;". This matter have any meaning today, but thinking about future, this is worth to keep in mind (look another example from the error page[S][Pw]).

Even if style-attributes don't have actual rules (they have only individual declarations and a single declaration-block), they create in the processing logical rules, which correspond the weight of them. According to CSS1 specification id-selectors have the same weight as declarations, which are inside style-attributes:

A declaration in the STYLE attribute of an element (...) has the same weight as a declaration with an ID-based selector that is specified at the end of the style sheet.

The CSS2 specification says (6.4.3 Calculating a selector's specificity), that they are considered to be after all other rules. This not a matter of weight but the cascading order[S], which I handle later.

Browser-specific notes:.

  1. The same kind of identification method is used also other than CSS-definitions, which might cause confusions for the author. Java-scripts use them also. It is however possible to use the same id attribute both with CSS and JavaScript encoding - to the latter the values of id attributes must be unique!

  2. The same id attribute for CSS and JavaScript doesn't normally cause any trouble to the UA, because they are interpreted with different interpreters. I got however an e-mail, where I was told that to use same id with CSS and scripts might cause problems in MS IE 4.x for Windows. I have created some advice how to use the id attribute in the page Help for HTML All menu[S].

  3. Id-selectors can be used in XML-documents. Because XML-documents don't need to use any specific DTD-files (or the browser don't always read them), rules like #id {} don't necessary work in XML-documents . Look at also another note[S]. and the first paragraph[S], where I handle attribute selectors.


Pseudo-classes and pseudo-elements



These classifications are created, because any definitions don't match to any particular part of the document tree. That's why is created two classifications, which are not depending on the document tree[S][Pw] at the same way as the element type selector. Pseudo-classes and pseudo-elements are assistance concepts. They behave like class or element type selectors. Because they don't use the class attribute or they don't have corresponding elements, they are in a way fictional. That's why they are called as pseudo-classes and pseudo-elements.

Pseudo-class is an assistant concept, which gives the possibility to classify elements like by using classes, but in some cases relating to outstanding features of the HTML-document (for example if the link has been followed or not).

Pseudo-element is an assistant concept, which is related to the presentational sub-part of the elements (like the first letter or row) resembling the way, how CSS is related with element type selectors.


Simple element type selectors are not tied with any particular attribute inside the element. Pseudo-classes are always bound with real or fictional attributes basically exactly at the same mechanism as an element is bound with the class attribute (remember that class selectors are also bound with certain attributes). Pseudo-classes offer the possibility to express the same element differently in various states.

Especially links can have several dictions in different states and you find pseudo-classes used commonly in link presentations. The existence of link is expressed in HTML-documents with the attribute href and the presentation of states of links has been defined in HTML 3.2 with link and visited attributes for the BODY element. Pseudo-classed :link and :visited gives the possibility to express the states of links without using HTML-attributes.

Link related pseudo-classes are link pseudo-classes :link & :visited and dynamic link pseudo-classes :hover, :active and :focus. Dynamic pseudo-classes affect wider than link pseudo-classes. They concern also other elements than A and they are related only to different states of elements.

W3C: CSS2: 5.11.2 The link pseudo-classes[Pw], 5.11.3 The dynamic pseudo-classes[Pw].

Some examples of the usage of them:

a:link { color: red }
:link {color: red }
/* it is not necessary to define the element A in HTML-documents, because the browser knows anyway, that it is related with links */

Browser-specific notes:

  1. The pseudo-class :link requires, that inside the element A is the attribute href and they should not work without it. Netscape 4.x support and Opera 3.x support :link without the href attribute.

  2. Opera 3.x and Netscape 4.x support only link pseudo-classes (:link, :visited).

  3. MS IE 4.x+ supports :active according to the CSS1 specification (like a link pseudo-class) and limited :hover.

  4. Opera 4.0x support :hover and Opera 5.0x+ in addition :active (both work limited).

  5. The widest implementation is in Mozilla Gecko and Opera 7.x+ browsers, which support also :focus. They support dynamic pseudo-classes also to other elements than to the element A. That's why should always mark, which elements dynamic pseudo-classes concern (for example a:hover). In Opera :hover works widest but :focus works only with form control elements. That is in my mind correct, because A just executes a task but it doesn't stay in the user focus.

I handle the usage of link-related pseudo-classe also in the page 7[S][Pw].

At the same principle works the language pseudo-class, which is depending on language attributes as if the language attributes could create classes (:lang()).

W3C: CSS2: 5.11.4 The language pseudo-class[Pw].

Only CSS2 level pseudo-class selectors is also first-child pseudo-class (:first-child; I handle it closer in the page What is the processing order of CSS[S][Pw] and I handle in the same connection so-called adjacent sibling selector). :first-child use the order of the elements as if the order could create a class specifier. First-child pseudo-class selects the first element at the same type in the same level.

Browser-specific notes:.

  1. The language pseudo-class doesn't work in any browser. Language-dependent rules can be set of Opera and Mozilla Gecko browsers by using attribute selectors. [lang="en"] is for HTML-documents the same as :lang(en). The language condition doesn't however concern XML-documents, because they use the xml:lang attribute. The language pseudo-classes in markup language independent, when for example :lang(en) match with both xml:lang="en" and lang="en" attributes.

  2. :first-child works only in Mozilla Gecko and Opera 7.x+ browsers.

Let's twist on the basis of until now handled selectors a wireframe example from various identifier and selector types, which an individual element can have and which work at least in some browsers.

<A href="some.hml" target="new" class="own" id="another">

That element includes following identifier types, which can be referred in CSS-rules:

  1. * (*{...}) = no special identifier - the browser just identifiers, that the document have elements
  2. A (a {...}) = the element type identifier
  3. own (.own {...}) = the class selector identifier
  4. another = the id selector identifier(#another {...})
  5. class, id, href, target ([class] {...} etc.) = the attribute name as the identifier of attribute selectors = (.own {...})
  6. class="own", id="another", href="some.html", target="new" ([class="own"] {...} etc.) = the name of the attribute + the value of the attribute as identifiers of the attribute selector
  7. a:link, a:visited (a:link {...} etc.) = the identification, if the link is unvisited or visited (the static states of the link)
  8. a:hover, a:active, a:focus (a:hover {...} etc.) = the identification, which is the possible dynamic state of the link


Pseudo-elements don't use any special attributes as their identifiers. They work together with other selectors. If pseudo-elements concern only a certain element type it is not necessary to add to them other selectors. Because in CSS2 :first-letter and :first-line concern any block level elements (according to CSS3 previous mentioned pseudo-element concern any element) it is necessary to define also the the element type, which they concern. It is possible to create fictional tag sequences for pseudo-elements. p:first-letter could be replaced for example with a tag sequence like this: <B><BIG><FONT color="#660033">?</FONT></BIG></B>. It is not however possible to replace :first-line always with a tag sequence, because lines can be broken from several places, if they don't have fixed width.

HTML 3.2 tag sequences are slow to create and they are quite an-flexible. Pseudo-elements are easy way to give to the first letter or row in paragraphs different presentation as in the other parts of the same paragraph. For example the following declaration makes the first letter of all paragraphs 120% bigger as other text in the same paragraph, makes it bold and gives it the color #660033 ([M][S][Pw]):

p:first-letter {font-size:120%; font-weight:bold; color:#660033;} /* the first-letter of paragraphs */
p:first-line {font-size:110%;} /* this definition match to the first line of paragraphs */

Browser-specific notes:.

  1. Opera 3.51-6.x, and MS IE 5.5+ for Windows and MS IE 5.0+ for Mac support them at CSS1 level. Indeed I have found that they don't always work in MS IE. In my tests the strange matter was that MS IE 6.0 for Windows supported them in my CSS-site for LI but not for P elements like MS IE 5.5 for Windows does.

  2. MS IE 5.5 for Windows doesn't support the font-size property for p:first-letter if the paragraph doesn't start with some inline-level element. Changes in the text color might in some situations cause incorrect results. It doesn't support pseudo-elements for heading elements.

  3. If the first letter is an element (for example <p><cite>Alkusana<cite>) Opera 7.x ignores all properties if they are against defined properties for the current element even :first-letter has been marked especially important (I handel importance later).

  4. Opera supports p:first-letter also in situations, where P has defined to behave as an inline level element if it should be applied only for block level elements.

  5. Opera 4.x+ and Mozilla Gecko browsers support also CSS2 level pseudo-elements (:before and :after), which I handle later in this site.

W3C: CSS2: 5.12 Pseudo-elements[Pw].


Other selectors and lists of selectors



Besides them in the CSS2 specifications is mentioned some other selectors. Tables have two special selectors (row What are selectors, classes and id-attributes and column What are selectors, classes and id-attributes). CSS2 specification doesn't count them to the main selector list in the chapter 5, but it handles them only in chapter 17. They don't have any special selector types. They use selectors, which have already mentioned in this page.

In CSS2 special pseudo-classes are also :left and :right. They are used in page breaking (those rules don't work today in in many browsers, but in future they are very useful).

Browser-specific notes:

  1. Mozilla Gecko browsers support huge quantity of proprietary pseudo-classes and pseudo elements (look at. CSS notes 1[S]).

  2. Pseudo-classes :left and :right work in new Opera browsers.

W3C: CSS2: 13 Paged media[Pw], 17 How to set CSS for table elements ([Pw].
Other sites: John Allsop: Kinds of Selector[Pw].


Selectors of CSS2

  • The universal selector
  • The element type selector/ type selector
  • The first-child selector
  • The adjacent sibling selector
  • The class selector
  • The id selector
  • Attribute What are selectors, classes and id-attributes
  • Pseudo-class selectors:
    • Link pseudo-classes:
      • :link
      • :visited
    • Dynamic pseudo-classes:
      • :active
      • :hover
      • :focus
    • The language pseudo-class
    • The first-child pseudo-class
  • Pseudo-element selectors:
    • :fist-letter
    • :fist-line
    • :before
    • :after
  • Special pseudo-classes, which are used in page breaks:
    • :first
    • :left
    • :right

Selectors of CSS3

People have proposed following new generic selectors to CSS3:

  • Structural pseudo-classes:
    • :root
    • :not-first-child
    • :last-child
    • :not-last-child
    • :first-of-type
    • :not-first-of-type
    • :last-of-type
    • :not-last-of-type
    • :only-of-type
    • :not-only-of-type
    • :only-child
    • :not-only-child
    • :nth-child(n) (n=integer)
    • :nth-of-type(n)
  • Other pseudo-classes:
    • :subject (the subject element pseudo-class)
    • :target (the target pseudo-class)
  • Other new selectors:
    • " (for example address"someContent"; the content selector)
    • ~ (for example ul ~ ol; the indirect adjacent combinator)

In additions into CSS3 has proposed new selectors to simulate the functionalities of HTML 4.0 form elements[S].

Browser-specific notes:

  1. Mozilla Gecko browsers support most into CSS3 proposed pseudo-classes and pseudo elements (look at CSS notes 1[S]).

I don't handle them. Next I handle the What is the processing order of CSS.


5. What is the processing order of CSS


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

The content as a one big page


In order to construct CSS-files it is necessary to understand, in which order browsers should read CSS-properties.


In principle there are three types of style sheets:

  1. UA style sheets (UA = User Agent = browser or other application, which use style sheets). In question is primary about the own definitions of applications, if there is not any style sheet defined. In fact this means primary understanding of ordinary HTML 3.2 or HTML 4.0 level elements and attributes. Browsers have a little bit different default settings. Browsers can also support some CSS-properties, which can use in all Web-pages. It is possible to define in MS IE 5.x+ to links the property hover. It has the same meaning as the pseudo-class :hover. Saved definitions creates a certain kind of UA style sheet. Mozilla Gecko browsers use actual UA CSS, because they define default HTML-setting by CSS in /res/html.css and /res/html.css (also Opera use UA CSS in non-HTML implementations; I handle UA CSS related properties in an extra page[S]). Own default settings of browsers are used, if any CSS-properties are not especially defined.

    In general other way defined CSS-properties override UA style sheets and HTML-attributes. There are however some exceptions, which I tell in another connections. In the rules, how browsers override HTML-attributes, are some differences between browsers. Authors should know them, if they want to create pages, which look out as much as possible the same in various browsers.
  1. User style sheets. They mean style sheets, which the user creates to the user agent. It is in theory possible to create CSS-properties to all wow-documents by feeding the path of the CSS-file to the UA (I handle the usage of user style sheets in an extra page[S]).
  1. Author style sheets. Those means just all CSS, which the author has defined to the document. The relation of the author style sheets to the users style sheet is in practise user agent dependent. In principle this relation can be controlled with the important rule. By using that rule some individual properties can be set to have an exceptional weight (I explain the usage more thoroughly at the end of this page). According to the CSS1 the priority is author style sheet and according to CSS2 user style sheets.
W3C: CSS2: 6.4.2 !important rules[S][Pw].


Basic ideas


Basic metaphors

Browsers interpret all definition by certain rules. Most of rules base on the document tree. Besides the tree metaphor in the computer language is used the family and kinship metaphor. We talk about for example parents and child. A parent element might have required and then also in a way "natural" children (child elements can be also non-necessary).

This relationship describes a simple document tree:

BODY  - H1 (this element don't have any natural child)
- P
- OL (an ordered list, which must have at least one child-element )
LI (individual list-element, which is the necessary child of the element OL)
LI (another list-element ; list-elements can have many level of sub-lists and then OL can have "grandchildren")

Most of the rules are named using the family metaphor. It is also remarkable that rules handle element levels, nested elements and bilateral relationships of individual elements in the document tree (this model works partially also with attribute selectors, but as I have told, attribute selectors don't work today in official browsers). I handle also in this connection the :first-child pseudo-class selector, because it is a part of whole system. It can be understand only in connection to other relationships. I try to explain everything as grass-root level as I can! Parts of the metaphor are:

  • Parent = parent level element. When we write about parent, the parent must have at least one child-level element. We must remark, that only the next sub-level elements are children. Parent is the direct surrounding element and between parent and children are not other element levels.
    Hen and chicken
  • Child = any child-level element, which have a direct parent-level element. A child is a part element of the parent level element.
  • First-child = the next level element after the parent level element (in the case of :first-child an individual element)
  • Ancestor = any element, which has inside it another elements. Partially the same as parent, but there can be several nested element levels between elements.
  • Descendant = any element, which is inside another elements. Partially the same as child, but there can be several nested element levels between elements. "Grandchildren" are always descendant elements.
  • Adjacent sibling = sibling level elements have the same parent and elements are not nested with each others. They are in parallel relationship to each others like sisters and brothers. An adjacent sibling is the next at same level being element level after the first mentioned element in the same level. CSS2 uses also more exact terms, which are listed below and they are related to the adjacent sibling.
    • The preceding sibling. The adjacent sibling definition gives only the element level. In the family is single first-born and after him becomes other children. In order to name the first-born, it must have pseudo-class :first-child. The preceding sibling is just the first-born, who is preceding before other siblings.
    • The following sibling. Some other siblings in the same "element family".
    • The preceding element. The element, which is a previous element or in the previous element level as the adjacent sibling.
    • Following element. The opposite relationship to the previous.
W3C: CSS2: 3 Conformance: Requirements and Recommendations[Pw].



In family children inherit their parents and descendant got his inheritance from his ancestor. It is essential to understand inheriting rules and the mechanism, which is called inheritance. Inheritance means the automatic mechanism, how properties are applied into elements. The principle concerns nested elements, which are parts of the document tree[S][Pw].

The inheritance of properties, which are give to the BODY-element works fine with certain block elements and their necessary child-elements. Automatic inherited properties are primary most font and text types.

Elements, which effect to the text, like H1-H6, B and I retain in variable level their characteristic features. H1-H6 keeps their relative sizes compared to the basic text, but most text style definitions are inherited from the element BODY. Some text elements retain their features even if CSS to BODY has defined. The reason why some font-related properties are not inherited to all possible elements is the fact that some elements have been predefined in the default settings of the browsers. The quantity of predefined elements is browser-dependent. Because of this reason some browsers need more CSS than some other browsers. In some browsers inheritance doesn't work correctly, but I handle some difficulties later.

All properties like background properties are not inherited from parent to child (in the appendix of CSS2 specifications is a table, which tells, which properties are inherited and which not). Children are in that means independent, that they can get own definitions.

Into the CSS specification has been added the value inherit (like TABLE {color:inherit;}), which means that all definitions are inherited from closest parent element. This is certain kind of "forced inheritance".

Browser-specific notes:

  1. I don't recommend to use the value inherit, because many browsers, which in other matters handle quite well CSS, don't support it. In my tests it has worked only in Mozilla 0.7 and Mozilla 1.1a but not in all relative Mozilla Gecko browsers.

W3C: CSS2: Appendix F. Property index[Pw].


Matching patterns and contextual selectors

The automatic inheritance principle concerns only necessary or natural relationships. I mean with the natural relationship, that some elements are designed to have many level of nested elements like ordered and unordered lists. Sub-lists inherit CSS-properties from their nearest parents. The automatic inheritance can create only generic guidelines. In order to get better control it is possible to create matching rules. Different selectors create like "patterns" and browsers try to find, where patterns could match. The whole system is pattern matching and I would call individual cases as matching patterns.

Because the meaning of matching patterns is to create rules to individual cases, the CSS1 specification write about contextual What are selectors, classes and id-attributes, which term is not used in the CSS2 specification, because relations are expressed using words descendants, ancestors etc. In my mind is is good to write also about contextual selectors.

Contextual selectors or matching patterns base primary on the bilateral relationships of elements and the relationships are described with the family metaphor. On the background of this method is also the document tree. But otherwise than in the automatic inheritance, pattern matching works like key and keyhole principle. According to the name they take account the context. Certain style is applied only to elements, which are in the right place or they have certain parent element.

In fact a simple universal or element type selector is a matching pattern. In order to separate simple selectors from complex selectors, I mean as matching patterns those kinds of rules, which have at least two conditions. An example of a very simple matching pattern ([M][S][Pw]):

table p {color:green;} /* the latter condition is called as descendant selector; in these kinds of patterns, it is remarkable, that the left round bracket ({) must be in the same row as the pattern, because I have found that patterns don't work if it is another row */

According to this rule, all paragraphs, which are inside tables and then are descendants of the element TABLE, got the property color:green (paragraphs are inside the start-tag and end-tag of the element TD).

I use often these kinds of matching patterns, when I define list-images to unordered lists (UL). If you use grouping[S][Pw], you can create with same declaration exact properties to several level of lists. Below is an example of this kind of solution ([M][S][Pw] - there is also models of the next examples):

ul li, ul li li li { /* in this example I have is defined first and third level lists and they get green list-images (I explain in other connection allowed properties for lists) */
list-style-type: disc;
list-style-image: url(pallo-vihrea.gif); /* vihrea = green */
list-style-position: inside;
margin-left: -10px; }

ul li li { /* according to this rule, second level lists got red list-image; if this list-marker is not defined, it gets the value from previous rule set and it would get green images! */
list-style-type: disc;
list-style-image: url(pallo-punainen.gif); /* punainen = red */
list-style-position: inside;
margin-left: -10px;}

To CSS1 level matching patters can add the class-specifier. In fact a simple element type selector with a class is a matching pattern, because it does have two conditions (element type and class). But these kinds of simple combinations can also add to normal element type selectors creating more complex matching patterns like these ([M][S] - there is also models to the previous examples):

ul.class li {
list-style-type: disc;
list-style-image: url(pallo-vihrea.gif);
list-style-position: inside;
margin-left: -10px;}

table.special td p {color:green;}
/* according to this rule paragraphs inside tables, got green color only, if they are in a table, which have the class special. Note! You don't need to define the class, because in this case the browser doesn't search properties to any table elements but only to paragraphs, which are inside the table! */

Let's looks at also CSS2 level matching patterns, because it is desirable, that browsers would support them. Following scheme describe this matter (OL and UL are list types; LI means individual list-items; I have tried to explain the system with some comments - think it in peace):

1) ul li ol li /* match to class="a"; this is a CSS1 level matching pattern and I recommend for some time to use only this kind of patterns */
2) ul li ol > li /* match to class="b" */
3) ul li ol > li:first-child /* match to class="b+" */
4) ul li ol + ul /* match to class="c" */
<LI class="b+"></LI>
/* class="b+" is the first child-element of the element OL (first-child selector together with the :first-child pseudo-class): any property for this element doesn't concern neither next level list elements nor other list items at the same level */
<LI and class="b"></LI> /* class="b" is the second child-element of the element OL (first-child selector): any properties for this level child-elements don't concern next level list elements */
<LI class="a"></LI>
/* class="a"; this element gets its properties according to the first rule, even if it is not the first-level child of element OL but second level "grand-child"; If this element have child-elements, they would get their properties from this element */
<UL class="c"> /* in this case element UL is at the same level being adjacent sibling of OL, which define properties also to the following list-elements */

It is also remarkable to remember that the length of the pattern is not the only meaningful factor. When I designed the list test, which I have mentioned, I made an error. I had not found all mutual relationships of different rules. I try to sketch them to you by this example:

li ol+ul {list-style-type: disc; /* according this rule the list-image should be red; It tested it with a preview-version of Netscape 6.x */
list-style-image: url(./Css/Kuvat/pallo-punainen.gif);
list-style-position: outside;}

ul li {list-style-type: disc; /* the previous rule don't remain in use, because the shorter pattern UL LI cancels it and redefine list-elements; It just continues at the point, where the latter definitions ends! */
list-style-image: url(./Css/Kuvat/pallo.gif);
list-style-position: outside;}

li ol+ul li {list-style-type: disc; /* in order to get the second rule in use, it must continue with an additional element LI - now Netscape shows the desired image! */
list-style-image: url(./Css/Kuvat/pallo-punainen.gif);
list-style-position: outside;}

The most exact matching pattern could be created by combining element and attribute What are selectors, classes and id-attributes[S][Pw].

Browser-specific notes:

  1. MS IE browsers don't support any new CSS2-level patterns.

  2. Only Mozilla Gecko and Opera 7.x browsers support all kinds of in this page mentioned pattern including the :first-child pseudo-class and attribute selectors (you can look a model list[S][Pw] from the error page, how selectors should work).

  3. Opera 3.6x doesn't support rules like .class p {...}..

  4. Opera 3.6x+ support rules like OL > LI {...}.

  5. Opera 5.x-6.x browser support also partially or fully rules like OL + UL {...}.

  6. Opera 4.x+ browser support attribute selectors.


Cascading order


Ordinary situations

Matching criterion are in principle simple. They include the cascading order. The browser might find definition, which have the same weight. Rules, which have the same weight last given remain in use.

In matching properties the main principle is that more specific override more common and last given all previous given rules. In this process it is also necessary to remember the usage of the import rule at-rule (@import), which I have already handled in the page How to put CSS into Web pages[S][Pw].

Cascading order is a part of the What is the processing order of CSS. In my mind it could be also written about cascading What is the processing order of CSS. Cascading order is connected to the pattern matching. The whole system can be simplified into tree main factors:

  • Inheritance (in CSS1 level only as automatic system + in CSS2 level also "forced inheritance")
  • All kinds of selectors with another selectors are matching patterns
  • Cascading order

Because these three factors are whole time in work, it is impossible to present a common model, which could describe, which definition is more specific than other. It is only possible to give some practical examples or general guidelines. The author must think in his mind, how browsers make their decisions in individual cases. He must know, what browsers can fulfil and what can't! Remember always also the document tree. Following order gives some general advice, when the effort is from general towards specific. The order might be in individual cases different.

  1. Bare universal selector
  2. BODY element without a class selector
  3. Class-specified universal selector
  4. Other Individual element type selector as BODY
  5. Other Individual element type selector as BODY with class selector
  6. Complex matching pattern, which have also class What are selectors, classes and id-attributes
  7. Id selector

Authors certainly want to create as manageable and powerful system as possible and where is minimum need of individual style definitions inside the document body. I give following recommendations:

  1. Single common BODY element definition with some common table declarations (I explain the latter in the page How to set CSS for table elements[S][Pw].
  2. Concerning document orientated definitions several rules to BODY element with different class and id specifiers
  3. Individual font styles have their own rules
  4. All other rules are made using matching patterns, which are counted from class specified BODY elements
  5. All kinds of specific document oriented definitions are used with care

Important rule

The normal cascading order can override by using so-called !important rule like:

body { color: black !important; background: white !important;}

If the order doesn't meet any other important rules, any afterward given corresponding properties are not taken account. The rule concern primary the cascading order overriding the normal order. But the rule concerns not only the cascading order. Properties, which are given with the import rule override also class, id selector, matching patterns and style attributes to the same element.

The !important rule concerns however only certain element and properties, which are given to the element. If some child-element has its own declaration, it remains in use. The following tested examples explain this complex matter ([M][S][Pw]):

body {color: black !important;}
body.CssSite {color:blue;}
/* the !important rule override this color-definition even if the BODY has as a specifier class CssSite */
p.new {color:blue;} /* the first definition is canceled, because to the BODY element given important rule doesn't override the property of the anew defined child-element (in this case it doesn't matter, if the child element have class specifier or not) but this rule is now in use; If the element P has not its own color-property, it inherit it from the BODY, which have the !important rule */
p {color:olive !important}
/* all previous definitions are canceled concerning the element P; Now it is in use a new important rule, which concerns the element P */
p#id-p {color:blue;} /* the previous important rule override also this definition and following definition, which is in the document body inside an element P; Because it is stronger than id selector, it is also stronger than matching patterns */

<BODY> <P style ="color:purple;">
You might believe, that the color of this paragraph would be purple, but it not true. The color is instead olive according to the important rule! Is this the result, what you really mean?
<P style ="color:purple !important;">If you want, that this definition could be in use, you must put the important rule to it!</p>

Because of the important rule overrides all other rules to an element, it is a certain kind of exception rule (the term is however quite problematic; read the Footnote 1). Authors might override with the important rule definitions, which they really don't want to override! Because the rule might cause much headaches to the authors and extra work to browsers, I recommend to use it extremely cautious.

Browser-specific notes:.

  1. Important rule doesn't work in Netscape 4.x series.

  2. With pseudo-elements :first-letter ja :first-line the important rule is related with only the element itself. If the element immediately starts with another element (for example >p>>cite>) different property values for child elements stay in Opera 7.x (for example cite {font-weight:normal} even if p:first-letter {font-weight:bold !important}). With other moder browser it is possible to override properties of the child-element with the !important rule. In my mind Opera 7.x works fully consitent.

  3. Redefining of the important rule doesn't always work.

After handling basics of CSS I handle next closer fonts and how to tailor web sites to different people and medias.


Footnote 1. The problem is, that it is not a rule in that way as in most cases is called a rule (look at the page What are selectors, classes and id-attributes[S][Pw]). But it is neither a declaration-block (look at the definition of declaration-block from the page Definition methods[S][Pw]. Because it is inside a single declaration, it might be called as the important declaration. The another correct alternative is to call the important rule as important properties, because they are added to the normal property list among normal properties like in this declaration-block: {color:blue !important; background-color: green}. !important creates however exceptional declarations, which weight are related to normal rules. Selectors + important rules create together conditional sequences or statements, which we can call as rules.


6. How to set CSS for texts and different media types


As I have explained in the page What are basic structures of HTML and XML documents, defining font with CSS-properties are problematic concerning compatibility. The basis view is, that how more documents have easily and flexible exchangeable CSS-properties, the lesser documents are compatible towards HTML 3.2 concerning the presentation.

The element FONT or CSS?

In order to get maximum compatibility, it is necessary to use the element FONT even if CSS-specification mention it in passing.If you define the class font-style1, you can afterward define properties to the element using CSS. Older browsers use instead alternative HTML 3.2 level attributes. Make following codes to the body part of the document ([M][S][Pw] - the model page includes all examples of this section):

<FONT class="font-style1" face="Arial" color="#3f3f3f">

This kind of method is however toil and HTML 3.2 level attributes are quite modest compared to CSS-properties. You can never get very big compatibility. In a way some level compatibility fulfils the media aims of CSS to offer different presentation to different devices.

Indeed by using attribute selectors existing HTML 3.2 level attributes could be used in CSS-rules. There would be not needed to use special CSS class or id selectors at all. Below is two examples of changing the color of the FONT element by using attribute selectors: ([M][S][Pw]):

font[color="#660033"]{color:blue} /* element FONT, which attribute color="#660033", get the color blue - remember the space rule; If you put a space after the element type selector, the rule says: element FONT, which have a descendant element, which have attribute color="#660033" get the property color:blue */
*[color="#660033"]{color:blue} /* color-attribute can give also as universal; This rule says: any element, which have exactly the attribute color="#660033", get the color blue */

Browser-specific notes:

  1. Don't define font-size with HTML 3.2 style like this:

    <FONT class="font-style1" face="Arial" size="3" color="#3f3f3f">

    MS IE bypass the font-size attribute if other value is given with CSS, but in Opera 3.x and Mozilla Gecko don't. Because the bypassing doesn't work in all CSS-capable browsers, it would be better to avoid it. If you want to exchange afterward the size of the font, enclose the element with the element BIG (you can define also BIG with CSS) according to the following example ([M][S][Pw] - here is a link to a model of the previous and next examples):

    <BIG><FONT class="font-style1" face="Arial" color="#3f3f3f"></FONT></BIG>
  2. Attribute selectors work with the FONT element properly only in Mozilla Gecko and Opera 7.x+ browsers. It is not possible to change the value of the color attribute with this method in Opera 5.x-6.x browsers even if they overall support attribute selectors.

The basic problem of HTML 3.2 way encoding is the fact that the presentation is in all situations the same. The presentation can't be focused. The element FONT (if it has not redefined with CSS) is excluding the size the same in all circumstances. One of the basic ideas of CSS2 is to focus CSS according to the modes of uses and destinations.

Especially this concerns the how documents look out on screen and printing. But more and more also in different kinds of special devices and tailored CSS for them. Also the language and affections of the user can be taken account.

The size and selected font type should be optimized according to the destinations. If that could be done, I handle first text-related properties and the ways to focus CSS for different users.


Basic definitions for texts

To the element BODY is reasonable give basic font-size and font-family properties([M][S][Pw]):

{font-family: Algerian, "Times New Roman",serif;
/* note quotes if the name of font have spaces - without quotes the browser doesn't necessary find the right font-face */
/* it is recommended to use in the base font size relative units */

The browser goes font-families in order. First two are installed font-faces. The third (serif) is so called as a generic font family, which are serif, sans-serif, cursive, fantasy and monospace. Browsers can decide with certain criterion, which font they use and they can offer different font faces.

W3C: CSS2: 15 Fonts, 15.2.6 Generic font families[Pw].

In headers is reasonable to use rich properties. I have collected to the following example a collection and I have mentioned properties, which belongs only into the CSS2 specification ([M][S][Pw]):

{color: #660033;
/* the color of the text as keyword value */
font-family: Algerian, "Times New Roman",serif;
font-weight: bold; /* how thick font is used - in this case as keyword value */
font-size: 18pt; /* absolute font unit */
font-style:oblique; /* almost like italic - the computer slant the normal font (the default value is normal) */
font-variant:small-caps; /* all letters are big, but small letter are lower */
text-transform:capitalize; /* quite like the previous definition - the first letter of the word is in upper case (other values are lowercase and uppercase); Note, that lowercase cancels the previous definition! */
text-decoration: overline; /* other possible values: none, underline, line-through, blink; This value is not automatic inherited */

font-stretch:wider; /* it should make the font wider (CSS2) */
text-shadow: 5px 5px red; /* defines shadows for texts (CSS2) */ }

Browser-specific notes:

  1. font-variant:small-caps works properly in MS IE for Windows browsers starting from the version 6.0.

  2. text-decoration: blink works only in Netscape, Mozilla Gecko and Opera 5.x+ browsers.

  3. font-stretch and text-shadow properties don't work in any tested browsers.

In the previous definitions it is remarkable font-weight value. In theory a font family can have nine font-weight values, which are marked 100-900 like font-weight:600 (I don't know any, which have so many). The value of normal is 400 and bold is 700. Browsers use certain algorithms to fill holes. In order to temporary exchange font-weight is possible to use keywords lighter and bolder, which I don't recommend as basic values.

Font properties can be defined also as shorthand properties, which includes also the line-height property ([M][S][Pw]):

... {font: normal small-caps 120%/120% fantasy;} /* shorthand definition to fonts: the first %-value is for relative font-size and the latter concerns the line-height property (the value of the property can be expressed exceptionally also without the unit: 1.2 = 1.2em); In my mind it is however in this case easier to control separate properties */

Browser-specific notes:

  1. Propertiesline-height:1.2em and line-height:120% are different in new Netscape/ Mozilla browsers in situation, when the user of the browser scales fonts. The percentage value is scalable but em-value doesn't.

  2. Some properties, which are used with text don't work just any browser. In my mind it is not sensible to use these even if in future Netscape 6.0 understand them: word-spacing, letter-spacing, white-space, word-wrap. Letter-spacing is most useful of them, because many browsers support it ([M][S][Pw]).


Media types and groups


The media rule and media types

CSS2 gives much possibility to tailor web sites for different representation devices. Most supported are normal screen presentation and printing. It is possible to give them own CSS by using the @media at-rule.

In CSS2 it is possible to use @media to make different presentation to the screen and printing or into some other devices:

@media print {/* this works at least in MS IE 5.x, new Netscape/ Mozilla and Opera 4.x+ */
body { font-size: 10pt }
@media screen {
body { font-size: 12pt }
@media screen, print {/* other possible media types: aural, braille, embossed, handheld, projection, tty, tv - note, that the device must identify itself and certain devices need special browsers and it is impossible to test these features before there are necessary browsers! */
body { line-height: 1.2 }
} /* note, that round brackets surrounds ordinary definitions */
W3C: CSS2: 7 Media types; 7.2.1 The @media rule[Pw].

If you put the media at-rule inside a single style sheet, the following conceptual scheme describes definition levels. I have used this kind of chart already, but I have added an extra level (the media rule block can have several rules like the declaration-block can have several declarations):

media rule block
selector property value
@media print { body { font-family : Verdana, Arial, sans-serif; } }

In the previous chart print is so-called media type. The media type information can connect also to the STYLE or LINK elements (<LINK rel="stylesheet" type="text/css" media="print">) or @import at-rule like @import url(print.css) print; (this CSS should be used only when the document is intended to print).

Browser-specific notes:

  1. The most common supported value is screen, which works at least in some versions of MS IE 4.x, Netscape 4.x and Opera 3.51+. Opera 3.51-3.6x supports also all and Opera 4.x+ in addition projection. MS IE 4.x+ supports also all and print. The latter works also in Netscape 4.x browsers. Corresponding values work also in many browsers with the @media at-rule. Media types have however following problems:

  2. The attribute media works correctly with the STYLE element among those browsers, which I have tested only in Mozilla 0.7+. Most other browsers read to the normal screen presentation part of the following CSS even if they should not to do so:

    <style type="text/css" media="projection">
    @import url(../Css/CssSiteProjection.css); /* this should not be read */
    body.CssSite div.docSlide p {color:red !important} /* Opera 5.x and MS IE can ignore this, which means that the attribute media works partially */

  3. Opera has the corresponding problem also with the LINK element, if the at-rule is not specified (for example @import url(...) screen;) or used media blocks in the imported style sheets.

  1. @import url(...) screen; etc. works among those browsers, which I have tested only in Mozilla 0.7+ and Opera 5.1x+.

  2. MS IE 4.0 for Windows and Opera 3.x read properties inside @media print {...} also to the screen version (indeed MS IE skips the first rule). @media screen {...} must write last and the author must be careful and define all necessary CSS another time. The same problem might be also with media attributes.

  3. Netscape 4.x doesn't read LINK and STYLE elements, if the attribute media has several values, for example media="screen,print". Netscape has also another issue, which I refer later in this page.

  4. Mac MS IE 5.0 for Mac and Netscape 4.x don't read rules, which are inside media blocks. Because Opera have difficulties with the import rules, @media and @import at-rules should not normally be used, if the purpose is to use media types so, that they work as many browsers as possible (they allow however skipping[S] some browsers).

  1. The full screen mode is in Opera 4.x+ so-called presentation mode, where the @media screen (concerns also the @media print) or corresponding media attributes don't work, but it is possible to use @media projection for it. I have noticed also this media type in this page (I have optimized it for 800x600 screen display - some hints[S]). Test, I you have quite new Opera - press the F11 button on the keyboard!

    Opera Software: XML in Opera.
  2. Opera has problems with defining CSS for several media types (I handle them closer in an extra page[S]).

Media groups

The normal screen media like some other media types are continuous media. Media types print and projection are parts of paged media, which is one of the media groups of CSS2.

In paged media the purpose is to control page breaks.

Ordinary paper printing, normal screen media, projection media and some other media types are parts of the What is the visual formatting model of CSS2. CSS2 has also non-What is the visual formatting model of CSS2s and special medias for aural handicapped people. Those are aural rendering model (for speech synthesizer) and tactile media.

In addition is taken account, if the device can render graphics. Or can the user affect to the presentation of the media or not.

The following list presents CSS2 media groups, formatting models and associated media types, if some media group/formatting model has only one or two media types:

  • How to put CSS into Web pages
  • Aural rendering model - the media type aural
  • Tactile media - media types braille and emboss
  • Paged media - continuous media (this matter concerns if pages are broken using page brake rules or not)
  • Interactive - static (can the user change the appearance of the page or not)
  • Grid - bitmap (in the previous situation the screen use so-called fixed-pitch character grid and graphics is not supported; The latter media group can use also proportional true type fonts and render graphics)

The relationship them to media groups and illustrate this table, which I have taken from the CSS2 specification (N/A means that this possibility is not applicable in certain circumstances):

Media Types Media Groups
continuous/ paged visual/aural/ tactile grid/bitmap interactive/ static
aural continuous aural N/A both
braille continuous tactile grid both
emboss paged tactile grid both
handheld both visual both both
print paged visual bitmap static
projection paged visual bitmap static
screen continuous visual bitmap both
tty continuous visual grid both
tv both visual, aural bitmap both

Media types

Generic notes:

  1. Some groupings are rather recommendations. The media type projection can be also interactive. By adding pause properties to the media type aural it can be create one kind of paged media.

  2. The problem of this table is in the media type handheld. New WAP mobile phones can handle quite limited way graphics. So-called palm pilot and Windows CE using devices have more capabilities. Which should be the dominant device? How the WAP severs should handle information to different handheld devices? The media type tty is text-only devices and it can't be used to them. Should there be a special group mobile_phones? (Look at also an extra page about this matter[S][Pw]).

Special at-rule for font types

In order to tailor different visual medias, CSS2 gives the possibility to download fonts using @font-face rule. Below is an example from the pages of W3C:

@font-face {
src: local("Helvetica Medium"), /* the browser tries to find this font from installed fonts */
url(http://www.fonts.org/sans/Helvetica_family) format("truedoc"); /* if it can't find it, it tries to download it; If it is doesn't succeed to download it, it use alternative fonts */
font-family: "Helvetica";
font-style: normal}
h3 {font-family: "Helvetica Medium", sans-serif }

W3C: CSS2: 15 Fonts, 15.3.1 Font Descriptions and @font-face[Pw].

Because fonts, which have the same point or pixel size might look as they have different size, CSS2 has been brought font matching algorithms, which gave better result using alternative fonts (font-size-adjust).

Browser-specific notes:

  1. font-size-adjust and other special font-related features don't work in those browsers, which I have tested.

  2. According to the information Mircosoft the @font-face at rule works in MS IE browsers starting from MS IE 4.0 for Windows (I have verified this matter with the version 6.0), but the font file format must be either .eot or .ote, not an ordinary font file (for example TT028M_.TTF). Because @font-face works in MS IE browsers only with some special font file format, the implementation is a little bit proprietary.

  3. Netscape 4.x support the proprietary @fontdef at-rule, which supports .pfr-files at (for example @fontdef url("http://www.example.com/sample.pfr");). Downloadable fonts works also by using a proprietary linking relation (>LINK rel="fontdef"...). According to a very reliable e-mail (21.07.2002) from Mozilla org @font-face is not yet supported.

W3C: CSS2: 15 Fonts[Pw], 15.2.4 Font size[Pw], 15.5 Font matching algorithm[Pw].
Other sites: Microsoft: @font-face Rule; Netscape: Dynamic HTML in Netscape Communicator Part 3. Downloadable Fonts.


Special at-rule for printing and printing-specific features

In addition at least for the printed paged media is possible to define the page size and orientation by using the @page at-rule. Below is some examples of using them:

@page {size: 210mm 297mm}

@page :first {size: 210mm 210mm; margin-left: 4cm; margin-right: 4cm;}

@page :right {margin-left: 3cm; margin-right: 4cm;}/* margin properties to the BODY or the root elements are added to the page margins. In addition the printer leaves some empty space, where it doesn't allow to print. Page margins start after that value. */

@page :left {margin-left: 4cm; margin-right: 3cm;}

@media print {
blockquote, table {page-break-inside:avoid} /* avoid dividing block quote elements into two pages; It is also possible to prevent small tables to be broken into two pages by using this property */

Below is a table, which describes in my mind most essential printing-related features of browsers (I handle the property content in the page Lists[S]):

All platf./ Windows (MS IE): media="print" @media print @import url() print; @page page-break-after/before page-break-inside content
Opera 5.1x+ [OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!]
Opera 4.x-5.0x [OK!] [OK!]   [OK!] [OK!] [OK!] [OK!]
Mozilla 1.0+, Netscape 7.x [OK!] [OK!] [OK!]   [OK!]   [OK!]
MS IE 5.5+ [OK!] [OK!]     [OK!]    
Mozilla 0.7-0.9x, Netscape 6.1-6.2x [OK!] [OK!] [OK!]       [OK!]
Mozilla 0.6, Netscape 6.0x [OK!] [OK!]         [OK!]
MS IE 5.0 [OK!] [OK!]          
Netscape 4.x, MS IE 4.0 [OK!]            
MS IE 5.0 [OK!]            

Browser-specific notes:

  1. Printing-related features work best in Opera 6.x series browsers. Opera 7.0x series browsers might print serious way incorrectly (7.10 not so bad but not as good as 6.x series browsers).

  2. Even if @page if not actual supported in MS IE, Microsoft informs that this at-rule can be used by print templates developed for applications that host MSHTML in MS IE 5.5+ for Windows browsers (MS Office 2000+ understands MSHTML[S]; it has also some What kind of non-standard (proprietary) CSS browsers support for printing). I don't count this as a real implementation, because the browser itself doesn't support the at-rule.

W3C: CSS2: 13 Paged media[Pw].
Microsoft: @page Rule.


List of at-rules

In general speaking at-rules are such processing instructions, which are more generic than ordinary rules. That's why certain matters can't be expressed with ordinary rules. Most at-rules are related with focusing CSS for special situations. One at-rule, which I have not yet mentioned is the @charset at-rule. This exchange the used character set. The rule can be used only in external style sheets and it might look like this:

@charset "ISO-8859-1";

Browser-specific notes:

  1. According to DevGuru CSS2 this at-rule is supported in Mozilla Gecko and MS IE 5.x+ browsers. According to a very reliable e-mail from Mozilla org. it's been supported since April 2000. Because I don't know how to test it I can't verify it concerning MS IE.

    DevGuru CSS2: @rules: charset; Microsoft @charset Rule.
  2. Opera Software doesn't inform @charset not to be supported in Opera 7.x, when Opera might support it.

Into CSS3 has been proposed new at-rules, like @namespace. I explain in the pages CSS notes 1[S] and What are selectors, classes and id-attributes[S]. It should be at the beginning of the style sheet like the @charset at-rule.

W3C: CSS2-CSS3: 4 CSS2 syntax and basic data types, 4.4 CSS document representation[Pw], CSS Namespace Enhancements (a proposal for CSS3).
Other sites: John Allsop: Basic concepts.

There are two kinds of at-rules. First simple line statements, which end to the mark ;. Second there are statement-blocks (or in other words block statements), which use curly brackets ({}) as their delimiters. In this page handled at-rules are following:

  • Simple line statements (they must set into the beginning of style sheets):
    • @charset (CSS2)
    • @namespace (CSS3)
    • @import (CSS1)
    • @import () [theNameOfTheMediaType]; (CSS2) (media-type focused CSS)
    • @fontdef (non-standard)
  • Statement-blocks:
    • @page (CSS2)
    • @font-face (CSS2)
    • @media (CSS2)

Below is a table of supporting of those at-rules, which I have mentioned in this page:

All platf./ Windows (MS IE): @import @import url() ...; @media @page @charset @namespace @font-face @fontdef
Opera 7.x+ [OK!] [OK!] [OK!] [OK!] [OK!] (?) [OK!]    
Opera 5.1x-6.x [OK!] [OK!] [OK!] [OK!]        
Opera 4.x-5.0x [OK!]   [OK!] [OK!]        
Mozilla 0.7+, Netscape 6.1+ [OK!] [OK!] [OK!]   [OK!] [OK!]    
Mozilla 0.6, Netscape 6.0x [OK!]   [OK!]   [OK!] [OK!]    
MS IE 5.5+ [OK!]   [OK!]   [OK!](?)   [OK!]  
MS IE 5.0 [OK!]   [OK!]   [OK!](?)   [OK!]  
MS IE 4.0 [OK!]           [OK!]  
Opera 3.51-3.6x [OK!]              
Netscape 4.x               [OK!]
MS IE 5.0 [OK!]       ?   [OK!]  


Special focusing features


User interface

At the same main principle it is possible to take account user settings in font and background properties. This paragraph should be rendered with the foreground and background colors of the desktop. In this connection in the CSS2 specification (not in CSS1) is also mentioned the possibility to use system fonts (caption, icon, menu, message-box, small-caption, status-bar) as a part of shorthand definitions like p {font: status-bar ...}. I don't recommend to use but in exceptional case like making in future pages for handheld devices. As a model, this sentence use system fonts.

User interface properties are also outline and cursor (I have defined for this paragraph cursor:wait).

Browser-specific notes:

  1. System colors work at least in Mozilla Gecko, MS IE 4.x+ and Opera 5.1x+ browsers.

  2. I have tested a property (outline), which has worked in some preview-versions of Netscape 6.0 (in the last tested Mozilla Gecko browsers has a proprietary variation -moz-outline in the style sheets of the user agent[S], which I handle in my CSS-notes[S]) and it works in modern browsers only in Opera 7.x+ indeed at least in Beta1 a little bit buggy.

  3. In Mozilla Gecko, MS IE and Opera 7.x+ work also partially the cursor property (all values don't work except in Opera 7.x).

  4. New Netscape/ Mozilla browsers support also proprietary system fonts and colors.

W3C: CSS2: 18 User interface[Pw].
Other sites: Opera Software: What's new in Opera 5.10.



The user is also taking account by using special language dependent properties. This aim is called as internationalization (it is shortened commonly to the format i18n). It is possible to use at the same row from left and right written text (like Hebrew) by using the direction property, which is handled in the chapter 9.

Other i18n features are handled in the CSS2 specification chapter 12. It handles language depending quotations by using element Q (= quote- look at a model[S][Pw]). It is also possible to use special list styles types (I handle lists in an own page[S]).

W3C: CSS2: 9 How to put CSS into Web pages, 9.10 Text direction: the 'direction' and 'unicode-bidi' properties[Pw], 12 Generated content, automatic numbering, and lists[Pw].



CSS3 goes further concerning the internationalization. It will have for example the layout-grid property.

I referred to a new at-rule. CSS3 adds also some new user interface properties. Especially paged media is developed further. The multi-column layout proposal of Håkon Wium Lie could be quite useful. I handle some CSS3 matters in the last page[S]. Next however something about anchors and links.

Browser-specific notes:

  1. Special quotations work in Mozilla Gecko and Opera 4.x+ browsers - look at a model[S][Pw]).

  2. Into CSS3 added new list style types work in Mozilla Gecko browsers.

  3. MS IE 5.5+ for Windows supports some into CSS3 proposed i18n features, which I handle in the CSS Notes 2[S].

W3C: Working drafts of CSS3: CSS Namespace Enhancements (W3C Working Draft 25 June 1999), International Layout (W3C Working Draft 10-September-1999), Multi-column layout in CSS (W3C Working Draft 22 June 1999), Paged Media Properties for CSS3 (W3C Working Draft 28 September 1999), User Interface for CSS3 (W3C Working Draft 16 Feb 2000).


7. How to set CSS for anchors and links



 How to set CSS for anchors and links

It is necessary to put link pseudo-classes into certain order. If you put a:hover to the top of the list, it doesn't work with visited links. If visited links or :active have the same background-color as the hover has in text-color, the browser doesn't show the link text at all! The correct order is the following:

a {text-decoration: none} /* because of some browsers the element A must be defined */
a[name] {color: ... !important; background-color: transparent !important} /* CSS2-compliant browsers implement a:hover also for named anchors; in order to avoid a:hover to change properties of named anchors they must define as important; in this solution a:hover should not use the !important rule */
a:link {color: #3f3f3f; text-decoration: underline;} /* unvisited link */
a:visited {color: green; text-decoration: underline;} /* visited link */
a:hover {color: red; text-decoration: none} /* the mouse "hovers" over the link */
a:active {color: green; text-decoration: none; background-color: yellow;} /* according to CSS2-specification :active should work between on-mouse-down and on-mouse-up events but according to CSS1 the link stays marked until the user click with mouse to another place */
a:focus {color: green; text-decoration: none; background-color: yellow;} /* :active and :focus are different states; Only :focus should leave the link marked until the next click of the mouse (:focus is designed primary into keyboard navigation and form control elements; browsers are not obliged to support it with the A element) */

Look at examples from my old presentation page[S][Pw], which I used CSS to define background colors to image links. I made also a separate test page[S].

If you want that the browser takes account a class for some ancestor or the BODY element (for example <BODY class="body_class">), make this kind of rules using matching patterns[S][Pw]:

.own a:hover {color: #dcd2d3; text-decoration: none; background-color: #706a6a;} /* the rule match first to all elements, which have the class own, but next the author gives an additional condition: the rule is applied only to the pseudo-class :hover */
.own table a:hover {color: #dcd2d3; text-decoration: none; background-color: #706a6a;} /* matching rules have more conditions; The rule says: :hover works only inside tables, which have an ancestor element, which has the class own */

Browser-specific notes:

  1. Opera 3.x and Netscape 4.x put underline to anchors, which have only the name of the anchor (name="anchor_name"), but not the attribute href even it should not to do so. A without href is an ordinary type selector and :link and :visited are pseudo-class selectors, which should work only if the anchor element have the attribute href.

  2. Combinated pseudo-classes work property only in Mozilla Gecko and Opera 7.x+ browsers. In principle by using a:link:hover and a:visited:hover combinators could prevent that a:hover would concern also named anchors but they don't work in Opera 4.x-6.x browsers. MS IE browsers read only the latter part of the combinator (a test, where both the foreground and background colors should change).

  1. I have explained the functionality of link-related pseudo-classes in the page 4[S][Pw]. In addition it is worth to remark that MS IE implements a:active according to CSS1 unlike new Opera and Mozilla Gecko browsers, which support in this matter CSS2.

  2. Mozilla Gecko and Opera 7.x browsers apply dynamic pseudo-classes for many elements. The consequense is that they implement a:hover also for named anchors and some form elements (Model23b.html[S][Pw]). Texts might drift, if :hover has some property, which affects to the position of elements (for example font-weight) and which is different as the text around the mouse pointer.


Image and text links

In principle image- and text links should be handled a little bit differently. If the image doesn't have a definition of its own to link pseudo-classes, the possible background-color or background-image should be only one line height and not grow to the height of the image.

W3C: CSS2: 10 How to put CSS into Web pages details, 10.6.1[Pw].

If a:hover, a:active and a:focus have background properties also for images should define rules, for example:

a.orange {display:block; border-width:0} /* might need height and width properties */
a.orange:active {color: #f85b07; background:#dcd2d3; border-width:0;}
a.orange:active img {background:#f85b07 url(.gif); border: #660033 1px solid;}
a.orange:focus {color: #f85b07; background:#dcd2d3; border-width:0;}
a.orange:focus img {background:#f85b07 url(.gif); border: #660033 1px solid;}

Browser-specific notes:

  1. Be careful not define a:hover so, that the text size changes. The change might cause the need to be reformat all the content, which is near the element and below it. Continuous need to reformat the document might make the handling of the page slow, it might cause unstability and even crash the browser. Opera 5.12-6.x doesn't add space for the text, if the size changes. The result might cause an ugly effect (a test), but this matter avoids the need of reload the page, it helps the browser to stay stable and the scrolling of the pages don't become slow (this matter might be also the reason, why Opera 4.x-6.x don't allow dynamic changes of the display value).

    I the text is intended to make bigger with a:hover I recommend to follow my recommendations below:

    • The link is inside a block and the block has so big height and width values that the text fits inside the block without causing reflow of other elements.
    • The link has defined as block and it has been given width and height properties so, that Opera 5.x-6.x don't cut the text when the mouse goes over the link.
  1. Setting for the link display:block a normal text link looks like an image. In new Opera and Netscape the whole element works always as a link but in MS IE the whole element is some cases active and sometimes not; in the latter case display:block cause just the visual effect but only the the text is active. if in MS IE the width property has other value than auto links are active at the whole available width except in situations, where links use the property float and links don't fit to the same line.

  2. display:block doesn't work correctly in Netscape 4.x and MS IE 4.x for Windows browsers.

  3. In MS IE browsers the background color is for the whole image without the definition display:block but not in Opera 4.x+ and Mozilla Gecko browsers. Indeed the correct display valued should be display:inline-block (I inform about this matter in the page Problems in the CSS2 specification[S]. Opera 4.x+ accepts also the display:inline-table, which cause inline level rectangular box and in most cases approximately the correct rendering.

  1. Opera doesn't support background images for dynamic and link pseudo-classes (fixed in Opera 7.0 Beta 2, but background properties don't work flawless in Opera 7.01). (A test.)

  2. In some Opera browsers border:none doesn't take from images borders.

  3. In some old[S] CSS-supporting browsers border don't work with links. If you want to use borders with a:hover set also borders for A elements so that the border color is the same as the background color. Then visible borders in the state a:hover don't cause reflow of any part of the document. The system works well in Opera also with a:active. MS IE and Mozilla Gecko browser puts build-in implementations over borders, which the author have set for a:active. Borders or default oulines for pseudo-classes :active and :focus work just randomly in Mozilla Gecko browsers. First versions of Opera 7.x don't support :focus at all for A. I found by accident that Opera 7.23 supports :focus for the A element (I don't know exactly what is the first version, which support this feature). Because :focus doesn't keep the visitor in a certain user focus I don't regard missing support of it an actual bug. But now the user can "paint" links and keep them temporary in a certain status.

  1. I have found, that if text-decoration and background-color properties are changed, all changes don't take effects in browsers. The functionality must test in many browsers. It is especially problematic to change background-color:transparent to some other. Look at examples from my old presentation page[S][Pw], which I used CSS to define background colors to image links. I made also a separate test page[S].

  2. Such Opera browsers which are older than Opera 7.x don't support the format a.class:pseudo-class element {...} (for example a.class:hover img {border:1px solid black} - works if img has been taken away).

  3. I handle links also in an extra page, which concerns dynamic menus[S].


Attribute What are selectors, classes and id-attributes

CSS2 offers also the possibility to use attribute selectors. Below is some examples of the usage of them:

a[href] {color:blue} /* this is in practice the same as a:link */
a[id] {color:blue} /* match to anchors, which have identifiers - nice way to mark links to the same page */
a[id="an_anchor_name"] {color:blue} /* match to an anchor, which have a certain name of the identifier */
a[href] img {background:yellow} /* you can also combine element type and attribute selectors making matching patters */
a[href="http://www.server.fi/~somebody/"] {color:blue} /* match to a certain link */
a[target="new"], a[target="_blank"] {color:olive; background-color:yellow} /* links, which open a new browser window are marked differently as other links */

Browser-specific notes:

  1. If you want to test, how attribute selectors work, you must download a new Opera or Mozilla Gecko browser. You can see in this page the effect. You can find other attribute selectors concerning notes from the page 4[S][Pw]

To link elements like other elements can define How to set CSS for backgrounds and borders, which I handle next.


8. How to set CSS for backgrounds and borders


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

The content as a one big page


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.


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):

{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 */
  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.


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])):

{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].


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).


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;}.


Special problems


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]):

{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.


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>

<table summary="A content example" cellspacing="10">

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.


9. How to set CSS for list elements



In my mind one of the most cute features in CSS is to use own list images - they are on of my favorite CSS-definitions!

List items

CSS1 examples

Below are some examples, where is CSS1-level list-related properties ([M][S][Pw]):

ul li /* an-ordered list and the first list-marker to it; all properties are inherited to descendant elements, if they are not especially defined */
{list-style-type: disc; /* CSS1 level list style types for unordered lists: disc, circle, square and none; The list item must define, because it might be happen, that the list image is not available */
list-style-image: url(pallo.gif);
list-style-position: outside; /* the default value and cause indent; Value inside means that the next possible row begins at the same level as the list-item */
ul li li /* a nested list; This defines the list-item of the next level child's element and all descendant elements inherit properties, if they are not especially defined */
{list-style-type: disc;
list-style-image: url(pallo-vihrea.gif);
list-style-position: inside;
margin-left: -10px; }

ol li /* ordered list - remember also to define sub-lists if you use them! */
{ list-style-type: upper-roman; /* CSS1 level list-markers for ordered lists: decimal, lower-alpha, upper-alpha, lower-roman, upper-roman; decimal is the default value */
list-style-image: url(.gif); /* sometimes might happen, that ordered lists inherit list-images from some matching patterns and to prevent this to be happen, it is necessary to define an-existing list image */
list-style-position: outside;}

You can look at also examples in the following pages:

It is possible to create from lists a table resembling presentations (look a model of an example[S][Pw], which I have already used).

Browser-specific notes:

  1. Netscape 4.x margins should set only for elements OL and UL, not to the LI element.

  2. List images don't work in Netscape 4.x browsers.

  3. In Netscape 4.x browserstext-align:justify doesn't work properly in lists.

  4. Table resembling list presentations don't work in Netscape 4.x browsers. Texts inside lists are readable even if the structure of the presentation is totally incorrect.

  5. If list-style-position:inside starts a block, the list marker should remain in an own row, because it should create an own element box. MS IE and Opera don't follow in this matter the CSS-specifications.

  6. Resetting the list-style-position in sub-lists doesn't work in MS IE 4.0 for Windows.

  1. I have found that MS IE browsers have difficulties, if list elements have much content. At least with frames some MS browsers render unnecessary horizontal scroll bars. If you add round the problematic list element (for example. UL) with the element DIV narrower width value (for example div.narrower {width:97%}), the problem might disappear.

  2. MS IE can't handle properly large and multi-level lists (as an example the Finnish CSS term list[S] - I divided it into sections, but still MS IE does have difficulties with the padding values.

  3. Mozilla Gecko browsers set the default positions of list elements differently as MS IE and Opera. Opera and MS IE use default margin values to create relative offsets between elements, but Mozilla use paddings. In order to avoid problems, if default values are changed, both margin and padding properties must be defined. If only the margin property is changed, this cause different rendering, which can be seen from the test page[S] and the screen captures, which I took:


CSS2-C223 new features

Into CSS2 has been added new list style types (for example list-style-type:decimal-leading-zero and list-style-type:lower-greek).

CSS2 brings the possibility to make extra characters and create counters to lists using pseudo-elements (:before, :after) and the content property. I use the content property especially in the printed version of this site.

CSS3 will add some new values (for example radio) to the list-style-type property, because CSS3 will have better support of HTML 4.0 form elements. Also some new content functions will be added.

The purpose of CSS is use not to embed arbitrary string or content into document. The idea of content property is to give the possibility to decorate element by using small images and special characters (for example *). The property makes also possible to show normally hided values of attributes (content:attr()):

blockquote:before {content:"*"; float:left; width:1.0em; height:1.0em} /* * have bee used like a list bullet before the element. */
blockquote:before {content:"*********************"; display:block; text-align:center} /* * has been used like a top border before the element. */
a[target="_blank"]:after {content: " <" attr(href) "> "} /* Addresses of such links, which goes outside of the site have been showed. Around the Web-address has been added some space and characters. */
W3C: CSS2: 12 Generated content, automatic numbering, and lists; 12.6 Markers and lists[Pw].

I don't handle in this page more thoroughly CSS2-C223 special features. I list them in the last page[S]. The next page handles tables.

Browser-specific notes:

  1. Mozilla Gecko browsers support also new CSS2-level list style types.

  2. New pseudo-elements, generated contents and quotes work in Opera 4.x+ and Mozilla Gecko browsers ([M][S][Pw]). Indeed new pseudo-elements don't work in Opera 5.1x-6.x for sub-elements of table. Mozilla Gecko and Opera 7.x+ browsers support content:url(); but only images can be used. The reason is that browser designers want to keep the spririt of CSS - ther purpose of CSS is not to embed artibrary content to the document.

  3. The content property doesn't work in Opera browsers if rules are grouped.

  4. In Opera 4.+ works also automatic numbering. Opera is the best browser to visit in the last model page. Opera has however some bugs in generated content related features, which I mention in the CSS-notes[S]. I have also a test page[S] for them.


10. How to set CSS for table elements


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

The content as a one big page


Tables have been used creating basic structures of Web-pages, which they are not originally intended. CSS works better, if the basic structure is base not on tables. It is much easier to crate basic structure using frames, which works well with relative old browsers (for example Netscape 2.x and MS IE 3.02).

Floating elements or tables?

If you want to create frame free pages and you keep the percentage of old browsers is relative small, there is an alternative solution. It is easier to create the basic structure using the common block element DIV, which presentation is defined with CSS. I handle them in the page 11. What is the visual formatting model of CSS2[S][Pw]. Applying CSS for tables browsers have some generic problems.

Browser-specific notes:

  1. In order to format the text inside tables is problematic, because horizontal alignment using CSS-properties cause also with certain browsers the horizontal alignment of the whole table. For example the CSS-property text-align:justify affect in MS IE 4.0 for Windows incorrect to the place of the table. Table {text-align:justify;} and table {text-align:left;} move the table to the left even if it has set into center using element CENTER or corresponding attribute inside the element TABLE. If you define text-align to child-elements (for example table.right td {text-align:right}), the behavior is ok.

  2. Netscape 4.x can't inherit CSS text-related properties definitions onto tables. Even MS IE 5.x and at least some versions of Opera 5.x have partially the same problem. It is easy to solve this problem with IE and Netscape 4.x by defining element TD. Because Opera 3.6x doesn't support properties to element TD, there is a need to define the element TABLE, when properties are different compared to the element BODY.

  1. To solve easy way these problems, I recommend to work to this way:

    body, table,th, td, p, ol, ul, blockquote /* define here common text-style properties and you can avoid all inheritance problems with Netscape 4.x and MS IE 4.0/5.0; There might be also other elements, which you must add into this list, because I don't have used all possible elements in my documents */
    {font-size: small;
    font-family: Verdana, Arial, Helvetica; }

    body {background: #dcd2d3 url(background_image.gif);}/* these properties concerns only the element body */
    text-align:justify; /* Opera inherit this property to tables; Define another time some descendant elements, if you need different properties */

HTML 4.01 table elements

It is possible to apply all properties, which I have explained in previous pages like borders, background, text types (look at an example[S][Pw]). In principle for all HTML 4.0 table elements (TABLE, CAPTION, THEAD, TBODY, TFOOT, COL, COLGROUP, TH, TR and TD). I recommend however to define CSS only for TABLE, TH and TD elements because all browsers support only partially the HTML 4.0 table model.

Indeed you can use more layered background properties if you define more table element ([M][S][Pw] - there is small examples in in the bottom left of the next model).

W3C: CSS2: 17 Tables, 17.5.1 Table layers and transparency[Pw].

Most of the properties work in the element CAPTION. CSS2 offers to change the place of the caption with the caption-side property ([M][S][Pw]).

In tables cells are descendants of rows, never of columns. Nevertheless, some aspects of cells can be influenced by setting properties on columns by using so-called column What are selectors, classes and id-attributes. They are related to the element COL just after the element TABLE. Below is an example of usage of them ([M][S][Pw] - the model on the bottom right concerns column selectors):

*#col1 { border: 3px solid black;}
*#col2 { border: 3px solid red;}
*#col3 { border: 3px solid olive;}...
<COL id="col1"><COL id="col2"><COL id="col3">...

There is also row What are selectors, classes and id-attributes. These can have also the first-child pseudo-class. Here is an example, which should give background and border properties for table rows ([M][S][Pw]):

tr:first-child {background-color: white; border-top: solid black 3px;}
tr {background-color: aqua; color:black; border:yellow 3px solid;}
*#row1 {border: 3px green solid; background-color:aqua;}
*#row2 {border: 3px solid green; background-color:white;}
*#row3 {border: 3px solid blue; background-color:lime;}
*#row4 {border: 3px solid blue; background-color:yellow;}
*#row5 {border: 3px solid blue; background-color:green;}

Browser-specific notes:

  1. Opera 3.x and Netscape 4.x support limited basic table elements (TABLE, TH and TD). For example CSS-borders don't work with these browsers.

  2. The element CAPTION works according to the HTML 4.0 specification only in Opera and Netscape browsers. MS IE handles it as if a special table cell. Different implementation makes the usage of this element problematic.

  3. the change of the place of the CAPTION element with CSS works only in Opera 4.x+ and Mozilla Gecko browsers ([M][S][Pw]). If the TFOOT element has been used Opera 4.x-6.x don't work correctly and implementations are messy (fixed in Opera 7.x).

  1. Supporting of COL seems to be quite limited. The model page ([M][S][Pw]), where on the bottom right concerns column selectors works correctly in Opera 4.x+ and Mozilla Gecko browsers but not in the MS IE versions, which I have tested.

  2. Opera didn't support in my tests padding for the COL element, but MS IE supported.

  3. The element COLGROUP has the most limited support. In my tests MS IE 5.x+ can center the text in a model document ([M][S][Pw]) and Mozilla 1.1 support border properties for it.

  4. Opera 4.x+ renders border colors of Model25a.html[S][Pw] as they have been defined. MS IE renders only background colors correctly except in the first row.

  5. Only Mozilla Gecko and Opera 7.x+ browsers render the :first-child pseudo-class in the previous model page.


Border models and empty cells

CSS2 offer two models, how to render table cell borders, which are inherited to sub parts of table elements. Here are two examples ([M][S][Pw]):

table {border-collapse: separate; border-spacing: 15pt} /* borders can't collapse each others; border-spacing (correspond the HTML-attribute cellspacing) */
table {border-collapse: collapse;} /* borders can collapse each others; CSS2 have priority rules in conflict situations */
W3C: CSS2: 17 Tables, 17.6 Borders[Pw].

In the separated borders model (border-collapse:separate) it is also possible to control the behavior of empty cells by using the property empty-cells (possible special values are show (according to CSS2 this should be the initial value) and hide). If to the element TABLE is used table-collapse:separate, border properties to the element TR should be ignored. The separate table model works only with elements TABLE and TD.

The element TR and some other elements work only with table-collapse:collapse. The initial value in browsers, which support border models should be according to the CSS2 specification border-collapse:collapse.

Browser-specific notes:

  1. The separate borders model works at least in Opera 4.x+ and Mozilla Gecko browsers. Opera hides as default empty cells. Mozilla Gecko browsers are in this matter DTD-dependent[S].

  2. MS IE 5.x+ doesn't support border-spacing and empty-cells properties. In MS IE border-collapse:separate works only as opposite to the border-collapse:collapse but the whole separate borders model is not supported. Border spacing values must define in MS IE by using the cellspacing HTML-attribute.

  3. The collapsing borders model works at least in MS IE 5.x+, Opera 4.x+ and according to an e-mail Mozilla 0.9.9+ browsers. Netscape 7.0 is the first Netscape browsers, which support this border rendering model. New Mozilla Gecko browsers don't render all defined borders at least in situations, where for all sides of table cells have not defined borders. Also MS IE and Opera have these problems. Opera 4.x-6.x has also as a problem that it can't center cell borders ([M][S][Pw]). MS IE and Opera 7.x+ give the nicest result in complex situations.

  4. Mozilla Gecko browsers define the default value as border-collapse:separate; border-spacing:2px. It is the same default value, which is commonly used in all browsers, when CSS is not used. It corresponds the default value cellspacing="2". Any browser doesn't use as the initial value border-collapse:collapse because browsers, which don't understand CSS2 table border models behave like tables, which have border-collapse:separate.

  1. Opera 3.x and Netscape 4.x don't support CSS-borders for tables.

  2. Border models don't work in MS IE 4.0 for Windows but it accepts CSS-borders for table elements.

  3. Browsers handle the border attribute of the TABLE element as if a set of predefined CSS-properties. This is following consistent the generic principles[S], how borders should be handled. For example following CSS corresponds the <TABLE border="10"> -definition:

    table {border-collapse:separate} /* not necessary because browsers use this value as the default value */
    table {border:10px solid; border-color: #bbb #7e7e7e #7e7e7e #bbb} /* The colors of the border attribute are browser-dependent. These values corresponds colors, which MS IE has with the HTML attribute. By experimentation can find colors, which correspond colors of the border attribute in other browsers. Look out more about border style from the page 8[S]. */
    th, td {border:1px solid; border-color: #7e7e7e #bbb #bbb #7e7e7e}
    /* The border attribute of the element TABLE defines to the table cells always only one pixel wide borders and only the border of the table itself can be thick */
  1. If you want one pixel borders or no borders to table cells, some browsers need border="0" and cellspacing="0" attributes. Try to define borders systematic so, that any cell don't have double borders and borders are defined to the correct sides.

    th, td {border: solid black;} /* common properties */
    td.left,th.left {border-width: 1px 1px 0px 1px;} /* cells on the left */
    td.right, th.right {border-width: 1px 1px 0px 0px;} /* other */
    .leftLast {border-width: 1px 1px 1px 1px;} /* the last cell on the left */
    .rightLast{border-width: 1px 1px 1px 0px;} /* other cells on the last row */
    <table cellspacing="0"...>
    <td class="left">...</td><td class="right">...</td>...
    <td class="leftLast">...</td>...<td class="rightLast"></td>

    At this way you can get better layout for Netscape 4.x browsers, when you use background colors and concerning borders equal result to MS IE 4.0+ Windows browsers. Newest browsers (like Opera 6.x) don't need any HTML-attribute to assist defining the presentation of tables, but it is not today reasonable to define tables according them.


Basic rendering methods

In addition CSS2 offers the possibility to change with table-layout:fixed the basic method, how the browser handle tables (The default value is auto. If you use grouping, you can cancel the change with this value by creating a new rule to tables, which you don't want to use it. The property isn't automatic inherited to child-tables.)

The browser doesn't read beforehand the whole table, but it needs the width value of the whole table, which it can get by setting width-values for the element TABLE or individual cells. To ensure proper functionality, you might need to define the width property both of the table and TH and TD elements. The browser counts as soon as possible how many columns the table has and then define column dimensions. The horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing. Below is an example of a simple definition:

table.someClass {width:600px; table-layout:fixed;}
table.someClass th, table.someClass td {width:150px}
/* if the width value for the table is smaller than the sum of total width values of individual cells, the browser increase the width of the table */

This method decrease drastic in modem connections the delay time before anything is rendered on the screen. Indeed the total time to download the page is quite the same, but the page is readable without waiting that the browser read first the whole page. The browser tries as soon as possible to render the viewport (window) area. This method is very useful in large tables, which have much text (an example table[S]).

If you want a wide cell above other cells, you need to define a hidden row:

.hiddenA {width:200px; font-size:0px; line-height:0}
.hiddenB {width:250px; font-size:0px; line-height:0}
.hiddenC {width:100px; font-size:0px; line-height:0}

<td class="hiddenA"> </td>
<td class="hiddenB"> </td>
<td class="hiddenC"> </td>
<td colspan="3">
A wide cell.</td>


The fast table layout method has also some disadvantages. If a long table has in the end more columns and then some extra cells, the browser ignores them. If table cells have wide images, they don't fit into cells.

Because table-layout:fixed affects in the basic level to the whole layout, if layout base on tables, before every project must think, if it is used or not. I recommend also to avoid nested tables and use instead DIV elements to delimit blocks inside tables.

The functionality of the fast table layout is however reasonable to test in many browsers. The main principle is that exact definitions gives the best results. The alternative solution is to use only DIV elements to build the basic structure of web documents. I handle this model in the next page.

Browser-specific notes:

  1. Table-layout:fixed works in MS IE 5.5+, Opera 4.x+ and Mozilla Gecko browsers. The overall functionality is best in Opera 4.x+ because Opera allows also to scroll partial read tables. By using MS IE 5.5 the reader must wait that the browser read first the whole table before he can scroll it.

  2. Opera 4.x has a minor bug. Even if in principle it is unnecessary to define the widths of first cells (elements TH or TD), Opera needs sometimes the width property to them, even if to the element TABLE has been defined the width value.

  3. Opera 4.x-6.x crop additional cell off if after the first row the table has more columns as in the first row. MS IE does that in long tables. Mozilla Gecko and Opera 7.x browsers show always all table cells.

  1. MS IE crops too wide images. Opera 4.x+ and Mozilla Gecko browsers render rest of images on nearby cells, but they don't increase the width of any cell according the space, which some image might need. By setting overflow:hidden also Opera and Mozilla behave at the same way as MS IE.

  2. In MS IE and, Mozilla Gecko and Opera 7.x+ browsers this situation can be helped by adding a DIV element and defining to it for example overflow:auto; width:150px. If the width value is smaller than the width of the image, it is possible to scroll the image but at least one scroll bar is always visible.

  3. Mozilla Gecko browsers need for low table rows the line-height property (for Opera only the font-size property is necessary).


Problems with content dimensions properties

CSS2 has left open, how the property height should be interpreted in tables, when browsers can interpret it as they wish. In my mind it defines also in tables the content height (this is also the interpretation of Opera Software).

In principle the width property means also in tables the content width. Because the element TABLE doesn't have direct actual content (between the actual content is at least one TR element), in ordinary cases only borders increase the total width of the block box of the table.

The problems is however the fact that in the HTML 4.01 specification calculating the width property of the TABLE element is used another formula as calculating the width property in CSS. In the HTML 4.01 specification has been said about the attribute width following:

This attribute specifies the desired width of the entire table...

According that definition borders are counted to the total width of the table and it is not the content width like in CSS.

When the browser calculates table dimensions it must take account following matters:

  1. Because both the (HTML) border-attribute and the (CSS) border-property affect to the total width value of the table, browsers which understand CSS must take account both border definition ways in order to calculate the width-attribute correct. The fact how in CSS the border-property is related with width-property is nothing to do in this connection. If the width-property would affect to the calculation formula of the width-attribute <TABLE width="100%"> would not be possible to calculate correct.
  2. In order to calculate the CSS-property width correctly, the border attribute of the element TABLE table must take account (the width property is the width, which must reserve for the concrete content, for example for an image, which has an exact width value). This matter should not be any problem for modern browsers, which can handle the border-attribute like a predefined set of CSS-properties.
  3. Because CSS should be able to define elsewhere for CSS-properties and CSS calculation formulas must have the priority. If both the width-attribute and the width-property has been set, the browser must follow the value and the calculation formula of the width property.

Browser-specific notes:

  1. Opera and MS IE for Windows interpret border table elements almost always differently - even by using HTML-attributes:

    • border="2" width="600" or border="2" style="width:600px" or style="border:2px solid black; width:600px;" = 604 pixel in Opera.
    • border="2" width="600" or border="2" style="width:600px" or style="border:2px solid black; width:600px;" = 600 pixel in MS IE 5.x for Windows.

    In this example Opera works incorrect in HTML and MS IE in CSS.

  2. Mozilla Gecko and MS IE 6.0 for Windows browsers follow in the standard-compliant mode[S] always MS IE 5.x for Windows rendering the width of the TABLE element even if they normally interpret the width property like Opera.

  3. Also the behavior of MS IE 5.0 is DTD-dependent[S]. The modes have bigger meaning for the width values of table elements than in MS IE 6.0 for Windows.

  1. I made a pair of test pages, which have two different DTD (HTML 4.0 Transitional[S] and HTML 4.01 Strict[S]) in order to show differences in Mozilla Gecko browsers. In new Mozilla Gecko browsers the DTD-dependence affect a little bit to one rendered width value but more how the background colors are rendered. The page pair gives following result in Mozilla Gecko browsers (links refer into screen captures):

    • No a DTD tag, HTML 4.0 Transitional[S]: cellspacing creates in Mozilla 0.9 areas, which have the same background color as with the BODY-element. Compare with Opera 5.12[S]. Note. The total width of the TABLE C is according to the HTML 4.01 specification different as it is with Opera. TABLE G is exactly correct. If the table doesn't fit to the box of the DIV element, it should go over it and the width of the table should not increase the width of the DIV element (only concerning the element TABLE the content should increase the total width of the element).
    • HTML 4.01 Transitional, HTML 4.0/ 4.01 Strict[S] + newer specifications: background-color is in Mozilla 0.9 for the whole table like in Opera and MS IE. The width of the tables behave like in an edited screencapture from MS IE 6.0[S].
    • Netscape 4.x doesn't support the width property in tables. If the cellspacing attribute has bigger value than 0 (the default value is 2), it is possible to get a nice result only by using outside the table a DIV or CENTER element, which borders have the same color as the parent element and the same background color as the table. TABLE F demonstrates this situation.

I made about this subject and a test case[S], which have been used the HTML 4.01 Strict DTD. I got some e-mail about the implementations of Mac-versions of some browsers. In order to show differences in the text case I made a table, where [OK!] means correct implementation and [NOT OK!] means incorrect implementation, when implementations have been judged according to HTML 4.01 and CSS2 specifications:

Tests Windows Mac
MicrosoftNetscapeOpera MicrosoftNetscapeOpera, 6.x7.0 Beta15.06.05.0 Beta 4
Test 0a[S][OK!] [OK!] [OK!] [OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 0b[S][OK!] [OK!] [OK!] [NOT OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 0c[S][OK!][OK!][OK!][OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 0d[S][OK!][OK!][OK!] [NOT OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 1[S][NOT OK!][NOT OK!][NOT OK!][NOT OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 1
[NOT OK!][OK!][OK!][OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 2[S][NOT OK!][NOT OK!][NOT OK!][NOT OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 3[S][NOT OK!][NOT OK!][NOT OK!][OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 4[S][NOT OK!][NOT OK!][NOT OK!][OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 4
[OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!]

Browser-specific notes:

  1. The implementation of MS IE 6.0 for Windows should be DTD-depending, when used DTD it should render Test 1-4 at the same way as MS IE 5.0 for Mac.

  2. In MS IE 5.0 for Mac given [OK!] / [EI OK!] are reversed excluding the last test, if the DTD is taken off. If this browser would render Test 0-0d DTD independent It would behave very consistent.

  3. According to some conversations with a worker of the Mozilla org. with the used DTD Mozilla Gecko browsers should behave as I have explained. Future versions of Mozilla might have a different behaviour. In principle Mozilla should handle with the used DTD Test 1-4 at the same way as MS IE 5.0 for Mac.

  1. The Mac-version of Opera 5.x works more consistent than 5.x-6.x Windows versions. It works at the same way as MS IE 5.0 for Mac with the DTD, which is used in my test case. If th HTML width attribute would work according to the HTML 4.01 specification, the behavior of this browser would not be anything to complain. The behavior of Opera is not DTD-depending. In my mind Opera for Mac and Opera 7.x for Windows work the most consistent.

  2. Windows versions of Opera 5.x-6.x work the most inconsistent, because the behavior is depending on the value of the width-attribute/ property. Opera has a weird width-switch, which is depending on the relation between calculated and the real content, when the calculation is done according to the formula of the width-attribute. The HTML calculation formula switch is on, when the real content is larger than the calculated content. The CSS calculation formula is on, when the calculated content is larger or equal as the real content. The result conforms either or HTML 4.01 or CSS2.

  3. CSS3 offers more reasonable way to change the calculation formula of the width value of the TABLE element as the "DTD-switch". I handle this matter in the problems of the CSS2 specification[S].

  4. When dimensions are set to table cells can create easier result, which look the same in all browsers (Test 4 Fixed[S]).

In principle it would be easier not to build the basic structure upon tables. I handle alternative ways in the next page. Tables are however necessary for all data, which need table presentation. That's why it is necessary to know possible problems.

Authors can define CSS so that it cause conflict situations, which browsers handle differently. The author might have created by accident conflict between the width of the table elements and the total width of individual cells.

He can also set properties, which don't fit into tables, for example table {padding:...} and tr {margin:...; padding:...}.

Browsers have also minor bugs, which cause problems. It is reasonable to list some of these problematic situations.

Browser-specific notes:

  1. Opera 5.x+ and MS IE solves the conflict situation between the width value of the whole table and individual cells in some cases differently. Opera calculates always the total width of the table according to width property of the cells, but MS IE in normal cases (table-layout:auto) according to the width property of the TABLE element. For example following CSS might cause a serious problem:

    td {width:200px; border:2p solid black}
    table {width:400px; border:1px solid black}

    In some tables in the Internet, which has three table columns. Opera rendered it a little bit wider than 600 pixel and MS IE about 400 pixel wide. In my mind Opera works correctly, because the total width should increase according to the width of individual cells. Properties width and height create a content box, which is one kind of fictional block or rather a reservation box. Even if a table has a special priority (for example table#special {width:400px}) the total width of individual cells should not be decreased. Indeed the CSS2 specification lets the browser the right to show the whole content and build the table using an algorithm, which the browser regards as best, when the normal table layout model is selected, but in in my mind MS IE takes "extra freedoms". MS IE works however with the fixed table algorithm (table-layout:fixed) normally at the same way as Opera.

  1. If the author sets the value of the width property for the fixed layout using TABLE elements greater than the sum, which can be get calculating together all properties in the first table row, which affect to the total width of the entire table MS IE for Windows calculates the width values for the entire table and individual cells best. Errors, which Opera 6.04 and Mozilla 1.1a can do can be seen from a test page[S] when the result has been compared with the behavior of MS IE 6.0 for Windows. Because browsers interpret the width property differently, authors should be very carefully defining width values in tables and they should avoid creating conflicts.

  2. Browsers accept at various ways table {padding:...} etc. weird definitions, but some interpretations are very quirky and they cause problems to the border models. When authors define groups, they should be careful and avoid defining previous mentioned rules (this concerns also thead, tfoot, tbody {margin:...; padding:...}).

  1. Counting the total width values of table cells it is necessary to take account generic problems which relates to the dimensions, which I handle in the page 8[S]. In order to decrease dimension related problems, it is reasonable to follow an advice[S], which I gave, when I handled common block dimension problems.

  2. I found that I doesn't work for table cells always work in Opera browsers (concerns at least until version 6.01). That's why I have used in some cases spacer images and for them linked width values (Netscape 4.x browsers behave quirky if images have certain CSS-properties). Setting width for any element, which are inside cells could do the same task.


11. What is the visual formatting model of CSS2


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

The content as a one big page


This page concerns in fact the How to put CSS into Web pages of CSS2 (CSS2 9-11). I handle the most powerful ways to exchange the presentation of pages.

Visible or hidden?

W3C: CSS2: 9 How to put CSS into Web pages[Pw], 10 How to put CSS into Web pages details[Pw].

Indeed in XML-documents can use even more powerful XSL language, which can use CSS-properties as parts of the whole system. In order to implement certain CSS-properties is fundamental point in creating presentation to XML-documents. Indeed CSS2 has some missing features (look at the page What other special features CSS has[S]).


Div + float

The property float moves elements to the right or left - elements as if "float" to those directions. At this way defined elements should be at the same horizontal level as elements without the property float. The heights of floated elements should not affect the height of the parent element. All elements including normally inline level elements should behave as block level elements. Together with the property float is commonly used the property clear. In the page mentioned below are some examples, which use these properties:

W3C: CSS1 Test Suite: 5.5.25 float[Pw].

Below is an example, which use these properties: ([M][S][Pw]):

{float: left; /* the image floats on the left - the another value is right */
clear: left;} /* the left side of the image is "cleaned" from other elements (even if there could be space for many floating element in the same row, all floating elements, are now in own rows) - other values are left and all (there is nothing on the right or left) */

Float is sensible to use with the common block element DIV by creating the basic structure into frame or table free documents. DIV-elements could be made "floating" block elements, which include link lists. The text would be written besides the floating box and there would be no need to use tables into basic formatting into frame free pages (strictly thought to use tables as creating the basic structure is misuse of them).

Floating elements or tables?

In fact it is possible to create the basic structure dynamic by dividing the content into floating sections. In 640x480 and 800x600 screen is only one column on the screen, but in 1024x768 or larger screen can be two or more columns (an example page[S] - use as wide screen as you can).

This idea can be applied in navigation frames, which don't have exact defined width values. I have used the property float with the element IFRAME, which has main navigation links.

CSS2 gives the possibility to set to block elements maximum and minimum width and height values. I used frames, because they make the same as max-width CSS-property. Frames have however disadvantages, why I don't use them anymore except in exceptional cases.

I give you an example, which is intended to use in pages, which have BODY class CssSite. The basic text is inside DIV-elements:

body.CssSite div {max-width:500px; text-align:justify; font-family: Verdana, Arial, sans-serif; font-size: x-small; margin-left:auto; margin-right:auto; border:1px solid #660033; padding:10px;}

After defining the basic layout element, the author defines two nested blocks as in the example below ([M][S][Pw]):

body.CssSite div {max-width:500px; text-align:justify; font-family: Verdana, Arial, sans-serif; font-size: x-small; margin-left:auto; margin-right:auto; border:1px solid #660033;padding:10px;}
body.CssSite div div {border:1px solid #660033; margin:0 10px 0 0; float:left; width:70px; height:200px; clear:left;} /* in this block, which is inside the previous block can place links; Next blocks can be simple one level blocks like paragraphs, because it is not necessary to present links more than once */

These kinds of blocks could be in many situations much more better than tables, which have fixed width value. There would not be a horizontal scroll bar in narrow windows, but the width of the text would however be under the control of the author.

Browser-specific notes:

  1. The functionality of float and clear properties are quite bad in Netscape 4.x. If several elements have in the same row several floating elements browser set them to the same "pile". Go through the CSS1 test suite of W3C concerning the float property.

    W3C: CSS1 Test Suite: 5.5.25 float[Pw].
  2. MS IE 4.x for Windows can't put a large quantity of floated elements into several rows. It might be more sensible to use tables, if the author doesn't want to create free scaling text. If you want flexible width values, use percentage values.

  3. If the basic structure base on floating elements some browsers put randomly unnecessary scroll bars. The system works relative well at least in Opera 4.x+, MS IE 5.5+ and Mozilla Gecko Windows browsers (presumably also in many Mac and Linux browsers).

  4. If ordinary inline level or block level elements are set to float, they need at least the width property. Otherwise browsers give them totally different width values.

  5. The height of floating elements might increase in some MS IE browsers also the height of the container (parent) element. This matter is fixed at least in MS IE 6.0 for Windows.

  1. In some browser floated elements goes a little bit downward, not directly to the left or right, when the position of floated elements is not the same in all browsers.

  2. The property clear doesn't work correctly at least in MS IE 5.x for Windows[S] and Netscape 6.1 browsers. In MS IE 4.x for Windows the property clear cause additional line breaks (also float might also cause them randomly).

  3. Netscape 4.x or older browser don't IFRAME elements. For such browsers, which don't support the IFRAME element I have defined alternative links.

  4. Max-width works on the base of my tests only in Opera 4.x+, Mozilla Gecko and Konqueror (Linux) browsers (on the base of a screen capture also in Safari (Mac)) browsers.

  5. Because MS IE doesn't support the display (I handle it later) property at XML-level, the only possibility to create flexible structure to XML-documents is to use the float property. It is remarkable to remember, that DIV + float looks completely different in browsers, which don't support CSS. Fast downloaded How to set CSS for table elements[S] are in that means backward compatible, but they work in MS IE only in (X)HTML-documents. In general the another way to replace frames is to use the position property, which I handle next.


Position model of CSS2


Common about positioning

The CSS2 has special position model. In this model position:static means ordinary positioning as if any position-related properties has not been given. The only reasonable usage of this value is exceptionally to take off the effects of other positioning values. Other positioning types (relative, absolute and fixed) gives the possibility to create layered elements. Positioned elements establish also a new containing block for the subsequent layout.

In order to control the stack level of layered elements it is necessary to use the z-index property. How bigger the numeric value is, the higher level the element is compare to other element, which have also z-index or don't have at all it (element, which have z-index:3 is positioned higher than element, which have z-index:1 and so on; if layered elements are inside a positioned element, z-index values are relative to each others and relative to other elements they have the z-index the same value as their parent element).

W3C: CSS2: 9 How to put CSS into Web pages[Pw], 10 How to put CSS into Web pages details[Pw]

When elements have position:relative the positions of elements have been calculated from the normal (static) positions of the elements. The most used positioning type is position:absolute. The positions of at this way positioned elements are normally calculated according to the the initial containing block, which is the root element. Concerning relative and absolute positioned elements the positions of positioned ancestor elements have impact for elements, which has these positioning types because the calculation of positions starts from the nearest positioned ancestor element. That's why absolute positioned elements are not each time positioned according to the root element. The positions of absolute positioned element should calculate from the padding edges of the container element when the margin and border properties of the container block have effects to the positions but the padding property is ignored.

Elements, which have position:fixed have been positioned according to the viewport (window). Because fixed positioned element has always the same starting-point depart from other positioning types positions of other elements have no impact to the positions of fixed positioned elements. Fixed positioned elements which are descendants of fixed positioned elements start always the calculation of the positioning of the subsequent layout from the very beginning.

Absolute and fixed positioned element are entirely taken off from the normal flow of elements. That's why width and height values for absolute/ fixed positioned descendants of static positioned ancestors don't change the height and width of the static positioned ancestors. The dimensions of absolute/ fixed positioned element can't be set (by using percentage values) on the basis of the dimensions of the static positioned parent element.

<div style="position:static"><div style="position:absolute; height:500px; width:500px; top:0; left:0"</div></div>

<!-- the height of the static positioned element is zero --> <div style="position:static; height:500px; width:500px;"><div style="position:absolute; height:100%; width:100%; top:0; left:0"</div></div>
<!-- the height and width values of the absolute positioned element should be in this case calculated on the base of the HTML element --> -->

Absolute positioned elements

Below is an example of a typical usage of absolute positioned elements ([M][S][Pw]):

html, body {margin:0; padding:0; border-width:0}

<DIV style="position:absolute; top:10px; left:10px; z-index:5; width:400px;">

... </DIV>
<IMG src="./Taulut/koneet.gif" style="position:absolute; left:20px; top:50px; z-index:3">
<IMG src="../Kuvat/Css/omakuvaIso.gif" style="position:absolute; left:100px; top:20px;z-index:4">
<DIV style="position:absolute; top:290px; left:10px; z-index:5; width:400px;">
<DIV style="border:1px solid black; padding: 5px">...


My recommendations:

  1. Positions have always been calculated from the top-left corner of the Web-page by using left and right properties. Both previos mentioned properties have always been set.

  2. The property z-index has been set for every positioned elements layer and if necessary also for the other elements.

  3. For container elements and for the element BODY properties margin-top, margin-left, padding-top, padding-left, border-left-width and border-top-width has been set to zero. Using of padding-right etc. leaves dimension problems[S]. The best result can be achieved if borders etc. have been set only for non-positioned descendants of positioned ancestors.

  4. Positioned elements have always pixel defined height and width properties, which have set so so that possible contents always fit inside positioned elements without setting the overflow property.

  5. Position:absolute works most reliable if it is given to direct child-elements of the BODY element. If nested positioned elements have been user inner element should fit inside outer elements.

  6. Absolute positioned elements should not be used in pages, which are horizontally scalable at the way that the content below might become unreadable.

  7. Avoid to set any element above form control elements and embedded visual objects.

  8. Don't position table cells.

Browser-specific notes concering absolute positioned elements:

  1. According to Opera Software nested solutions (for example <div style="position:absolute; top:50px;left:50px"> ... <div style="position:absolute; top:20px;left:20px"> ... </div></div>) work in MS IE 5.0 incorrectly.

    Indeed I coudn't verify this claim concerning Windows browsers. Instead I found that MS IE 5.x for Mac takes incorrectly account margins for the non-positioned ancestor element(s). I found also that Opera 4.x-5.x calculate sometimes nested positioned elements incorrectly ignoring positions of outer positioned elements when positions of inner positioned elements have been calculated. Concerning Opera 6.x I found that position:absolute + nested relative positioned elements positioning didn't work for innest elements.

  2. The bottom property works incorrectly in all browsers. If any containing block has not been set browsers position the element in the bottom of the viewport in a situation, where the page has not been scrolled. right doesn't work at all in all position:absolute supporting browsers.

  3. In MS IE 4.x for Windows positioning doesn't work if the starting point of the positioned element is totally outside of the positioned container element.

  1. Browsers set the width and height differently if they are undefined. In some Opera 7.x browsers the width and height are zero, if they are not explicit defined. Menus might be collapsed.

  2. MS IE 5.x for Mac and Mozilla Gecko browsers can't position table cells.

  3. With percentage values defined width and height properties don't work correctly in MS IE and Opera browsers. MS IE calculates positioned elements on the base of parent element even if the parent element is static positioned. If the parent element has not exact height value, the value is the height of one row of text. Opera takes the height from static positioned parent element (if the parent element doesn't have the height property the height would be the height of the viewport subtracted the space, which Opera reserves for the vertical scrollbar). Opera 7.x calculates the width correctly from the base of the HTML element but other according to the viewport in situations, which resemble example below:

    html {width:400px; width:400px}...
    <div style="position:static; height:500px; width:500px;"><div style="position:absolute; height:100%; width:100%; top:0; left:0; background-color:yellow"</div></div>
  1. Only Mozilla Gecko browsers calculate positions according to the padding edges of the HTML element. MS IE 5.x+ and Opera 7.0 Beta 1 for Windows browsers ignore the margin. MS IE 5.x for Mac takes sometimes account paddings for the HTML element. Older Opera browsers ignore both margin and borders like MS IE 4.x for Windows (the latter browser ignores totally these properties). I made a test case[S] for it. In ordinary situations Opera 4.x-6.x calculates positioned elements incorretly according to the border edges.

  2. According to an e-mail MS IE 5.0 for Mac starts in some cases calculating from BODY element. In a case padding-left:100px for the BODY element moved the absolute positioned element 100px to the right (a test page[S], where the menu should be on the top-left edge of the page).

  1. Opera needs both horizontal and vertical values of them (MS IE use as the default value the top-left edge of the element).

  2. MS IE 5.x+ for Windows (except MS IE 6.0 in the standard-compliant mode[S]) needs height values for TD elements, which are inside positioned elements. Mozilla Gecko browsers need in some cases the height property for positioned DIV elements. MS IE 4.x for Windows seems to need for positioned elements always both height and width properties.

  3. The positioning doesn't always work in Netscape 4.x browsers. In these kinds of situations it is necessary to define corresponding HTML-attributes for LAYER or ILAYER elements (look at an example from the page, which handles dynamic menus[S]). If positioned elements are inside cells of full width tables all properties for positioned elements don't work correctly.

  4. The problem in almost all new browsers is that the z-index doesn't work properly with embedded plug-ins object and/or with form control elements. In in Opera (until 6.x series) this problem concerns both of them and in Konqueror 3.1 form control elements. MS IE has problem with the SELECT-element. These broblems have almost been fixed in newest Mozilla Gecko based browsers. Indeed if layers, which have been set above an embedded object have background-color:transparent the background-color of the parent element of the embedded object shines through and layers crop a piece from the embedded object.

  5. All CSS2 supporting browsers don't support all values for the overflow property. I mention this problem further, when I handle position:fixed related issues.


Kiinteästi asemoidut elementit

Navigointielementtien suhteen paras vaihtoehto voisi olla position:fixed, jolla voi emuloida kehysten käyttöä. Navigoinnin suhteen etuna on se, että pysyy paikoillaan, vaikka asiakirjan muuta sisältöä rullataan. Mikäli kaikki linkit eivät mahdu samaan lohkoon niille voi periaatteessa määritellä overflow:auto, jolloin loppuja linkkejä voi rullata.

Kun systeemin laittaa taulukkosolun (TD) sisälle, voidaan luoda hyvin taaksepäin yhteensopivia tiedostoja (esimerkkisivu[S]). Systeemille on aina syytä määrittää oma lohko elementtiä DIV käyttäen, esim. ([M][S][Pw]):

div.jokuLuokka {overflow:auto; width:100px; height:150px; position:fixed; left:10px; top:10px}

Jos ajattelemme sivustojen tekemistä idealistiselta näkökannalta, BODY-elementin kanssa ei ole vättämätöntä käyttää mitään lapsielementtiä dokumentin visuaalisen perusrakenteen luomiseksi. Sen sijaan että käytetään juurielementtiä HTML visuaalisena perus rakenne-elementtinä käytetään elementtiä BODY ja kiinteä navigointielementti muodostaa oman kerroksen (layer). Juurielementti HTML toimii visuaalisena pohjaelementtinä, kuten seuraavassa esimerkissä:

html {background-color:#603} /* dokumentilla on kaksitasoinen tausta */
body.Class {max-width:600px; margin:auto; background-color: white} /* BODY toimii visuaalisena perus rakenne-elementtinä */
#one, #one2, one3 {z-index:4; text-align:right; border:1px solid black; background-color:#ffc; font-size:11px; padding:1px 2px 1px 0px;} /* navigointielementtien eri variaatioden yhteiset ominaisuudet */
#one2 {position:fixed; bottom:0px; right:0px; width:102px; height:27px;} /* #one2 käyttää DIV elementtiä kiinteänä navigointielementtinä selaimet, jotka eivät osaa toteuttaa CSS:ää näyttävät sen sivun lopussa alavasemmalla */

Systeemi toimii periaatteessa jopa niin, että määrittää max-width ominaisuus elementille HTML, jolloin HTML toimii myös dokumentin perus rakenne-elementtinä (kuvakaappaus[S]):

html {padding:0; margin:auto; max-width:500px; background-color:red}

Ratkaisussa ei tarvita taulukoita, ei kehyksiä eikä sisäkkäisiä DIV elementtejä, mutta dokumentin näkyvä rakenne on silti kontrolloitu.

Ajatus käyttää kiinteää navigointielementtiä ei ole uusi. Dave Ragget ehdotti HTML 3.0 Draft:ssa (1995), että BODY elementin sisällä voitaisiin käyttää paikallaan pysyvää BANNER elementtiä (ks. myös HTML 3.0, elementti BODY[S]):

The BANNER element is used for a banner section which appears at the top of the window and doesn't scroll with window contents. This can be used for corporate logos, copyright statements and disclaimers, as well as customized navigation/search controls.
  1. Jos haluat antaa kaikille kiinteätä asemointia tukeville selaimille jonkin elementin pysyvän paikoillaan, määrittele vain suhteellisen yksinkertaisia kokonaisuuksia. Varmista, että elementit ovat sopivilla paikoilla selaimilla, jotka eivät tue kiinteätä asemointia.

  2. Jos asemoit kiinteiden elementtien sisällä muita elementtejä, käytä vain asemointityyppiä position:relative.

  3. Jos luot monimutkaisia dynaamisia ratkaisuja käytä niitä vain sellaisten selainten kanssa, jotka pystyvät toteuttamaan monimutkaiset rakenteet. Luo tarvittaessa selainkohtaisia tiedostoja.

  4. Määritä mahdolliset dynaamiset valikot vain vasempaan yläkulmaan suhteellisen kapealle alueelle siten, että päävalikko ei mene asiasisällön päälle.

Selainkohtaisia huomautuksia:

  1. Tuntemistani selaimista position:fixed että overflow:auto toimivat vain MS IE 5.0+ Mac, Mozilla 0.6+, Netscape 6.1+ ja Opera 7.x+ selaimissa. Molemmat toimivat todennäköisesti myös Konqueror (Linux) ja Safari (Mac) selaimissa (en ole niissä testannut overflow-ominaisuutta; Konquerorissa olen testannut position:fixed ja Safari näyttäisi erään kuvakaappauksen perusteella sitä tukevan). MS IE Mac overflow:auto ei toimi kunnolla. Käsittelen toisessa yhteydessä visibility ominaisuutta koskevaa ongelmaa. On syytä tiedostaa, että position:fixed toimii lähes moitteitta vain sangen uusista Mozilla Gecko Opera 7.0 Beta 2 selaimista lähtien.

  2. MS IE 5.5+ Windows ja Netscape 6.0x tukevat overflow:auto mutta eivät position:fixed. Sivulla 8[S] on tähän asiaan liittyvä linkki testisivulle ja toteutuksista annetut kommentit. Opera 4.x-6.x:ssä ei toimi overflow:auto. Operalla on myös eräitä pienempiä virheitä, joita käsittelen eräällä lla[S].

  3. position:fixed ei toimi eräiden upotettujen objektien kanssa Opera 5.x ja MS IE 5.0 Mac selaimissa (IFRAME rullautuu sivun mukana; sama asia koskee ainakin Operan kohdalla myös APPLET, EMBED ja OBJECT elementtien avulla upotettuja objekteja).

  1. Jos position:fixed asemoitujen elementtien jälkeläiset on määritelty position:absolute avulla jotkut Mozilla Gecko selaimet laskevat absoluuttisesti asemoitujen elementtien paikan ikään kuin ne eivät olisi kiinteästi määriteltyjen elementtien sisällä (käsittelen tätä asiaa tarkemmin eräällä sivulla[S]). Konqueror 3.1:llä ongelmana on se, että absoluuttisesti määritellyt elementit jäävät kiinteästi määriteltyjen elementtien alle (z-index ei toimi oikein).

  2. Jos käytetään ominaisuutta bottom on ehdottomasti määriteltävä ominaisuutta height, jotta position:fixed toimii Operalla kuten pitäisi.

  3. max-width toimii elementin HTML kanssa vain CSS2:ta tukevissa Opera selaimissa. MS IE selaimilla on koko dokumenttia ajatellen jonkinlainen width-ominaisuus, on välttämätöntä lisätä DIV elementti ja käyttää sitä dokumentin perusrakenteen luomiseen. MS IE:lle leveys voi olla kiinteä, mutta Opera 4.x+:lle, Mozilla Gecko, Konqueror ja Safari selaimilla sen arvo voi olla joustava, kun määrittelee CSS:n seuraavalla tavalla:

    div.perusRakenne {width:550px;}
    div[class="perusRakenne"] {min-width:200px; max-width:550px; width:auto}
    /* MS IE ei lue tätä sääntöä; width:auto eliminoi width:550px vaikutuksen */
  1. Kiinteästi asemoitujen elementtien sijaan voi käyttää JavaScript-koodauksella toteutettuja "kelluvia" elementtejä, jotka pienellä viivellä asettuvat paikoilleen. Toimivuus on kuitenkin jossakin määrin huonompi kuin kiinteästi asemoiduilla elementeillä. Käsittelen tällaisia elementterjä eräällä lla[S].

  2. Eräät Mozilla selaimet tulkitsevat katselukanavan eri tavalla. Operassa vierityspalkkeja ei lasketa katselukanavaan, mutta joissakin Mozilla selaimissa ne lasketaan. Tein asiasta myös erityisen mallisivun[S], josta minulla on muutamia kuvakaappauksia:

    • Opera 5.01[S] - ok.
    • Mozilla 0.7[S] - sivu on madalletussa ikkunassa, jolloin tulee vaakatason siirtymä (korjattu Mozilla 0.9:ssä).
  3. MS IE 5.0 Mac versiossa ei toimi edellisellä esimerkkisivulla margin:auto, mikä näkyy kuvakaappauksesta[S]. Mac IE:llä monimutkaiset dynaamiset valikot eivät toimi kiinteästi asemoituina.

  4. Mitä itse tiedän vain Opera 7.x, Mozilla 0.9-1.1 / Netscape 6.1-7.0 Konqueror + todennäköisesti Safari osaa käsitellä kunnolla monimutkaisia dynaamisia valikoita (tällöinkin muistettava, että position:fixed + position:fixed eikä position:fixed + position:absolute ei käytetä).


Visual effects



Possible specialvalues to the display property are inline , block, list-item, run-in, compact, marker, table, inline-table, table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, table-caption and none.

W3C: CSS2: 9 Visual formatting model, 9.2.5 The 'display' property[Pw].

This is the most powerful tool in CSS. The purpose of this property is to define the basic behavior of element, for example should the element be rendered like block level or inline level elements.

Just the property display is the method to exchange the character of HTML-documents almost into pure markup language like XML. All display-properties are not intended to use in HTML-documents. They are only intended to create HTML 4.0 table model to XML-documents, which don't have predefined table model. The browser may ignore exchanges to the table structure in HTML-documents.

In principle it is possible to exchange drastically the structure of HTML and XML documents by using suitably nested elements. In this example CSS display properties create first table structure from nested elements. Inside the created table CSS create then list element display from P elements. In principle it is possible to exchange table display into list display and opposite. Below is an example of creating table structure with CSS:

*[class~="tables"] {display:table; border:2px blue solid; padding:2px; margin-bottom:5px;} /* this definition require two nested element level, when the outermost can be exchanged into the element table */
*[class~="tables-tr"] {display:table-row} /* exchange the next level element into table row */
*[class~="tables-td"] {display:table-cell; text-align:justify;} /* exchange the next level element into table cell */
td p {display:list-item; padding-left:12px; list-style-type: disc; list-style-image: url(./Css/Kuvat/pallo-vihrea.gif); list-style-position: inside; /* if preceding way is created a table, all P elements are exchanged into list-elements */}

In theory it is possible to create table-like presentations to XML-documents without creating all element levels. The UA should create missing levels automatic. It is necessary to create always table cells, but it is not necessary to create corresponding element to the element TABLE. If there is not table row elements, it is not possible to create parallel table cells. Cells are then always under each others.

Only empty elements are problematic. It is not possible to remove in HTML the formatting features of some empty elements except removing them from use by the display-property value none. Neither it can make empty elements of XML formatting codes. It is possible to exchange with a pseudo-way the order of elements. The real order is not exchanged, but if some element is removed and another is revealed, it is as if an exchange of the place of elements ([M][S][Pw]).

With display:none can smart hide information about using CSS. In the following way the text is visible only to browsers, which don't support CSS - why newer browsers should read this text:

<DIV style="display: none;"> If you see this text, you browser doesn't support HTML 4.0 style definitions and CSS-files. Get a newer browser, if you want to see my pages as I have design them (you don't lose however any important information with old browsers). My pages are best viewed with MS IE 5.x+, Opera 5.x+, Netscape 6.x+ or corresponding other browsers (like Mozilla and NeoPlanet).</DIV>

This method can be compared to HTML-comments. The basic difference is, that it is not necessary to use comment tag in the document body (like ). The hiding of elements can be fulfilled by using external style sheets. Changes can be also dynamic, when it is possible to create visual effects.

Browser-specific notes:

  1. Only Mozilla Gecko and Opera 4.x+ browsers can give table presentation for XML-documents with CSS. Look at following pages and and an image:

    I made also an other example[S]. MS IE shows the pages messy, but Opera 4.x+ and Mozilla Gecko browsers as clear tables.

  2. Netscape 6.x can fulfil most values but not all. I tested display:compact and display:run-in, which don't work in Netscape 6.2.1, but they work in Opera 4.x+.

  1. MS IE 5.0 for Windows can create basic block and inline structure (display:block or display:inline) - and hide some area from the screen (display:none).

  2. They work also in MS IE 4.x for Windows and Netscape 4.x browsers, but display:block doesn't create a block but it works just as the opposite of display:none at the same way as display:inline.

  3. MS IE 6.0 for Windows supports all CSS1 level display types + CSS3 level display:inline-block, which is not supported in other browsers. I has a DTD-dependent special usage, which I refer in an extra page[S].

  4. It is possible to play with display properties if they are connected into dynamic pseudo classes and at that way create visual effects. Then they correspond simple scripts. Play with my images with MS IE 4.x+, Mozilla Gecko or Opera 7.x+ browsers ([M][S][Pw]). Because Opera 4.x-6.x don't support dynamic changes of the display property they don't work in those Opera browsers.



New features in CSS2 is also visibility that means, is the object on the screen visible or not (visibility:hidden; visibility:visible). According to CSS2 specification the difference between display:none and visibility:hidden is, that visibility:hidden takes the space of hidden element, but display:none means the same as nothing! By using visibility:hidden it is possible to create hidden formatting, which however works today well only in MS browsers. This property can be used with dynamic pseudo-classes to create dynamic structural exchanges.

Browser-specific notes:

  1. The visibility property doesn't work in Netscape 4.x always correctly.

  2. MS IE and (in most cases) Mozilla Gecko browsers render elements, which have visibility:visible as visible even if they are inside elements, which have visibility:hidden, which is the correct. Opera hides always these kinds of elements and Mozilla Gecko browsers if position:fixed has been used (a test page[S]).

  3. Compare properties display and visibility with MS IE 5.x+, Mozilla Gecko or Opera 7.x+ browsers ([M][S][Pw]). These changes don't work in older Opera browsers.

John Allsop: Page Layout([Pw].



So-called DHTML (Dynamic Hyper Text Markup Language) means dynamic changes to the visual structure of the document, which are made by CSS + JavaScript/ ECMAScript encoding (in most cases they have been done by changing the values of the visibility property). The most used solutions are dynamic menus. I use them today and I made an extra page, which handles creating of dynamic menus[S].

I don't handle very thoroughly DHTML/DOM in this site. I don' handle either some other matters, which concerns CSS, which I refer in the last page. Compare the points of views of this page to the possibilities of How to set CSS for table elements[S].


12. What other special features CSS has



When devices become better, I handle in this page some CSS2-CSS3 advanced features. I have referred to most of them in the page 6[S].

Paged media

Into the CSS3 have proposed following extensions:

  • @page at-sub-rules:
    • @top, @bottom, @left and @right
    • @outside
  • Other new at-rules:
    • @counter
    • @string
  • New properties:
    • page-policy (only to @string and @counter at-rules)
    • hidden-policy (only to @string and @counter at-rules)
    • float new values (outside | inside)
    • padding-inside
    • border-inside
    • string-set
  • New content functions:
    • date()
    • document-url()
    • pages()
    • target-content(X)
    • target-counter(X, C)

Font matching algorithms

To adjust the secondary font size by using the font-size-adjust property is quite easy, if you know, which is the so-called x-height value of the font face = lower-case x compared to the upper-case x (aspect ratio). For example in Verdana the lower-case x is relative high. Texts made with this font face look out bigger as many other font faces, which has the same pixel size (for example Arial). I recommend to use about the value 1.2, if other font faces are Arial, Helvetica or Times New Roman.

If this paragraph has the same font size as the previous paragraph, this property doesn't work. In order to use other new features efficiently, it is needed to have much font designing skill, because there are much special terms and systems.

W3C: CSS2: 15 Fonts, 15.3.1 Font Descriptions and @font-face[Pw].

@charset and unicode-bidi

I have not tested, because I don't need them (I don't write in special languages).

Aural style sheets

I have not tested, but they are in principle easy to use. Instead of normal properties, you use aural properties like in this example:

h1, h2, h3, h4, h5, h6 {
voice-family: paul;
stress: 20;
richness: 90;
cue-before: url("ping.au")
p.heidi { azimuth: center-left }
p.peter { azimuth: right }
p.goat { volume: x-soft }

Look at also the extra page What are semantics of (X)HTML elements.


CSS2 can emulate almost all HTML elements and presentational attributes but not certain form elements. In order to create the functionality and presentation of HTML 4.0 form element, into CSS3 has proposed for example following matters (UI = User Interface):

  • Pseudo-classes to UI element states:
    • :enabled
    • :disabled
    • :checked
    • :indeterminate
  • Pseudo-elements to UI element fragments:
    • :selection
    • :menu
  • Properties, which allow define the state of the element (Dynamic presentation):
    • user-input
    • user-modify
    • user-select
    • user-focus
    • user-focus-key
    • user-focus-pointer

Browser-specific notes:

  1. New Netscape/ Mozilla browsers support most into CSS3 proposed pseudo-classes and pseudo elements (look at CSS notes 1[S]).


New features in CSS3

In my mind most remarkable changes in CSS3 will be following matters:

  • Modularization. Indeed it could work better, if instead of CSS would be XCSS[S].
  • Better implementation to form elements.
  • More pseudo-classes and pseudo-elements.
  • CSS3 goes further concerning the internationalization supporting the international layout.
  • More rules and properties to the Paged Media.

I have listed my own and other persons proposals in the page Proposals for CSS3[S].

W3C: Working drafts of CSS3: CSS Namespace Enhancements (W3C Working Draft 25 June 1999), International Layout (W3C Working Draft 10-September-1999), Multi-column layout in CSS (W3C Working Draft 22 June 1999), Paged Media Properties for CSS3 (W3C Working Draft 28 September 1999), User Interface for CSS3 (W3C Working Draft 16 Feb 2000).