Table of topic groups > Front page of CSS-guide > Extra pages > B Which problems are the CSS2 specification

B Which problems are the CSS2 specification

Topics

• Common
• The content width
• Inline blocks
• Centralization of blocks
• Forms
• Collapsing table borders
• Viewport
• A plug-ins application to CSS3?
• Fixes in CSS3

Common

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

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.

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

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, 10.2 Content width: the 'width' property, 17 Tables, 17.6 Borders; 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.

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

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}

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.

Forms

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.

In addition they have a small problem rendering borders (look at the page Backgrounds and borders, 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.

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

Viewport

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.