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 2

(This gathering includes extra pages. This gathering is primary for printing and reading the printed document offline.)
Start page

A What are purposes of Web standards



How Internet browser designers should develop their products? The basic idea of the Internet was, that the web is platform independent and wide accessible. Designing, which purpose it to prevent the information to be read from certain browsers and accessed only with a certain browser, is against the main principle of the original idea of the Internet.

If the main content should be accessible, that doesn't mean that everything is represented at the same way in all browsers. Originally browsers have freedoms how to represent tags. Web authors should use new features, if they help reading the content in some browsers without violating the accessibility from other browsers.

Additional technology, Java and so-called plug-ins applications should be easily added to any common used browser. In order to maintain the accessibility, authors and browser designers should use as standard techniques as possible. That's why exists W3C (= Word Wide Web Consontium: it has developed for example HTML, XHTML and CSS specifications) and other standardizing organizations like ECMA (it creates standard scripting languages).

I appreciate the work of the Webstandards organization to keep the web common accessible. Actual teaching and extra pages in the CSS-site use 100% standard-compliant XHTML 1.0 Transitional and CSS encoding (only framesets and a navigation frame use a little bit non-standard features). It can work as an example, how XHTML 1.0 and CSS can work together.

Standards: W3C, ECMAScript.
Other sites: Webstandards.


I like HTML 4.0 + CSS in order to make documents into the Internet. Netscape 4.04 was terrible disappointment. Its CSS-implementation is awful bad! I have however succeeded to avoid some problems. It is reasonable to define own style sheets for Netscape 4.x (instructions[S]).

I though that this means the end of Netscape, but now I don't think at the same way. I have much tested Mozilla Gecko rendering engine. It does have almost flawless CSS1 level implementation and wide CSS2-implementation, much better than in any MS IE browser. Netscape 7.0+ could even work as comparison application to all other browsers, how CSS1 should work according to the CSS2 specification. If Mozilla organization fix some tiny problems, it could work even like a validator application.

I give now a public congratulation to the main designers of the CSS-implementation in the Mozilla organization. Mozilla Gecko is the first application, which support all CSS2 level matching patterns including attribute selectors.

Main problems have been related with the generic functionality, but newest Mozilla Gecko browsers work quite reliable. I don't hope today, that it should be "scuttled like a ship into the bottom of the Atlantic Ocean" as I hoped before. Mozilla organization has made a real remedy! Because new Mozilla/Netscape browsers are highly standard-compliant, Mozilla could even save the Internet demanding also from other browser designers standard-compliant implementations.

The Mozilla Organization: FAQ.


Mean while I wanted however to find a browser, which have a good CSS-implementation. Microsoft Internet Explorer 4.01 has terrible flaws too even if it is not so bad as Netscape 4.x. I read about Opera. Opera 3.51 was a bad disappointment. Also that browser had bad bugs. I though to put the whole application into the trash and newer download that application into my hard disk.

But I found that Opera improves the browser whole time and I has released much new better versions. Because it is today available as ad-sponsored version, I hope that Opera could get much users.

Opera is quite standard-compliant. All Opera browsers have however incorrect handling of nested frame sets[S]. Opera can render complex nested frame sets almost properly only at 1024x768 with full screen - in all other situations it displays them incorrect!.

Opera is fast, handy and the security is at the top level. The newest version is quite reliable and fast. Even if Opera supports few proprietary features, Opera Software respects however highly web standards. If Opera could be more common browser, web standards could be more appreciated. These matters make it a highly recommended web browser.

When many Web-designers use proprietary features of MS IE, the user of Opera might get incorrect impression from the browser (the user might accuse the browser in situations, where he should accuse the author of the page[S]).

The chief engineer of the Opera Software is a former worker of W3C, Håkon Wium Lie, the main architect of CSS1-CCS2 specifications. He really understand the importance of specifications. But in a situation, where people don't get Opera (or new Mozilla Gecko browsers, for example Netscape 7.0) much enough, MS can dominant and finally almost totally destroy the original ideas of the Internet. When one company has monopoly state we are far from the original ideas of the Internet. The aims of Opera Software base clearly to the original ideas of the Internet:

Why do some Web pages render incorrectly in Opera?

The Opera browser is the strictest supporter of the W3C's technical standards in the browser market today. This is done to ensure interoperability between browsers and hardware manufacturers, meaning that a Web page made in accordance with W3C's recommendations is viewable with whatever browser-application an Internet user chooses. Unfortunately some Webmasters have been lead astray into making their sites specific to one or the other browser's proprietary standards. The result is that some sites effectively shut other browsers out, or their pages may look strange in them.

However, this is a transitional problem. With the advent of the wireless Internet, Webmasters must start complying to W3C standards, or else their pages will not be accessible to the majority of the Internet population. The two dominant browsers on the PC's are too bloated to fit into small, handheld devices. Why does Opera always emphasize that it follows W3C's standards? Because we at Opera believe in an Internet where everyone can meet, innovate and thrive. For this to happen certain international standards must be followed by everyone. The World Wide Web Consortium (W3C) [www.w3c.org] develops interoperable technologies (specifications, guidelines, software, and tools) that make this possible. We don't want to own or monopolize the Internet, we prefer an open Net where everyone is granted access and can thrive. For more information on Opera's values, take a look at Opera's Mission.

Indeed Opera supports some proprietary encoding of MS IE. Especially Opera 7.0 Beta 1 supports much proprietary JavaScript extensions in order to avoid situation, when some site is not accessible by Opera. The problem of Opera is that it is not so well-know browser. It is primary delivered by the Internet and many people are not ready to get it.

Opera Software: Press FAQ, , Opera 7 for Windows Beta 2, What's new in Opera 5.10, Web specifications supported in Opera 5 - the details, XML in Opera.


MS IE 4.0-5.5 for Windows browsers have been disappointments. I expected that Microsoft would have fixed main bugs of MS IE 4.0 in the 5.x series. Microsoft has fixed in this series some minor bugs in CSS1 level implementation, but MS IE 5.5 doesn't have at least flawless CSS1 implementation.

Finally MS IE 6.0 for Windows is a real trial to make a browser, which follow concerning supported features quite strict the CSS2 specification and it has almost flawless CSS1 implementation. Indeed it strict only in the standard-compliant mode[S].

Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.

MS IE 6.0 for Windows has still much missing of important CSS2 features. Some of them are supported in MS IE 5.0 for Mac. They have a long way to full CSS2 implementation.

I know pretty well, that Microsoft is more interested about XSL. For XSL(T) is necessary to supports only partially CSS. But also XSL(T) might suffer of missing features (read about my thoughts[S]).

Especially features, which are important for XML are missing. The property display would be easy way to manipulate document structure without making double structure with XSL-templates. I was disappointed also the fact, that except some pseudo-classes MS IE 6.0 doesn't support advanced CSS2 level selectors and property values of the property display (MS IE 6.0 for Windows supports one into proposed CSS3 value (inline-block)).

But even if MS IE 6.0 for Windows and MS IE 5.0 for Mac support quite well CSS2, that doesn't mean that MS honors generally the basic principles of the Internet. Microsoft also violates seriously the original idea of the Internet developing proprietary system in order to "steal" the whole Internet into its hand and at that way destroy possibilities of other browsers to work in sites. This is extremely evil and arrogant "steal and destroy" designing politics.

Microsoft use much non-standard implementation is MS IE and other products. In addition in MS IE has always implemented features, which are under construction and which are only public discussed. As an example we can take XML data islands (I handle them in a HTML note[S]). XML data islands like some attributes (I handle them in the page Help for HTML ALL menu[S]) were thought to implement in future HTML specification like in the possible HTML 5.0 specification. HTML 5.0 newer published because XHTML 1.0 became instead of it. MS IE 5.x implements then partially just an imaginary specification. Supporting of proposed features MS tried to make MS IE as an advanced browser compared to competitors, but those implementations are today just non-standard (proprietory) implementations, which work only in MS IE 5.x+.

I appreciate that Microsoft develop new systems. But in my mind those half-ready applications should be only experimental releases. They could be delivered commonly like official versions and, but all users should know, that the system is just half-made.

Do we want to support a company, which use much proprietary encodings, platform and browser dependent components and half-made specifications in order to monopolize (and that way "steal") the Internet? Proprietary solutions destroy also possibilities to render Web-pages properly such browsers, which follow stricter existing specifications. Also partial or buggy implemented specifications are bad matters (indeed CSS2 is hard to implement and there is not any browser, which has full visual implementation of it). All of these matters violate the original idea of the Internet to be an open, platform independent and common standards using global net! Supporting of common standards creates stability and breaking them continuous unstability and increasing chaos. This is the reason, why it is not good, if over 90% of web browsers are made by Microsoft.

Indeed also Opera and the Mozilla Gecko browsers support a little bit proprietary encoding (you can look proprietary CSS features from a special page[S], which handle non-standard and non-standard HTML from a table[S]). But according to my experience new AOL/ Netscape/ Mozilla org and Opera Software try to create browsers, which support existing specifications more strict than MS IE. If these browsers would be used more Microsoft could not behave very arrogant and it should develop its browsers to follow stricter existing specifications.

Web authors should avoid using such feature in MS IE browsers, which promotes this aim. Supporting non-standard systems, authors create in the long run total chaos to the Internet. When this happens, Internet is dead, if we judge it according to the basic principles of the World Wide Web. I hope that Web-authors could use those features, which belongs to existing recommended specification, neither proprietary nor half-made proposals.


Some questionable encodings

In the WWW used official recommended specifications are primary designed by W3C (there is also some other standardization organizations). In addition of official specifications, there are extensions, which have almost standard positions. These extensions should be judged according to the original purposes of the WWW:

  1. Extensions should be platform independent.
  2. They should be able to use in any browser.
  3. Common security problems of WWW has been taken account.

On the base of these principles Java applets fulfil quite well the original principles of the WWW. The half-official position of Java applets can been seen from the fact that they have in (X)HTML-specifications a special element (APPLET). Indeed to run Java applets some browsers need a plug-ins application.

Some commercial extensions don't fulfil these principles. The fact, that some feature belongs to the official recommendations doesn't make it problem free. If some feature works only in certain browsers and missing of supporting that feature prevents functionality in some browsers, using of that kind of feature is problematic.

I list some such encodings, which are questionable because of the security problems or they work only with certain browsers:


Fair play

Authors may favor either fair or unfair competition between browsers. It is possible to slow down the good development of the Internet by designing sites according to eldest browsers. The healthy development can be destroyed by using solutions, which works only in the dominant browser, MS IE.

Microsoft itself is an example of bad way evil Web-site designing. MS has been detected in its own site MSN-site Opera browsers and gave for them on purpose CSS, which cause bad result in Opera browsers. Microsoft works criminal way trying to stain the reputation of one competitor - the "moral" of Microsoft resembles the moral of virus designers.

Opera Software: Why doesn't MSN work with Opera.

In my mind more inconvenient feature is to Visual Basic scripts instead in the MSN site instead of standard scripting languages just the reason that pages would work as designed only by using MS IE browsers.

Because the healthy development of the Internet needs standards, the fair play means such completions, where browser designers have demanded supporting standards and using them in fair ways.

I have designed my sites quite strictly according to existing What are purposes of Web standards. There isn't any browser, which can render them exactly I have designed. One reason for this is to promote fair completions.

In my sites users of Opera 4.x+ and Netscape 6.1+/ corresponding Mozilla browsers can enjoy fixed navigation bar and always pleasant width of pages. Visitors, which use MS IE can enjoy quick menus.

When some solutions, which is made according to existing standards doesn't work in some browser, it could give an inspiration to improve the product. When visitors see different working browsers, they could learn to appreciate several browsers. At this way the existing situation, which promote the dominant position of Microsoft could get healthier features.

Using such features, which might become in some day as standards and which don't cause any harm to other browsers could be at some level used - I shun them. I give in the extra page, which handle What kind of non-standard (proprietary) CSS browsers support[S] some moral principles. Even if the author knows, who are the main visitors of his site, he should be aware, that his site might be found with some search engines. The author can't know exactly, which browser or which platform visitors have. Sites, which are primary designed for some certain browsers should work at least at some level with as many browsers as reasonably possible.


B Which problems are the CSS2 specification



The CSS2 specification has some known errors, which are listed after the CSS2 has been published. For example as changes, underscore (_) has been added as an allowed character for the names of id and class attributes. This is very good because in JavaScript is a common habit to use the underscore. All browsers don't however support it (look at a model page[S]).

W3C: Errata in REC-CSS2-19980512.

In addition of known bugs, CSS2 has some missing of important feature. This might be due because CSS1 designed primary to HTML documents, which have default behaviors and presentations to almost all visual elements. In XML elements don't have them and at that point of view, CSS2 has some remarkable missing features and CSS2 is too much HTML-oriented.

At some points CSS2 is too complex. This matter might not be able to fix anymore, but I propose however one matter, which could have done simpler.

The content width

In HTML the possible content is defined in DTD-files. The content can be possible child-element or data for some element (XML-document don't have necessary exactly defined contents for used elements). The content is normally between start-tag and end-tag. Concerning replaced elements the content comes from an independent file, which is placed instead of the original element. In this case some attribute defines, what is the replaced content (for example >IMG src="replacedContent.gif">). Because the content width means the concrete space, which must be reserved for the content, it doesn't include decorative/ separative borders or possible paddings - they are just additional attributes or properties for elements.

In HTML the attribute width is sometimes the total width and sometimes the content width. It is the total width for the element TABLE, when also possible borders belong to the value of the width attribute and not only the content. Concerning the replaced inline level element IMG it is the content width, which doesn't include possible borders. Because HTML-attributes are element dependent, the calculating principle of the attribute width doesn't need to be the same.

In CSS the width property concerns both blocks and replaced inline level elements. Because the behaviors of elements can be changed and the property must be able to apply almost all elements, the calculating principle must be element independent. The creators of CSS (Håkon W. Lie and Bert Boss) must choose, either use the content width or total width principle, but they couldn't choose both of them.

In CSS the property width is the content width of the element, not the total width of the element. The element, which has the content is like a "present box", when the content is the "present" itself. I hope that the image below could illustrate what means the content width.

A demonstration of the box model

Note. If some element can have also as a HTML attribute border, these borders don't belong to the content width and they should not alter the calculating principles of CSS defined element dimensions. HTML-borders are just "decorations" of the element like CSS-borders. If by CSS has not been defined width or border properties, but corresponding or resembling HTML-attributes are defined, HTML-values are used. CSS should however override them, when both are used. CSS must be able also to use with same calculation algorithms also in XML-documents, which don't have any predefined dimension calculation principles.

The content width principle is natural for images. Presumably just the definition of image dimensions was the decisive reason, why the content width -principle was chosen. An example how to define with different ways dimensions to the element IMG:

<IMG width="100" height="100" style="height:100px; width:100px">
<IMG border="1" width="100" height="100" style="height:100px; width:100px">
<IMG width="100" height="100" style="height:100px; width:100px; border:1px solid black">

What could happen, if the width property would not be for images the content width but the total width? Let's say that the intrinsic dimensions of an image are 100x100 pixel. When the pictures gets border="1" or border:1px solid black. At least with the border-property the image should be scaled to the size 99x99 pixel, when the result might look awful. How to behave with the border-attribute? Because it is non-CSS attribute, should the content width of the image remain 100x100 pixel? The total width principle would have caused calculation problems with images! If the dimensions of image would have defined with CSS, when images would have got borders, the width value should have been altered.

In tables the content width principle create problems if tables have borders. Also percentage values are problematic, especially width:100%, which purpose is to create full width tables. The total width principle could be less problematic in tables. Opera 5.x seems to follow CSS-specifications most strictly in tables, when other browser apply the total width principle of HTML into CSS (look at the page 10[S]).

Calculations of table dimensions is also other problems. What means table {padding:10px}? Should it be ignored? Because according to the HTML 4.01 DTD-files the content of TABLE is at least one TBODY element (in practise in most cases TR), then padding is in theory between TABLE and TBODY or between other child-element of the TABLE (in most cases in practise between TABLE and TR elements). This doesn't fit to the table border model concepts. Also TR {margin:10px} doesn't fit to the border model concepts. The CSS2 specification tells, when border can be applied and when it must be ignored. In the specification should be also expressed, in what conditions margin and padding should be ignored. The specification is not clear enough.

Concering general interpretation of the width property, the Windows folks of Microsoft tried the backward-compatibility principle in the interpretation of the width property in the relation of the HTML width attributes, which caused inconsistent and incorrect CSS-interpretation. With certain DTD MS IE 6.0 for Windows it follows either earlier versions of MS IE or (almost correct) the CSS specifications.

Maybe in general the total width principle would have been easier for Web-designer, because normally dimensions of images are not defined with CSS. But chosen what is chosen. In the sight of Web-author two different width-properties might have been ideal. Onto CSS3 had been proposed two different models, how the property width can be calculated (4.4 box-sizing (interpetation of width and height)). The property box-sizing defines the used calculation formula. The default value is content-box, which correspond the existing calculation formula of CSS2. The alternative for it is border-box, which correspond in HTML common used calculation formula, where border and padding are calculated to the width-value. Then <TABLE width="100%"> could be replaced with <TABLE style="box-sizing:border-box; width:100%">. Especially by using percentage dimension values border-box could be useful.

W3C: CSS2: 8 Box model, 8.1 Box dimensions[Pw], 10.2 Content width: the 'width' property[Pw], 17 Tables, 17.6 Borders[Pw]; CSS3: User Interface for CSS3 (W3C Working Draft 16 Feb 2000).
Microsoft:CSS Enhancements in Internet Explorer 6 Public Preview.

Inline blocks

Ordinary HTML elements can be classified according to the behavior into two main class, inline level elements and block level elements. CSS2 can in most cases describe these behaviors correctly both in HTML and XML-documents.

The problem is in some special inline level elements, which flow like a phase in a line, but which create a rectangular boxes round them. These kinds of elements are replaced inline level elements.

The CSS2 specification explains, how browsers should apply CSS differently to ordinary (non-replaced inline level elements) like STRONG and replaced inline level elements like IMG. This difference concerns especially applying width, height, margin and padding values

W3C: CSS2: 10 Visual formatting model details[Pw].

Demanding different rendering to non-replaced and replaced inline level elements, the CSS2 expects that browsers have to certain inline level elements the behavior type inline-block. CSS2 doesn't however have the corresponding property value to the display property (display:inline-block), which could describe this behavior. Indeed in some cases (approximately) the correct behavior can be get by setting display:inline-table, it is semantic incorrect do so. Works at least in Opera 4.x+, but the property width doesn't work and display: inline-block would be better.

Because of the deficiencies of the CSS2 specification MS IE 6.0 for Windows supports display:inline-block. With DTD, where the browser works in so-called standard-compliant[S] mode, it is the only possibility to set an ordinary inline element dimensions (for example <span style="display:inline-block; border:1px solid black; height:50px; width:200px">...</span>) so, that the behavior of the element resemble replaces inline level elements like IMG. Because other browsers don't support this method yet, the usage of this display type is not recommendable. A test element.

Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.

The centralization of nested blocks

When a block element has margin:auto, it should be centralized in the horizontal direction (it doesn't work in all CSS understanding browsers). I thought, that this could work also in the vertical direction, if the block is inside another block like in this example:

div.outer {width: 150px; height:100px; border: 1px solid black; margin:auto; vertical-align: middle}
div.inner {width: 100px; height:50px; border: 1px solid black; background-color: yellow; margin: auto; vertical-align:middle; text-align:center}
A test block

This doesn't happen, which is according to the specification correct. But in table rows the content can be centralized (<tr valign="middle">), but there is not corresponding CSS to general block elements, because the property vertical-align affects to the positioning of elements in the same line like the property text-align in the horizontal direction. Automatic centralization of nested block elements in the vertical direction is however desirable.



The fact, that the authors of the CSS2 have not thought thoroughly the rendering of elements in XML-document can be seen most in forms. Especially in order to get proper rendering of forms in XML, authors have added much new features to CSS3 (look at the last page[S].

In addition they have a small problem rendering borders (look at the page Backgrounds and borders[S], but this is quite small. It could be however desirable, that CSS3 could say, what could be the primary recommended way to render borders to certain form elements even if CSS3 would not force browsers to do at the recommended way.


Collapsing table borders

I have discussed about the collapsing border model (CSS2 17.6.2) of table borders (border-collapse:collapse) with some designers of browsers.

W3C: CSS2: 17 Tables[Pw].

I agree with them that the model is complex and messy. Especially the system, how to solve the border conflict resolution is too complex. It is quite difficult implementation to browsers and authors have extremely difficult to remember, how the browser should work in individual situations. If it could be possible to develop alternative simpler rendering model, which could be following:

  1. Borders to table cells are rendered according to cascading order and progressive rendering. When the browser reads the table, it start the progressive rendering from the top-left and goes to bottom-right. Table cells get the borders according this order.
  2. All rules, which are explained in the Border conflict resolution, except the rule, which handle the width of borders (narrow borders are discarded in favor of wider ones), are ignored.
  3. The author could define, which border have the highest priority with z-index the property, which could override the natural order. If borders have the same z-index, the cascading order and progressive rendering determines the borders.

In my mind this is simpler model and gives freedoms to the author. It is however remarkable that table-layout:fixed cause that the browser doesn't necessary read the whole table before it starts rendering. The browser should have the right to discard properties, which might cause problems to the progressive rendering (the browser can't change the width of cells in the bottom of the table).



Because the viewport is loose defined in the CSS2 specification, UA's have different interpretation of it. Opera doesn't count scrollbars to the vieport, but Netscape counts. That cause that position:fixed; bottom:0; right:0 is different in those browsers.

Could CSS3 give a recommendation, what is the viewport?


A plug-ins application to CSS3

Because CSS2 has some missing of important features, it takes very long time these matters are fixed in common used browsers. It could be best, if someone could develop a CSS3 player, which could be installed to browsers.


Fixes in CSS3

I gather in my mind the most remarkable fixes, which CSS2 brings to the detriments of CSS2:

  1. Proper handling of form elements.
  2. box-sizing, when for example to implement <TABLE width="100%">, because the calculation formula of CSS2 doesn't create corresponding result in certain circumstances.
  3. display:inline-block, which could be used also with the IMG element, because the display:inline doesn't really correspond the actual behavior of the IMG elements.

C What conceptual schemes and term trees relate with CSS

Handled conceptual schemes and term trees


Conceptual shemes

HTML/XML comment tag

comment tag
open identifier end identifier
markup open delimiter comment open delimiter comment close delimiter markup close delimiter
<! -- comment text -- >

Element tags

start-tag end-tag
open delimiter generic identifier close delimiter open delimiter generic identifier close delimiter
< HTML > contents </ HTML >

Term trees


CSS needs identifiers in two meanings. First the browser must find target elements to the declaration-blocks. The browser needs element and rule identifiers in the relation to the main documents. These could be called as external identifiers. Second CSS needs internal identifiers in order that the CSS-parser could be able to read correctly individual style sheets. It must be able to identify properties. The browser needs internal rule and property identifiers. I have completed the term list also with terms, which are not handled in the actual explanation page of the used terms.

W3C: CSS2: 4 CSS2 syntax and basic data types[Pw].


Markup codes

In addition the same kind of tags as xml-declarations are used also in server-side scripts, for example in PHP3 (<?php ... ?>; ASP and many other server-side scripts use instead <% ... %>).


D What are semantics of (X)HTML elements



HTML elements should be used according their original purpose. Instead of presentational elements should use elements, which have clear semantic meaning. Indeed if someone wants to support Netscape 4.x browsers, in situations, where CSS doesn't work for them, it is reasonable to use presentational elements (I must use them in some navigation elements).

Elements, which has clear semantic meaning have been called as phrasal elements. What is a phrasal element? The following block gives the answer:

A phrasal element is such text element, which have as far as possible media independent semantics. The name of the element is defined according to the contents (and it should be used only in appropriate content dependent situations). As an example is this block quote (the element BLOCKQUOTE), where I as if quote myself.

Block level phrasal elements have also more or less structural meaning, which inline level elements don't have. The importance of good semantics concerns especially inline level elements. I use commonly only Inline Phrasal elements and I express presentation only with CSS and the CSS-related element SPAN.

In HTML 4.01 and XHTML 1.0 sections, which need only presentational advice should be used DIV (division > div; block level) or SPAN (inline level) elements. The are generic elements, which are especially designed for presentational purposes of CSS (they can be used also for some other generic purposes like language overriding). If they are not needed in some media types[S], they can be skipped without causing any harm to the semantics of the documents. These elements can be used to anything, because they are generic elements, which don't have exact defined semantics (in addition of CSS, they can be used for exampe in language overridings).

The semantics of this site

Because HTML can't describe all semantics, I have to use the closest element. The meanings of semantic used elements in this site and additional pages are following:

Inline level elements

Block level elements

W3C: Modularization of XHTML™: Block Phrasal, Block Structural, Inline Phrasal, Inline Presentational.

Other elements

In theory it is possible to use also following phrasal inline level elements, which I have not used:

Indeed I would need at least one additional element (for example NAME or TERM) to represent official names and terms. I know that XML designed to give more semantics to the Internet, because HTML can never fully satisfy semantics needs and semantic HTML elements must use wider, which is the original purpose. I would like to write <term>Inline Phrasal</term>, but user agents should handle XHTML like XML in order to apply CSS to own elements - maybe this is possible in future.

In principle the semantics could be expressed with the class attribute, but it is intended primary as presentational usage. It is not good idea to express semantics with this attribute. HTML could work better at the following way:

Importance of semantics for aural style sheets

In order to get proper working aural and visual pages, it is important not to misuse elements and create artificial complex structures, which don't have reasonable semantics.

Some authors recommends to use the element P to add space. In my mind this cause bad semantics, because an empty paragraph is not semantic a real paragraph. Instead BR means always additional line break and I recommend to use it or CSS to add space. On the other hand if real paragraphs are needed, it is also bad habit to create paragraphs by using the double BR element!

When pure visual presentational elements (B, I etc.) are not used, the structure is clear and the content is accessible. I have tried to use elements so that they have reasonable semantics also to aural browsers. I have used also the title and summary attributes in order to give short explanations of some links, images and tables (the attribute summary concerns only aural browser, but the the attribute title works also in many visual browsers).

Such traditional HTML 3.2 elements, which are not recommended to use in HTML 4.0 documents are called as legacy elements (for example the element FONT and the attribute align). They have commonly only visual meaning and they should be used as seldom as possible (in the Modularization of XHTML, the Legacy Module concerns also some non-presentational attributes).

W3C: Access for People with Disabilities; Modularization XHTML™: Legacy Module.

E What kind of non-standard (proprietary) CSS browsers support


What kind of non-standard (proprietary) CSS browsers support must look from different points of views:

  1. Proprietary CSS can be designed only for the internal usage of the browser, when CSS-files defines any kinds of default settings (preferences) of the browser. These kinds of style sheets are UA style sheets (UA CSS, UA = User Agent = any application, which use style sheets to define its preferences).
  2. It can be designed especially for define the interface of the browser, when it is UI CSS (UI = User Interface). This kind of CSS can be UA CSS, or document CSS (I handle these points of views shortly in the page 5[S]). I doesn't normally affect to presentation of the actual page, but it concerns rather just the interface, like the color of the scroll bars, mouse cursor etc.
  3. It can concern the presentation of the document itself.
  4. It can be designed for the Web-author. This kind of CSS can concern both the document and the interface.
  5. It can harmless to browsers, which don't support it. It can be also serious harmful for browsers, which can't interpret it.

The usage of What kind of non-standard (proprietary) CSS browsers support should be avoided in common Web pages. It can be a little bit used, but using proprietary CSS in my mind should be used following "moral principles":

Between standard and What kind of non-standard (proprietary) CSS browsers support are implementations of working draft level proposals for CSS3. W3C recommends to use non-finished specification only in special test pages. The usage of them should be limit only to intranet solutions. MS IE supports them most. Also Netscape 6.x supports a little unfinished CSS3 proposals. I don't handle them in this page just at all. I made however a list of proprietary and proposed CSS-features, which I have found (or I have read) to be supported in MS IE 5.5, Netscape 6.1 and Opera 5.12.

Note 1. The disadvantage of proprietary CSS is that the official CSS validator of W3C tells that the CSS is invalid. In order to avoid this problem, it is reasonable to define proprietary CSS in own CSS-files. With some script can be done a function, which finds the special CSS-file only for the use of certain browser. Indeed this doesn't help users of Opera, because they can choose, how they identify their browsers. A CSS-file, which have proprietary CSS, might always cause problems for some users of Opera.

Note 2. If special feature of MS IE are used, it could be find, if also such features, which work only in new Netscape/Mozilla and Opera are also used. They support much such standard CSS2 features, which are not supported in MS IE but which make browsing with previous mentioned browsers especially comfortable. Properly designed these features don't cause any harm to browsers, which don't support them. I have use one proprietary feature of MS IE but much more such features, which works only in Opera and new Netscape/Mozilla browsers. I have not in any connection tried in purpose to make harm to visitors, which use MS IE (I have however in purpose made this site so, that it doesn't work optimal in the Netscape 4.x series).




UA CSS in Mozilla Gecko browsers

Browsers after Netscape 4.x have much UA CSS. In concerns both the interface and the presentation of documents. Netscape (and evaluation version of it like Mozilla) are in my mind first browsers, which use UA CSS at the way, which is explained in the CSS2 specification - defining the default presentation of (X)HTML elements. Default setting are stored in /res/html.css, /res/forms.css and /res/quirk.css CSS-files (/ = the base directory of Netsape/Mozilla).

The used CSS is primary standard CSS2. In my mind the most inconvenient feature in the UA CSS files is, that part of the UA CSS is defined by using the keyword !important. Then Web-authors can wonder, why some defined CSS don't work. Below is a piece of code from the file html.css:

frameset {
display: block ! important;
overflow: hidden;
iframe {
background-color: transparent ! important; /* (b=49779) */
border: 2px inset;

What kind of non-standard (proprietary) CSS browsers support in UA CSS files is absolutely ok, because it is for the internal usage of the browser. But "teasing" authors by using the keyword !important is in my mind inappropriate. It can't be assumed, that authors could understand to use the same keyword to override default settings, which are defined in UA CSS files!. In addition there is a small inconvenient feature in the UA CSS. Some standard CSS2 property values to the element LI are defined so, that default property values of that element are different as W3C has been recommend.

Indeed concerning the /res/quirk.css the usage of the important rule is ok, because the purpose is to emulate with certain DTD the buggy behaviors of the Netscape 4.x series. In this case is also correct to use proprietary CSS in order to cause non-standard behaviors.

The existence of UA CSS and proper usage of it could be possible mentioned? I don't have found information about the UA CSS, which new Netscape/Mozilla browsers use.


UA CSS in Opera 4.x+ browsers

Like Netscape/Mozilla Opera 4.x+ doesn't use an external UA CSS file in order to define the default settings of (X)HTML elements. Indeed according to an e-mail Opera does have a default UA CSS-file, which is built into the browser, but not available as an external UA CSS-file in some folder of Opera.

Instead it use external CSS-files in order to define default settings for other other file types and special implementations like rendering WML 1.x documents. UA CSS files are stored in Opera 5.1x to the sub-folder Styles (in Opera 4.x in the root directory of Opera). Concerning WML the purpose of What kind of non-standard (proprietary) CSS browsers support is to define the presentation of the element card by using position:deck, make linking to work and show used images (the property -replace()). To use proprietary CSS for this purpose is fully acceptable.

I have written a letter to Opera Software because it doesn't inform, that the proprietary CSS is especially designed as UA CSS. According to the Web-site of Opera Software the What kind of non-standard (proprietary) CSS browsers support: can be used - even if it is not recommendable - to use in XML-documents to get linking to work. (concerning Opera 5.x the proprietory CSS is exactly the same CSS, which Opera use in UI CSS files; Opera 4.x use a little bit different proprietory CSS in UA CSS files as Opera Software once informed in the Web-site).

This CSS is useful for example in a situation, where for Netscape 6.x has been done *.xml documents, which use the XLink linking language, which is supported in Netscape but not in Opera. In order to get the linking to work at least partial in Opera, it is necessary to add to the CSS-file the same CSS, which is primary intended as UI CSS for Opera.

Hopefully Opera supports one day also standard XML linking systems in order to get rid of using propriety CSS in XML-documents. Then the What kind of non-standard (proprietary) CSS browsers support could be used only as UI CSS.

It could be also fair, if Opera Software could announce, that Opera 5.x use proprietary UI CSS (it is not necessary list, which files and how they use it). The company could also tell, that What kind of non-standard (proprietary) CSS browsers support should be be used only in intranet solution, where all people use Opera as the default browser.

Opera Software: Web specifications supported in Opera 5 - the details.


As I have been already mentioned, the proprietary CSS in Opera and new Netscape/Mozilla is not (at least primary) intended for the Internet use. The What kind of non-standard (proprietary) CSS browsers support for MS IE is in principle level different as the proprietary CSS in Opera and Netscape/Mozilla because it is designed especially for Web-authors. The final purpose is is that Web-sites could work properly only in MS IE browsers. This aim violates the basic principles of the WWW and the Internet because WWW is intended as global net community, which use common agreed standards.

The proprietary CSS in MS IE concerns much UI CSS, for example defining the color of scroll bars (for example scrollbar-base-color: #603;). In principle non-standard UI CSS is such CSS, which belongs to UI CSS, when the user could define the presentation of his own browser. Using proprietary UI CSS in common Web-sites is in basic level a little bit questionable. But defining color of scroll bars doesn't cause any harm to other browsers. That's why I have used it in the "link books". Because CSS2 has some UI CSS, the fact that Microsoft calls them as extensions is in this connection appropriate.

Even if proprietary UI CSS belongs in principle among UA CSS, I don't resist the usage of such non-standard UI CSS, which doesn't cause harm to other browsers. Browser designers could even fairly compete, which browser helps visitors to understand better the content of Web-pages without causing any harm to other browser, which also visit in the same pages.

The UI CSS of Opera doesn't have UI CSS features. The proprietary UI CSS of new Netscape/Mozilla includes some UI CSS features. Netscape 6.x doesn't support the outline property, but it has non-standard proprietary properties, which make the same task. In principle they could be used in common Web-sites even if it is not recommendable. Because Netscape/Mozilla doesn't tell about this possibility, it might be impolite to use those properties.


Harmfulness of proprietary CSS

The the syntax of What kind of non-standard (proprietary) CSS browsers support in Opera and Netscape/Mozilla is according to CSS". The only matter, which is different, is that some property and pseudo-class selector names start at hyphen (for example in Opera -replace and in Netscape :-moz-dummy-option). Even if somebody puts among standard CSS2 What kind of non-standard (proprietary) CSS browsers support of Opera or Netscape, it doesn't cause any syntax problems for MS IE or presumably for some other application, which understand CSS. Using such Netscape/Mozilla specific CSS, which concerns the presentation of documents, it just cause that for example forms are rendered differently as in other browsers. Differences are not however drastic and presentation differences don't cause serious functionality problems. In fact properties, which use the -moz- prefix are not (or at least most of the are not) non-standard properties but experimental CSS3-implementations. Because the final CSS3 specification might define them differently as working drafts Mozilla Gecko browsers don't support them without the prefix.

Most of the proprietary CSS in MS IE is not harmful for other browsers. One of my e-mail friends send me an example of CSS, where some CSS was defined for the element H1. One line was MS IE specific CSS. That line caused Opera to ignore the whole declaration block for the element H1. Below is fragments of the original code, which I got from an e-mail:

h1 {
font-variant : small-caps;
font-size : 20pt;
margin-bottom : 1em;
color : #005a9c;
background : transparent;
/* below is the MS IE specific CSS */
filter: progid:DXImageTransform.Microsoft.DropShadow (color: '#C0C0C0', offX=3, offY=2); }

In principle Opera should be able to pass at least part of the encoding, which is written only for MS IE because of they should notice future specifications (the forward compatible parsing principle). Partially Opera can do this, but not in all respects. In the example above is so much features, which don't belong to CSS2, that Opera can't survive it. I examined, what matters are against CSS2 and what caused the fact that Opera ignored the whole declaration-block. I changed the original code first into the format filter:progidDXImageTransformMicrosoftDropShadow(color: '#C0C0C0', offX=3, offY=2), which Opera can pass. After that I changed it. The result was following:

  1. First filter:progid: is according to CSS2 specification invalid, because the double dot (:) should be used in CSS immediately after the name of the property (white space is however allowed) and property values should terminate to semicolon (filter:progid;). This matter didn't cause the problem in Opera and it can pass this kind of syntax, which is against CSS2. The browser must be aware, that future specifications might have property values like progid:... or properties use the format property:sub-property: (subordinated properties).
  2. Property values use dots in DXImageTransform.Microsoft.DropShadow. This is a decisive matter. These kinds of syntaxes might be added to CSS3. The basic idea of forward-compatible parsing is that the browser could skip properties, which might become into future specifications. The property starts according to CSS2 by using syntax property:value. If Opera finds unknown values, in my mind Opera should try to find the termination of the property, either ; or }. Now Opera can't find the termination of the block, it ignores the whole declaration-block. In my mind, Opera should not skip the whole declaration-block, but just the property filter. In other hands Opera interprets presumably DXImageTransform.Microsoft.DropShadow as a selector, when the declaration block should be terminated with curly brackets (}) either before or after DXImageTransform. The rest part of the code should then belong to a new declaration-block. Because the declaration-block is not broken at the place, where Opera expects, it can't terminate the block. If Opera interprets at this it behaves ok ignoring the whole declaration-block (not only the property filter). Opera Software just have not taking account that any future specification can have dots in property values. The presumably logic of Opera as a code example:
    /* after this code should be a new declaration-block, which start at open curly bracket ({) */
  3. Before a CSS-function is a space (DropShadow (color...)). A space in property values means that a single property ends and after the space is a new property value, which belongs to the same value set. According to the CSS2 syntax the browser should understand DXImageTransform.Microsoft.DropShadow and (color:...) to be two values of the same property. This is not however allowed because the syntax value() in CSS2 a CSS-function, which must write together. According to my logic the syntax of the value, which only MS IE understands should be DropShadow(color...). This is a decisive matter. I believe that CSS3 can't tolerate this kind of syntax because the common habit in computer languages is to write functions and arguments, which are inside normal brackets together (in addition of CSS for example JavaScript encoding follows this principle). In my mind in this case MS IE is too tolerable, "kind" toward syntax errors. Because of the syntax error Opera could determine, where the declaration block ends, it ignored the whole declaration-block.
  4. Another property is a value of the first property ((color: '#C0C0C0', offX=3, offY=2)). This has no effect and into CSS3 will become these kinds of features. Opera 5.x and other CSS1-CSS2 supporting browsers should be able to parse.

Partially the problem is in Opera, because it can't skip syntax errors in unknown properties (this is fixed versions, which are newer than 5.12). I made a test page[S], which demonstrates problems 2 and 3. Mozilla 0.9 can render it correctly like Opera 6.0 Beta 1 for Windows.

The author of the code, which I have used as an example wrote to me 28.09.2001 that he had error in DropShadow(color...) and it should be DropShadow(color...). According to an e-mail MS IE 6.0 accepts a space, but it is bad matter, because browsers should skip properties, which use invalid syntaxes and read the next valid property or the termination of a declaration-block. If browsers accept syntax error it cause validating problems.

In this case the encoding might in principle conform with some CSS3 proposal and the following encoding might be valid CSS3 property syntax:

filter: progid:DXImageTransform.Microsoft.DropShadow(color: '#C0C0C0', offX=3, offY=2)

That kind of syntax has not however proposed to any CSS3-proposals. The only proposal, which supports the property filter is SVG (Scalable Vector Graphics). It is a special language and the property filter doesn't belong to common used proposed CSS3-properties. In SVG the proposed syntax is quite different as in MS IE.

W3C: W3C Specification - Scalable Vector Graphics (SVG) 1.0 (Candidate Recommendation 20000802).

In fact the property filter is a proprietary property even if Microsoft gives in its WWW-sites incorrect impression, that MS IE uses the property filter according to a CSS3 proposal. Microsoft explains the usage of the property filterat the following way (I added to the text some emphasizing):

Filters often create effects that can be generated with script. This raises the question, "Why use filters if script can do the job?" There are several reasons for using filters. The most important is because they don't require script. For better or worse, many HTML authors do not use scripting. Filters are a convenient package for the same functionality that scripting provides. Another benefit of filters is that they are easier to author and can be applied to entire classes of elements, because they use the declarative and inherited syntax of CSS.

Filters and transitions display properly only on systems that have the color palette set to display 256 colors or more.

Almost any object can have filters applied to it. However, the object that the filter is applied to must have layout before the filter effect will display. Put simply having layout means that an object has a defined height and width. Some objects, like form controls, have layout by default. All other filterable objects gain layout by setting the height or width property, setting the position property to absolute, or setting the contentEditable property to true.

MS IE supports however really such properties, which are proposed for CSS3. As such it is good to have experimental level implementations - but common Web-sites are wrong places to test them! Because Microsoft recommends to use half-made specifications in the Internet, it breaks recommendations of W3C, where to use working draft -level specifications.

In general encodings, which might be harmful for other browsers are misuse of dominant position in the software markets. Everybody knows, that the purpose of Microsoft is to create total monopoly state in browser markets. Some means are supporting of proprietary and half-made specifications. By using them MS use "browser dominance terrorism"! If using of half made specification cause clear problems to other browsers, they should not be used in the Internet. At this point of view using of harmful encoding in the Internet used documents is supporting of the browser dominance terrorism of MS! I hope that all readers of this page could read "moral principles", which I have done.



In a way proprietary features are such features, which belong to the specifications, but implementations broke in purpose existing specifications. New MS IE and Netscape/ Mozilla browsers use DTD-switches, when with certain without DTD or with certain DTD new browsers work in some matters at the same way as older and more buggy browsers. Newer browsers support overall better CSS and HTML specifications and they are designed to work in certain modes better according to the CSS and (X)HTML specifications than in another mode.

Netscape/ Mozilla calls the better mode as the standard mode/ strict mode. The opposite is the quirks mode.

Microsoft calls the better mode as the standard-compliant mode, when the other mode is just the mode, where the standard-compliant mode has not been turned on. The "switching mechanism" is in MS IE 6.0 for Windows, MS IE 5.0 for Mac, Netscape 6.x/ corresponding Mozilla and Opera 7.x+ browsers.

In fact Opera 7.5x and newest Netscape/Mozilla browsers have a third mode (the Almost Standards mode).

Activating the Right Layout Mode Using the Doctype Declaration.

Maybe the most remarkable effect is in MS IE browsers, where the switch affects calculating width and height properties in MS IE browsers. The system works quite well except calculating the width property in tables. In MS IE 5.0 for Mac the DTD-switch affects also to the width attribute of the TABLE element. MS IE 5.0 for Mac handles in the standard-compliant mode the width attribute like the corresponding property, which is an error at the sight of HTML (I handle these matters also in the page 10[S]). In Mozilla Gecko and Opera 7.5x browser the standard and almost-standard mode differs each others when calculating the width of the table.

The switch cause also in MS IE into proprietary CSS. MS IE doesn't accept for example scroll bar properties in the standard-compliant mode. That's why pages, which are inside IFRAME and which have colored scroll bars, use DTD, which doesn't switch the standard-compliant mode on. Other pages work in new MS IE and Netscape/Mozilla according to strict/ standard-compliant modes.

I have found some differences and I have read from web pages about them. I found also that Netscape/ Mozilla defines non-standard behavior by using the quirk.css and a part of the information base also on that UA CSS file (differences, which are caused with this CSS-file are not general necessary to test). I have got also information through e-mails. The table below is not complete, but it mentions some possible differences (because I have not personally tested all listed matter, the table might have errors and I need help to get it better and the table doesn't make difference between the standard and almost-standard modes):

MS IE 6.0 for Windows MS IE 5.0 for Mac Netscape 6.2.1Opera 7.x
The first element inside BODY and TD elements have different top margins (concerning TD also the bottom margins of the last elements are different) if they are not set with CSS. Yes (UA CSS)
width and height properties for generic block-level elements. Yes Yes
The width property for the TABLE element. Yes (Maybe)
The width property for TD and TH elements together with table-layout:fixed. Yes Yes
The need of display:inline-block for ordinary inline level elements together with width and height properties. Yes
Applying CSS for the HR element. Yes (UA CSS)
Different font size handling inside heading elements (H1 etc.). Yes (prop. UA CSS)
Different wrapping of the PRE element. Yes (prop. UA CSS)
The presentation of list elements is different. Yes (UA CSS)
Different display type for the MAP element. Yes (UA CSS)
Different margin for the IMG element, if the image has the align="left" or align:right attribute. Yes (UA CSS)
Different handing of percentage heights on images and tables. Yes
Background properties for table elements. Yes (UA CSS)
Inheritance for most text related properties works/doesn't work for TABLE and CAPTION elements (font-size, font-weight, font-style, font-variant and for the element TABLE text-align). Yes (partially prop. UA CSS)
When tables have a border style of inset or outset, the border color is based on the background color of the table or of the nearest ancestor with non-transparent background. Yes (needs tests)
The empty-cells property defaults to hide/ show empty cells. Yes (UA CSS)
Table cells with a border have a minimum width of one pixel. Yes (needs tests)
The basic table layout strategy ignores/accepts paddings. Yes (needs tests)
Floated tables never move/ move to the next "line" if they don't fit next to other floats (if they don't move to the next line they just keep widening the page). Yes (needs tests)
Slightly different default presentation for INPUT elements. Yes (UA CSS)
Browsers render font-size:xx-small - font-size:xx-large differently (look at Model8c.html[S]). Yes Yes
The CSS parser accepts invalid names of id and class selectors. Yes
The CSS parser reads @import even if it is not on the top of the style sheet. Yes
The CSS parser accepts hexadecimal colors not beginning with #. Yes Yes
The CSS parser interprets unitless numbers as px (concerning Netscape browsers except for the font-size property because Netscape 4.x did according to the specifications; in general this matter doesn't concern the line-height property and any other properties where numeric values have distinct meaning). Yes (but a buggy fixing) Yes
Accepting of proprietary CSS. Yes


  1. Netscape/ Mozilla has also some HTML element and attribute related matters, which can't change with CSS. I have tried to list such default settings, which can change equal with CSS (in most cases the behavior can set equal with standard CSS but in some cases changes might need proprietary CSS, which Netscape/ Mozilla use much in their UA CSS files; in principle it is possible to change with proprietary UA CSS stand behaviors into non-standard).
  2. In the site of Mozilla org. according David Baron the basic table layout strategy handles widths differently in some way and Mozilla browsers. Because I didn't find any differences I put that matter into parenthesis. In principle Netscape/ Mozilla and MS IE 6.0 should have different handling of the width property with the TABLE element in the standard(-compliant) mode.
  3. David says also, that Mozilla browsers have a minimal difference handling xx-small-xx-small values. I didn't find any difference in handling font-size:xx-small - font-size:xx-large. That's why I don't mention about any difference in this matter. The effect might be different in different versions and Netscape 6.2.1 just doesn't have this difference.
  4. According to David the behavior of certain form control elements in Netscape/ Mozilla can alter also with some JavaScript encoding but I have tried to list only such features, which can be changed only by altering the DTD of the document.
  5. I have listed some details also in the extra page, which handles CSS-implementation errors of MS IE browsers[S].
  6. The switching point, where standard(-compliant) mode is on, is different in MS IE and Netscape/Mozilla browsers. In Netscape/ Mozilla browsers the strict mode starts from HTML 4.0 Strict or HTML 4.01 Transitional document types. In MS IE the standard-compliant mode starts from the HTML 4.0 Transitional document type, if the URL ("http://www.w3.org/TR/REC-html40/loose.dtd") has been given. If the URL has not been given standard-compliant mode starts from the HTML 4.0 Strict document type.
  7. The DTD-declaration must be on the top of the page without anything before it. I had in the CSS-site in some pages before it a comment, when MS IE understood XHTML 1.0 Transitional documents so that the standard-compliant mode was off.
Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview; The Mozilla org.: Mozilla Quirks Mode Behavior.



I handle non-standard and proposed features for CSS3 in in CSS-tables and notes for them (Table 1[S] Table 2[S] Notes 1[S] Notes 2[S]). In addition of listed proprietary CSS, according to some e-mails Netscape/Mozilla use much more proprietary CSS than I have listed. I don't however list such CSS extensions, which are not used in files (/res/html.css, /res/forms.css and /res/quirk.css), which defines presentations for (X)HTML elements.

Below is a list of mentioned proprietary and CSS3 proposed features according to the order, which they have in the previous mentioned pages:

In addition I mention in the page, which handles JavaScript tricks[S] using of the value expression.


Software-specific encoding



In addition that browsers support nonstandard CSS or markup up tags, some editing software support nonstandard features. Some of them might be supported by some browsers but at least a part of the encoding is only for the internal usage of the software itself.

I handle two cases. The first is related both with HTML and CSS encoding. The latter concerns just HTML-encoding and at that mean it goes over the topic of this page. In some respects it however resembles the first case. Because of the quite small meaning I don't handle the latter case in a separate extra page. I a little bit compare these two cases.


Microsoft writes about MSHTML. MS Office 2000 applications creates it. In addition of ordinary HTML markup MSHTML has also so-called XML data islands (<xml> ... </xml>) and proprietary CSS for Office-applications (in many cases the proprietary CSS use the prefix -mso- like Mozilla Gecko browsers use the -moz- prefix). The aim of the proprietary encoding seems to to maintain better original formatting than using standard HTML when Web-documents has been converted back to the original file formats like Word 2000 and Exel 2000 documents.

The MSHTML of MS Office 2000 was in fact the proposal of Microsoft for the HTML 5.0 specification but it was rejected. It was however discussed with in W3C.

W3C: XML in HTML Meeting Report (W3C Note 11 May 1998).

The way how MS Office 2000 combines HTML and XML is today totally nonstandard. If the document use XML, the whole document must be valid XML, not only data islands. MS Office XP creates the same kind of MSHTML, which doesn't fulfil formally the requirements of XML.

Word for Office 11 supports at some way XHTML through the InfoPath application.

Cover Pages: Microsoft Office 11 and InfoPath [XDocs]; InfoWorld: Exploring XML in Office 11.

MS IE 5.x+ might understand a part of the MSHTML but not everything. The way how Microsoft thinks software designing can be seen in the fact that MS IE doesn't support properly the paged media (paged media handles page margins and page breaks in printing). But when MSHTML has been imported into Word 2000 and printed with Word page breaks work better than in MS IE because of the proprietary CSS for MS Office applications. MSHTML-documents have been intended to print with MS Office applications.

MSHTML has very much encoding which is only for the internal usage MS Office applications. I removed once half of the MSHTML created by Word 2000. If I take account that the code had text approximately about 70-80% of the total quantity of markup codes and CSS definitions was special MSHTML.

MSHTML stress unnecessary Web-servers by feeding unnecessary encoding into the Internet. If with Office application has been created MSHTML and the final product has been sent into Internet, Internet has been used as if an intranet of Microsoft products. In my mind MSHTML doesn't belong into the Internet but only into some intranet solutions. According to an e-mail there are applications, which convert MSHTML into ordinary HTML, at leastMicrosoft Office HTML Filter 2.0.

Microsoft: Microsoft Office HTML Filter 2.0.

Word 97 tries to create almost standard HTML. If special formatting (for example bold or italic text) has been used the result is in most cases invalid but relative easy to fix with some HTML editor, which creates valid HTML and which can HTML-encoding errors.

Because it is not possible to create directly with any Office product valid XHTML instead of using some Office product (X)HTML for the Internet should create with valid (X)HTML editor. FrontPage 2000 is not a proper HTML-editor because it use a Windows character set and doesn't encode special characters at the way how they should be encoded in the Internet usage (for example "ä" should be encoded &auml; etc.), when the text can't be read correctly with Mac browsers. According to an e-main FP 2002 support relative well character entities.

At least some versions of FrontPage work also in some other respects. I found the following encoding from a Web-page:

<style fprolloverstyle>
A:hover {color: red; font-weight: bold}

That creates an ordinary a:hover effect. The fprolloverstyleattribute is completely unnecessary "FPHTML" encoding. That attribute is not for some browser because the information is relevant only for the editor. That kind of information should be inside comments. The code lacks type="text/css", which should set in valid code for the STYLE element. Mentioning of a certain style could be expressed with a standard way for example at the way below:

<!-- fprolloverstyle -->
<style type="text/css">
A:hover {color: red; font-weight: bold;}

In general informative encoding is not harmful for any browser but it is just inappropriate encoding. It is worth to remark that fprolloverstyle doesn't use at the sight of HTML 4.01 a valid attribute syntax. Some old HTML-specifications support compact attributes like <DL compact> but starting from HTML 4.x the syntax should be always attribute="value" (quotes are not always necessary). The format <style fpstyle="rolloverstyle"> would me at some level appropriate. In the pages, which had that attribute Mozilla 0.9 rendered the first page incorrectly. Presumably new Mozilla browsers get randomly confused the ending point to the end-tag. The seem to require two part. Indeed when I visited second time in that page I didn't had that problem. The problem might be related with some other issue..

I can't however recommend to use any HTML-editor of Microsoft's, which is older than FrontPage 2002. With the newest FrontPage and Macromedia Dreamweaver can create XHTML and those editors can regard as recommendable WYSIWYG editors. I have used HTML-Kit, which can be created standard HTML 4.0/HTML 4.01 or XHTML 1.0.

Adobe GoLive

At the same way Adobe GoLive creates editor specific encoding. The main difference is just that only products of Adobe understand the code and no parts of it is for browsers. I mention Adobe's codes[S] in a note page.

I have found some Web-pages created by Adobe GoLive, which had approximately encoding, which was unnecessary for browsers - the quantity of the unnecessary code for the Internet is about as big as in the MSHTML of MS Office applications. It would be smart if product of Adobe would have an option to remove editor-specific encoding before pages has been sent into the Internet. I don't regard editors of Adobe as appropriate editors.

Is there any application, which can remove the unnecessary Adobe GoLive specific encoding and create from nonstandard markup language of Adobe ordinary HTML or XHTML?


Examples of illegal definitions


Illegal CSS definitions

I have used and met much illegal definitions, which doesn't work.

Hints to avoid problems

I put a list of tiny errors, which I have done and you can avoid. First of all, use the CSS validator of W3C as I have done (a member of Webstandards ask me to use it - and he was right - I have made tiny errors, which were difficult to find). In this list is also my recommendations, how stylesheets could work better in problematic situations.

If you want to make some CSS definitions to Netscape 4.0x, I give you special hints (some other hints - no return link to this page):

Illegal HTML 4.0 Transitional loose definitions

I'm not a professional to understand all W3C doc type definitions (and I'm sure that there is only few people, who understands them properly!), but I recommend to use HTML 4.0 Transitional, not the strict definition, where all HTML 3.2 level definitions (like ALIGN, bgcolor="white" TEXT="#3f3f3f" LINK="#3f3f3f" VLINK="#2f2f2f", FONT FACE) are removed (they are defined with CSS) and then supporting transitional documents concerning appearance of documents is extremely limited. In my mind HTML 3.2 align-definition are in many cases faster to define and also older browsers understand them. HTML 3.2 align definition can also override with CSS (<P style="text-align:justify;" align=center> is justified to CSS understanding browsers). It is quite easy to make proper documents with this doc type definition:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">

This is the strict definition:


strict.dtd cause inflexibility to element P - in many cases it is more reasonable to use the align attribute.

All hints in this page concerns however the loose dtd. My designing principle is however that all definitions, which are harmful to the full functionality of CSS should not be used. Following definition limits the functionality of CSS and that's why I can't recommend it:

<FONT FACE="Arial" COLOR="#3f3f3f">

This works well also with CSS even if it could be defined also by using CSS:

<FONT SIZE="+1">

There is however a trick to make font definitions to HTML 3.2 and 4.0 compliant without losing the flexibility of CSS. This works to Opera 3.60, MS IE 5.0 and Mozilla 5.0: Welcome, because in the css definition is .font-color {color:maroon;font-size:20px;}. The rule means that class, which have the name font-color is applied to all elements. This system brings more compatibility between HTML 3.2 and 4.0 style font definitions and all commercial page designer likes this!Footnote 3. This is in fact valid according to DTD, because FONT accept core attributes - look at the DTD:

style %StyleSheet; #IMPLMS IED
title %Text; #IMPLMS IED">
color %Color; #IMPLMS IED
CSS definitions don't tell about it, because it is against strict HTML principles! But remember, that browsers handles them a little bit different ways. Opera don't take font-size values from CSS if it is defined like <FONT SIZE="+1">. To use FONT, B, I is not recommend to use and they don't belong to the strict DTD. HTML 4.0 strict base on a little bit too academic page design philosophy!

If you want to use your HTML page in some as parts of XHTML or XML files, use always lower case letters in tags, attributes and css-files and use always termination tags to p and li and mark empty tags to img, br, hr like
- HTML TIDY automate this process except in some "empty" element (empty means in this case that the tag doesn't have normal termination tag). Remember: making XHTML and XML files must be much more careful as making ordinary HTML pages!

Illegal HTML 4.0 Transitional loose definitions

Most common errors using HTML 4.0 loose, which W3C validator give error messages:

Opera and MS IE 5.0 puts often horizontal scroll bar - it is for these browsers much more common than MS MS IE 4.x and Netscape 4.0x. There is however a trick, which helps in many cases. I have used width="100%", which might cause horizontal scroll bar, but using width="99%" it disappears.

There is however some situations, where to slipper from standards is sensible. At least this one:

Other validator services


Also some commercial companies offer validator services, like Netmechanic

Other sites:

I have validates these pages with W3C and I Netmechanic complained many errors from a file.

Some comments to Netmechanic:
  1. It understand only certain type of DTD definition. This is okay for it: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">, but it doesn't allow to put file name "http://www.w3.org/TR/REC-html40/loose.dtd" after it - Incorrect - the file name is permitted. The robot has invalid list of accepted !DOCTYPE definitions!
  2. Doesn't accept empty titles (<TITLE></TITLE>) - in a way Netmechanic is right, but it should not handle it as erroneous HTML but it should give a comment. My comment: Because of search engines, it is sometimes sensible to try to avoid them to find pages. Using empty titles and this definition <META name=robots content=NOINDEX>,in meta tags, robots probably don't find pages. These are however matters of readiness - not of HTML validation!
  3. Don't accept empty definitions. I have put in a file ACTION="" - again in a way Netmechanic is right again, but I don't need any value - I admit, that this was only a trick to cheat the validator of WC3 - Netmechanic doesn't allow cheating, but it should give only a comment!.
  4. Doesn't accept other empty codes like <P></P>. This is worth to complain.
  5. But I found also other some real functionality errors in addition pf the first error. This is correct TITLE='Art box' and Netmechanic complained incorrectly!
    = = = = = = = = = = = = = = = = = = = = = ^Error: "BOX'" is not a supported attribute for "A".
    And it doesn't keep this valid either:
    Title='"The heart" of my pages -partially in English'
    Single quotation marks and also nested quotation marks are permitted!

It is easy to put so, that also Netmechanic regards them valid, but the result of those kinds of validation services should react with reservations. However - guite good validating after fixing some errors.

Web Site garage

Other sites:
Web Site garage.
Some comments:

Footnote 1. Also the style attribute (style="") includes an embedded declaration. 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 4.x 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 javasripts, which use also ";" as the separation mark like onClick="uusikkunaa(); if(browser) nayta(10, 'b')"

There is also a terminological problem, which concens the "!important rule' - in my mind it is misleading to call it as a rule. Read another another footnote from my CSS-teaching pages ([S]). (Return)

Footnote 2. You can find from CSS1 definitions (4.5 The canvas following, but this doesn't work in any browser and today it should not work:

This rule allows: <HTML style="background: url(http://style.com/marble.png)">
<BODY style="background: red">
In the example above, the canvas will be covered with "marble". The background of the BODY element (which may or may not fully cover the canvas) will be red.

In my mind HTML should have the possibility to define styles to <HTML> like in the example of CSS1 and just now there is needless limitation in the CSS2 spesificattion

In fact many of the problems in displaying HTML and BODY are derived too loose definitions in CSS1, which Håkon Wium Lie and his collaborators had done:

The canvas is the part of the UA's drawing surface onto which documents are rendered. No structural element of a document corresponds to the canvas, and this raises two issues when formatting a document:
  • from where should the dimensions of the canvas be set?
  • when the document doesn't cover the whole canvas, how should this area be rendered?
A reasonable answer to the first question is that the initial size of the canvas is based on the window size, but CSS1 leaves this issue for the UA to decide. It is also reasonable to expect the UA to change the canvas size when the window is resized, but this is also outside the scope of CSS1.

HTML extensions have set a precedent for the second question: attributes on the BODY element set the background of the whole canvas. To support designers' expectations, CSS1 introduces a special rule to find the canvas background:

If the background value of the HTML element is different from transparent then use it, else use the background value of the BODY element. If the resulting value is transparent, the rendering is undefined.

Microsoft and Opera has made different conclusion and this kind of over loose definition cause fragmentation. Also CSS2 in my mind too loose concerning displaying borders in container elements HTML and BODY.

Read my suggestion. The canvas is the most import matter to remark, because just the canvas is the space, which all CSS definitions should be rendered! (Return)

Footnote 3. I have discussed about this matter. Commercial web designer use HTML 3.2 font definitions just for the compatibility and they are not ready to use only CSS based definitions, which doesn't work with Netscape 3.x. My solution is a compromise. There is more need to use class-definitions than using strict HTML, but font values can be exchanged from linked CSS-files. (Return)


G What JavaScript tricks can be used with CSS


Flexible width control for MS IE

In all situations it is impossible to get the desired result only by using CSS. Especially defining width values for Web-pages are problematic. Well, it would be nice, if pages would work in most resolutions optimal. I personally hate phrases like:

This site works best 1024x768 or bigger resolution.

It is very easy to set flexible width control for Mozilla Gecko and Opera browsers. Just writing for the main content a class, for example content and following CSS for it (in this case inside a DIV element).

div.content {margin-left:auto; width:90%; margin-right:auto; max-width:620px}

This CSS would fit well also in 800x600 or lower resolution screens for MS IE 6.0 for Windows and MS IE 5.x for Mac if browsers work in the standard-compliant mode (I explain this mode in another extra page[S]). Because MS IE doesn't support the max-width property, that CSS would not be good in wide windows (texts remain inconvenient wide).

This matter can be fixed by using JavaScript, which have been set to the of the BODY element or at least before elements, which have been referred. It detects the width of the BODY element by DOM-based standard method document.body.clientWidth. If the width value is bigger than 800 px then for MS IE is a link to a CSS file (in the beginning are conditions for browser detections which purpose is that the script would concern only certain MS IE browsers; I handle browser detections in another extra page[S]):

	var nua, IE, OP, Gecko, Mac, ie_pos, IENu, IE6x, IE5x; 
	nua = navigator.userAgent;
	IE = (nua.toUpperCase().indexOf('MSIE')!=-1);  
	OP = (nua.toLowerCase().indexOf('opera')!=-1);
	Gecko = (nua.toLowerCase().indexOf('gecko')!=-1);
	Mac = (nua.toLowerCase().indexOf('mac')!=-1);
	ie_pos = nua.toUpperCase().indexOf('MSIE');
	IEnu = nua.substr((ie_pos+5),3);
	IE6x = (IEnu>=6.0);
	IE5x = (IEnu>=5.0);
if (IE5x && !OP&& !Gecko) {
	if (document.body.clientWidth>800) 
		if (IE6x || Mac)
		'k rel=\"stylesheet\" type=\"text/css\"'+
		'media="\screen\" />');

Note that MS IE does not count the right side scroll bar to the width value. If you want to set for fully open MS IE values, which fit into 800x600 resolution screen, the correct value is 780. In my example the value is not critical.

I a way the result is non-standard because LINK elements should be inside the HEAD element. Because the element has been generated by JavaScript it remains only in the RAM of the computer and it would never actually printed to the document, it doen't cause problems for validating the Web-page (instead of the LINK element could have been possible to generate a STYLE element or other HTML-elements, which affect the width of the content).

For wide windows could in principle just add the following CSS:

div.content {width:620px}

MS IE 6.0 for Windows/ 5.x for Mac could behave like Opera and Mozilla Gecko browsers except in situation, where the visitor changes the width of the window. MS IE measures the width of the BODY-element only once per each page. If the visitor has come with for example width 1000 px and then he sets the width as 700 px, he would not get the optimal CSS.

In order to get the optimal CSS the page should be reloaded. In order to avoid unnecessary reloading the page, the script should first test, if reloading is necessary. The script must be changed at the following way:

function changeCSS()
	if (((document.body.clientWidth>800) && (originalwidth<800) 
	&& (originalwidth!=document.body.clientWidth)) 
	|| ((document.body.clientWidth<800) 
	&& (originalwidth>800) && (originalwidth!=document.body.clientWidth)))

if (IE5x && !OP&& !Gecko) {
	var originalwidth = document.body.clientWidth;
	window.onresize = changeCSS;...

Now most used MS IE browsers work almost as well as Opera and Gecko browsers (you can download the full script[S] from my Web-site). Because reloading page is slower than just reformatting page, changing the size of the window might take some extra download times. I have also found that MS IE doesn't always get the right CSS (widths of the window has been changed one after another too rapidly).

The previous mentioned CSS doesn't fit for older MS IE browser and MS IE 6.0 for Windows/ MS IE 5.x for Mac if browsers don't work in the standard-compliant mode. If the content use padding-left and padding-right properties the width values are always different. In addition older MS IE browsers don't support properly margin-auto. At least MS IE 6.0 for Windows in non-standard-compliant mode and older MS IE Windows browsers calculate especially incorrectly percentage defined width values (I'm not sure how MS IE 5.x for Mac behaves). That's why the original CSS should be different. The following CSS gives wider working result:

div.content {margin-left:5%; margin-right:5%; }
div[class="content"]{margin-left:auto; width:90%; margin-right:auto; max-width:620px} /* New values for Opera and Mozilla Gecko browsers by using attribute selectors, which are unsupported in MS IE browsers. */

CSS for MS IE 6.x for Windows/5.x for Mac in a big screen and for situations, where browsers work in the standard-compliant mode could be for example:

div.content {margin-left:auto; width:620px; margin-right:auto}

CSS for MS IE 5.x for Windows in a big screen could be for example:

div.content {margin-left:100px; width:650px; margin-right:auto}

In order to horizontally center the content in MS IE 5.x for Windows browsers, the content should be inside instead a DIV element inside a CENTER element (<DIV align="center> doesn't cause the correct result). Then margin-left could be set as auto. It is also possible to generate for MS IE 5.x with Javascript a CENTER-element outside the DIV element. If it doesn't have the termination tag (</CENTER>) it doesn't cause problems for MS IE browsers.

For MS IE 5.x for Windows could add following statement after if (IE6x || Mac) {...} statements:

		'k rel=\"stylesheet\" type=\"text/css\"'+
		'media="\screen\" /><center>');

If you want to apply this system for Netscape 4.x browsers use detecting the width of the window the window.innerWidth method (also many Opera browsers support this method and they don't support previous mentioned DOM-based method) and in the browser-detection the document.layers method.

As an alternative to the system, which I have explained is to use multilevel nested tables. Flexible width control with them doesn't work in Netscape 4.x and I have not tested functionality in Opera and Mozilla Gecko browsers. Rendering multilevel nested tables is for browsers slower than handling just one DIV or CENTER element and the structure becomes complex. Indeed it is not necessary to reload the opened page, when the width of the window has been changed.

It is possible to get flexible width control and other dynamic CSS-effects by using the value expression() and putting inside it (DOM-related) JavaScript commands (works starting from MS IE 5.0). Because other browsers don't support this method, I recommend that, other browsers would get CSS with some standard way. Below is an example:

expression(document.body.offsetWidth - 110 + "px");
WebFX: CSS Expressions.

Floating elements and other tricks

Another important missing CSS-feature is MS IE for Windows browsers is support for position:fixed. It is possible to get blocks follow the mouse movement. Indeed JavaScript works worse than position:fixed. I got a script of Roy Whittle to work in my pages with MS IE browsers but not with any Gecko browser (indeed in the example page bottom positioned elements disappear from the screen in Opera browsers).

Javascript-FX: Floating Div.

It is worth to know that MS IE 5.x+ needs 5-10 times faster computer than Opera 7.x in order to run my pages approximately as good. Especially floating menus need fast computers.

MS IE supports much proprietary tricks. I don't recommend to use them because fully proprietary page systems don't belong to the basic idea of the Internet. Those what I have in this page handled are related with official standards.


H What CSS-features I have used in my pages



This page gives some answers, which CSS-features is reasonable to use. It is then in a way a continuation page to the page Frequently asked questions[S]. I have tested all CSS2 visual features excluding some font-related matters (I have mentioned them in the page 12. What other special features CSS has[S]).

Into CSS is some proprietary extensions. In MS browsers they are designed into common use, but in Opera and Netscape primary into the use of the browser itself. The proprietary CSS, which concerns only the user interface is not harmful for browsers, which don't support it. I had used in my sites scrollbar-base-color (it changes the color of scroll bars), but just now I don't use any non-standard in any actual content page (the previous mentioned property is used in some model pages). In general supporting non-standard features of MS IE is objectionable because of the designing politics of Microsoft (read the page concerning What are purposes of Web standards[S]).

Some browsers support also proposed features for CSS3. I have used one of these features. You can find quite exact information supported CSS-features from two How to set CSS for table elements (CSS table 1[S], CSS table 2[S]) and notes for them. Model pages have an own extra page[S]. Some models are XML-document. I handle XML-documents in in an extra page[S].

I list to this page the CSS, which I use today in my pages. Tables don't have the CSS, which I have use only as demonstrating purposes. Because my site works as an example how to use CSS, I have used quite wide quantity of different CSS-features - in commercial sites it is scarcely not possible to use them so much. I have not however used some non-supported, bad working or not widely supported features. I tell shortly, why I don't use anymore certain CSS. In some cases I tell also, why I recommend to use some CSS features.

Basic concepts, rules and What are selectors, classes and id-attributes

Into basic concepts belong applying CSS to (X)HTML documents. According to the HTML 4.01 specification also user style sheets[S] can regard to belong basic concepts, because the specification highly recommends, that user agents support them.

Basic mechanisms in CSS are also different rules and selectors. Some of them belong into basic concepts and some of them are rather advanced features of CSS.

Elements and attributes
<LINK rel="stylesheet" media="..." ...>
<LINK rel=stylesheet=" media="screen" title="..." ...>

<STYLE media="..." ...>

I give primary site wide CSS by using the LINK element and document wide CSS by using the STYLE element, because all media type supporting browser understand the attribute media (I don't always use at all the attribute media, when CSS concerns automatic all presentation modes). Because Opera supports the "slide show" mode, I have used for the media attribute values print, screen and projection.

Mozilla Gecko browsers (for example Netscape 6.x+) and Opera 7.x+ support alternative style sheets. Because browsers don't keep them when going next pages they are in practice useless and I took them out of use.

I handle basic definitions in the page 2. How to put CSS into Web pages[S] and so-called media types for different devices in the page 6. Font and text properties media types[S].


I use the attribute style quite seldom, because they cause problems with the Netscape 4.x series.

I handle this attribute in the page 2. How to put CSS into Web pages[S] and Netscape 4.x series problems in an extra page[S].

class, id

I handle these attributes in the page 4. What are selectors, classes and id-attributes[S].


I used import rules before quite much, but I have almost abandon using them because they cause with Opera (my favorite browser) problems with the attribute media. I use them in some situations importing primary such CSS, which is common to all used media types.

I handle the definition of the at-rule in the page 2. How to put CSS into Web pages[S] and problems in the page 6. How to set CSS for texts and different media types[S].


I used media blocks before quite much, but I have primary abandon using them. I use them only in exceptional cases, because MS IE 5.0 Mac doesn't support them.

I handle the problems of media types in the page 6. How to set CSS for texts and different media types[S].


It works at least in quite new Opera browsers. I handle the property in the page 6. How to set CSS for texts and different media types[S].

Important rule

Even if this feature is called as a rule, it is connected among property values and it belongs rather into properties than rules. Netscape 4.x doesn't support this feature. I handle it in the page 5. What is the processing order of CSS[S].

What are selectors, classes and id-attributes

Attribute selectors (for example. [class="some"]) work at least in new Opera and Mozilla Gecko browsers. I use them giving additional visual information and in some cases to pass MS IE in situations, where same property values to new Opera and Mozilla Gecko browsers would cause problems.

I handle rules and selectors in the page 4. What are selectors, classes and id-attributes[S].

element element
element.class, .class
#id, element#id
:before, :after

I use them primary in printing and the "slide show" mode of Opera in order to give assistance information with the property content.

I handle these selectors in the page 4. What are selectors, classes and id-attributes[S] and 9. How to set CSS for list elements[S].


Standard CSS2 properties (in the alphabetic order)
background etc.

I handle background and border properties in the page 8. Borders and backgrounds[S]. I have used them both as with shorthand properties and by using separate sub-properties.

border etc.

I handle the property in the page 10. How to set CSS for table elements[S].


It is related to the property position. I handle the property in the page 11. What is the visual formatting model of CSS2[S].


I handle the property in the page 3. What are color, units and keywords in CSS[S].


This property is very useful in printing and in the "slide show" mode of Opera. Together with :before or :after pseudo-elements it can give useful information with new Opera and Netscape browsers. I generate with this property also automatic ' marks together with the quotes property. I handle this property shortly in the page 9. How to set CSS for list elements[S].


I use it for special links. I handle the property in the page 6. How to set CSS for texts and different media types[S].

displayThis is one of the basic properties, which I control different presentation modes. I handle the property in the page 11. What is the visual formatting model of CSS2[S].

I use this property in positioning some elements but not in basic structures. I handle this property in the page 11. What is the visual formatting model of CSS2[S].

font-family, font-size, font-style, font-weight

I handle the property in the page 6. How to set CSS for texts and different media types[S] and concerning font sizes in the page 3. What are color, units and keywords in CSS[S].


I handle the property in the page 8. Borders and backgrounds[S].


It is related to the property position. I handle the property in the page 11. What is the visual formatting model of CSS2[S].


I handle the property in the page 6. How to set CSS for texts and different media types[S].

list-style etc.

I use them by using sub-properties. I handle properties of lists in the page 9. How to set CSS for list elements[S].


I handle the property in the page 8. Borders and backgrounds[S].

max-width, min-height, min-width

I addition of using height and width properties I control block box dimensions with these properties. They work in new Opera and Mozilla Gecko browsers. I handle these properties in pages 8. Borders and backgrounds[S] and 11. What is the visual formatting model of CSS2[S].

orphansThis property and the property widows prevent in some level lonely rows, when pages are printed with Opera. These properties belongs to the paged media, which I handle in the page 6. How to set CSS for texts and different media types[S].
outline (-moz-outline)

I use it in some special links above dynamic menus for Mozilla Gecko browsers. They support the outline property through -moz-outline. It works according to CSS2 specification with a:hover. After discussing with a browser designer the property outline is not directly supported because full support of the property according to the CSS2 specification failed. My purpose is now just try to take off the default outlines of the browser. This aim works partially. Opera 7.x+ supports outline directly and I give it for form control elements together with :focus. I handle it in the page 6. How to set CSS for texts and different media types[S]


I use in some tables controlling of the content of table cell the value hidden. I handle this property in the pages 10. How to set CSS for table elements[S] and 11. What is the visual formatting model of CSS2[S].


I handle the property in the page 8. Borders and backgrounds[S].

page-break-after, page-break-before, page-break-inside

I control with them page breaks in printing and in Opera changing "slides" in the "slide show mode". The last works only when printing documents with Opera. These properties belongs to the pages media, which I handle in the page 6. How to set CSS for texts and different media types[S].


I have used all possible values. I handle the property in the page 11. What is the visual formatting model of CSS2[S].


Look at notes of the property content.


It is related to the property position. I handle the property in the page 11. What is the visual formatting model of CSS2[S].


The property belongs to the paged media, which I handle in the page 6. How to set CSS for texts and different media types[S].


I handle the property in the page 10. How to set CSS for table elements[S].

text-align, text-decoration, text-indent

I handle these properties in the page 6. How to set CSS for texts and different media types[S].


It is related to the property position. I handle the property in the page 11. What is the visual formatting model of CSS2[S].


I handle these properties in the page 8. Borders and backgrounds[S].


I use this property in the main navigation element to hide some links. I handle the property in the page 11. What is the visual formatting model of CSS2[S].


Look at the property orphans.


I handle the property in the page 8. Borders and backgrounds[S].


I handle the property in the page 11. What is the visual formatting model of CSS2[S].


Mozilla Gecko browsers support it with the -moz- prefix (-moz-opacity). I use it for "shadows" of dynamic menus.

What kind of non-standard (proprietary) CSS browsers support-properties

I use it in shadows of dynamic menus for some MS IE browsers. This property creates special effects in Microsoft for IE 5.5+ Windows browsers. Microsoft informs it to be an implementation of the CSS3 specification. That is not however true. filter has not been intended for ordinary documents in order to create special graphic effects. It belongs to the special SVG language, where the syntax is totally different as the syntax, which MS IE uses.

W3C: Scalable Vector Graphics (SVG) 1.0 Specification (Property Index).

I How to design dynamic menus

Nature pages


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

The content as a one big page


This page gives hints to create multilevel dynamic menus. In the presentation section is also advice, which can be applied also for static menus.

How to design dynamic menus worked at the beginning only certain versions of Netscape and MS IE browsers with proprietary JavaScript-encoding, which was given the name DHMTL (Dynamic Hyper Text Markup Language). After that time scripting, which creates for example dynamic menus standardized in the DOM-specifications (Document Object Model) by W3C. The standard scripting language is ECMAScript and JavaScript encoding is standard as much as it conforms with ECMAScript standards.

ECMA: ECMAScript language binding; W3C: Document Object Model (DOM) Level 1 Specification (Version 1.0, W3C Recommendation 1 October, 1998), Document Object Model (DOM) Level 2 Core Specification (Version 1.0, W3C Recommendation 13 November, 2000).

Newest browsers support DOM at various level. The best implementations are in newest MS IE, Mozilla Gecko browsers (for example Netscape 6.1+) and Opera 7.x browsers. Also Opera 4.x-6.x browsers have experimental support of DOM. The used JavaScript works in Opera 4.x and it supports necessary CSS-features but according to my experience the generic functionality of dynamic menus is bad. It is quite working in Opera 5.x-6.x browsers, but all DOM-based menus don't work in them. They support also some extensions of MS IE.

Because it is fully possible to create dynamic menus, which work at least in MS IE 4.x+ for Windows, MS IE 5.x+ for Mac, Netscape 4.x and Opera 5.x+ browsers, I concentrate in this page to give hints in order to create dynamic menus, which work in the previous mentioned browsers. How to design dynamic menus might work also older versions of MS IE for Mac, but I don't have any information about the functionality of the menus in these browsers.

Scripts which have been designed only for the Netscape 4.x series browsers don't work in Mozilla Gecko browsers, because Netscape 4.x use in dynamic menus the proprietary method document.layers(), which is not supported in Mozilla Gecko browsers. They don't support either proprietary Netscape 4.x LAYER and ILAYER elements (it is in principle possible to use with them the element IFRAME but I don't regard using it very reasonable because of some problems). How to design dynamic menus should be made by using the method document.getElementById() (maybe in some situations getDocumentElement() could be used too). Scripts which work in Netscape browsers should include methods both for both Netscape 4.x and Netscape 6.x browsers.

Mozilla org: What have *YOU* done for web standards today? Mozilla new layout engine.
Are your JavaScript and CGIs ready for Nav5, IE5, and HTTP 1.1 CONTENT_TYPE? Get the latest info from Erick Krock.
Have a question? Before you email to him, first please check his answers.

It is easiest to create dynamic menus with some commercial applications. DHTML Menu Builder generates automatic necessary HTML-structures and CSS for different browsers. Older versions of the application create invalid CSS (most recent versions create standard CSS). If the CSS is not valid, menus work in some browsers only together with such HTML document types, when the browser don't work in the standard(-compliant) mode[S].

xFX JumpStart: DHTML Menu Builder.

If you know PHP, I have tried to create a model in order to update dynamic menus easily with PHP[S]. Menus, which I handle in this page are static HTML-code.

In this purpose is also free scripts. The original script, which I have used seems to be made by a quite new version of Macromedia Dreamweaver (according to an e-mail starting it is used starting from the version 4.01; the script is not in my sites in the original format). The usage of the main function (MM_showHideLayers(), the version 3.0) has been thought in many Web-sites, for example in TecsOfTheWeb.Com. Even if the script base on encoding of a commercial application, it can be freely used.

Macromedia, TecsOfTheWeb.Com: Using and Manipulating Dropdown Windows.

The site of the Finnish TV channel Nelonen (nelonen = four) use the same script as I have used in one level sub-menus. The site used however slow Java applets for Netscape 4.x. By giving as the keyword for search engines the name of the main function, it is possible to find much Web-sites, which use the same function, which I have used. As another example of good working dynamic menus in Opera (and presumably also in other new browsers) is also the site of Yomi Media (it use another JavaScript-encoding, but it use a resembling working system).

Nelonen, Yomi Media.

From the Internet can be found also other scripts, which work in Netscape 4.x and older MS IE browsers, but which don't work in Opera 4.x-6.x and Mozilla Gecko browsers (Opera 7.x supports the proprietary DHTML of MS IE, when at least a part of dynamic menus for old MS IE browsers work in that browser). Some versions of MS Frontpage creates scripts, which don't work in all DHTML/DOM supporting browsers. Scripts might be done also so, that they work in new MS IE and Netscape browsers, but not in older versions of MS IE and Netscape browsers. Below is an Web-address, which teach building dynamic menus, which work in most DOM1 supporting browsers (MS IE 5.x+ for Windows, Opera 4.x+ and quite new Mozilla Gecko browsers), but not in older MS IE and Netscape browsers.

CodeStyle: DOM1 Visibility menus.

Also MS IE 5.0 for Mac supports DOM1. Webreview writes about the support at the following way:

A good portion of DOM1 is supported in IE 5 for the Mac (chunks of DOM1 core are missing). However, the DOM support in Mac and Windows IE 5 is not consistent. This code is not cross-platform, and the Macintosh engine, while perhaps better at implementing DOM 1.0, is not consistent with IE 5 for Windows in all areas.

The advance of of the used script is that it works in all browsers, which overall support dynamic menus. The script has alternatives both according to proprietary DHTML and standard DOM working browsers. Advice, which I give in this page base on one ready made script (it is not necessary to change it at all).

Browsers have however problems, when it is difficult to find optimal solution. I give higher priority to newest browsers, if satisfactory solution for all browsers can't be found. In principle - but after hard work - it is possible with the used script to create in most browsers working nice "hand made" dynamic menus. For eldest DHTML supporting browsers might be reasonable to give static links. I explain in a separate page[S], how my own used dynamic menus work in different browsers.

If you use another code, dynamic changes must base on changing the value of the property visibility, because dynamic changes of the display property don't work in Opera. If you use the latter way, make sure, that users of Opera get at least so much links, that navigation is in overall possible without dynamic menus.

DHTML/DOM-menus can be in principle replaced with dynamic pseudo classes (:hover, :active and :focus) and IFRAME elements. I made some pages, which have experimental sub-menus[S]. In my tests systems work only in MS IE 5.5+ for Windows and Netscape 6.1+ (should work also in corresponding other Mozilla Gecko browsers), but not at all in any Opera browser (indeed works almost in Opera 7.0 Beta 1). Like DHTML/DOM menus IFRAME-based menus don't work in all browsers. That's why browsers should have the possibility to navigate the site also without the IFRAME-support. Because the functionality of this solution is very limited, I don't recommend anyone to use it. The only advance of this solution is that JavaScript support can be turned off. By using only CSS it is however possible to create only one level dynamic menus but DHTML/DOM menus can be as multi-level as necessary in individual cases.


Solutions for problematic situations

Because DHTML/DOM1 works at different level in browsers, in my mind DHTML/DOM-based menus should build so, that pages work also in such browsers, which don't support DHTML/ DOM scripts. Pages should work also in situations, where the user of the browser has turned off the JavaScript support. I have found situations, where without the JavaScript support doesn't exist at all working linking system. There is two reason for that matter. Either links have been generated "on fly" with JavaScript or they are hided (they have as default either visibility:hidden or display:none). I regard both solutions as bad. Links could be visible if the hiding would have done by using the onload attribute for the BODY-element. In this case links are visible if JavaScript has been turned off. This solution doesn't however work, because in dynamic menus links overlap the main content and maybe also total or partial each others.

In my mind following solutions are better:

  1. Main links work in all browsers and by using them it is possible to go to pages, which have continuation links. In this solution DHTML/DOM menus concern only sub-menus. In this case it is not relevant, if sub-menus have been automatic generated by scripts or they exist in the page, but scripts just hide/show them. It is not harmful, if a part of links are always hided, if the JavaScript support has been turned off.

    Browser-specific notes:

    1. It is not possible to solve all JavaScript and server problems, but if the presentation is not depending on the situations, if JavaScript support is enabled/disabled the visitor doesn't wonder, why the presentation changed quirky. At that mean this alternative is the most reasonable.

  2. Menu-related LINK elements are generated with JavaScript. At this way it is easy to tailor CSS for different browsers. Below is some examples of possible solutions:

    <script language="JavaScript" type="text/javascript">
    function linkStyle(sStyleFile,sStyleMedia)
    {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
    href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}
    /* Shortening code by using a function. In later scripts the file name and the media type has been give as arguments of the function. */

    if (document.layers)
    /* This is a condition for Netscape 4.x browsers, which don't support DOM1, but which support proprietary DHTML. For Netscape 4.x browsers should not set several values for the attribute media (for example screen,print).*/

    else { /* CSS for other browsers. Netscape 4.x has difficulties with complex conditional statements. It is best to give for it the simplest possible conditions. */
    if (document.getElementById) /* This test, if the method which belongs to DOM1, is supported. This is a condition for all such browser, which support in the used script the DOM1 section (under Windows it is supported in MS IE 5.0+, Opera 4.x+, Netscape 6.x+ / corresponding Mozilla browsers). */
    {linkStyle("layers.css","screen,projection");} /* Opera needs the media type projection. Future PDA-browsers might need also handheld.*/

    else if (document.all)
    /* This is a condition for such MS IE browsers, which don't support DOM1, but which support proprietary DHTML. Because the used file is the same as in the previous condition, the condition could be combined with the previous test by using the format (document.getElementById) || (document.all). */

    else if (!(document.layers) && !(document.all) && !(document.getElementById)) {linkStyle("noLayers.css","screen");} /* For unknown browsers, which don't support either proprietary DHTML or standard DOM1. If they support CSS, they get static link tables without layers. In this case these conditions are unnecessary but this is an example of using excluding conditions. */

    else {} /* A formal termination of this block. This statement-block is not necessary but it is a good practise to end conditional statements a this way. */
    <script language="JavaScript" type="text/javascript">
    /* In this example most browsers have been detected on the base on browser-specific informations. */

    function linkStyle(sStyleFile,sStyleMedia)
    {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
    href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}

    var IE4, OP, Gecko; /* It is a good practise to list global variables. */

    IE4 =(((navigator.userAgent.indexOf('MSIE')!=-1) || (navigator.userAgent.indexOf('Internet Explorer')!=-1)) && (navigator.userAgent.indexOf('Mozilla\/4.')!=-1)); /* Because newer MS browsers identify as Mozilla/4.0 compatible this detection fits also for newer versions. Some versions of MS IE use instead of the string MSIE the string Internet Explorer.*/
    OPua = (navigator.userAgent.indexOf('Opera')!=-1); /* Generic detection of Opera browsers. */
    op_pos=nua.indexOf('Opera'); /* Get the desired string. */
    /* At first has been defined, where to start counting digits after the desired string. The number 1 tells the quantity of used digits. In some identification strigs of Opera 5.x+ for Symbian OS (EPOC) browsers before the actual version number might be the letter v when the format (op_pos+7),1 is needed. */
    OP=(OPua && ((OPnu>=4) || (OPnu2>=5))); /* Detects Opera 4.x or newer browsers. In this case numeric values has been compared on the base of the previous variables (Opnu and Opnu2). Opera browsers can detect also by using detection strings like ((navigator.userAgent.indexOf('Opera 5')!=-1) || (navigator.userAgent.indexOf('Opera\/5')!=-1) || (navigator.userAgent.indexOf('Opera\/v5')!=-1) || (navigator.userAgent.indexOf('Opera v5')!=-1)). If for example Opera 5.12 for Windows would be in the mode Identify as Opera it would give the string Opera/5.12 and in other identification modes it would give the string Opera 5.12. Because dynamic menus work properly staring from 5.x+ it would be reasonable to ignore Opera 4.x browsers. */
    Gecko = (navigator.product == ('Gecko')); /* The detection for all Mozilla Gecko based browsers. It is possible to use also the same kind of detection method as for MS IE browsers above (navigator.userAgent.indexOf('Gecko')!=-1). */

    if (document.layers)
    /* CSS for the dynamic menus for Netscape 4.x browsers. Detecting Netscape 4.x browsers by creating variables from the identification strings doesn't work. */

    else {
    if (IE4||OP)
    /* The CSS for dynamic menus for MS IE 4.0+ and Opera 4.x+ browsers. */

    else if (Gecko)
    /* Total new or added CSS for Netscape 6.x+/ corresponding Mozilla browsers. The need of an own file is very small. If this section is not needed, the detection can be combined to the previous condition by writing it (IE4||OP||Gecko). */

    else {}

    <script language="JavaScript" type="text/javascript">
    /* A combination of method and browser based detections. You can support the widest possible range of unknown user agents if you test their feature availability. At least primary detections should base on supported methods. Only a part of the detection should base on the name of the browser or other browser-specific information. */

    function linkStyle(sStyleFile,sStyleMedia)
    {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
    href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}

    if (document.getElementById){

    var OP, Gecko;
    OP =(navigator.userAgent.indexOf('Opera')!=-1);
    Gecko = (navigator.userAgent.indexOf('Gecko')!=-1);

    if (OP)

    else if (Gecko)


    else if (document.all)

    else {}


    Browser-specific notes:

    1. If it is necessary to detect the MS IE browsers more exact that in the previous examples, that can be done for example by using conditions like (navigator.userAgent.indexOf('MSIE 6')!=-1). Instead it is a bad idea to use the version number based detections, for example navigator.appVersion.indexOf("5.")>=0. In addition of the version number of the browser itself, it might mean also the version number of the compatible Mozilla, platform (for example Windows NT 5.0) or the version number of the deliverer of the browser (for example AOL 5.0). A possible identification string might be for example Mozilla/4.0 (compatible; MSIE 6.0; AOL 7.0; Windows NT 5.0).

    2. Some version of MS IE use exceptional version number strings, for example MSIE+5.5+. If version numbers have been test exceptional version number strings might remain unnoticed.

    3. MS IE for Mac and MS IE for Windows have not taken account separately. That can be done by adding conditions (navigator.userAgent.indexOf('Mac')!=-1) and (navigator.userAgent.indexOf('Win')!=-1). Don't use full names of platforms because some browser use for example identification strings Win32 and Mac_PPC.

    4. Opera browsers have many identification modes and they in most cases they partially "lie". In most case Opera works in the mode Identify as MSIE 5.0. Opera might get bad CSS or it doesn't get any CSS in solution, where has only been asked browser names and version numbers depending of course the way how browsers have been detected. The ways how I have detected in my examples Netscape 4.x and Netscape 6.x+ browsers don't concern Opera even it would be in a mode, where it pretends to be some Netscape browser. If detections are nested they might slower the performance.

    5. It is not possible to get the real version number of Opera by using for example navigator.appVersion.indexOf('5.')>=0 because Opera return just the version of the browser, which it pretends to be.

    6. Even if Opera would be in any identification mode, at least relative new versions can however always be identified as Opera, but this detection must be before other browser-specific detections or there must be additional conditions so that Opera would not read the incorrect CSS.

    7. I found that Opera 4.x is very sensitive that before spaces is a backslash (\) and after it just one space and no additional line breaks. Because of small error first detections, which I made failed. If line breaks makes the code clearer, the code must be catenated for example at the following way:

         'k\ rel=\"stylesheet\"\ type=\"text\/css\"\'+
         'href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+
         sStyleMedia+'\"\ \/\>');

    8. According to an e-email for Opera 3.x browsers is impossible reliable to give CSS, which is intended for browsers, which don't support DOM or proprietary DHTML because they don't always give the version number of the browser itself. I don't know, if this is true. At least Opera 3.62 for EPOC informs the version number.

    9. Concering mobile phones Symbian OS browsers use in their identification string as the platform the string EPOC. As far as I know Opera 5.x+ are the only browsers which support dynamic menus.

      Opera for Symbian: General Opera information.
    10. In the second, third and fourth alternatives Opera 4.x-5.x browsers might suffer. They don't read the JavaScript if the user has used backward/forward arrows (or other corresponding actions) of the browsers. If the visitor doesn't always select a new page they render links at the way, how other new browsers render links if the JavaScript support has been turned off. This disadvantage concerns however only few visitors.

    11. If Mozilla Gecko browsers are necessary to detect more exactly I recommend to use additional detections, which base on the Build ID of the browsers. They can be combined with the detections, which I have used in my examples. For example (Gecko && (parseInt(navigator.productSub)>=20011018)) concerns Netscape 6.1/ Mozilla 0.9.1 and newer browsers. You can separate Netcape from Mozilla by adding for example the condition condition navigator.vendor == ('Netscape7'). Then you can give different dates for Netscape browsers if it is necessary. In principle separations could also be done by using as exact version numbers as possible, for example userAgent.indexOf('Netscape6\/6.1'). I have a list of dates and some detection examples in the extra page, which concerns Netscape[S].

    12. You can use as a model a commented source code fragment[S], which I have used. You can also find more detection examples from pages of an e-mail friend of mine.

    13. In the Linux platform can be used also the Konqueror browser. As default it writes the name and the version number of the browsers and it uses an own rendering engine. Then it can be detected with it own name but an additional condition must be used (in the examples, which I have used it would be && !Gecko) because Konqueror can be set to use the Mozilla Gecko rendering engine. The user of the browser can however alter the identification string, when it is impossible to detect reliable Konqueror.

    14. When the purpose is to design forward-compatible detections it could be reasonable to eliminate effects of possible changes in the case of the sub-strings. Adding either toLowerCase(). or toUpperCase(). before indexOf changes in the case have no effects (for example toLowerCase().indexOf('win') works with both Windows and WINDOWS strings).

    15. I handle in another pages PHP-based[S] browser detections.

  3. All links are in the page, but elements, which define layers have been generated by scripts, when all links are visible, if the JavaScript support has been turner off. Below is an example of a generated start-tags (they needs also corresponding generated end-tag):

    <script language="JavaScript" type="text/javascript">
    if (document.layers)
    {document.writeln('\<lay'+'er\ id=\"Layer1\"\ class="\pageGroup\"\... \>');}

    else {document.writeln('\<di'+'v\ id=\"Layer1\"\ class="\pageGroup\"\... \>');}

  4. It is possible to make a combination of two previous alternatives. In this solution in the main CSS-file is almost all needed CSS including most of the layer-related CSS. Only very little is in the CSS-file especially for dynamic menus. Even if the browser doesn't read the CSS file for dynamic menus, dynamic menus could work at least partial if just the browser can generate the necessary elements.

  5. In the menu is in a clear place a link to a special link page, which has continuation links into all necessary pages. It is not necessary that the actual menu is as default visible. There can be instead of the menu a link to the special link page, which can be for example a big link table.

  6. In situations, where JavaScript support has been turned off, the browser gets an alternative link set. The basic CSS-file ends in situation, where dynamic menus will be hided and the browser reveals alternative links. Below is an example of this solution:

    /* The following CSS is in the end of the basicScreen.css file: */
    #alternativeLinkSet {display:block;} /* Links for the alternative navigation. */
    #tableAllPages {display:none} /* Links for dynamic menus. */

    /* The following CSS is the beginning of the layers.css: */
    #tableAllPages {display:block}
    #alternativeLinkSet {display:none}

    Browser-specific notes:

    1. If the CSS commands to changes property values and much CSS has been given in two big CSS-files, the situation however "stress" browsers. I found in a test, where browsers had alternative link set in situations, where the JavaScript has been turned off in MS IE 5.0 for Windows the page must reload to get dynamic menus. This might be related on CSS (and/or servers), but not necessary because the CSS was partially depend with JavaScript supports. One way might be to generate CSS for hiding the alternative link set/ link set of revealing dynamic menus CSS with JavaScript like in the example below, but the following system doesn't necessary solve the problem:

      <script language="JavaScript" type="text/javascript">
      {document.writeln('\<sty'+'le\ type=\"text\/css\"\>');

    2. That previous solution doesn't solve another problem, which concerns alternative links. The another weakness of alternative links is that if the JavaScript support have been disabled Netscape 4.x shows both links for the dynamic menus and alternative links because taking off the JavaScript support takes off also the CSS-support. Also such browsers, which don't support at all CSS get two link sets.

In all ways to give different CSS for situations, where JavaScript support is enabled/ disabled have some problems, which might be related on servers, JavaScript handling or CSS-handing. If the server must gather CSS from several pieces, the browser might not get it enough fast, the browser might render the page incorrectly. If connections work well, CSS doesn't cause problems.


Used JavaScript encoding


Model files

In DHTML/DOM menus the JavaScript encoding is related with CSS and HTML encoding. The system needs one JavaScript and few CSS files, encodings to head section and event handlers to the body sections of the document. Following example files (I have used them in my Finnish and English CSS-pages) can be freely used designing dynamic menus:

Generic notes:.


Links of the dynamic menus can exist in the page or they can be generated by JavaScript encoding or some server-side systems. In the example pages links are inside tables. The JavaScript, which I have used just controls which menus will be revealed/ hided and how they will be revealed/ hided.

The main principle of dynamic menus is very simple. The author defines blocks, which work as dynamic menus. He sets for them id-attributes, which correspond values, parameters (they are called also as arguments) in the even handlers. The most used event handlers are onmouseover, onmouseout and onclick (the last can be replaced with href="javascript:" in situation, where normal links are not needed). I teach using of them. Functions, which Web-authors should detect when he designs dynamic menus are just three:


Timered menus

The author must then just select, how menus should work in each levels. Below is an edited screen capture from the English example page[S]:


How to design dynamic menus have timer functions and the menu use the following system (the explanation has shortened source code examples):

  1. From the main menus the visitor can go the the second level links by moving the mouse over the link and then moving the mouse to the right (if the visitor clicks the link he goes to the first page of the selected page group) or clicking links in the arrows (). Selecting one sub-menu closes other second level menus:

    <a href="index2.php3#Full" onmouseover="ajastin_pois(); MM_showHideLayers('indexPages','','hide','allSites','','hide','Generic','','show',...);" title="">Generic</a>
    <a href="javascript:ajastin_pois(); MM_showHideLayers('indexPages','','hide','allSites','','hide',...);" title="..."> <img src="..." title="..." alt="..."/></a>
  2. Going out from the second level menus they disappear from the screen after few seconds with a timer. It is possible to go from the second-level to the third-level at the same way as from first-level to second-level. Below is the source code, which keeps the second level menu visible and close it after going out of the menu:

    <div id="Generic" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Generic','','show');" onmouseout="piilota_valikot_hitaasti('Generic');">
  3. The third-level menu keeps the second-level menu visible. The third level menu can be closed fast when the visitor goes out of the menu:

    <div id="Generic1" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Generic','','show','Generic1','','show');" onmouseout="MM_showHideLayers('Generic','','show'); piilota_valikot_nopeimmin('Generic1');">

In the previos explained solution has quite many generic and browser-depending JavaScript-related problems.

Generic notes:

  1. Commands for the container elements have higher priority than commands for individual links - links inside the container element can't change show/ hide commands, if the commands concern the same element(s)!

  2. The previous explained system has problems with closing in some situations third-level menus, if the visitor moves the mouse to the left and ever goes to the menu itself.


    If there is no links on the left, the third-level menu might remains visible until the visitor goes to the main menu. In the meantime the third-level menu leaves as an "orphan" on the screen. The problem could be partially solved by adding to the left of the opening link of the third-level menu a transparent image or some non-breaking spaces (&nbsp;), which (normally) close the opened third-level sub-menu. Below is an example of an imaginary filling image (so-called spacer images, which are usually transparent GIF-images):

    <a class="filling" href="#" onmouseover="ajastin_pois(); MM_showHideLayers('AppendixesStandards','','hide');"> <img src="../Images/spacer.gif" width="11" height="15" /></a>

    These kinds of tricks are in my mind irritating artificial. They have the problem that fast movements of the mouse might leave third-level menus visible, because active areas are very small. The browser has just not enough time to react to the events.

  3. Additional active spacer images are needed also in situations, where the lowest links of menus open a sub-menu. In these situations the invisible links close the last opened sub-menu.

  4. If function calls become too big to keep track, they can be gathered as new functions, for example (this is in the Finnish example page):

    function hideThlMenus() /* Hide all third-level menus */
    {ajastin_pois(); MM_showHideLayers('GenericPreface','','hide',...);}
  5. I have found that slow reacting speeds of browsers is a generic problem. That's why I have added some such closing commands to the main menus, which should in principle be needed only in the second-level menus.

Browser-specific notes:

  1. Especially in Opera 5.x-6.x and sometimes also in MS IE second level menus might disappear unexpected if the visitor scrolls menu items upward and downward without clicking anything. In Opera 7.0 Beta1 doesn't have stability problems with timered menus.. Menus are even more stable than in MS IE browsers.

  2. Opera 5.x-6.x don't keep in this solution second-level menus reliable open, when the visitor is in some third-level sub-menu. The visitor must whole time move his mouse. If Opera have hided the second-level menu, moving of the mouse pointer can again get visible the hided second-level menu. The user of the whole menu system feels quite unstable even if the stability problem is not serious.

  3. If in the third-level menu in the state onmouseout have been not been use a timer but instead onmouseout="MM_showHideLayers(...,'Generic1','','hide');" it is not possible to go the third-level menu at all with Netscape 6.1 level Mozilla 0.9!

  4. If for example the third level menu AppendixesStandards will be closed from the second-level menu with MM_showHideLayers('AppendixesStandards','','hide'); the result is that with MS IE 4.x for Windows browsers it not possible to go to the third-level menu at all, because the browser support buggy onmouseout for container elements (onmouseout affects the result in areas, which are not links even if the behavior should be dependent on the edges of the container element). If the closing has been done with the timer function piilota_valikot_nopeasti('AppendixesStandards'); Opera 5.x-6.x have problems with it, because it cause in Opera unexpected closing of menus! In my mind following commands for the second-level menus are not very useful:

    <div id="Appendixes" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Appendixes','','show');" onmouseout="piilota_valikot_hitaimmin('Appendixes'); MM_showHideLayers('AppendixesStandards','','hide');" >
    <div id="Appendixes" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Appendixes','','show');" onmouseout="piilota_valikot_hitaimmin('Appendixes'); piilota_valikot_nopeasti('AppendixesStandards');" >
  5. Browsers work better if the timer has not set direct to the links (the A elements) but instead in the container block, in the ancestor element (possible padding areas are active, but borders and margins don't belong to the active area of the container element). Timers for individual links cause flickering, links disappear unexpected and they can't be opened immediately - in overall the accessibility is in general bad! Especially Opera 5.x-6.x have problems. The same problems are also in MS IE for Windows browsers, but not as a bad as in Opera 5.x-6.x. I found that closing links with the container element don't however always work in Opera 5.x-6.x as expected if timer functions has been used (Opera might close menus unexpected).

  6. In Netscape 4.x browsers container element of links work at the previous mentioned way only by using LAYER or ILAYER elements. This one of the two reasons, why I use LAYER elements. I must use them also because used CSS didn't work in all situations in Netscape browsers together with DIV elements and JavaScript-encoding as it does in other DHTML/ DOM capable browsers. It is however possible to get JavaScript to work together with LAYER elements. I had difficulties to get JavaScript to work with the first LAYER. I took off position-related CSS from the corresponding DIV element (other browsers get it linked). I used in certain evaluation versions formal empty "menus" (<div id="foo" style="visibility:hidden"></div>), which I don't anymore need. In random situations I need to generate an additional LAYER in order to get the first menu-related element to work properly. I got finally every desired menu to work with LAYER elements. I have generated them with following kinds of scripts:

    <script language="JavaScript" type="text/javascript">
    if (document.layers)
    {document.writeln('\<lay'+'er\ width=\"120\"\ visibility=\"hidden"\ top=\"66\"\ left=\"141\"\ id=\"MainPages\"\ bgcolor=\"white\"\ onmouseover=\"ajastin_pois(); MM_showHideLayers(\'MainPages\',\'\',\'show\');\"\ onmouseout=\"piilota_valikot_hitaasti(\'MainPages\');\"\>');}

  7. According to an e-mail onmouseover event handler attributes didn't always work in MS IE 5.0 for Mac browsers in some evaluation version of my dynamic menus. Because of this reason in some pages only javascript:... commands opened sub-menus. If possible dynamic menus should be tested also in MS IE 5.0 for Mac browsers. According to my experience the same kind of problems are also in Opera 4.x browsers, but it is not necessary to take account Opera 4.x browsers.


Non-timered menus

As it has been obvious in my mind in the previous mentioned example "solution" which use timer functions has too much serious problems, which are related with the stability and closing of sub-menus. It is however possible to get rid of them. Following solutions work better:

  1. Menus have special closing links.

  2. Menus have hided closing links in necessary sides of the menus.

  3. Menus have closing link in the actual content of the page (in this solution dynamic menus should not be inside the actual content). The closing function should not have a timer because Opera 5.x-6.x works well only if the timer has not been used. Browsers might have small delay times before they close open menus. This is however quite harmless delay because browsers always close menus when the visitor moves his mouse.

In the previous list first and second spots are however unnecessary. For most browser the most reliable working system is the following:

A background box

Shadow boxes

If the purpose is that dynamic menus will be opened and closed automatic with onmouseover attributes they are the only possible ways, how menus work as reliable as possible in MS IE 5.x+ (Mac and Windows), Opera 5.x+ and Mozilla Gecko browsers. Especially my solution improve the performance of dynamic menus in Opera 5.x-6.x browsers if multi-level sub-menus have been used. I must however point out that menus work in all previous mentioned browsers as flawless as they can ever work. Also user of MS IE can be fully satisfied in my solution. In my mind (at least) three-level dynamic sub-menus work well if the menu system fulfil following requirements (my system fulfils all of them at least with some variations):

  1. All sub-menus are absolute stable in all circumstances. For example when the user is in some third-level menu the second-level menu, which works as the "parent menu" (the menu, which opens the next level menu) remains stable visible.

  2. Sub-menus will never close unexpected (all situations, when the menu will be closed, when the visitor is inside the menu block are unexpected situations; also situations where the visitor scroll menu items and the menu disappears is an unexpected situation).

  3. Sub-menus never will be close before the visitor has passed the whole menu block.

  4. The visited sub-menu will be closed when the visitor goes out of the whole menu block except situations, where the mouse is in a position, which opens a next level sub-menu.

  5. The parent menu is visible the whole time, when the visitor is in the last opened menu level.

  6. There are no situation, where a sub-menu could leave as "orphan" (for example a third-level menu is orphan in a situation, where the third-level menu is visible but the second-level parent menu is hidden).

  7. When the visitor has gone to any last level sub-menu he can go from that sub-menus to the same path back to the first-level main menu.

Special advances of my solution are following (many of them are impossible to solve with other kinds of solutions):

  1. In my solution is never serious problems, which timer delays might cause.

  2. Artificial spacer images are not needed at all.

  3. Special closing links are unnecessary.

  4. The quantity of event handler attributes can be minimized and onmouseout is not necessary needed at all in closing commands of sub-menus.

  5. Menus can be quite multi-level without remarkable problems. I have used four-level sub-menus and they have been worked as flawless as second-level sub-menus.

  6. This is extremely easy solution for Web-authors (authors must however know, which browsers support it).

  7. If the author leaves enough empty space around links (and/or menus have background boxes), the user of menus don't by accident close menus and fast closing menus feels quite comfortable to use.

The restrictions and disadvantes of this solution are following:

  1. The only remarkable restriction is that smooth "comfortable" delay times are not used. Users of Windows XP might have used them (personally I don't like slow and smoothly opening drop-down menus). Browsers must however work in the Internet in much more unstable environment that ordinary application under stable platform. It not reasonable to ask for a Web-page the same "comfort" as for example MS Word. Indeed delay times are more harmful for some browser than for some other browser. If author (like many author in fact do) don't care more or less impaired functionality in some browsers, timer functions can be used.

  2. Menus can't be designed so that when the visitor goes outside the last level sub-menu only the last level sub-menu disappears but previous level sub-menus remains always visible. In generally visitors don't want this kind behavior because if the last level menu would leave always previous level menus visible, the visitor should always especially close previous level menus. It would cause extra work for the visitor, which is in generally regarded as an unpleasant feature. In my system it is always the possibility to go back along the same path to the main menu but "slipping" from the path closes all opened sub-menus. Indeed as needed it is possible to avoid slipping by using background boxes.

  3. As a small disadvantage of my solution is the fact that the best possible solution for MS IE 4.x for Windows Web browser needs defining much shadow boxes. Shadow boxes have however some advances also for other browsers but doing them only because of MS IE for Windows is questionable. MS IE 4.x for Windows has become quite little used browser and the meaning of this disadvantage lessens day by day.

Browser-specific notes:

  1. If the structures of the dynamic menus are very heavy I have found that going from third-level menu to second-level menu MS IE 6.0 for Windows (concerns presumably also the 5.x series) might close menus unexpected if the whole content close the menu by the onmouseover or onmousemove attributes in situations. I found that I didn't have defined the z-index property for the base element of the dynamic menus and the main content. When I set the functionality improved but the problem didn't disappeared totally.

    I got that problem solved only by defining an active background box behind the entire menu. It is reasonable to set for the background box either the onmouseover or the onmousedown attribute because onmouseout attribute close menus when the visitor goes first out of the whole menu and then tries to return back to a sub-menu, which is inside the background box. If the background box has a background color there is no problems between the closing commands of the background box and the actual content. A transparent background box worked worse. In my tests onmousedown for the colored background box and onmouseover for the content worked ok. If the background box used onmouseover the content should have either onmousedown or onclick attributes. In problematic situations it is reasonable not to use at all closing menus through the actual content or closing menus trough the content has been designed so that it doesn't concern MS IE 6.0 for Windows. If sub-menus have shadow boxes closing through the content doesn't cause problems.

  2. MS IE 4.x for Windows closing menus with onmouseover or onmousemove or attributes from elements, which are directly below the menu cause the problem, that sub-menus don't always stay open and menus are extremely unstable. I tried onmousedown but links were difficult to open and it doesn't work as it should. Only the onclick attribute can be used in this purpose. If this browser is intended to support, closing sub-menus through the content should be implement conditional by using the document.write() method of JavaScript so that the closing dynamic menus from the content by using certain event handler attributes doesn't concern MS IE 4.x for Windows. Sub-menus might remain open but this is much better situation than the situation, where it is not possible to select some menu items in the desired sub-menus.

    In the example code below the task of the function hideAllGroups() is to close all opened sub-menus through the actual content of the Web-page. Adding the following code before the actual content of the document force all dynamic menus supporting browser at least with some event handler to close all opened sub-menus (all of these even handler are not necessary to set):

    <script language="JavaScript" type="text/javascript">
    if (document.getElementById)
     onmouseover=\"hideAllGroups(); \"\>');}
    else if (document.layers)
    {document.write('\<layer\ z-index=\"0\"\ 
    else if (document.all)
    else {}
    The actual content starts here...

    If behind the menu have been set a background element and/or each sub-menus have their own shadow boxes, which don't have event handler attributes, which concerns the previous mentioned browser, menus can be closed from the actual content with any supported event handle attribute because the content is not directly below the menu. The background element and/or shadow boxes work then as an "insulations" between the menu and the main content.

  3. If shadows are positioned on the base of the absolute positioned element, Opera 5.x might not position them correctly. Use browser-specific CSS for Opera 5.x or don't use nested postioning.

  4. As I have earlier explained all structural solutions don't work in MS IE 5.0 for Mac browsers, why it would be reasonable to use as simple solutions as possible (you can go through a test case[S] MS IE 5.0 for Mac browsers).

  5. Closing menus from the content needs in Netscape 4.x browsers that the whole actual content is inside LAYER or ILAYER elements.

If you want more advice, I recommend to visit in other sites. You can find good hints also from the site of TechsOfTheWeb.

TecsOfTheWeb.Com: Using and Manipulating Dropdown Windows.




Visibility & position

In all other browsers than Netscape 4.x the positioning base on CSS and In all DOM/DHTML capable browsers properly supported properties and property values are position:absolute, top and left. In addition of these authors must define the stacking order with the z-index property, where higher value means higher position in the stack. The default visibility value for dynamic menus is in general for the main menu visibility:visible and for sub-menus visibility:hidden. These values will be altered with JavaScript.

If menus are intended to close through the content both for the base element and the actual content should be set the z-index property in order to get stacking order relative to the whole Web-page. If the base element of menus doesn't have the stacking order any following element in the content, which has the z-index property should set above the menu. Stacking order values for elements inside the base element of menus remain internal.

At this way positioned element don't affect anything to the positioning of other elements. For example the effect of position:absolute; top:50px; left:50px; width:600px; height:400px; visibility:hidden is in practise the same as if for the element has been set display:none. Hided and positioned links don't take any space of the other content of the document.

The system, which I have explained can be used in all situations, when elements can beforehand set exact positions. The most typical solution is a drop-down-menu, which I have handled in this Web-page. The advance of this solution is that opening of menus newer cause need of redraw the whole document or most of it. In my solutions only defined menus will be revealed in the positions, where they really are in the page! Even if menus will be generated "on fly" they will not affect anything to the positions of other elements in the page - only the speed and/or reliability is different compared to links, which already exist in the page.

Because I have from the same basic menu several versions I collected groups according to the horizontal or vertical positions of menus (the names of menus and values of properties are today different as in the example):

/* horizontal positions and x-index for second level sub-menus */
#Generic, #MainPages,... {left:128px; z-index:19;}
/* horizontal positions and the z-index for third level sub-menus */
#MainPages, #Appendixes, #Generic1,... {left:266px; z-index:20}
/* vertical positions for all menus */
#Pages, #PagesEn,... {top:42px}
#MainPages, #Generic1,... {top:59px}

I have used in my examles multi-level sub-menus. Instead of multi-level sub-menus it would be possible to use indented links for lower level pages - compare alternatives with two screen capture images[S].

Browser-specific notes:

  1. MS IE renders elements, which have visibility:visible as visible even if they are inside elements, which have visibility:hidden. This is the correct behavior. Opera hides always and new Mozilla Gecko (for example Netscape 6.1) browsers if position:fixed has been used hide incorrectly these kinds of elements (a test page[S]).

  2. In first dynamic menus previous mentioned properties didn't always worked in these Netscape 4.x browsers, which I have tested. That's why I have in all cases given in the example pages corresponding attributes for LAYER elements. The LAYER element doesn't have the position attribute but in the previous example <LAYER top="66" left="141"> means in theory the same as position:absolute; top:66px; left:141px in CSS (and for example z-index="3" means the same as z-index:3) - indeed Netscape positions elements a little bit differently as MS IE and Opera. Because LAYER elements are proprietary I use them only generated by scripts.

  3. I recommend to read my generic advice[S], when it is possible to avoid big problems.

In the most advanced browsers could be used also the position:fixed positioning type. This way positioned menus are accessible in all situations. Using position:fixed cause on remarkable limitation to the designing because the only reasonable system is that the main menu is vertical. Menu items are under each other. If a wide horizontal main menu is used all anchors cause problems because the menu hides the beginning of the content. The visitor should scroll page always a little bit upward when internal links have used - he would be soon as an angry wasp and he would swear very much!

If there might be a situation, that the menu could hide some content, it should be the possibility to hide the whole menu[Pw]. Of course there should be also a link to show the hided menu again. Below are some images, which could be used to hide and the main menu. They are on the left side of the screen capture of a dynamic menu, which use them.

Nature pages

Hiding and showing menus could also set as full or half-automatic. In the latter case onmousedown for the main content should close the whole menu. It would reveal then on the (left, right of both) sides of the page active areas, which have onmouseover to reveal the menu again.

Browser-specific notes:

  1. It can be defined with attribute selectors, when MS IE doesn't understand it but it would work in new Opera and Mozilla Gecko browsers:

    div.pageGroup, div#allPages {position:absolute} div[class="pageGroup"], div[id="allPages"] {position:fixed !important}/* Because attribute selectors have lower weight than id-selectors, in the the declaration must use the !important rule. */
  2. The system doesn't work ideal in Opera 5.x-6x (works properly starting from Opera 7.0 Beta 2) and not at all in MS IE 5.0 for Mac. It works ideal only in new Mozilla Gecko browsers (read about deficiencies closer from the page, where I handle the functionality of browsers[S] in my sites; I made also a test case[S] in order to demonstrate problems)

  3. Instead of fixed positioned elements is is possible to use with JavaScript-encoding implemented elements, which "float" with some delay to their positions. The functionality is worse than fixed positioned elements. I handle these kinds of elements in an extra page[S].
  4. Even if Netscape 6.0 doesn't support the position:fixed type I found that it works according to the position:absolute, when this solution didn't cause those problems with Netscape 6.0, which I expected.

  5. I have sometimes seen elements, which stayed in their positions. Because browsers moved elements upward/downward the functionality was not very good. I can't teach scripts, which implements (at least partially) fixed elements. Below is a Web-address to the menu Top Navigational Bar IV (ver. 3.3.19) by Andy Woolley. That menu works with certain setting stable in most browsers (including Opera 5.x-6.x) and it follows scrolling (with default preferences the menu in unstable in Opera 5.x-6.x and Opera 5.x has difficulties to download the JavaScript).

    Setting in the script menu_arrays.js for the menus for example ,,120,1,,style1,0,"left",effect,1,,1,,,,,,,,,, menus stay visible and they follow the scrolling until another sub-menu has been selected. In multi-level menus the behavior is in most browsers quite bad because sub-menus follow the parent menus with irritating delays. The functionality is much worse than position:fixed in Mozilla Gecko browsers. The most reasonable usage for this kinds of links is few link arrows, which go to the top of the page (a model page[S]) and previous/next page. Indeed with Opera 7.x also multilevel menus in the Milonic Web-site of Andy Woolley work quite well (much better than in MS IE 6.0 for Windows) and Opera 6.x (the menus doesn't however start working as soon as in Opera 7.x). That site use an updated version of the previous mentioned menu (the version, which I downloaded was 3.5.08 but today it is presumably newer). Opera 5.x can't always download the version 3.5.08 and if Opera can download it, ver. 3.5.08 doesn't fit for Opera 5.x. In order to solve this problem it necessary to write a script so that Opera 5.x gets the older version (look at the source code[S] of this page). In general the basic problem of these kinds of menus is that menus are available only if the JavaScript support is enabled. It would be a better solution to build the basic structure of menus by using server-side programming, when the menu would be at least at some level available also in situations, where the JavaScript support has been disabled. Try to create dynamic menus with PHP[S].

  6. The problem that menus might be over the content could in principle ease also by setting the transparency with the opacity property, which belongs to CSS3. With Netscape 6.2+/ Mozilla 0.9.4+/ at least as new other Mozilla Gecko browsers can use the -moz-opacity property, which is a temporary implementation of the opacity property.

  7. With Opera could test also other positioning types than top-left, but the functionality is in other browsers is weak. I don't recommend to use bottom-left, top-right and bottom-right positioning types. Individual links or small link sets can be positioned according to them but not dynamic menus.


Other alternatives

If menus will be defined in the same place and the same size, in principle they can be implemented instead of changing the values of the visibility property with the changes of the values of the z-index property. I don't however how wide this alternative works.

The weakness of both visibility and z-index based solutions is, that they don't fit for menus, where the position of elements can't set beforehand. An example of these kinds of menus is the Explorer of Windows, which I have a screen capture below.


Because the menu can be expanded in any situation, the vertical positioning can't be defined beforehand. Elements should be able to hide/ reveal by changing between display:none and display:block. If elements have display:none they behave as if they don't exist at all in the page. When they have display:block they clear space for themselves.

This solution has a great disadvantage if for the menus has not been reserved at all or for them has been reserved insufficiently space to expand. Opening of menus can cause continuous need to reformat the document. This slow down the performance of the browser and it might crash it. As I have written changes of the display property don't work in Opera 4.x-6.x browsers. If I have understood correctly, because of previous mentioned reasons Opera Software has been decided, that Opera 4.x-6.x browsers don't accept dynamic changes of the display property. In my mind changing of the display property in frame free Web-sites is overall a bad solution even if Opera 7.x+ and other modern browsers support them.

Menus, which resemble the Explorer fits in my mind only into frame documents, where the menu is in its own frame - also the Explorer works in this principle! The corresponding system can be achieved with Java applets, for example with products of Auscomp. The disadvantage of Java applets is that they are slow and many browsers don't support them as default. The JRE of Sun Microsystems is a big plug-ins application in order to download with modem connections! It is possible to create dynamic menus also as Flash-animations. In addition of products of Macromedia it is possible to create them also with other application. I have no experience creating dynamic menus with them.

Auscomp, Macromedia, Sun Microsystems.

Advantages and disadvantages of Flash- and applet menus:

Menus are relative easy to implement inside frames also by creating "on fly" with JavaScript of server-side encoding a total new menu page, when the visitor has been clicked a link of a sub-menu. These kinds of menus work also in Opera.



Concerning the presentation problems continues with the Netscape 4.x series because CSS works just partial in the dynamic menus, which I have used. Browsers have especially difficulties with linked CSS, because just a part of it works. Because direct CSS works better, I have used some style attributes (if necessary I have cancelled the effects by using the !important-rule in the CSS for other browsers). I must add some extra elements (for example B and IMG) in order to get the presentation better. Links seem to need the FONT element, because even the style attribute doesn't always work. For other browsers than Netscape 4.x I have defined the presentation primary through external CSS-files.

If Netscape 4.x series browsers should be supported, the HTML-code for dynamic menus must be in the beginning of the page because I found that Netscape 4.x crashed when the code was in the middle of the page inside a table!

In my mind it is reasonable to set id or class attribute for each individual link or the container element of each links. At this way is possible to get the same menu to look different in every page. Each page has a style sheet, which defines the style of the link, which refers to the current page. In one level dynamic or static menus the link to the current page can be hided with display:none or for it have been set special color and/or background-color/ background properties. The latter alternative can be used also in multilevel dynamic menus. For Example this page has the following CSS:

#Dy {background-color:#ffd700 !important; color:#303400 !important; cursor:default}

It cause the following result (in order to get good result as many browser as possible the definition should be given both to the link itself and the container table cell, if the link is inside a table; remember that the value of the id-attribute should be document wide unique):


Properties have !important in order to eliminate changes of link and dynamic pseudo-classes (a:visited ect). If links don't have any sub-menus they can have cursor:default. By marking the current page the visitor doesn't click so easily the link of the current page. He can also clearer know, where he is in the selected page group.

New Opera, MS IE and Mozilla Gecko (for example in Netscape 6.x) browsers don't need image links because setting for the link display:block a normal text link looks like an image as in the screen capture image below (in new Opera and Netscape the whole element works always as a link but in MS IE the whole element is in some cases active and some cases not; in the latter case display:block cause just the visual effect but only the the text works as the link; 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; it is also possible to get rid of this problems by the method, which I have intended primary for MS IE 4.x for Windows).


By using some pseudo-classes it is possible to get the same result as with JavaScript & event handlers, which change images or background colors of text links, when the mouse goes over/out of links or it does some other actions. In order to get the optimal result links need for example following properties:

.pageGroup a {display:block; width:100px; height:15px; line-height:15px; margin-top:0; margin-bottom:0; padding-top:0; padding-bottom:0 font-size:12px} /* Without the line-height property there might leave vertical space between links and text links don't behave exactly like image links. If links are inside table cells, also table cells need the line-height property in order to get good result also in Mozilla Gecko browsers (further is into this matter related code example). It is reasonable to set padding and margin properties should be set as zero in order to get links work equal in as many browsers as possible. The font size would be desirable to set so, that is possible to zoom it 120%. */
.pageGroup span.link {background:...; padding-left:11px;...} /* I have used in some versions around text links elements, which I gave background properties and the padding-left property. This element layer is not necessary. I recommend to set only background colors because background images don't work in all browsers. */
.pageGroup span.Link a:link {background:...; color:...}
.pageGroup span.Link a:visited {background:...; color:...}
.pageGroup span.Link a:hover {background:...; color:...}
.pageGroup span.Link a:active {background:...; color:...}
.pageGroup span.Link a:focus {background:...; color:...}

Because display:block doesn't work properly in Netscape 4.x and MS IE 4.x for Windows browsers, the solution doesn't look out smart in MS IE 4.x for Windows and Netscape browsers (look at a screen capture from the implementation of MS IE 4.x for Windows above on the right and compare it to the image on the left). It is however possible by using media blocks to define CSS so, that MS IE 4.x for Windows and Netscape 4.x don't get background properties for text links (I have advice in the extra page, which handles MS IE problems[S]; I use however background colors for text links, which gives sometimes a little bit bad looking result in these browsers).

Indeed for MS IE 4.x for Windows is possible to create the same result with event handler attributes for container elements of links. If all opening and closing commands have been executed by using the container elements of links, it would be possible to give the illusion, that links are active at their whole available widths, for example::

var nav_over = "this.style.background='#cee8ea';";
var nav_out = "this.style.background='#ffffff';";
<div onmouseover="MM_showHideLayers('Generic','','show',...); eval(nav_over);" onmouseout="eval(nav_out);"><a onmouseover="MM_showHideLayers('Generic','','show',...);" href="..."></div>

Adding corresponding functionality for Netscape 4.x browsers increase drastic the quantity of necessary encoding because it is necessary to add (9nce again) LAYER elements.

Text based links could work relative well in Netscape 4.x and MS IE 4.x for Windows browsers, if links itself would not have background properties and each link would be in an own table row so, that both on the left and on the right would be a table cell and widths of the cells, which has the text links would have been defined with spacer images. In the cells on the right and left would be opening/closing links of sub-menus. On the cells on the left would be list bullets. If necessary height values have been defined by using spacer images. I changed my menus using this style in order to demonstrate the system.

Indeed it still exists a problem, which concerns borders. If borders have been set with CSS Netscape 4.x leaves between the background color and the borders of the container block few pixel wide ugly transparent padding. In addition eldest Netscape 4.x series browsers crash easily, when CSS-borders have been used. Taking account all matters, the best solution to avoid this problem is to set the background color for the entire table and set "borders" by using table cells around the the content (cells can use rowspan and colspan attributes). I don't have created these additional cells to all menus, but only for the main menus.

Another way to avoid transparent paddings is to set background colors for LAYER elements and the descendant block has the borders. Below is a screen capture from a test menu. In the first level menu I have solved background color and border problems with additional table cells. In the second-level menu I have used a generated LAYER element.

A test page

The advance of the LAYER solution is that is is simple and also background images work so, that Netscape 4.x doesn't splitter them ugly way into individual table cells. But it has also disadvantages. From the screen capture can be seen, that the height of table rows are not the the same. Around the right hand table is a block, which has border and padding properties. In these kinds of situations the height of the tables vary even if they would have equal quantity of rows. The advance of additional cells is that vertical dimensions work more exact. In fact exact working paddings areas need around the content additional table cells at the same way as borders (the quantity of needed columns is then seven and additional table rows four).

In the example document[S] has been used have seven columns but in sub-menus simpler three columns structures. All menus and related link sets on the top-left are inside LAYER elements, which are generated by scripts. Below is the method how to create additional table cells and columns (because the natural dimensions of the spacer image is 1x1 pixel, it is not always necessary to set both height and width attributes):

<table summary="" cellspacing="0" cellpadding="0" border="0" bgcolor="white" width="126" >
<tr class="topCells">
<td id="cell1" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="1" /></td>
<td id="cell2" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="2" /></td>
<td id="cell3" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="11" /></td>
<td id="cell4" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="101" /></td>
<td id="cell5" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="8" /></td>
<td id="cell6" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="2" /></td>
<td id="cell7" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="1" /></td>

<tr class="paddingCells">
<td rowspan="5" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" width="1" /></td>
<td rowspan="5"><img src="spacer.gif" border="0" alt="" width="2" /></td>
<td colspan="3"><img src="spacer.gif" border="0" alt="" height="5" /></td>
<td rowspan="5"><img src="spacer.gif" border="0" alt="" width="2" /></td>
<td rowspan="5" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" width="1" /></td>

<tr class="contentCells">
<td><img src="menuButton.gif" border="0" alt="" height="10" width="10" /></td>
<td>The first row</td>
<td><img src="rightArrowr.gif" border="0" alt="" height="15" width="8" /></td>

<td><img src="menuButton.gif" border="0" alt="" height="10" width="10" /></td>
<td>The second row</td>
<td><img src="rightArrowr.gif" border="0" alt="" height="15" width="8" /></td>

<td><img src="menuButton.gif" border="0" alt="" height="10" width="10" /></td>
<td>The third row</td>
<td><img src="rightArrowr.gif" border="0" alt="" height="15" width="8" /></td>

<tr class="paddingCells">
<td colspan="3"><img src="spacer.gif" border="0" alt="" height="5" /></td>

<tr class="bottomCells">
<td bgcolor="#303400" colspan="7">
<img src="spacer.gif" border="0" alt="" height="1" /></td>

I found that the main menu worked in my primary test browser (Opera) a little bit slower than before. At least Opera suffers the more complex structure, which gives better presentation for Netscape 4.x browsers. That's why I don't recommend to create more complex structures, which I have used. In in the basic structure has been used nested tables I counted that Netscape 4.x needs over 50% percentage more code than modern browsers in order to get reasonable good result. Compared to the minimum HTML-encoding it might be necessary to add because of Netscape 4.x over double quantity of HTML-code! Because of this reason it is quite questionable to support Netscape 4.x series browsers.

#Pages table, #PagesEn table {width:136px; table-layout:fixed} /* When the fixed table layout algorithm has been used the widths of individual cells must exactly match with the width of the whole table. */
#cell1,#cell2, #cell3,... {height:1px; line-height:1px; font-size:1px}
#cell1 img, #cell2 img, #cell3 img,... {height:1px}
#cell1 img, #cell7 img, td#cell1, td#cell7 {width:1px}
#cell4 img, td#cell4 {width:105px}
.paddingCells td {line-height:5px; font-size:5px; height:5px}
div.pageGroup td {height:15px; line-height:15px; padding:0}
/* Cells, which have actual links. Without this definition table rows are don't have the same heights as new MS IE and Opera browsers. This solution doesn't work properly in MS IE 4.x for Windows because only a part of cell have correct line height values. */

Old-fashioned HTML 3.2 style structure solutions cause additional work and they are difficult to get work exactly correct in new Mozilla Gecko based browsers. For new browsers it would be more reasonable to take off additional rows and (if rowspan attributes have been used) at the same time also all additional columns by using display:none for the additional table rows (to the tables of the main menus remain then three columns). In order to do that additional table rows must have id or class attributes (for example tr.topCells, tr.paddingCells, tr.bottomCells {display:none}). In this case it is possible to define real padding and border properties for the container element of the main menu. At this way Netscape 4.x works according to HTML 3.2 guidance and newer browser guided by CSS. I have however noticed, that setting the line-height property doesn't always help getting the correct result in Mozilla Gecko browsers (a test page[S]).

The previous mentioned solution doesn't work properly either in MS IE 4.x for Windows because it doesn't support display:none for table rows. If additional rows and columns for Netscape 4.x have been generated with scripts documents don't conform with (X)HTML specifications. I don't fine any fully satisfactory solution for MS IE 4.x for Windows when text links have been used. If menus will be created on fly with JavaScript (like DHTML Menu Builder does), they can be different for Netscape 4.x and other browsers. But generating menus with scripts is also problematic.

The smartest and the best working result for MS IE 4.x for Windows and Netscape 4.x browsers can be achieved only if all links are images. I don't change all links as image links because they cause so much additional work. If some favors image links it is not in my mind reasonable to encode menus by hands, even if the site of the TechsOfTheWeb.Com teaches, how to use images in dynamic menus. Because MS IE 4.x for Windows and Netscape 4.x series browsers are not anymore very common and they are quite buggy, I don't regard personally as reasonable giving full possible support for them. When menus are intended to encode by using code editors I recommend to use text links with necessary spacer images. In my mind the only reasonable alternative for this is to create menus with commercial applications like Macromedia Dreamweaver and DHTML Menu Builder. Indeed dynamic menus, which have been created with these applications have presumably stability problems at least in some browsers.

Presentation of menus can get better to set true or illusory transparent menus and shadows.

Browser-specific notes:

  1. For Netscape 6.2+/ Mozilla 0.9.4+/ at least as new other Mozilla Gecko browsers can set well-working real transparent sharp-edged menus and shadows by using the -moz-opacity property.

  2. For Opera 6.x+ browsers can set well-working half-transparent sharp-edged menus and shadows by using PNG-background images (MS IE doesn't support transparency in PNG-images). (A model image[S].)

  3. For MS IE 5.5+ for Windows transparent menus and soft-edged shadows can be made by using the proprietary filter property, but it is worth to note that for MS IE 5.5 can set only one effect for one element (a link to CSS-notes[S]). For example soft shadows has the following CSS: filter:progid:DXImageTransform.Microsoft.Shadow(color='#777777', Direction=135, Strength=5);. From the collection of Dynamic Drive can be found a ZIP-file, which can be found a model of a dynamic menu, which use the filter property (Top Navigational Bar IV). Indeed the menu has problems with Opera, which I have mentioned in the previous section[S].

  4. For other browser than new MS IE and Mozilla Gecko can be set transparent GIF-images. Certain pattern can create rough transparency.

Dynamic Drive: Top Navigational Bar IV; Macromedia; TecsOfTheWeb.Com: Using and Manipulating Dropdown Windows; xFX JumpStart: DHTML Menu Builder.

I explain some matters also in the browsing advice[S] - most pages has a short cut to this help (the question mark Apua).


J What are user style sheets



They work relative well at least in MS IE 5.x+ and Opera 4.x+. How they are used and what is the effect of the user style sheets to the presentation of documents is browser dependent.

Why user style sheets?

They have at least following productive usages:

Note. If you define the screen media (@media screen), remember to define also the media type for the full screen mode[S]. Use for it its own media type (@media projection) or define it together with the normal screen media (@media screen, projection).

Try my userCss.css file for example going to the CSS2 specification site with my CSS (the link opens a new window).
Note. This CSS-file removes the meaning of all FONT elements and all text and background colors, which the author has defined! This is necessary in order to avoid situations, where text colors and background colors are the same or very close to each others. This file is optimized to Opera 5.x+ because the meaning of this css is the control the width of the textual content.

In those browsers, which I have tested, the CSS can control the width of the page only in Opera 4.x+ and Netscape 6.x+. Indeed the CSS-file doesn't force wide tables to fit to the maximum width, which I have set (body {max-width:600px}). It is not reasonable to force the width of tables to certain maximum value, because the content of tables might overlap each others and the content is unreadable.

Usage and deficiencies

In MS IE 4.01 and Opera 3.x they don't work well. The most irritating is that the font-family property doesn't work properly.

The change of preferences

In all browser, which allow to define user style sheets, it is in the first time define the path of the CSS-file (you need to do this however only once, if you don't want to change the file).

In MS IE the usage is a little bit troublesome, because the user must browse through multi-level submenus: Tools > Internet options > Acessibility.

The defining of basic preferences is also in Opera a little bit troublesome: File > Preferences > Documents (indeed the change is easier, if you use both the keyboard and mouse: ALT + P > Documents - next time this dialog is ready open and the resetting of original settings is fast). You get finally a dialog, where you must define with check boxes, how to use document and user style sheets.

Next times in Opera to change between user and author style sheets is extremely easy, because in the address bar is a button to change between document and user mode. In Opera 7.x the button has extra menu, where the user can select predefined style sheets, which can be used at the same time. Some of them are for Web-authors (many people think that they don't belong to basic browsers and for Web-authors should be an own browser) and ordinary users.

Note 1. If the the style sheet control is changed by the option Document mode as default, the user must push Apply, if he wants that the effect works immediately - otherwise the change takes the effect, when the user opens a page into a new window.

Note 2. According to an e-mail, also to MS IE can add a button by using a development kit to take off/ put on user style sheets. Today it is also possible to customize Opera.

Opera Software: Opera Composer lets users customize their Web browser; Microsoft: Internet Explorer Administration Kit.

I don't find from the user interface of any Mozilla Gecko browser any option to set a user style sheet file. In the site of Mozilla org. has been explained how to set some files into a sub-directory of the /Chrome folder.

Mozilla org.: Customizing Mozilla.

The name of the files and the folder, where they are are exact defined. They can't be freely named and set into any folder like in MS IE and Opera browsers. I hope, that also Mozilla Gecko browsers could have as easy way to set a user style sheet file as Opera - this might be too much to ask because Mozilla Gecko browsers has so different user interface.

Because of the different user interface the best solution in Mozilla Gecko browsers would be the option User style sheets under the menu View so that the user could choose between different style sheets. The browser should give easy way to set multiple user style sheets. The possibility to set user style sheets should be found by using the path Preferences > Appearance.

Indeed Mozilla Gecko browsers give the possibility to change style sheets (View > Use Stylesheet), which MS IE and Opera 3.x-6.x don't allow (Opera 7.x+ supports alternative style sheets). According to W3C user agents should support both user and alternate style sheets. The functionality of them needs using the title attribute (for example <LINK rel="alternate stylesheet" title="Alternate SS">; I handle this matter also in the page 2[S]).

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

Unsupported features

Even if user style sheets work quite well in Opera 4.x+, they don't work however as well as author's style sheets. Following matters don't work in Opera 4.x+:

In MS IE 5.5 list-style-image and background-image properties work, but the @media and @page at-rules crashes it (MS IE 6.0 doesn't crash using of them). Printing can't be controlled with the user CSS in MS IE 5.5. In MS IE can't take off the document CSS (like in Opera) in order to use only the user CSS.

Because the user style sheets is a intended to be a single style sheet, the import rule (@import) doesn't work. This might be also a bug.


The so-called important rule (!important look at the page What is the processing order of CSS[S]) has not in practise much meaning. In MS IE it is possible to control with the browser preferences (roughly) fonts and colors, but other properties might need it (for example ul li {list-style-image: url(ball.gif) !important;} sets more weight to the user defined list style images as the author's defined list style images). MS IE seems to follow CSS2 and user's important rules have more weight than author's defined important rules.

At least until the version 5.01 Opera browsers seem to follow CSS1, when author's style sheets has more weight than user's style sheets (this is not however so important, because in Opera it is possible just take off all document CSS). In my tests Opera 5.12 gives higher priority to the import rule of the users style sheets and Opera 6.01 to the document CSS. Only the Opera 5.1x series seems to work in this matter according to the CSS2.


K How to use CSS with XML documents



Related to HTML XML is an independent language. They have however as their "parent" language SGML. XML is also a metalanguage, which gives some basic rules, how XML-based languages should build. It has more exact syntax than HTML.

Unlike HTML, XML doesn't have any formatting code as such. XML is a pure markup language, where all start-tags, end-tags and empty elements tags are as such only markup codes. The formatting and presentation of XML-documents must be define with assistant languages (for example with CSS and HTML).

In this case I handle only how to give presentation to XML-documents with CSS. Elements are not defined with any other language. It is possible to create to XML-documents DTD-file or XSD (XML Schema Document) file, which describes the correct usage of elements and attributes. To use DTD-files or XSD-files is not necessary. Common to all XML-based languages is the usage of declarations at the beginning of the document (I explain them in the (X)HTML notes[S]), for example:

<?xml version="1.0"?>
<?xml-stylesheet href="XML.css" type="text/css"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml">

Into CSS2 has been added certain features especially for XML + CSS implementations. To be a proper XML user agent, the UA should follow principles:

  1. Supporting standard syntax and XML-principles.
  2. Because XML doesn't have common attributes like HTML, it is important to support generic attribute What are selectors, classes and id-attributes[S][Pw].
  3. Enough wide implementation of the display property[S][Pw] in order to create simple tables and list presentations.

Note 1. Concerning the first principle MS IE 5.0 can't regard a XML + CSS browser, because it supports some obsolete working draft based <?xml:stylesheet ...?> proposed syntax to xml-stylesheet declarations. The existing standard syntax is <?xml-stylesheet ...?>, which is supported in MS IE 5.5. At this respect, MS IE 5.5 is the first Windows IE, which can be regarded as an XML-browser.

Note 1. MS IE like Opera 4.x+ support however CSS-rules, which are intended only to HTML-documents (look at the page What are selectors, classes and id-attributes from the place Attribute What are selectors, classes and id-attributes[S]).

Note 3. Concerning the second and third principle, only Opera 4.x+ and Netscape 6.x are browsers, which can be regard as proper XML + CSS browsers. MS IE 5.5 is not a proper XML + CSS browser, because it doesn't support necessary CSS2-features.

The example document, which I handle in this page is not fully functional web-document. CSS is a pure formatting language and XML is a pure markup language. The result is an XML-document without functional linking system. XML is not alone a hyper text markup language. A fully functional XML-document needs some kind of linking system, which can be done with different ways (I don't handle in this page linking possibilities)). Example documents in this pages resembles an ordinary word processor document.

Usage of CSS

I take an example document, which use the same element type names as HTML-documents. I give to that document only a CSS-file (<?xml-stylesheet href="xml-sheet.css" type="text/css" ?>).

If that file is not given, MS IE 5.x shows only the source code, but the browser indents the code ([M][S][Pw]). If the linked CSS-file is not found or it doesn't include any information, the text is after each others, for example (I have given an example page, which refers to an an-existing CSS-file):

<?xml version="1.0"?>
<?xml-stylesheet href="xml-sheet2.css" type="text/css" ?>
<meta name="robots" content="noindex">
meta1- elementti META -</meta>
<style type="text/css>
Uutta tyyliä - elementti STYLE -</style>
Problems in the new technology - elementti TITLE -</title>
<h2><a name="Uutta">
Structural solutions</b></p>

the browser shows the code at this way ([M][S][Pw]):
meta1- elementti META - Uutta tyyliä - elementti STYLE- Problems in the new technology - elementti TITLE - Problems Structural solutions ...
Elements are separated only with a space and the beginning and end can't know

When style sheets are used almost all element must be defined at some way. Only such empty elements, which don't have after them any text are not necessary to define. In this situation is necessary to remember, that elements head and body have no basic level difference without a DTD-file. Because it doesn't have standard elements, you can freely change the behavior of elements, which are inside the head element between normal and empty elements. You can also write between <head></head> text and it is not an error. It is only important, that the document has one root element and the encoding is well-formed.

This expands and limits the usage of style sheets. You can show the content of the element title. It is not really TITLE only to browsers, which don't understand XML-documents and which interpret XML as HTML. But in XML-browsers is doesn't fulfil any task in the example documents, because the meaning of this element has not defined. But you can't hide with display:none ordinary used meta elements, if you have put text after it, for example ([M][S][Pw]):

<meta name="robots" content="noindex" />meta1- elementti META -

In this case the element has a task, but it doesn't come from the element itself but from the search robots, which identifies the element! But if I give it as tasks, which concerns for example MS IE 5.0, the UA would not fulfil it. If the following code would be in a HTML-document, the UA would go to another page. In the example XML-file this doesn't happen. The attributes of the element would be the same if the browsers would get attribute="0".

<meta http-equiv="refresh" content="0; url=../Teaching/XSL.php3" />

This concerns also the HTML-elements HR and BR, if they are used in XML-documents. If you put to the element meta both start- and end-tags, you can use it as a formatting code even if you can't do so with HTML-elements. Without any content they can be used limited as formatting codes (display:block creates a line break). To Opera 4.x+ and Netscape 6.x you can define meta:before and meta:after, when you can use them wider as formatting codes. To use empty elements as formatting codes is however limited compared to element, which have both start- and end tags.

Following is an example of a CSS-file, which has a head element and the content of that element is also defined. Only the element meta is hided ([M][S][Pw]):

head {font-family:Verdana, sans-serif; display:block; background-color:aqua}
meta {display:none}
style {display:block; background-color:yellow}
title {display:block; background-color:yellow; border: 1px solid #660033}
body {font-family:Verdana, sans-serif; display:block}
h2 {font-size:21px; display:block; text-align:center;}
p {display:block; margin-top:1em;}

Now the browser formats the document! Note, that is always necessary to define margins to the element p - in other situation elements are tightly after each others. After this definition the page begins to resemble HTML-documents! The start- and end-tags of CSS-defined elements can work as formatting codes. In fact the example document has more elements, which I have defined, but undefined elements don't affect anything to the final presentation (the presentation of the element b has not defined).

Because XML is not a formatting language, XML-elements are not as such block level or in-line elements - the existence of them must be defined with assistance language or DTD-files. From the sight of XML it is not incorrect to set an element, which is defined with CSS as block level element inside an inline element. When the presentation is defined with CSS, the author of the site must take the response to set elements correctly. It is not possible to test the nesting of elements with a validator, if DTD-files are not used. Incorrect setting of elements might cause, that the page is rendered badly.

An another element. I take as an example a file, which have the following code:


MS IE 5.0 selain joko näyttää tuon juuri tuon tapaisena, jos dokumentin elementeiltä puuttuu kuvaus. Yksikään noista koodeista ei toimi ilman kuvausta muotoilukoodina. XML:ssä tuo koodisarja on vain sarja tietyn nimisiä elementtejä ja on aivan sama vaikka niiden tilalla lukisi näin:


In principle it is possible to define with CSS, that the element table-mainElement is formatted like the HTML-element TABLE etc. Indeed the formatting works only with Opera 4.x+ and Netscape 6.x+ browsers. MS IE 5.x can't format with CSS a table. It can't either format with CSS list items (look at possible values to the property display from the page How to put CSS into Web pages[S][Pw]).

If in XML-documents is necessary to use tables or list presentations, the formatting of documents must made with XSL. In practise final documents must be XHTML-documents, which might have additional elements from other XML-based languages.

Linking and other XML features

Netscape 6.0 supports linking with XLink, when it is possible to get proper linking. Opera uses proprietary CSS-features, when concerning linking it is not a proper XML-browser.

To MS IE can get working linking by ruin the xmlns attribute. MS IE 5.5 supports DTD-files and at this respect is it a real XML-browser. Opera and Mozilla 0.7 don't react errors in DTD-files, which means that they don't read them. IE 5.5 supports also schemas, when taking account all features, it can regard as the most advanced XML-browser.

None of existing browsers has a proper XML-implementation, because it needs at least:

  1. Opera 4.x+ level display-implementation and supporting of generic attribute selectors.
  2. DTD and/or schema support like in MS IE 5.5.
  3. XLink-implementation of Mozilla.

Note 1. XSL-implementation is not necessary, because it is reasonable to use XSL only in server-side applications. If XSL is supported in browsers, it is just easier to test it. CSS in much more important in User Agents.

Note 2. Some of the features are still under construction and they can be changed. Then browsers might support them proprietary way, if we think this matter at the sight of official recommendations. At this moment it is impossible to exist a fully XML-capable browser. In fact browsers are Working Draft -level in XML.

W3C: XML Linking Language (XLink), XSL Transformations Version 1.0 (XSLT), Schema Modules.
Other pages: CSS notes 2[S].
Other sites: Opera Software: Web specifications supported in Opera 5 - the details; Microsoft, XML Schema Refere.


L What is the situation of XML and XSL today



The situation concerning XSL is going better. I is divided into two parts. It has a transformation language and an actual style language.

If we think the essence of XSLT (eXtensibe Style Sheet Language Transformation), it is not at all a style sheet language. It is rather a generic transformation language (XTL = eXtensible Transformation Language), which can generate or transform style-related elements and attributes.

It can be used also to elements and attributes, which don't have anything to do with styles. Transformations can in most cases made with other languages, which are used in server applications. As a transformation language XSLT is clear. If it is used in browsers, it makes a browser some kind of server application. In my mind XSLT belong only to server-side applications.

XSLT doesn't define any style-related element behaviors. By using XSLT actual styles are defined with elements, attributes and possible CSS of the final document.

In XSL the real style language is XSL-fo (fo = formatting objects). Unlike in CSS in the final document, the content, structure and presentation are not separated from each others. At that mean it is coming back to the HTML 3.2 resemble way to create styles.

If XSL-fo documents are created directly by hands, it means extremely heavy encoding. The purpose is not however to use it alone but together with XSLT in various XML-transformations: XML > XLST > XSL-fo > PDF/RTF/TEX/DVI or some other document type, which needs inline styles. XSL-fo doesn't fit a style sheet language for XHTML documents.

Even if XSL-fo can be used as a part of different transformations, in my mind transformations could be done with another way. Read my comments from the page Cascading Style Sheets with Transformation[S].

W3C has made recommendations to XSLT and XPath in 1999. There is not however applications, which support them totally - some promising applications is however in the market. Parts of XSL is still open.

W3C recommend to use CSS always when it is possible and XSL, when it must be used. CSS is designed also to WAP devices, but they don't yet support it. XSL could be sensible in situations, when the same document should be use in normal computers and WAP devices. Servers should deliver different versions to normal computers and WAP-devices. But because of deficiency in applications and unfinished specification also this matter is quite questionable.

MS IE 5.x

Even is XSLT should be used only in server-side, if it is used in browser, it should be done according to the specification. The XSL-implementation of MS IE 5.0 base on an out-of-date proposal from the year 1998 XSL-proposal, which worst deficiencies are:

It is quite questionable to do any XLS files for MS IE 5.0, because it support an-standard XSL. XML-support has been brought too unfinished into the market.

When I tested pages, which were made with InDelv, MS IE showed only white background-color. It seems to be a common habit with Microsoft to bring new features very unfinished before existing systems work properly.

When Microsoft brings new features into so-called "official" versions, this cause much problems. Big and heavy applications are not so easy to update. It is not any sense to use one year old specification proposals. This kind of design politics ruins the functionality and credibility of new systems. Experimental level systems like XSL needs also experimental level application, which are regularly updated. It is not any sense to use out of date specification proposals. Read about my groans[S].

MS IE 5.5+ should support existing specifications. Proprietary and standard needs however a conversion utility.

Microsoft: Microsoft XML Parser, MSXML XSLT FAQ.


I downloaded a Canadian InDelv XML-application, which have both a browser and editor. It support latest 1999 proposals, which are quite final. The application has good help files. Those instructions can be found however also from the specification proposals of W3C.

Almost fully implementation of XLink and XPointer. Support formatting objects (fo)

Warning. If you have already installed Java virtual machine, remove the sub-folder /jre from the InDelv folders. Two Java-machines cause the application to crash.

The browser doesn't display properly HTML-documents. It does have following differences or problems to the relation of MS IE 5.0:

  1. Namespace information is oriented towards specifications:
    <xsl:stylesheet xmlns:xsl='http://www.w3.org/XSL/Transform/1.0' xmlns:fo='http://www.w3.org/XSL/Format/1.0' result-ns='fo'>
    MS refer to old working drafts:
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns:fo='http://www.w3.org/XSL/Format/1.0' result-ns='fo'>
  2. Text() doesn't work at the same way in InDelv. InDelv doesn't need it. The problem is presumably in MS IE.
  3. MS doesn't work if some fo-object are used even if it doesn't understand them (like fo-objects to the element P). The problem is in MS IE.
  4. InDelv doesn't have proper XSLT-implementation. For example P doesn't work using XSLT:
    <xsl:template match="p">
    <p style="display:block; margin:10pt; width:100%"<
    <xsl:apply-templates />
  5. Fo-XSL doesn't have all necessary properties (some values in XSL proposal are for some reason written differently in fo-XSL than in CSS2 - I can't understand why? This is confusing).


HTML-kit is a freeware code editor, which can build own menus. XSL(T) markup menu. This menu base on an obsolete W3C XSLT proposal from 1998 (the official recommendation is from November 1999). The menu is intended to use only with MS IE 5.0, because it includes much proprietary extensions to the old proposal (those don't work in other browsers). I don't recommend to install it. I try to create a better menu.The half-made menu is available in a zip-file. In order to edit it, it is necessary to install Plugins Generator, which is available in the HTML-Kit pages. Could someone check my menu? I'm working with XPointer extensions to it. I might make also XSL formatting objects menu.

I have done to it a CSS-menu (TM CSS), which can be used in creating XSLT files with CSS support. You can get it as a zip-file from the sites of HTML-Kit (also the source code is available from the pages of it) or from my site zip-file (you must read first README_NOW.txt).

HTML-kit Home Page, HTML-Kit Plugins page.

Other applications

There is also other application and some comments:


Test pages

I made one page several different versions, which should look out quite the same:

W3C: XML Path Language (XPath) Version 1.0, Extensible Stylesheet Language (XSL) Version 1.0, XSL Transformations (XSLT) Version 1.0.
Other sites: Netscape, Opera Software.

Send me comments with e-mail (add to beginning of the e-mailaddress my name, Tapio Markula, separated with a comma).


M What kind of problems WAP has



The functionality of page in WAP-devices (Wireless Access Protocol) with CSS has two alternative. The first is a browser, which has a proper CSS-implementation. The second alternative is, that the WAP server can understand CSS. The WAP server could read firsst this part of the page:

<LINK rel="stylesheet" media="handheld" href="handheld.css">
<LINK rel="stylesheet" media="print" href="print.css">
<LINK rel="stylesheet" media="screen" href="screen.css">

Those kinds of files include declarations, how pages should be handled in mobile phones, palm pilots and other small devices or on printing and computer screens. The WAP server could keep the file in its memory in order to printing it. The media="print" could control the printing process.

I have heard that the WAP-server take off big image. But the process is out of the control of the author. If the server could understand CSS, the author and the server could both control the layout of the page. Same pages could be made both to WAP-devices and computer screens so that the author could always know how they work in different devices.

The identification of media type is the base of the whole system. Because CSS2 pays regard to WAP-devices, it could be extremely desirable that devices and WAP-servers could exploit CSS2-technology.

Media types

The media type handheld is problematic, becuse the ability to handle graphics is very limited in mobile phone (look at table from the page a table[Pw] from the page and a short explanation after it).

The media type tty can't be used, because it is text-only. Shoud there be a special media type mobile_phones? Then the type handheld concerns only palm pilot and other small handheld computers.

Link images

A link systems, which base on images are problematic. Pictures should not be primary linking elements. Pictures should be pictures and links should be text links! Especially problematic are so-called imagemaps. Imagemap-systems could be used with following way or they could be replaced with a CSS-based system:

In that way it is in fact easier to create much more flexible linking system as by using image maps. Indeed links are always rectangular. Users of old browsers might not see all image at all. It is not possible to define alternative background by using HTML 3.2 level background attributes for all elements. This is not however a basic level problem, because most browsers support CSS.

If same pages are used in handheld devices and large computer screens, in my mind imagemap systems should not be used at all. Instead of them I recommend to use alternative solutions. Image links should have alternative text links. They could be hided in the version (media="screen"), which is intended for ordinary computers. Browsers, which don't understand CSS view them. That's why also alternative text links should look out relative nice.


For many people the most inconvenient feature might be, that most of scripts are harmful. The optimal situation is, that they are not used at all. They can't be used in mobile phones. Scripts can be used so, that they could have different versions to different devices. I have however made a proposal[Pw] to implement the media rule also into scripts.

Many scripts are useful but some of them are totally unnecessary. It is easy to give up from scripts, which exchange images. I had once in navigation frames about 150 links. They used following kind of CSS:

:link {...}
:visited {...}
.some_class a:hover {...}
.some_class a:active {...}
.some_class a:focus {...}
.some_class a:hover img {...}
.some_class a:active img {...}
.some_class a:focus img {...}

..., .some_border a:hover, ... {display:block;margin-right:1px;text-decoration: none}

If I had replaced navigation elements related images using four script event related image, I would need 600 images. It is common habit to use only two events (OnMouseOver / onMouseOut). Then the minimum quantity of images is about 300. The maximum replacing quantity was about 750 images (five different event handlers). These images might have taken about one megabyte (1 MB) hard disk space. CSS needed only few kilobytes (Kb). Compared to the large quantity of images almost nothing.

And If I would like to make exchanges. I write some minor exchange to the CSS-code. It is extremely easy to exchange the appearance on unlimited quantity of links in a minute. To make 300-750 images could take a lof of time. "Into the bargain" the advance is, that CSS doesn't cause any harm into the accessibility in small devices.

CSS save enormous quantity of graphic work! It is possible to create cheap pages both to computers and handheld devices. The graphic artists could create few backgrounds to links and elements, which works as parent elements of links. They could also create background to the whole page and make some basic images. There could be however much less work as in HTML 3.2 page designing.

This needs however exchanges in attitudes. People, who would use old browsers could suffer in the appearance of pages. But all could win in the speed. All could have less images and less an-reliable working scripts. If the appearance is not satisfactory, it is always possible to get free a new better working browser from the Internet.

The replacing CSS2-system works today only in MS IE and Mozilla Gecko browsers. In Opera browsers, which are older than Opera 7.0 Beta 2, background images don't work with dynamic pseudo-classes.


N What CSS-implementation errors are in browsers



Browsers make errors and they have missing features. In spite of the fact that MS IE 4.x-5.5 for Windows tolerate quite much errors it is necessary that authors try to avoid errors. This is important because some CSS-supporting browsers don't tolerate errors at all or very little. It is sensible to validate CSS using the CSS validator of W3C.

Even if all new browser don't accept much errors also browsers, which should behave with certain DTD in the standard(-compliant) strict according to the existing specifications, accepts some invalid/ unknown CSS for the browsers (if they don't work in the standard(-compliant) mode they accept more illegal CSS). They have so-called "[S]DTD-switch"[Pw]. I have found following errors accepting total invalid or unknow properties:

Opera 7.x browsers have much more limited DTD-switch and elder Opera browsers don't have it at all. That's why Opera browsers must make some compromises, because Web-authors have bad habit to favor invalid CSS especially in JavaScript encodings. Opera accepts at least following errors (I mention also if Opera Software could in my mind change the behavior):

Style sheets and rules should organize very systematic. I have met problems, because my pages are not originally designed to use them. The organization is only satisfactory, but not good. This situation cause following problems:

A hint. Create an index.css, when you can validate all your style sheet using a single file! Look at the source code of my test css-file as a text file[S][Pw].

Look at also my page Illegal definitions and hints to avoid problems[S][Pw].

You can get more exact information about errors in browsers from the pages of Webstandards. They give top ten list of CSS-errors and I give some estimation here. You can also read from Webreview documentation about CSS1-implementations in various browsers.

Webstandards, webreview.com.

Microsoft Internet Explorer

I judge the MS IE 5.x series according to the CSS2. Overall MS IE 5.x has only average level CSS-implementation and it has been a disappointment for me. Only part of the CSS1 level errors in MS IE 4.x are fixed. It does have also missing of important features in CSS2. The CSS implementation is overall only partial.

The biggest problem is that Windows-browsers have basic level CSS-implementation errors (read the page How to set CSS for backgrounds and borders[S]).

Microsoft has however made remarkable improvements into the 6.0 series (also MS IE 5.0 for Mac is a good browser. Concerning supported features the browsers works with certain DTD quite strict following existing specifications. Detailed analyse about errors and fixes are in a separate page.

Netscape Navigator

Netscape 4.0x is terrible bad - just terrible! It is so bad, that I don't have time to describe of all errors, which it makes (read from an extra page some hints, how you can survive with Netscape 4.x[S][Pw]). Netscape 6.x+ has quite fine CSS-implementation! It use Mozilla Gecko rendering engine. Many other browsers use the same rendering engine (for example Mozilla, Galeon and Phoenix). Mozilla Gecko browsers have almost flawless CSS1 level support and quite wide CSS2-implementation. Because Mozilla Gecko browser (like new Opera browsers) applies dynamic pseudo-classes wider than many other browsers, this matter might cause problems for web authors (read CSS notes 1[S]).


Opera 5.02 has quite functional CSS-implementation and it support all CSS1-features (Opera 4.02 doesn't support :visited). Opera 5.x doesn't have any serious CSS-implementation errors.

Newer versions implement more features, which belong to CSS2, but the strictness to follow the specification has some minor bugs. In some respects older browsers follow specifications better than newer. Following the specification is however overall quite good.

Some demonstrations or errors or missing features

The following list is CSS 2 level pattern matching test. I have explained with text and images, what the browser should show. (I have explained patterns in the page What is the processing order of CSS[S][Pw]). This a test for all types of selectors and it explains also at some level the cascading order. Among those browsers, which I have tested, only browsers which can survive this test without any error are Mozilla Gecko and Opera 7.x browsers (it is possible that also Safari and Konqueror browsers might survive from this test as well).

In this paragraph is some inline areas using SPAN. Around these bold words should be 1px #660033 border. If you can't see it, the browser doesn't support properly CSS-properties to inline elements. If you try to make the border visible to IE 4.01/5.0 giving a height-value, which belongs to block-level elements, the result is incorrect. IE don't keep this bordered text at the same vertical level as the other text. It only exchange the area almost as normal behaving block-element. IE tries to keep it in the same line and if it must make a line break, it creates a block box around the text. It doesn't allow other text in the same row. The behavior is something between common inline and block elements. Sometimes it is closer to DIV and sometimes SPAN - always incorrect. According to an e-mail MS IE handles inline elements some kind of special blocks, which explains the error behavior. MS tries to fix this matter in the MS IE 6.0 series.

W3C: CSS validator[Pw].
Other sites: Webstandards[Pw]; Webreview[Pw]: CSS1 Master Compatibility Chart, CSS2 Selectors Support Chart; Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.


0 What CSS-implementation errors are in MS IE browsers



A very useful application in order to look at supported features of MS IE is Bradsoft's TopStyle (Lite-version is free), which lists all implemented CSS properties and values in MS IE. Indeed any of versions, which I have tested doesn't mention at-rules (for example @font-face). The application gives much tips concerning implementations.

Bradsoft: TopStyle.

I don't handle MS IE browsers, which are older than MS IE 4.x for Windows because I can't install very old version of it. With Windows 98 becomes a MS IE 4.x series browser (the exact version number is 4.76). There are some people, who never update their browsers under the same platform and that's why authors must at some level take account old browsers.


MS IE 4.x for Windows

MS IE 4.x renders basic CSS relative well, but I has most of the bugs of MS IE 5.5 for Windows, which I handle later. The browsers have however following special features, which are worth to mention:

  1. The browsers doesn't support the @media at-rule but the media attribute is supported.
  2. It has very bad implementation of clear and float:
    • The browser implements float in many cases so, that it puts floated elements into an own row even if this is not necessary. This cause additional line breaks.
    • If the same row has much floated elements after each others, it can't divide them into several rows.
    • clear cause lonely floated elements even if the browser could in principle set elements to the same row. This cause additional line breaks.
    • Floated elements might increase the height of the parent element.
  3. Accepting of incorrect names of id and class selectors differs from newer versions (look at a model[S]).
  4. Missing supporting of pseudo-elements :first-letter and :first-line (concerns also MS IE 5.0 for Windows).
  5. The width property with margin works much worse than in newer versions.
  6. display:block is not supported other way as opposite for display:none. Natural inline level elements, which have been defined as block behave always like inline level elements.

Because MS IE 5.0 for Mac doesn't support @media at-rut but pass all CSS, which is inside media blocks, adding to a style sheet an unknow media type can create a section, which is read only by MS IE 4.x, for example (a test element):

@media MSIE401 {#testMSIE401 {color:red !important; text-decoration:none !important}}/* This unknow media type is primary for MS IE 4.x for Windows. Note, that Opera 4.x+ supports the media type projection and don't use that media type in this purpose. If the style sheet use the for example the media type screen adding a block, which has the media type tty, can bet get the same result. */

MS IE 5.5 for Windows

Bugs and missing features

I have found following following positive matters in MS IE 5.5:

MS IE has serious CSS1 implementation errors. Rendering borders for BODY and HTML is incorrect. Calculation dimensions of block boxes is seriously incorrect. I handle these bugs in the page How to set CSS for backgrounds and borders[S]).

Also float and clear properties work incorrectly (concerns also MS IE 6.0 Windows; MS IE 4.x for Windows has more and different errors). If the property clear is used, MS IE might move later in the content existing floated elements above earlier floated elements. With values left and right the property float should move the element as high as possible (however so, that the later floated elements don't go above the previous floated elements), but MS IE moves elements often a little bit downward. MS IE might copy/move a part or the whole of the content of the floated element outside the element. In spite of some bugs, the property float is however useful. Following screen captures show problems with the clear and float properties:

CSS1 implementation was disappointment, because I expected that MS IE 5.5 could survive from the CSS1 Test Suite of W3C as well as Opera 4.x and Netscape 6.0, which render the whole suite almost flawless (at least better than MS IE 5.5). MS IE 5.5 doesn't render at least following test pages flawless:

W3C: CSS1 Test Suite.

MS IE 5.5 should ignore invalid CSS, but it accepts at least following invalid CSS:

  1. Accepts invalid property values:
    • For example MS IE render following box as if it has 1px as the width value (style="border: 1p solid #636"):
      a bordered inline element.
      According to CSS2 it should ignore the invalid value 1p and render borders with default value. MS IE should render it at the following way (border: medium solid #636):
      a bordered inline element.
    • It accepts invalid font size values, for example {font-size:15}; it renders unitless font-sizes as if they would have been defined with pixel values ({font-size:15px}). Katso esimerkki[S][Pw].
  2. It accepts hexadecimal color values, which don't start with #.
  3. It accepts @import at-rule even if it the rule would not be in the beginning of the style sheet.
  4. Accepts invalid id and class names.
  5. Forward compatible parsing doesn't work.

Note. It is really bad matter, that MS IE 5.5 accepts invalid CSS, because Netscape and Opera don't tolerate as much invalid encoding. The author might create invalid CSS, which works only in MS IE. In fact it would be very desirable, if the browser could validate used CSS and complain spelling errors. This is much better solution than tolerate invalid CSS (accepting invalid CSS has also a disadvantage, which concerns the forward compatible parsing).

Also the implementation of CSS2 in MS IE 5.5 was in some matters disappointment to me. MS IE 5.5 is not a real XML + CSS browser, because it doesn't support some important features (I handle them also in the page How to use CSS with XML documents[S].

CSS2-implementation has at least missing of following features:

In addition I mention that MS IE 5.5 supports overflow quite well, but overflow:auto should create scroll bar(s) only if it is absolutely necessary. MS IE might create the horizontal scroll bar even if it is not necessary. This is a quite tiny bug.

Overall MS IE 5.5 has fair, but not very good CSS-implementation.

Proprietary CSS

An inconvenience designing feature in Microsoft is that the company have been concentrated on creating proprietary solutions instead of creating a proper implementation of existing standards. I handle proprietary CSS in a separate page[S]. Below is a link to comments in some web pages.

Webreference, Webstandars.

MS IE 6.0 for Windows

MS IE 6.0 doesn't have much new implementations. Concerning features, which belongs to CSS2 but not to CSS1 Microsoft informs that only supporting of min-height in tables has been added (the property doesn't work with generic block level elements). In general MS IE 6.0 has the same missing of important CSS2 features as MS IE 5.5. Instead Microsoft has tried to get full CSS1-implementation and make existing CSS2-implementations to conform with the CSS2 specification.

Microsoft has succeed in this matter quite well. In spite of some bugs MS has really tried to create standard-compliant browser concerning rendering of CSS2, when the standard-compliant mode have been turned on with the so-called DTD-switch[S]. Trials to follow the CSS2 specification concerns primary situations, where the standard-compliant mode is on. In the standard-compliant mode MS IE 6.0 support future proposals but not proprietary extensions.

The DTD-switch creates also problems, because the rendering with MS IE 6.0 for Windows might be quite different than with MS IE 5.5 for Windows. Matters, which I handle in the page 8[S] concerning dimension problems are worth to notice. Following my advice it is possible, that MS IE 5.5 for Windows, MS IE 6.0 for Windows, MS IE 5.0 for Mac and new Opera and Netscape/ Mozilla Gecko browsers renders sites approximately at the same way with all kinds of document types.

The browser makes also in the standard-compliant modes errors, which are worth to mention. Almost all CSS1-level bugs/missing features has been fixed/added. Below is a short list matters, which I have found concerning CSS1:

Note. Because MS IE 5.5 implements incorrectly height and width to ordinary inline elements (for example STRONG), MS IE 6.0 supports the into CSS3 belonging display:inline-block display type. If the browser works in the standard-compliant mode[S], this CSS must be defined in order to get dimensions for ordinary inline level elements. I refer to this property also in the page, which handles problems of the CSS2 specification[S].

W3C: CSS1 Test Suite.
Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.

MS IE 5.0 for Mac

MS IE 5.0 for Mac differs in many matters essential from MS IE 5.5 and MS IE 6.0 for Windows. MS IE 5.0 for Mac has the DTD-switch[S] like MS IE 6.0 for Windows. MS IE 5.0 for Mac might render sites so, that the presentation is either closer MS IE 5.5 for Windows or new Opera and Netscape/ Mozilla Gecko browsers.

Overall it has better CSS2 implementation than MS IE 5.5 for Windows. It can be rather compared to MS IE 6.0 for Windows than MS IE 5.5 for Windows. MS IE 5.0 for Mac differs from MS IE 6.0 for Windows at least in following matters:



There are situation, where something in the common CSS-file doesn't fit for certain version of MS IE. Different handling of @media gives the possibility to get some browser to skip certain CSS. If the same skipping has been needed both for MS IE 4.x for Windows and MS IE 5.0 for Mac browsers, the same CSS must give several times.

In order define individual properties for MS IE 4.x for Windows can use unknown media types:

/* MS IE 5.0 for Mac don't read any CSS inside media blocks, but MS IE 5.x+ for Windows ignores only unknow media types */
@media tty {
foo {} /* MS IE 4.x Windows skips this rule and reads just the next rules. */
#IE4 {...}

This fits also for newer versions than MS IE 5.0 for Mac because Microsoft doesn't anymore develop Mac browsers. However the most reasonable way to tailor CSS for different versions of MS IE is to create one big CSS-file, which fits at some level for all browsers (look at a model source code fragment[S]). If necessary some versions get own CSS-files, which have browser-specific changes.

It is possible to skip certain versions of MS by using conditional comments, which other browsers than MS IE interpret as conventional comments, why they work only in MS IE browsers, for example:

<!--[if IE 5]>
Msdn: About Conditional Comments.

Note. If the purpose is to give for Opera 4.x+ in the full screen mode the same CSS as for new MS IE browser, it is necessary to take account advice, which I have given for Opera[S]. It is also reasonable to take account advice, which I give when I handle dynamic menus[S].


P What CSS-implementation errors are in Netscape/Mozilla browsers


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


I handle in the next section Netscape 4.x related problems and after that Netscape 6.x+/Mozilla Gecko related problems.

Netscape 4.x related problems

Passing Netscape 4.x

Giving direct CSS (style="...") is problematic. In one respect it is bad, because certain CSS might crash Netscape 4.x or create some other serious problems. On the other respect it is necessary, because linked CSS doesn't always work. I found the latter matter, when I designed dynamic menus[S]. If the direct CSS doesn't fit for other browser, they can get different CSS in linked files, if declarations have the !important rule. The rule should not however unnecessary overload, because all browser don't accept many times overloaded rules.

In many situations it is reasonable to pass Netscape 4.x. In principle one way to pass Netscape 4.x is to use import rule[S][Pw] and combine it with JavaScript encoding. Because Opera 4.x+ has the mode Identify Mozilla 4.x, the script should have a condition, which prevents Opera to read the CSS for Netscape 4.x. The code should write for example at the following way:

<script language="JavaScript" type="text/javascript">
if (document.layers) /* No other browsers than Netscape 4.x support this method, when Opera like other browsers skip the block, which is after this condition (I give further another alternative) */
{document.write('\<\lin'+'k\ rel=\"stylesheet\"\ type=\"text/css\" href=\"Netscape4xStyle.css\"\>'); }
<style type="text/css">
@import url(otherBrowsers.css);

I got the basic hint from Sam Marshall, but I changed it concerning the browser detection. The system works in all browsers. Users of MS IE, Opera and new Netscape/ Mozilla Gecko browsers it doesn't matter anything, if the JavaScript-support has been turned off. The JavaScript is only needed for the Netscape 4. series and style sheets don't work at all in Netscape 4.x browsers, if JavaScript has been turned off. If all browsers get the style sheets with JavaScript, when the the JavaScript is turned off, CSS don't work at all. In some conditions a part of the CSS might be reasonable to give by using JavaScript-encoding. I handle these kinds of situations in the extra page, which handles dynamic menus[S].

The problem of the previous example is that media blocks[S] and that way media types can't be used, if the purpose is that pages works well also in Mac browsers. MS IE for Mac (concerns at least to the version 5.0) namely doesn't support media blocks (@media {...} but skip all CSS, which is inside them.

Opera has another special problem. It reads always the @import at-rule to all media types, if there is not told, which media type is used (this concerns at least until the version 5.11). The media type specifier (for example @import url(...) screen;) works in few browsers. @media and @import at-rules should not be used at all, if the purpose is to create CSS-code for all media type supporting browsers!

A better variation of the same basic idea is to generate for the Netscape 4.x series own CSS-files and comments around files, which Netscape 4.x should not read. The way of the following example makes possible the functionality of media types also in Mac browsers (the following code is for XHTML-documents):

<script language="JavaScript" type="text/javascript">
if (document.layers)
{document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text/css\"\ href=\"../Css/basicNetscape4.css\"\ \/\>');
document.writeln('\<lin'+'k\ rel=\"stylesheet\" type=\"text/css\"\ href=\"../Css/Netscape4SomeOtherSite.css\"\ \/\>');}

<script language="JavaScript" type="text/javascript">

if (document.layers)
{document.write('\<'+'!\-\-'); }
/* If the comment tags have not generated in two parts, browsers might handle them incorrectly! If instead of \-\- have been marked as -- validator services interprets the code so, that in the document has nested comments, which are not allowed. */
<link rel="stylesheet" type="text/css" href="../Css/CssSitePrint.css" media="print" />
<link rel="stylesheet" type="text/css" href="../Css/CssSiteProjection.css" media="projection" />
<link rel="stylesheet" type="text/css" href="../Css/CssSiteScreen.css" media="screen" />
<script language="JavaScript" type="text/javascript">

if (document.layers)
{document.write('--'+'\>'); }


I have found that the difference between first and last Netscape 4.x series is quite big concerning the reliability of browsers. Netscape 4.04 crashes very easily but Netscape 4.79 is quite stable. Presumably also Netscape 4.6x is quite stable. If necessary it is possible to make own CSS for different Netscape 4.x series browsers. In the example below Netscape 4.0x-4.5x and newer Netscape 4.x series browsers get different CSS:

<script language="JavaScript" type="text/javascript">
if (document.layers)
{document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text/css\"\ href=\"../Css/basicNetscape4.css\"\ \/\>');}

<script language="JavaScript" type="text/javascript">
/* Because in this case is needed more exact browser detection, the process has two parts. The purpose is that first condition is that Opera would skip in all circumstances the script for Netscape 4.x */

if (navigator.userAgent.indexOf('Opera')!=-1){} /* Because Opera finds a detections string, which fits for it, it skips the next block even if pretends to be a Netscape 4.x browser. Works reliable at least starting from Opera 4.02+. Older Opera browser don't always give this string, when they can't be reliable detected at this way. In principle also document.getElementById could be used but according to an e-mail Netscape 4.x has sometimes difficulties with unsupported methods. */

else if (navigator.appName.indexOf("Netscape")!=-1 &&
/* Without the first condition this block would concerns also Opera browsers, if they identify as Netscape 4.7x. */
{document.writeln('\<lin'+'k\ rel=\"stylesheet\" type=\"text/css\"\ href=\"../Css/Netscape4CssSite.css\"\ \/\>');}

Note. It is also possible to use JavaScript in order to identify other matters than the name and the version number of some browsers, for example the size or the color depth of the screen and the create screen dependent CSS-files. Instead only few browsers have the possibility to switch between default and alternative style sheets. You can search JavaScript examples by using in common search engines (like Altavista and Google) for example keywords javascript+window+color depth and javascript+window+size.

The alternative of JavaScript is to use serve side encoding, which it is not dependent, if JavaScript support is in use. But server-side encoding can't test, which features the JavaScript interpreters of different browsers support, when method-based detections can't work. At least Opera can easily get incorrect CSS. By using JavaScript it is also easier to take account situations, where the JavaScript-support has been turned off. I handle however PHP-based detections[S] in mixed information technology pages.

Webreference (the color depth), Javascripter (the size of the window), Sam Marshall (United Kingdom; The writer of the first hint).

Without linking

You can use these without linking:

I give you two examples, how to define CSS for Netscape 4.x browsers:

Especially problematic features

Trying to get good presentations, following matters are especially problematic:

Because you can't do anything to these, I recommend to define following properties so, that Netscape 4.x doesn't read them or it gets them only in some circumstances:

Some other hints

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

A list of errors in the CSS1 Test Suite[S][Pw] in my Finnish page is terrible long and in fact I should be longer, but I was not sure of some pages and I don't put them into the list.

Remember. The CSS-implementation of Netscape 4.x is in many matters very bad. Certain in many matters about the same level as MS IE 3.02 (the most important difference is to support most features of CSSP (P = position), which is today part of CSS2). The basic structures documents should base on HTML 3.2. Netscape 4.x must be handled primary as HTML 3.2 capable browser, which can give a little bit CSS.


Netscape 6.x+/Mozilla Gecko related problems

Netscape 6.0 has much worse CSS-implementation than newer versions and Mozilla 0.9+. It doesn't support position:fixed. It might need is some circumstances an own CSS. Below is an example of way how to separate different Netscape/Mozilla versions from each others on the base of the date (Build ID) of the browser.

<script type="text/javascript" language="Javascript">
Gecko = (navigator.product == ('Gecko'))
Date1 = (Gecko && parseInt(navigator.productSub)>=20020728);
Date2 = (Gecko && parseInt(navigator.productSub)<=20020727);
if (Date1){
document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\ href=\"..\/Css\/MozillaNewest.css\"\ media=\"screen\"\ \/\>');}
if (Date2){
document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\ href=\"..\/Css\/MozillaOlder.css\"\ media=\"screen\"\ \/\>');}

In this example the "separator line" of browsers is in certain sub-versions Mozilla 1.1/ Netscape 7.0. For example experimental supported CSS3-implementation -moz-opacity crashed Netscape 6.0 and worked bad in Netscape 6.1 level Mozilla and Netscape 6.2.1. Because of that and another reason set in my CSS-file one separator line to the point above (you can study a source code fragment[S], which I have used).

The dates (Build ID) and corrersponding Mozilla versions of the Netscape 6.x+ are following:

DevEdge: Netscape Gecko User Agent Strings; Mozilla org.: user-agent strings.

Instead of the Build ID it is possible to detect Mozilla Gecko browsers accorind to the version of Mozilla. Below are two string of Mozilla browsers and a possible contition in order to detect those browsers:

Netscape 6.2.1:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
Mozilla 0.9.4:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128


Indeed that kind of string doesn't work with Netscape 6.0 because it inform the corresponding Mozilla version differently as you can see from the string of Netscape 6.0 (I put below the string some possible detection strings):

Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0

navigator.userAgent.indexOf('m18')!=-1 /* I don't know, if this concerns also Netscape 6.01. */
navigator.userAgent.indexOf('Netscape6\/6.0')!=-1/* This concerns also Netscape 6.01. */

Because there are different types of Mozilla (for example Mozilla 0.9.1 and Milestone 18), Build ID based detections are more covering. Anyway it is possible to detect Mozilla Gecko browsers as exact as it is necessary.

Netscape browsers can detect indepent from Mozilla browsers by using additional conditions like navigator.vendor == ("Netscape7"). Then you can give different dates for Netscape browsers if it is necessary, for example:

NetscapeGecko = ((navigator.vendor == ('Netscape6') || navigator.vendor == ('Netscape7'));
else if (Mozilla101&&NetscapeGecko)
else if (Mozilla11&&!NetscapeGecko)

There are much reasons to separate Gecko browsers. For example with some 6.1+/ corresponding Mozilla browsers inside position:fixed defined elements position:absolute defined descendants don't strip correctly. The position:fixed defined ancestor creates a container block for position:absolute defined descendant elements, but some builds don't take always correctly account the position of the position:fixed defined ancestor element. In the screen capture with Mozilla 0.9 below position:absolute defined links should be inside the yellow position:fixed defined block (on the base of my tests this matter is fixed at least starting from Netscape 6.2.1).

div.pageGroup, div#allPages, div.allPages2,div#PagesFi, div#PagesEn {position:absolute} /* PagesFi and PagesEn are descendants of allPages */
div[class="pageGroup"], div[id="allPages"], div[class="allPages2"] {position:fixed !important}
div#allPages {left:6px; top:1px;}
div#PagesFi, div#PagesEn {z-index:17; left:2px; top:2px;} /* those Mozilla Gecko 0.9 based browsers, which I have tested calculate the positions of these blocks from the top-left corner of the HTML element ignoring the position of the fixed positioned container DIV, which has allPages as the value of the id attribute */
Mozilla 0.9

In order to get elements into correct position in all modern browsers, it might be necessary to define conditional CSS for Gecko browsers. It should be defined as small quantity as possible. I recommend to read also extra pages, which handle problems of Opera[S] and MS IE[S] browsers.

Also in quite new versions of Netscape/ Mozilla have some problems rendering my dynamic menus in some topic groups (read about problems from a test page[S]).

Such dynamic menus, which have been implemented only by using CSS don't work in Netscape 6.0 (look at models[S]). This is not however a remarkable problem, because dynamic menus are much reasonable to create according to DOM1 JavaScript/ECMAScript + CSS encoding (I handle them closer in another extra page[S]).

The previous mentioned problem relates with the IFRAME element. Many Netscape 6.x/ Mozilla browsers have difficulties with this element (the z-index and positioning don't work correctly). Some versions don't position them correctly. Netscape 6.0 prints them even if they have been defined with display:none. Netscape 6.1+-6.2.1 crash in printing if documents have them and display:none have been used in order to hide these elements. In the newest build of Mozilla has been solved all IFRAME-related problems.

Netscape 6.1+ has fine normal screen presentation. In the fact the only remarkable problem is that it needs more CSS than other modern browsers, because default HTML-settings are not equal with MS IE and Opera. At least following matters should be especially noticed:


Q What CSS-implementation errors are in Opera browsers



Because Opera is from the 5.0 version available as half-free ad-sponsored (adware) application I handle in this page primary Opera 5.x browsers. I refer to the 3.x series on a little. It is reasonable if pages would work at least fair in Opera 3.x series.


Problems in Opera 5.0-6.0x

Opera has fine support of different media types, but just usage of them has some problems, which should be aware. I have handled some matter in the page 6[S]. I addition of matters, which I have handled in that page in order to get pages to work well as printed and on screen it is important to take account also following matters:

  1. The browser supports media="projection". If for the screen presentation style sheets has been given by using media="screen" or corresponding media blocks[S] the browser doesn't get at all CSS in the full screen mode. If you have Opera 4.x+ and you press the F11 button in this site, the page looks quite different (I have advice[S] for this mode and every page have short hints how to navigate in this mode).

  2. Opera behaves incorrectly if media types have been given at the following ways:

    • If to the same CSS-files has been referred at the following way:

      The problem in the latter solution is that Netscape 4.x doesn't support several values at the same time for the media attribute. I the style sheet has been intended to use both in Opera and Netscape 4.x browsers, the media type projection should give an own CSS-file.
    • If media block doesn't exactly match to the value of the media attribute:

      /* Doesn't work with following media blocks: */
      @media screen {...}
      @media projection{...}

      /* It works only with following kinds of media blocks:*/
      @media screen, projection{...}
      The problem of this solution is the fact that randomly the same CSS-file has been needed both for one and several media types.. Then it is necessary to use several media blocks for the same CSS. For example in order to get media blocks to work with both and <link media="screen" type="text/css" href="Screen.css"> the same CSS needs two media blocks:
      @media screen {
      #linkSet a {color:red}}
      @media screen, projection{
      #linkSet a {color:red}}
    • The attribute media doesn't work correctly with the @import at-rule if the at-rule doesn't have the media type (for-example @import url() print;). It doesn't work in all browsers (in Opera browsers it works starting from the version 5.10).
    • @media doesn't work in the Opera 3.x series.
  3. The media type projection has problems keeping "slides" continuous. In order to avoid incorrect page breaks I give two hints:

    • Write tight code. Except tables and lists I have written start-tags and end-tags one after another.
    • If the browser breaks inside or after the first paragraph I have added an empty DIV element with a class attribute before the content of the slide (I have defined for media types print and screen div.noScreen {display:none}).

Media blocks can be use in situations, where MS IE 4.0 for Windows need certain CSS, which is not intended for other browsers. In addition inside media blocks can write such CSS, which is not intended for Netscape 4.x and MS IE 5.0 for Mac browsers because these browser skip all CSS, which is inside media blocks. I have given an example in the extra page, which handles MS IE problems[S]. When media types are used clever, they allow fine solutions especially with Opera.

Another big problem concerns fixed or absolute positioned elements if they need the z-index property. The problem concerns always certain embedded objects (they are embedded to Web-pages through OBJECT, APPLET and EMBED elements) and until Opera 6.x form control elements (EMBED, IFRAME, INPUT, ISINDEX, OBJECT, SELECT, TEXTAREA). Any text or images can't set above these elements. It is possible to avoid this problem by positioning problematic elements so, that they newer go over each others - it is especially important to remark this with elements, which are fixed positioned (position:fixed). In my updated navigation system navigation elements are on the left and right and problems have been avoided as far as possible. Concerning form control elements this matter has been fixed in Opera 7.0 Beta 1.

Opera has also a small problem with the visibility property. Opera hides always such elements, which have visibility:visible if they are inside elements, which have been defined visibility:hidden (look at a test page[S]) (MS IE 6.0 for Windows works always correctly but new Netscape/ Mozilla browsers work in some circumstances incorrectly). This matter has been fixed in Opera 7.0 Beta 2.

Opera 5.x and Opera 7.0 Beta 2 might position horizontally incorrectly nested absolute positioned elements. The property left doesn't always work. Concerning Opera 6. I found that position:absolute + nested relative positioned elements positioning didn't work for innest elements.

In addition position:fixed has also following special problems (if you have Opera 5.x+ I have a test page in order to demonstrate these problems):

  1. The combination position:fixed + position:absolute doesn't work in official versions of Opera 7.0x (in Beta 2 nested absolute positioned elements don't work correctly). One of the consequences is that background colors of links don't always follow the movement of the mouse in the state :hover

  2. Using the positioning right Opera 7.0 Beta 1 - Opera 7.01 might move elements too much to the right and Opera 7.02 might randomly hide elements.

  3. In Opera 6.0x the padding-top and padding-bottom properties for the BODY elements affects to bottom property. For example div#fixedNavigation {position:fixed; bottom:0; left:0;} together with body {padding-top:50px; padding-bottom:50px;} cause that the fixed element is 100px from the bottom of the viewport (this problem is not in the 5.x series). This problem is possible to avoid but at least Opera 7.0 Beta 2 has not this problem (I have not tested in Beta 1).

  4. If the fixed element is on the bottom of the viewport, the min-height property can't be used. This matter has been fixed at least starting from Opera 7.0 Beta 2.

  5. Fixed positioned elements, which are inside positioned elements scroll among the page (this problem is not in Netscape 6.1+; in Opera 7.0 Beta versions the element might disappear from the screen or the position moves a little bit if the element has been clicked). This problem is possible to avoid at the same way as the next problem.

  6. If an element, which is later in the content (for example position:fixed; bottom:0; left:0; z-index:3), has been set as fixed, it might disappear from the screen. I tested in this page with Opera 7.0 Beta 2, which had no problems at least in this page. This problem is possible to avoid by setting fixed positions elements only to the top of the page and as direct child-elements of the element BODY.

  7. If dynamic menus have been positioned by using position:fixed menus don't work as expected (and how they work in Netscape 6.1+ and other corresponding browsers, which use the Mozilla Gecko rendering engine). This problem can't be avoided but it is fixed in Opera 7.0 Beta 2.

  8. If fixed positioned elements have background images, Opera browsers which are older than 7.x series scroll them among the page, if background images have not defined as fixed (background-attachment:fixed). If they have defined as fixed, Opera calculates the position against the CSS2 specification according to the element. This cause problems with newest Mozilla Gecko based browsers, which calculates background images correctly. This matter has partially been fixed in Opera 7.0 Beta 1 because it is not necessary to use fixed background images (the positioning problem remains, but in Opera 7.0 Beta 2 also this matter has been fixed). This problem can be solved only by writing conditional CSS.

  9. If links have with dynamic pseudo-classes (a:hover and a:active) borders, borders work only in the top of the page. This is fixed in Opera 7.0 Beta 2.

  10. If fixed positioned elements have position:absolute defined descendants, this matter cause problems in some Mozilla Gecko builds[S] (this is not a bug in Opera but instead in some Mozilla Gecko based browsers). This matter is impossible to avoid except setting conditional CSS for certain Gecko browsers, where the position has been set by using position:fixed (Gecko browsers have so much version-dependent differences that position:absolute doesn't give equal result for all such Gecko browsers, which support position:fixed).

  11. Position:fixed doesn't work in the 5.x-series for elements IFRAME, OBJECT and EMBED, but this matter has fixed in the 6.x-series.

  12. Form control elements move horizontally one pixel when the page has been scrolled. This matter has been fixed in Opera 7.0 Beta 1.

  13. Internal links don't always work as expected. I must put the link to the top of the page ([Top]) immediately after the anchor (<a name="Top" id="Top"></a>), which it refers. Otherwise Opera didn't go exactly to the top of the page. This matter has been fixed in Opera 7.0 Beta 1.

The third remarkable feature is quite weird implementation of xx-small-xx-large properties, which resemble most the implementation of MS IE 5.x for Windows browsers (look at Model8c.html[S]).

Opera browser don't have as wide working two different rendering modes (in the 7.x series is some kind of DTD-switch) for the screen presentation like new MS IE and Netscape 6.x+ browsers, it can't follow in certain respects the CSS2 specification as strict as MS IE 6.0 for Windows in the standard-compliant mode[S]. Opera would wider working DTD-switch.

I mention smaller problems in other connections. You can read them for example from the following pages:

Because Opera is a visual browser it naturally doesn't support aural style sheets. The widest area in visual media of CSS2 is missing of supporting the @font-face at-rule. Other missing features are missing of some individual property values and some rules, which I have mention in my CSS How to set CSS for table elements (table 1[S], table 2[S]).

If for Opera is necessary to give partially own CSS, I have in an another extra page[S] hints for browser detections.

Opera 7.0 Beta 2 has some setting, which are different compared to other browsers:

Opera 7.x series browsers print worse than 6.x series browsers. In Beta 1 the printing is relative good but bad at least until 7.03 in these respects:


R What CSS-editors and application are available



PageBuilder is a code editor, which has a good CSS1-level wizard. The only CSS2 level addition is the dynamic pseudo-class hover (that is not depending on the CSS2 specification but the MS IE browser, which has used it as proprietary extension).

The application use MS IE as its internal browser (3.02 or newer). It is relative cheap Shareware-application.

Taf Web Software.


HTML-kit is a freeware code editor, which have all CSS2 level properties. The problem is that in the Style Sheet selector list is all HTML 4.0 elements - also those, which can't have CSS-properties. The list doesn't include pseudo-classes and -elements like the list of PageBuilder. Chami has not made for CSS an own list of elements, which can have CSS-properties. There is however additional plug-ins just for CSS.

HTML-kit includes full list of HTML 4.0 level elements and attributes. It doesn't browse files without additional plug-ins. Like PageBuilder it use MS IE as the internal browser.

It can convert HTML-documents into XHTML or XML-documents and correct errors with a plug-ins -application, which include in the installation package. It is possible to use additional plug-ins, which are made with the designer of the application or other people like:

I recommend that you check you pages randomly with the HTML-validator of W3C. HTML-kit has the HTML-Tidy plug-ins application, which helps to fix all syntax errors. Older versions of it are however real validator, because they accept to use some proprietary attributes and elements. Newest version doesn't accept them at it can be regarded almost like an online validator (it is however possible to take off warnings, which concerns proprietary elements and attributes). With HTML-Kit is also possible to test pages with an online validator.

W3C: HTML validator.
Other sites: HTML-kit Home page, HTML-Kit Plugins page.


Amaya is a WYSIWYG editor, which works also as a browser. It doesn't show all CSS-properties. Indeed it creates style attributes, generates CSS rules and handles CSS style sheets.

It might be useful in testing new recommendations, because it has experimental implementations of new recommendations: MathML, SVG, XLink, and namespaces that allow you to mix in the same document all these XML applications.

It has some disadvantages. It stacks easily. It doesn't use common entities to special characters (for example to ä and ö), which is inconvenient for example Scandinavian users of Amaya.

W3C: Amaya, MathML 1.01, Scalable Vector Graphics (SVG) 1.0 Specification.

Top Style

The best editor is today regarded as Bradsoft TopStyle, which have MS Office 97 style interface. The application supports also the CSS2 specification. Version 1.50 does have some missing CSS-properties but they are added into version 1.51. It give advice, which properties don't work in various browsers. In the version 1.50 the validator and the sweeper of the application work incorrectly, but I have made bug reports and they will be fixed at least to the version 2.0. I have installed free Lite version, which doesn't have the validator and sweeper. I don't know if bugs are fixed.

The light version marks however incorrect properties as red (if the CSS-has @media, it puts however incorrectly the first rule as red). Note, that the import rule is marked bold red.



I tested the version 1.5, which includes almost all rules, properties and values, which include into visual rendering model of CSS2. It does have good comments, how to use CSS. Doesn't include Aural rendering properties and a CSS-validator.

Western Civilization.

Netscape 6.x

Netscape 6.0 can almost use as the comparison browser how CSS should be rendered (I has however some bugs). It does have almost perfect visual CSS-implementation.

It includes also in my the best WYSIWYG editor (I tested the version, which I got with Mozilla 0.7), if we think the rendering according to the HTML 4.01 and CSS2 spesifications. It seems to use the rendering engine of the browser, because the editor doesn't essential differ from the browser. It renders fine CSS but doesn't have an easy way to add CSS.

The encoding is valid HTML with common entities to the text (unlike MS FrontPage Express, which is in the MS IE bundlet). Indeed it use the name attribute to anchors but in XHTML anchors should have also the id attribute. The editor adds much white space, which all don't like. It could also have an option to convert HTML into XHTML.


Macromedia Dreamweaver 4.0

As a WYSIWYG editor, Dreamweaver is far from the level of the editor of Mozilla 0.7. Concerning CSS Dreamweaver is just a half Wysiwyg editor.

Dreamweaver creates as default CSS-layers with the element DIV setting to it the property position:absolute. The system work fine, if layers are direct child-element of the element BODY (or inside some element, which doesn't create any margin or padding relative to the element BODY). But if the are inside some element (for example a table cell), which creates margin and padding relative to the element BODY, the CSS-layer system of Dreamweaver 4.0 just doesn't work, because all browser have serious bug in the CSS-implementation at this point.

Dreamweaver should set CSS-layers always as direct child-elements of the element BODY. It is in practise incorrect way to change values of absolute positioned element. The place of the DIV element must move, in order to get the desired result. Absolute positioned elements are in principle calculated according to the nearest block-level container element, not according to the viewport. In my mind Dreamweaver doesnt' do at this way. Even if browsers have bugs, the editor should work according to specifications (look at also a CSS notes 2[S]).

Dreamweaver doesn't support position:fixed (supported in Opera 4.x+, MS IE 5.0 Mac) and :focus (supported in Netscape 6.0) and some other CSS features. The CSS editor of Dreamweaver is modest (TopStyle is much better).

Concerning HTML Dreamweaver doesn't list all form element in the dialog (Netscape 6.0 supports ALL form elements except the deprecated ISINDEX, which is supported in Mozilla 0.7). It adds proprietary attributes, when defining background. If Macromedia Dreamweaver adds proprietary background properties, it should also add automatic corresponding CSS in order to ensure functionality in standard compliant browsers (Opera 4.x, Netscape 6.0). I don't understand attributes, which don't work in any browser (<BODY tracingsrc="some.gif" tracingopacity="23">).

Dreamweaver could inform, if something is standard or proprietary, because standard-compliant browsers (like Opera) don't support proprietary attributes to BODY. It could just divide dialogs into two section: standard HTML 4.01/XHTML 1.0 and proprietary (HTML-Kit informs, if elements and attributes belongs to certain specification or if they are proprietary).

It use terrible much resources, which might cause very slow performance in many computers. I has much handy features (site map, roll-overs etc.), but in many respect it is possible to do with free editors the same matters as easy.


DHTML Menu Builder

Many applications create proprietary DHTML, which functionality is limited. How to design dynamic menus are one of the best DHTML solutions. It is easiest to create dynamic menus by buying DHTML Menu Builder application, which creates DHTML/DOM menus for all browsers, which can handle them (for example Netscape 4.x, Netscape 66.x, MS IE 4.0+ for Windows and Opera 5.x). It generates automatic necessary HTML-structures and CSS for different browsers. Older versions of the application create invalid CSS (most recent versions create standard CSS). If the CSS is not valid, menus work in some browsers only together with such HTML document types, when the browser don't work in the standard(-compliant) mode[S].

xFX JumpStart: DHTML Menu Builder.


S What are some speacial advances using CSS


Basic advances

CSS has at least following basic advances compared to HTML 3.2:

Special advances

In some matters Microsoft have made a good favour to CSS system introducing first hover, which doesn't belong to the original CSS definitions, but which is added to CSS2 like focus, which have quite the same idea as A:active. A:focus is a good companion to A:hover. Advances of A:hover and A:focus:

The only disadvantage is, that in order to get best performance, HTML 4.0 + CSS must degrade browsers, which doesn't support it. HTML 3.2 is inflexible old-fashioned way to design appearance to pages and the philosophy of CSS is totally different - concerning appearance of pages, they are incompatible.