In Opera and MS IE the font-size is not inherited from the BODY element to table elements. Indeed this doesn't mean that Opera has necessary a bug in this matter. The reason why some font-related properties are not inherited to all possible elements is commonly the fact that some elements have predefined font-related properties in the default settings of the browsers. The quantity of predefined elements is browser-dependent. Because the quantity of predefined elements is unknown, it is reasonable to define for all possible element exact properties and don't rely on inheritance.

By using td {font-size: inherit} together with body {font-size:25px} caused with Opera smaller font size as the the font size of the BODY element. Because of this reason some browsers need more CSS than some other browsers. It doesn't had any affect with MS IE. In my tests the value inherit works in Mozilla 1.1, but it has not worked in all relative new builds (Mozilla 0.9 (date 20010505)) and Netscape 6.2.1; worked however in Mozilla 0.7) because the following CSS changed the border-width property of TH and TD elements in these browsers:

body {border: 10px solid black;} table, tbody, tfoot, thead, tr, td, th {border: inherit} /* doesn't work without defining at least the TBODY element, because TBODY etc. are logical parent elements of TR elements */

Mozilla Gecko browsers use as if opposite to inherit -moz-initial in the /res/quirk.cssorder to disable the natural inherintance in order to emulate the buggy behavior of Netscape 4.x series, when the browser works in the quirks mode.

Because MS IE handles BODY and HTML elements like the FRAME element, it renders borders to those elements incorrectly.

Mozilla 1.1 doesn't render randomly borders for all table cells in huge tables. This problem is not in some earlier builds of Mozilla.

Opera 4.x-6.x has incorrect rendering in table rows, which have the attribute colspan. If nearby table rows have different quantity of cells, Opera can't change the border style. In the top of this table cell on the right should not be the top border, but Opera continues the bottom border of the left cell, which is above this cell to the end of the table row. This cause the top border to this cell. This matter has been fixed in Opera 7.x. I have found, that images needs in Opera border-width:0 to avoid visible borders (border:none should do the same; I have not checked this matter in Opera 7.x). Webrewiews informs also a small bug.

MS IE 5.5 for Windows calculates all box dimensions incorrectly. Presumably MS IE has just converted HTML 3.2 calculating principles directly into CSS. That means, that MS IE should create a total new rendering engine, because this is a basic level bad bug. The author of the CSS1 Master Compatibility Chart has not read thoroughly CSS-specifications, because he has not noticed this bad bug.

According to an e-mail MS IE 5.0 for Mac renders box dimensions more according to the CSS2 specification than the MS IE 5.5 for Windows. I handle calculating of box dimensions more thoroughly in the page below. Microsoft has fixed the calculation of containing box dimensions in the 6.0 series, if certain DTD are used, when the browser works according to standard-compliant mode. The DTD-switch works well except tables

Mozilla Gecko browsers use also a DTD-swicth. They calculate in the strict mode the width property according to CSS specifications but not with table elements. Also sometimes Opera renders in tables the width incorrect.

Opera 4.x-6.x calculate min-height like MS IE Windows the property height (this matter has been fixed in Opera 7.x). It doesn't seem to work with fixed positioned elements (the property height works like min-height and the property min-height doesn't work at all). I handle calculating of box dimensions in the page, which is mentioned below. According to the own information of Microsoft, MS IE 6.x for Windows will support partially min-height in tables.

I don't have any situations, where MS IE 5.5 supports margin:auto but it works in MS IE 6.0 for Windows. This property works in Opera even with the element HTML. It doesn't work in work in MS IE Mac in all situations even if Webreviews informs so. According to tests the Mac IE 5.0 works however better than the Window IE.

Opera 5.12 has a bug concerning shorthard properties, which have the value auto. margin:10px auto 10px auto works and it is not necessary to write margin-left:auto; margin-right:auto; margin-top: 10px; margin-bottom:10px;.

Using padding cause box dimension problems, because MS IE calculates block box dimensions incorrectly. In order to avoid them, it is more reasonable to use margin to the child-element and no padding to the parent-element. Browsers implement at various ways collapsing margins incorrectly (I have a test case for this).

The property clear is used with float. MS IE and Netscape 6.1 renders this incorrectly. When the clear:left/right/both have been used they move later content before the earlier content (this is fixed in Netscape 6.2.1 and corresponding Mozilla). MS IE and Netscape don't position floating elements always as high as possible. MS IE has also some other minor broblems. I have some screen captures in my CSS-site. The problem in Opera is that if the width is undefined, Opera might render floated elements very wide. This is actual a bug in the specification, because it doesn't define how browsers should behave if the width is undefined.

I have found any effect, when I tested the property clip in Opera 4.x-7.x, MS IE and Mozilla.

The property overflow works quite well in MS IE and Mozilla Gecko browsers except that overflow:auto cause in many situation two scroll bars even if only one is necessary. MS IE support also properties overflow-x and and overflow-y. Mozilla use corresponding system in the UA CSS file /res/forms.css for the SELECT element (overflow: -moz-scrollbars-vertical; in principle also overflow: -moz-scrollbars-horizontal exists too). In my mind they are unnecessary, if overflow:auto could work well. Even if MS informs, that overflow-x and and overflow-y belong to some proposal, I don't find them in any proposal for CSS3. I list them as proprietary properties. Into CSS3 is proposed also the property resizer to do this task.

Opera 5.x-6.x don't support overflow values scroll and auto, but hidden and visible are supported (Opera 7.x supports all values). The value hidden is useful with table-layout:fixed to hide the content, which goes over table cells (MS IE use that value as default value with table-layout:fixed). I handle in my CSS-site these properties in pages below.

The overflow property seems to be supported limited for table elements. It doesn't seem to work with the height property in some Opera 5.x browsers (I have not tested in newest versions). MS IE and Opera 7.O Beta 1 support only values hidden and visible. It is reasonable to use it only by defining a block box with the element DIV element.

Note. A part of the information base on a development CD of Microsoft. I have not tested all informed properties or property values.

These are i18n (Internationalization) properties. MS IE doesn't support i18n by using the CSS2 direction property but the proposed writing-mode property. It supports also corresponding attribute dir, which is commonly used with the BDO element.

In addition MS IE supports International Layout, which it proposes to CSS3. Ruby-align etc. are related to the Ruby Annotation Module, which is a new module in the XHTML 1.1. Note, that the XHTML module will become to future specification, but CSS3 extensions are just proposals.

I18 features of MS have also the ime-mode property. An Input Method Editor (IME) allows users to enter and edit Chinese, Japanese, and Korean characters. The IME is an essential component for writing Chinese, Japanese, and Korean scripts. Even if MS lists ime-mode as proposals of CSS3, but I don't find it in any proposal of CSS3. I put list it as a proprietary property.

I18n-related properties includes also to CSS2-level new values of the property list-style-type, but only Netscape 6.x supports them.

Note. A part of the information base on a development CD of Microsoft. I have not tested all informed properties or property values.

MS IE supports at some level all CSS1 values, but display:list-item is rendered only partially. MS IE 6.0 supports properly all CSS1 level display types + CSS3 level display:inline-block, which is not supported in other browsers.

Mozilla use in the system CSS-file (html.css) all HTML 4.01 table model related display values. All basic table model related values work, but it doesn't really support all values, because the HTML-functionality of some table elements don't work. Neither values inline-table, compact, marker and run-in work.

Opera has the widest support and it support compact, run-in, basic table related values + display:inline-table. Because Opera doesn't support all elements in the HTML 4.01 table model, all table related values are not supported. In addition Opera doesn't support display:marker.

Position:absolute works incorrect in all browsers. If they are defined to the bottom, browsers (according to an e-mail also MS IE 5.0 for Mac) put the to the bottom of the viewport, no to the bottom of the containing block. According to the Opera Software MS IE 5.0 doesn't handle this property always correctly. Opera and MS IE have problems, if the HTML element has border and padding properties (I made a test case in order to show problems).

Position:fixed is positioned best in Mozilla 1.1 but some earlier versions have problems with it. Opera has several bugs, which I handle in a special page.

Earlier version of Mozilla had several bugs with position:fixed. For example Netscape 6.1 can't keep the position absolutely the same. MS IE Windows doesn't support position:fixed. It is supported in MS IE Mac for 5.0 but not as well as in Opera 6.x. MS IE 5.0 for Mac and Opera 5.12 have problems with the IFRAME element.

The z-index property works flawless only in newest Mozilla. MS IE has problems with some embedded objects (like OBJECT) and Opera 4.x-6.x also with form control elements (Opera 7.x has not problems with form control elements). These browser can't set other elements above previous mentioned elements.

Opera 4.x+ supports proprietary position:deck in /Styles/wml.css to emulate the card element of WML. Opera use also some proprietary properties to implement WML, but this matter in the only, which is intended only for WML. It can't be used in HTML-pages, because linking doesn't work.

Opera doesn't allow dynamic changes with dynamic pseudo-classes. Opera and Mozilla support in certain circumstancees incorrect the visibility property. This property has also as special value, which is designed only to tables.

The vertical-align property cause serious rendering problems in MS IE, when it used to the TD or TH elements. It works a little bit buggy in Opera 5.x-6.x because it is not always rendered ok (I have not found problems in Opera 7.x).

Opera 4.x-6.x supports all content values except url(). It works in Mozilla and Opera 7.x but only images are supported. It is the only browser, which support automatic numbering (indeed I found from the UA CSS file /res/html.css of Netscape 6.2.1 a proprietary definition counter-reset: -html-counter 0, when automatic numbering might work according to some proprietary method). Opera 5.1x-6.x don't support generated content for table elements, which worked in some 5.x versions. The property content works only with pseudo-elements :before and :after. Grouped rules don't work with them in Opera (for example cite:before, cite:after {content:open-quote; quotes:"<" ">"})

Opera use in this note mentioned proprietary CSS in many UA CSS files, for example in /Styles/wml.css in order to implement linking and rendering of images in WML-documents (in addition WML use also a proprietary property value to the position, which is not used in other UA CSS-files). The same CSS can be used (but not recommended) to implement linking in XML-documents. Opera Software has changed several times names of XML-related properties (in Opera 4.x they were -link-set, -link-use and replace), why they are extremely unreliable to use or names in all version of Opera 4.x+ must know. -o-link corresponds -set-link-source/ -link-set. -o-link-source corresponds -use-link-source/ -link-use.

Note. A part of the information base on a Web page of Opera Software. I have not tested all informed properties or property values.

Mozilla support CSS2-level list-style properties but MS IE and Opera just CSS1 -level list styles.

Even if MS IE supports in some respect i18n, it doesn't support it to the element Q. In Opera and Nestcape with other elements than Q, the property quotes works only together with pseudo-elements :before/:after and content:open-quote/content:close-quote.

If nested elements use the property quotes Opera doesn't render quotes correct. Grouped rules don't work with them in Opera (for example cite:before, cite:after {content:open-quote; quotes:"<" ">"}). Opera 7.0 Beta 1 they work partially but the property itself doesn't sometimes work at all.

Even if many paged media properties work best in Opera, it has some minor bugs and missing features. Opera doesn't support the marks property. The final width property, which is set to the page doesn't always match to the preview.

Page-break-inside:avoid seems to have difficulties in tables, if the table has rowspan attributes, but overall it works fine. Even if Opera software doesn't promise to support named paged they worked in the print preview in my tests, but Opera can't change the actual printing orientation of the printer (the user must change it) but just set the page into landscape/ portrait mode.

Note that margin properties for the BODY or the root elements are added to the page margins. In addition the printer leaves some empty space, where it doesn't allow to print. Page margins start after that value.

Page-break-after and page-break-before properties work relative well in MS IE 5.5+, Opera 4.x+ and Mozilla 1.0+. In tables it is reasonable to use them between table rows. I have found, that at least values always and auto seem to work, but avoid doesn't seem to work. Also right and left had effects in MS IE and Opera, but I don't know if the effects are correct (I tested all values with the h3 element).

@page is not directly supported in MS IE. (according to Microsoft the rule can be used by print templates developed for applications that host MSHTML; attributes such as size and margin, which are not explicitly supported, are exposed as expando properties in these applications). 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 properties.

Even if paged media works in Opera relative well, in general paged media doesn't work as well as the screen media. Especially designers of Netscape have much to do get better results in the paged media because any of the possibilities to control page breaks don't work. Paged media properties don't work in Mozilla. According to an e-mail paged media will be supported in Mozilla 1.1.

The first estimation concerns how many element background properties are supported and how well basic color and image definitions work. At this mean the widest and least buggy implementation to the background properties is Mozilla, because it supports them to most form elements. Opera 4.x-6.x has the poorest implementation of form elements (Opera Software admits it fairly), but even Netscape could have a little bit better implementation. Opera 7.x support background properties for form elements but in Opera 7.0 Beta 1 background images works just randomly.

The bug in Opera 5.12 concering keyword values (for example center and center center) to the background-position is fixed in Opera 6.0 Beta 1.

Background-attachment:fixed works in MS IE only for elements HTML and BODY but in Opera and Mozilla wider. Opera 6.0x has some bugs with it especially if background-position has been defined. This bug has not fixed in Opera 7.0 Beta 1.

MS IE renders fixed background images incorrectly to HTML and BODY, if borders are defined. In addition it works in Netscape very buggy especially with repeated images (it doesn't work at all with both directions repeated images). Opera allows to set fixed background images also to other elements than HTML and BODY. In addition it supports background-position-x and background-position-y, which Microsoft informs as proposals to CSS3, but I don't find them in any working draft. I list them as proprietary properties. Because the same result can be achieved with two values to the background-position property, it is no reasonable to use them.

The background-color value can be also transparent, when the color of the parent element shine through. This cause problems at least with links. MS IE and Netscape might need this value to image links (a:link img, a:visited img {background-color:transparent}) even if the background color of underlying element should as default shine through. This happened in my site inside DIV elements, which have links. The unvisited link, which had an image had white background according to the BODY, but the background color of the parent element is #ffc. Setting sometimes certain background color and sometimes transparent color cause problems (most to Opera) and dynamic pseudo-classed don't work as they should. In Netscape/ Mozilla can use also a proprietary value invert, which these browser use in their UA CSS files (also some proprietary UI colors are supported)

Even if the validator of W3C suggests to set always the background-color property if the color property is set, this is not always reasonable. It is enough to set the background-color property to the element BODY and set text colors to work well with the background-color of the BODY.

Opera supports proprietary Netscape's named 140 colors at least in the 5.x series, but the 3.x seriers supports only 16 color keywords, which represent 16 first Windows colors. Even if the CSS2 specification allows to use proprietary keywords, it is better to use instead of them hexadecimal or RGB-values. All three browsers support UI colors, which I handle in another connection.

The property filter is for graphics to control the graphics mapping. It is one of the special CSS properties for Scalable Vector Graphics (SVG) 1.0 Specification. Even if Microsoft says that filter belongs to proposed feature of CSS3, in CSS3 filter is totally another property, which doesn't have anything to do with the implementation of MS IE except that they have the same name and the usage of MS IE and SVG at some level resemble each others. Property value of MS IE are maximal way proprietary (they start with progid:DXImageTransform.Microsoft.). That's why supporting the property filter in not an implementation of a part of the future CSS3 specification but Microsoft simple lies. On the base of a script for MS IE 5.5 can set only one effect for one element.

Note. A part of the information base on a development CD of Microsoft and an e-mail. I have not tested all informed properties or property values. The task of the property accererator is unknown for me.

Font families can be increased at least in MS with the @font-face at-rule.

Browsers render relative font sizes from xx-small to xx-large really differently. Netscape has almost fully consistent behavior.

The font-size-adjust could give more exact control to the used font-sized, but it doesn't work yet in any browser.

Using font-variant:small-caps uppercase characters should be higher that lowercase characters, but they are as big in MS IE 5.5. This matter is fixed in the 6.x series.

Opera and Netscape support text-decoration:blink, which is necessary to support to have a proper CSS-implementation. Tables have a special value to the text-align property, which is not supported.

MS IE supports also some working draft level and proprietary text-related properties like text-justify and text-underline-position, which are like an extensions to the text-align and text-decoration properties. CSS3 properties are listed in the CSS3 Module: Text and most of them also in the International Layout documentations.

Netscape/ Mozilla support some proprietary values in the UA CSS files for the text-align property in order to define default presentations for some elements (-moz-center for CENTER and start for INPUT).

Note. A part of the information base on a development CD of Microsoft and from an e-mail. I have not tested all informed properties or property values.

MS IE doesn't support white-space:pre, which emulate the behavior of the element PRE. Instead it supports proprietary or proposed line-break, word-break and word-wrap properties. The property word-spacing is supported in MS IE Mac. MS promise to support them in Windows browsers in the 6.x series. I have found, that some proprietary extension don't work in MS IE 6.0 in the standard-compliant mode (tested with the scrollbar-base-color property), which might concern also the word-wrap property. Properties word-break and line-break are proposed in the International Layout proposal.

Opera accepts a non-standard value for the CSS2 white-space property, namely white-space:-pre-wrap. This value is exactly like white-space: pre with the exception that lines will wrap if wider than wider than the containing box. Opera use it as UA CSS for example in /Styles/email.css. It can be also used in XML-implementations like most other UA CSS (for example -use-link-source).

Netscape/ Mozilla use quirky word wrapping for the PRE element by using propietary value -moz-pre-wrap in order to emulate the buggy behavior of Netscape 4.x series, when the browser works in the quirks mode.

Note. A part of the information base on a development CD of Microsoft. I have not tested all informed properties or property values.

MS IE doesn't fully support the separate borders model, because border-spacing and empty-cells properties don't work (they work properly in Mozilla and Opera). Border-collapse:separate works only as opposite to the border-collapse:collapse, when it is possible to override the collapsing border model. Border spacing must define in MS IE by using the cellspacing HTML-attribute (as default the value is the same as cellspacing="2").

Mozilla 1.1a supports border-collapse: collapse but all previous versions, which I have tested doesn't support it. The implementation is however sometimes a little bit messy but less than in Opera 5.x-6.x (it is not messy in Opera 7.x).

Opera supports both table border models, but if the border-width property varies when using the collapsing border model, it renders borders a little bit messy. The text-align property has a special value to table cells (text-align:<string>), which is not supported in Opera (neither in any other browser).

Note. A part of the information base on a page of the Opera Software.

The property caption-side doesn't work in MS. Even Opera Software informs, that the caption-side is not supported, it is supported in Opera. Indeed to set it to bottom cause problems to Opera, if the TFOOT element is used.

The functionality of table-layout:fixed is best in Opera it the screen media, because it allows to scroll forward a page, which is not totally downloaded. Opera interprets this property very strict. MS IE and Netscape might add the quantity of columns after reading the first row, if they are in the first window area. The fast table layout model has however some matters, which must remember (I handle them in my CSS-site). Opera seems not to support this in the printed media.

Some of values of cursor are supported in Mozilla and MS IE, but not all. Opera 7.x has full support. I have an example of one of them. Overall user interface properties works fine in MS IE except missing implementation of the outline property (Mozilla use proprietary CSS to define it). Into CSS3 is proposed some extensions to the cursor property.

Behavioral extensions to CSS (BECSS) are proposals to CSS3 and they react to movements of the cursor triggering events.

MS IE 5.5 has proprietary extensions to the user interface like scroll bar properties (for example scrollbar-3d-light-color) and zoom. In my mind the zoom property is unnecessary, because this matter should be handled from the user interface. Opera has zoom from 20-1000%and it doesn't need this property. I have found, that some proprietary extension don't work in MS IE 6.0 in the standard-compliant mode (tested with the scrollbar-base-color property).

In general don't resist proprietary UI properties, because they are not harmful to other browsers. There should however to be a standard method to validate proprietary user interface extensions properly. I have a proposal concerning this matter in a page, which handles MS IE 5.5.

Note. A part of the information base on a development CD of Microsoft. I have not tested all informed properties or property values.

System fonts work only in MS IE 5.5+, Netscape 6.x+/Mozilla (I don't know the first evaluation version, where they have started to work) and Opera 5.10+ (they are not supported in previous versions). Netscape/ Mozilla use also a proprietary UI font (font-family: -moz-fixed;). Normal browsers don't need them. Instead of normal web browsers, they are more reasonable in handheld devices, which have limited memory like WAP phones. Into CSS3 is proposed some extensions to them.

In principle User Interface (system) colors can be used in all color-related properties. I have tested them with the background-color property and they work in MS IE and Mozilla. To support system colors is added to Opera 5.10. Mozilla/ Netscape supports also proprietary system color (-moz-Field, -moz-FieldText).

Mozilla use quite wider range of UI colors, which belong to CSS in the /res/forms.css, which it use to define default presentations to form elements. It use also in that file some proprietary UI colors (for example -moz-field).

In my tests outline to :focus and worked in some builds of Netscape. They are useful especial with dynamic pseudo-classes, because the usage of normal borders with them might cause drifting elements. Switching outlines on and off should not cause the document to reflow.

Indeed MS IE and Netscape has build-in implementation of outlines (dotted outlines) to elements, which has the user focus (only this state needs the outline property) and they don't necessary need the CSS outline property.

Mozilla use proprietary CSS properties to set some UI default settings to HTML elements in /res/html.css, /res/forms.css and /res/quirk.css files. For example -moz-user-focus and -moz-outline are for user focus states (the latter use a proprietary invert color value). In addition of proprietary properties, Mozilla use also some proprietary pseudo-classes (for example :-moz-focus-inner) to get more exact control to user focus states. It doesn't need CSS3 or so-called widget libraries to define presentation to form elements, but in future CSS3 will offer necessary standard UI properties.

Note. Even if all listed proprietary properties can apply for form element, some of them concern in the UA CSS files of Netscape/ Mozilla only or in addition of form elemens also other than form elements (for example -moz-box-sizing: border-box is in the res/quirk.css for the element HR; a ccording to CSS3 this could be defined with box-sizing: border-box).

I got an e-mail about some properties, which use the -moz- prefix. The politics behind -moz-box-sizing: border-box is that until these new values become standardized as CSS3, they can't presume to make these properties without the -moz- prefix. When they are made standard, the functionality might be slightly different for a given CSS property or value, so this gives them separate "CSS namespaces" to play with in implementing CSS as it is evolving. In fact -moz-box-sizing: border-box and some other resembling properties are experimental implementations of CSS3. Accoring to an e-mail -moz-outline is used because supporting of outline according to CSS2 was failed. The only reason why it Mozilla org. did not turn it off entirely is because the UI uses it.

In general proprietary extensions of Netscape are not intended into general usage but just to define necessary functionalities in UA style sheets. The problem in UA CSS files are that some properties are defined as important (!important), when authors can't change values, if they don't know which properties are defined in UA CSS files as important. This is questionable usage of UA CSS! 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, which defines presentations for (X)HTML elements.

Also in Opera proprietary features are primary intended to use only in UA styles heets (they are used for example in /Style/wml.css and /Styles/email.css).