MS IE 5.x handles BODY and HTML elements like the FRAME element. Opera and Mozilla allow to use them as basic layout elements. Because the overflow property is supported in Mozilla, it is a little bit better than Opera. Microsoft has however promised to fix the behavior of the element BODY in the 6.0 series, when the browser use certain document types.

MS IE accept to use style, id and class attributes with CSS to the HTML element, which is against the HTML 4.01 specification.

MS IE supports border properties to FRAMESET and FRAME elements in situations, where the framesets have actual contents. Mozilla Gecko browsers hide normally defined CSS behind the defined or imaginary frame documents. If the defined documents can't be found with Mozilla 1.1 it is possible to define border and background properties for FRAME and FRAMESET elements (with some older versions it is only possible to get visible border properties for the FRAMESET). Because these browsers support frames, the functionality of NOFRAMES can' properly tested. It is possible to take off the support of frames in Opera, but Opera doesn't apply CSS to the element NOFRAMES.

The functionality of navigation frames can in principle achieved with CSS (for example div.navigation {position:fixed; top:0px; left:0px; width:100px; height:150px}), but it works relative well only in Mozilla 0.9+, Netscape 6.1+ and Opera 4.x+ and at some level also in MS IE 5.0 Mac browsers (the main navigation in this page is on the bottom of the page using these browsers) if the navigation element is an ordinary block. Dynamic changes work properly in relative new Mozilla Gecko browsers (Mozilla 0.9.4+/ Netscape 6.2+). If the navigation element is alone or inside a table cell, it doesn't cause any harm to browsers, which doesn't support it.

In browsers, which support special link relations (for example rel="index") the CSS might have the desired effect.

Even if CSS works well, the HTML functionality doesn't.

In principle CSS can applied to the NOSCRIPT element, if JavaScript support is turned off.

It is supported in MS IE IE 2.0+. It has strange default behavior.

MS IE Windows counts dimension of block boxes incorrectly. Opera has difficulties with vertical dimensions. Only Mozilla calculates block box dimensions correctly.

The element CENTER is unnecessary, when used CSS. In Principle also the element HR. Opera handles colors to the element HR differently. For some reason Netscape/Mozilla defines the element in /res/html.css by using proprietary CSS (, text-align: -moz-center). Mozilla use a proprietary value for the border-style property in order to define the default presentation to of the HR element (border: 1px -moz-bg-inset).

Pseudo elements are supported in MS IE and Netscape only in the newest versions. Opera supports them from the version 3.5x. Opera 4.x-5.x or older have minor problems with :first-letter. Opera 7.x doesn't support it fully if the block starts with some element.

Opera has excellent implementation, because it supports display:compact and display:run-in, which can emulate special list elements. It supports also generated content and automatic numbering. The previous is supported also in Mozilla, but not the latter.

Mozilla sets the default positions of list elements differently as MS IE and Opera. Opera and MS IE use default margin values to create relative offsets between elements, but Mozilla use paddings. In order to avoid problems, if default values are changed, both margin and padding properties must be defined. If only the margin property is changed, this cause different rendering, which can be seen from the model images.

In all cases, where is possible, it is reasonable to use table-layout:fixed.

MS IE doesn't support the caption-side and the element behaves always like TD/TH elements.

Because Opera and Mozilla handle this element like an independent DIV element, the CAPTION element might have offset compared to table rows. It is however remarkable, that according to the CSS2 specification the TABLE and CAPTION boxes retain their own content, padding, margin, and border areas. The width is computed with respect to the width of the table box's containing block, which is common anonymous box to TABLE and CAPTION elements. This cause however some problems to web authors.

Because Opera and Mozilla support the caption-side property, they have at this respect excellent CSS-implementation to this element.

Opera 4.x-6.x has a problem, if CAPTION and the TFOOT elements are used together. This problem cause also CSS-implementation errors (this matter has been fixed in Opera 7.x).

In my tests have been worked border, text-align and font-size properties. Text alignment works to with TD/TH and font size with the TH element in MS IE. Opera and Mozilla 1.1a (not older tested versions) support borders to the COL element and Mozilla also for the COLGROUP element (older tested Netscape/ Mozilla don't support border properties for these elements).

In IE border properties don't work always work. Even if CSS works in most cases well in Opera, it works buggy, if THEAD or TBODY elements are defined together with the CAPTION Element.

Mozilla/Netscape has the default definition to it in the /res/html.css -file. Some CSS properties (for example margin, display and border) had effects, but all effects were not correct. Even if Mozilla/Netscape at some level identifies it, it doesn't really support it.

Håkom Wium Lie has proposed the functionality of this element as Multi-column layout in CSS for CSS3.

:link and :visited are link pseudo-classes and they are only related to the element A. Netscape 4.x and Opera 3.x supports only them. Rules, which are format :pseudo-class element {} work in Opera starting from 7.0 Beta1.

Other are dynamic pseudo-classes. They don't concern only the anchor element (A). Indeed MS IE handles :active according to the CSS1 specification, where it is just a link pseudo-class and the functionality is different as in CSS2. In principle :active and :hover concern all elements, which the user can hover over or activate - they work at that way in Opera 7.x (also Mozilla has quite wide implementation). Focus concern elements, which can get or loose the focus and they are intended for form control elements and they are supported them in Opera 7.x. :focus might be reasonable to apply for A and AREA and Mozilla supports it for A.

If the author has not defined, that it concerns only the element A, it cause drifting text in Mozilla and Opera 7.x+ if :hover use such properties (for example font-weight), which affect to the positioning of elements and which is different as the text, which in normally at the place of the mouse pointer (in my presentation pages Mozilla had drifting text, but I got it off). I have explained these matters closer in other pages. Indeed it seems that Mozilla doesn't work fully consistent. Sometimes properties to :hover work to the basic text, sometimes not.

If pseudo-classes are combined (for example a:link:hover) MS IE browsers read only the latter part of the combined pseudo-classes.

If they are used with transparent images, the author must set display-properties to them (I explain this matter in my CSS-site in a page, which is mentioned below).

The HTML implementation of MS IE to Q is poor, because it doesn't render any quotation marks. Mozilla and Opera support advanced CSS features to them and that's why I regard the CSS-implementation of the element Q excellent in those browsers. Look at a test to ABBR and Q from the appendix page below.

SPAN is especially designed to use of CSS to temporary overriding of the style of the parent element.

It is recommended to replace all of them except SUP and SUP with CSS. Only in presentational purposes also SUP and SUP should be replaced with CSS.

It recommended to replace all of them with CSS.

Rules like font[color="red"] {color:blue} works only in Mozilla. That's why only Mozilla has excellent implementation to the element FONT. Other attributes can be used with Opera to override the attributes of the FONT element.

Normal CSS works in all of them, but the basic HTML functionality only in MS IE. I tested :lang using example in the CSS specification and I don't find any effect, when I used them.

MS IE supports also some extra properties to it.

The HTML basic effect works only in all Netscape/Mozilla browsers even if IE 4.x+ can apply CSS (and common attributes) to it. Opera and Mozilla support the effect of this element with CSS (text-decoration:blink). SPACER is another inline-level proprietary element, which purpose is the same as transparent GIF-images. Therefore it is only partially supported by CSS. Width and height can be defined with CSS, but for example background-color and border don't work.

I found, that at least display:none works in HTML in all of them, when it is possible to remove in certain circumstances line breaks. In Mozilla and Opera it has quite wide implementation with the content property by using it together with :before and :after pseudo-elements.

Embedded object are in the top level and stacking by the z-index property doesn't work except in Mozilla (older versions of Netscape/ Mozilla have difficulties with this property). CSS can affect only matters, which are outside of the content of embedded objects.

Concerning Opera the effects of the properties to the element OBJECT are related used attributes. If the element has the attribute data, CSS works.

Like in embedded object, CSS can't affect to the content of this element. But in principle stacking order can work, because it doesn't use external applications. Stacking order works best in new Netscape/Mozilla browsers. With Opera IFRAME can't be set below other elements and position:fixed doesn't work with in Opera 5.12.

If the image has inline-level parent, background properties should be applied only to a one line. MS IE works in this matter incorrectly (I handle this matter in my CSS-site). MS IE doesn't support padding to this element, but this matter will be fixed in the 6.0 series.

MS IE doesn't accept set dimensions for the element MAP, when it is defined as block by using display:block (note, that the IMG element must set inside (as a child-element) of MAP - otherwise the MAP element creates an independent element and it behaves like a caption). This means too limited support in order to use background properties. In practise only border properties can be used.

At least the outline property could be applied to the AREA element. Indeed MS IE and Mozilla have prorietary outline implementations for the user focus.

FIELDSET is support only in newest Opera and Mozilla browsers but it is supported also in older MS IE browsers. Opera doesn't have any default rendering to it.

Mozilla 0.6 doesn't support ISINDEX, but borders to that element cause a small block box. This element is however supported in some builds newer versions of Mozilla. It is unsure, if Netscape will support it in future.

MS IE and Mozilla use a predefined font family but Opera doesn't. The background-color works at least in Opera and Mozilla but I'm not sure if it work in MS IE 5.5 (works at least in 6.0). Mozilla doesn't support the text-align property for it.

Borders are rendered at different principle in Opera 4.x-6.x compared to MS IE and Mozilla (this matter has been changed in the Opera 7.x series). Opera 4.x-6.x have a little bit poor implementation, because background properties don't work. I have explained these matters also in other pages.

Mozilla have excellent rendering, even type="radio" is supported.

Background properties don't work. Opera 4.x-6.x don't position the LEGEND element like Mozilla and MS IE, which cause rendering problem (this matter has been fixed in Opera 7.x). Indeed Opera Software doesn't promise to support these elements at all in 4.x-6.x, Opera has however partial and problematic CSS-implementation to them. These elements should be implemented fully functional or the browser should not identify them at all.

Mozilla has excellent support to them like almost all form elements. Also Opera 7.0 Beta1 supports it at some level. MS IE has better CSS implementation to SELECT than Opera.

Mozilla doesn't need so-called widget libraries to define presentation to form element, because it support proprietary pseudo-classes, proprietary properties and some proposed CSS3-features. Proprietary features are not intended to use in normal web pages. They are UA CSS, which intention is to define default settings for (X)HTML elements. Most of them authors can in future define with User Interface for CSS3. Netscape/ Mozilla supports also other UA CSS pseudo-classes/ elements, which are not related to forms but the purpose is to implement non-standard quirky behaviors (/res/quirk.css). Most of them are proprietary but some of them have been proposed into CSS3 (this concerns also UI properties and I recommend to read also CSS notes 2). [_moz-rs-heading] (this is for heading elements) etc. could be called as a "pseudo-attribute-selector" because the syntax is according to the attribute selectors, but there is no real attribute to do the effect, when it can be compared with pseudo-classes. According to an e-mail from a designer of Mozilla that kind stuff is handled in odd parts of the DOM and not in the style system. It is then not in fact real CSS but other presentation-related features, which have been defined inside a CSS-file. 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 list such CSS extensions, which are not used in files, which defines presentations for (X)HTML elements. I have added however all added supported CSS3-features, which I have got information through e-mails.

They are not supported in Mozilla.

The basic functionality of LISTING is incorrect in Opera and MS IE, but CSS works. In Opera the basic functionality is incorrect also to the XMP element.

All new browsers for Windows 95 allow incorrect values to id and class attributes but MS IE 6.0 (needs Widows 98+) doesn't allow any incorrect value if it works in the standard-compliant mode. I tested some character escapes (for example #a\? {color:red} with id="a?"), which have worked in MS IE 6.0 and new Netcape/Mozilla browsers.

MS IE reads also @import rules, which are not at the beginning of the style sheets. Other CSS1-level ways to use style sheets (external, embedded and inline styles) work ok in MS IE and all modern browsers.

Certain rules are intended only to HTML-documents, but MS IE and Opera accepts them as to XML-documents. Some of them could work in XML, if the browser gets the xmlns-attribute or DTD-declaration (I explain this matter, when I handle attribute selectors).

In CSS2 has been added some media dependent features, which don't work properly in MS IE and Opera. I hande those feature with the @media at-rule.

The cascading order is different in CSS1 and CSS2 concerning the important rule. MS IE supports it according to CSS2 and Opera CSS1. Because I don't have find the possibility to test user style sheets in Mozilla, I don't know how it behaves concerning user style sheets. Even if Opera supports !important in general well, I have found some situations, where it doesn't work.

I have found, that changes to property values don't always work in browsers and they have difficulties in the cascading order. It is recommended to avoid changes. For example changing of background properties might cause problems.

Comments work ok in these browsers.

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

This rule must be in external style sheets at the beginning of the style sheet. The @charset is primary for XML-documents to define used character set. The same kind is the proposed @namespace at-rule, which I found in /res/html.css of Mozilla and /Styles/wml.css of Opera 7.0 Beta1. It is used together with proposed new CSS3 universal selectors. Concerning XML-documens it defines, which XML-namespace use the CSS. If the XML-document doesn't have a matching xmlns information, the CSS is ignored.

All of them support necessary media types screen and print. Indeed @media print works only partial in Mozilla, because paged media properties don't work. Media with the import rule (for example @import url(...) print;) doesn't work in MS IE, but works in Opera 5.1+ and new Netscape/ Mozilla browsers. Note, that MS IE 5.0 for Mac ignores everything, which is inside media blocks. Opera reads @import url(...); to all media types even if the LINK or STYLE element has the media attribute (MS IE has the same problem only with the STYLE element).

I have found, that table-layout:fixed related properties, which works in the screen media, doesn't seem to work in the printed media in Opera. It could help setting equal table cell width values even if in other respects it is unnecessary in the printed media.

Note that the full screen mode in Opera is so-called presentation mode, where the @media screen (concerns also the @media print) doesn't work, but it is possible to use @media projection for it! Other media types are for special devices and in my mind normal web browsers are not obliged to support them. At that respect Opera has full media type support.

According to the information Mircosoft they work in MS IE browsers starting from MS IE 4.0 for Windows, but the font file format must be either .eot or .ote, not an ordinary font file (for example .ttf). At this way the implementation is a little bit proprietary.

Netscape 4.x support instead a proprietary at-rule (@fontdef), which is not supported in Mozilla. @font-face is unsupported in Mozilla at least until 22.07.2002.

@page rule works relative well in Opera, because it is possible to set the size of the page, but named pages don't work. Indeed according to an e-mail :first might cause empty pages in Opera, but I don't have found this error in my tests. I explain paged media more thoroughly, when I explain paged media properties (orphans etc.).

Even if @page if not actual supported in MS IE, Microsoft informs that this at-rule can be used by print templates developed for applications that host MSHTML in MS IE 5.5+ for Windows browsers. In other words the browser needs an additional application in order to get this at-rule to work. This is in a way non-standard solution of this at-rule and related pseudo-classes.

They are well supported in Opera and Mozilla. Indeed newest versions of Opera don't support them for table cells like some earlier versions.

I have an example of the usage of this pseudo-class in an appendix page, where I have a list item test. It is supported in Mozilla Gecko and Opera 7.x+ browsers.

The basic universal selector (*) works overall good in all browsers, but Opera needs in attribute selectors the universal or element type selector (for example *[target] {...}), but the usage of universal selector with the attribute selector cause a problem to MS IE 5.0 (it renders them as * {...}). Mozilla Gecko and Opera 7.x+ browser supports also into CSS3 proposed new universal selectors (*|* etc.; if no default namespace has been specified, *|* is equivalent to *; otherwise it is equivalent to ns|* where ns is the default XML namespace). The same basic idea is also for attribute selectors (for example [*|att]). Namespace-related universal selectors are commonly used with the @namespace at-rule. MS IE 5.5 use in XML instead of | the sign \ (for example html\img and html\*), when the system is proprietary.

Element + class(es) type selectors don't work in Opera 3.x browsers. They work buggy also in all Windows versions. For example the th.a.b.c should match with <th class="a b c"> but not with <th class="c"> as it does in MS IE browsers. Among class names a, b and b should be mentioned but MS IE takes account only the last name of in the list. According to Erich Mayer combined class selectors don't work in MS IE for Mac.

In principle this kind of selectors should be used only in HTML-documents and in XML should be used instead attribute selectors. MS IE doesn't however support in corresponding attribute selectors, but HTML-rules work also in XML (I explain this matter, when I handle attribute selectors).

MS IE accepts also illegal names to class selectors.

The first CSS2 level selector works also in Opera 3.x browsers. I tested h2 + h3 with Opera and it worked, but a list test didn't work in Opera 5.12 like it worked with Mozilla and Opera 6.01 Beta1.

Attribute selectors work well also in Mozilla Gecko and Opera browsers in attribute lists, which use ~, for example td[class~="a"] code{color:red}, which match for example with <td class="a b c">. In combined rules, which use the | (for example td[class|="a"][id="a"]) Opera ignored the latter attribute selector (the previous mentioned rule should not match with <td class="a-b-c" id="b"> like it does in Opera). In general attribute selectors work in Opera 4.x-6.x, but they need always the universal or element type selector (for example a[target] {...}). Opera 7.x doesn't need additional selectors. Attribute selectors don't work in all cases in Opera 4.x-6.x (for example font[color="red"]{color:blue} doesn't work).