You’re viewing an archive of outdated material. Visit The Web Standards Project’s updated site to learn about our current mission.
This is the second of a series of WSP standards-compliance reviews. As a matter of policy, the WSP provides thorough coverage of and feedback on interim releases of major browsers. The first was a review of Internet Explorer released in early November, 1998.
Opera Software has made a late but commendable attempt at implementing the CSS1 specification in the latest releases of their browser (Opera 3.50 and 3.51). Opera 3.50 is so far the best first implementation of CSS1 by any company and arguably the best implementation released today. However, Opera's implementation is in no way perfect, having a few mistakes of varying importance. This document presents the most glaring of these problems.
The uneven deployment of CSS1 in major Web browsers over the last two years has caused Web authors great frustration and expense, and has won CSS an undeservedly obscure and difficult reputation. As unfortunate as this failure has been for HTML in the recent past, the implications for XML in the near future are even more disturbing: lacking adequately mature CSS implementations, XML will generally be converted first to non-reusable HTML for display. This will retard the deployment of distributed XML applications, as the richest data will tend to remain on servers or decay quickly on clients.
Now that Netscape promises to release a comprehensive and thoroughly tested CSS1 implementation in the near future (which we will be examining in depth in due course), the WSP calls upon Opera Software to improve its implementation, letting Web designers, authors, application developers, and users build upon a single, robust foundation for Web presentation: CSS1.
width
Opera 3.51 has a number of major problems with the CSS box model.
The most serious of these involve width. Opera
incorrectly handles over-constrained box properties (i.e., when the
width, padding, border, and margins don't add up to the available
space). This is a serious obstacle to the use of
width. Both versions also misinterpret
auto margins on replaced elements, causing small
images that should have been centered or justified to instead be
enlarged to the size of the window.
auto values on the margins of
replaced elements
Opera 3.51's handling of floating elements threatens to make
floating elements harder for web designers to use and to encourage
the use of HTML tables for layout. Furthermore, Opera does not
follow the rules defined in the CSS1 specification for the vertical
alignment of floating elements and text surrounding them. It also
produces extraneous line breaks around floating DIVs.
Opera also has a number of problems with borders. Borders expressed in CSS are not supported on tables; the only support for table borders is with presentational HTML. Image borders and padding also do not work.
Opera also handles background and borders on inline elements incorrectly. It considers the inline element to include the line-height, and thus padding and borders of inline elements invade the inter-line spacing. This is incorrect. This problem is visible on the links in this page, where the background has extra padding above and below the link.
There are also two problems with background images. Tiling of background images should begin at the padding edge, but it begins at the border edge. Also, the top row and the left column of background images are repeated at the bottom and the right edges, causing background overflow. This can in fact be seen on this page.
Opera's CSS parser has a major fault in the error recovery code. The CSS1 specification explains very clearly how unrecognized CSS should be handled (i.e., what to ignore), but Opera does not follow this part of the standard. This causes documents designed for levels of the CSS specification not yet supported by the browser to render incorrectly.
Opera has problems with vertical formatting that cause web pages
to display incorrectly. The middle value of the
vertical-align property should center the middle of
elements with the middle of the parent element's text, not the parent
element's baseline (as it does in Opera 3.50) or the top of the parent
element's text (as it does in Opera 3.51).
Opera also handles line height incorrectly because it misinterprets the definition of font size. The font size is the height from the bottom of the lowest letter to the top of the highest letter, and therefore characters should never overlap if they are in a paragraph with the line height set to one. This does not happen in Opera. There is slight overlap between descenders and accent marks.
There are a few different problems with the interpretation of the selector syntax, the assignment of specificity and the sorting of the cascade. This set of problems is less visible than the others, but that does not imply that they are any less important.
The first problem is that descendent selectors in which elements
are selected as a descendent of BODY do not work if a class or id
selector is used to select body (possibly in combination with BODY).
That is, the following selectors do not work: BODY#home H1,
BODY.home H1, .home H1, #home H1.
However, the following do work: BODY#home, DIV#home
H1.
Secondly, the specificity of rules is calculated in base 10, rather than an arbitrarily large base, as required by the CSS specification. This causes the more complicated rules to be applied incorrectly.
Finally, Opera sometimes incorrectly overrides author stylesheets
when the text-decoration property is used on links.
This is a difficulty with the cascade.
Opera 3.50 only supports two of the four values for the
display property. It supports none and
block, but it does not support inline
or list-item.
inline is needed to allow a correct combination of
logical markup and display. For example, an unordered list should by
contained in a UL element, but the author may want that
list displayed on one line. The display value of inline
allows the correct combination of logical markup with style.
This document has manually numbered H3 elements. If the
list-item display type were supported for H3,
the UA might generate the numbering as with any other list, resetting
the counter at each occurrence of H2.
CSS2 introduces a number of new values for the display property; and as nice as it would be to see those implemented, we believe designers would rather see them postponed in favor of complete support for the CSS1 values.
CSS1 allows authors to associate multiple stylesheets with a document, allowing users to choose the most appropriate or pleasing.
For example, a designer could create a default "public" stylesheet for a body of documents, a second sheet suitable for intra-organizational or -departmental access to the same documents, and a third suitable for users who are visually impaired (using high-contrast colors, for instance). The mechanism is extensible to include transparent application of media-specific stylesheets: one for print, one for WebTV, another for hand-held device browsers - all without content redundancy. This document, for instance, written in HTML 4.0 Strict, is associated with three distinct stylesheets. Unfortunately, due to lack of support for this CSS1 feature, you are unlikely to have any choice but the default, or no stylesheet at all.
Among the primary design goals of CSS is to restore balance among the responsibilities the author, the user, and the user agent (UA; i.e., the browser) must share when negotiating the presentation of Web content under varying conditions. Opera has implemented two parts of this balance: it allows the user to turn off stylesheets with a convenient button and it allows the user to specify a user stylesheet (within the "Document Appearance" dialog box). However, these goals also require the exposure of alternate author style sheets, the ability to change user stylesheets quickly, and the exposure of a UA default stylesheet for each media type.
By not implementing a more extensive user interface for alternate and user CSS, Opera turns CSS from a language designed to balance user and author needs into a fundamentally user-hostile instrument. With users unable to interact with CSS easily, authors are not only entertained with the promise of reckless authority in matters of style, but are also tempted to create documents that lack structural markup and are thus meaningless with any stylesheets other than their own.
white-space
Support for CSS1's nowrap property would permit
retirement of the nonstandard NOBR extension and the
deprecated NOWRAP attribute, as required by HTML 4.0.
Control over whitespace preservation with the pre value
would help further abstract presentational considerations from markup.
The problems described above all show problems in the latest version of Opera Software's browser, Opera 3.51. Some problems we had initially discovered in Opera Software's first CSS implementation, Opera 3.50, were fixed between Opera 3.50 and 3.51. We present them here as a testament to the dangers of releasing a browser without complete testing, since Opera 3.50 will continue to be used by many users who do not find any reason to upgrade. If this user base is large enough (it probably will not be), web authors will be forced to accommodate the bugs of Opera 3.50 in their work.
width
Two of the most glaring width
bugs were fixed in 3.51. In version 3.50, the width
property is not supported on tables. Also in version 3.50,
the width of floats is treated as a maximum width rather
than a width, so the width is reduced to fit the contents. This
reduction is done after line-breaking, so the float is almost always
at least slightly too small.
Opera 3.50 does not support background images on floating elements. It also does not follow the rules for assigning widths (see above). Opera 3.50 also sometimes hides text behind floating elements.
Opera 3.50 has a strange bug which causes serious display problems when images aren't loaded. Fortunately, this was fixed in 3.51.
Another problem in Opera 3.50 that was fixed in 3.51 is the
handling of whitespace in the stylesheet. Opera 3.50 has trouble
handling tabs before selectors that contain pseudo-selectors (i.e.,
A:link or A:visited) because it uses
strange "logic" to replace the standard error handling
procedures. This "logic" determines that the A:link is
a misplaced property and value, so it treats a correct selector as
an error.
In Opera 3.50, in addition to the middle value
not working correctly, the text-top value of the
vertical-align property causes alignment with the the
highest text in the line instead of the text of the parent element.
Another, even more serious problem occurs with Opera 3.50's handling
of numeric values with the line-height property. Opera
makes the calculated values inherit, not the factor itself,
as is required by the CSS1 specification. This can cause text to
be totally illegible.
As Ian
Hickson's import test demonstrates, Opera 3.50 has various problems
importing stylesheets when they are linked across folders. It
also appears to totally ignore the media attribute
of the LINK element in
HTML,
thus causing stylesheets that are destined to be read only by text
browsers (such as Lynx) to
be acted upon. (Admittedly, this is part of HTML 4.0, which Opera
does not claim to support, but it is an important part of CSS.)
This can cause havoc with the layout of pages.
Although there are still a few problems with importing in Opera 3.51, most problems have been fixed. The remaining problems relate to very complex issues. It would be good to correct them, but they are not so high a priority.