Tutorials Bugs Masterclass Free stuff Test pages Proposals

RichInStyle.com bug guide - Opera 4.01


Several bugs have been introduced, whether by accident or design, into Opera since v3.6. These bugs are marked in orange.


Opera has been tested for support for CSS 1 and CSS 2. However, only CSS 2 bugs are noted - not support; when a CSS 2 feature goes unmentioned, it is unsupported.


These have been sorted into categories. This should make it easier for to you find whether the property that you want to use works.

While it should be easily apparent what area you are using, and therefore which section you should read, everyone uses Section A and Section B, so therefore everyone should read these sections.

Bugs by type

Topics to be found in this part of the bug guide

Part 0 - Core issues: everyone must read

Section A - Bugs relating to attaching style to pages (4 bugs).

Section B - Bugs relating to associating style with elements (7 bugs).

Section C - Bugs relating to key concepts (7 bugs).

Section D - Bugs with units (1 bug).

Part 1 - Topic related issues - must read if you use the section involved

Section E - Color and background bugs (6 bugs).

Section F - Font bugs (11 bugs).

Section G - Text bugs (16 bugs).

Topics to be found in part 2 of this bug guide

Section I - Border bugs (2 bugs)

Section J - Float bugs (3 bugs)

Section L - Display and whitespace bugs (13 bugs)

Part 2 - Element related issues - must read if you use the elements involved

Section M - Table bugs (4 bugs)

Section N - HR bugs (3 bugs)

Section O - Form bugs (2 bugs)

Section P - List item bugs (7 bugs)

Part 3 - Error correction bugs - bugs, but inconsequential unless you produce invalid style sheets

Section Q - Error correction bugs (51 bugs)

Part 4 - Other problems (not bugs but still problematic)


Missing colors

Total bugs = 4 + 7 + 7 + 1 + 6 + 11 + 16 + 2 + 3 + 13 + 4 + 3 + 2 + 7 + 51 = 137.

Part 0 - Core Issues - MUST READ

Section A - Bugs relating to the attachment of style to pages

Alternate style sheets
Bug 1: unsupported

Opera does not support alternate style sheets.

Preferred style sheets
Bug 2: treated as persistent

Opera treats preferred style sheets as persistent (those where a title="" is specified on the LINK element) - rather than only applying one preferred style sheet (as is correct), it applies them all as persistent. This won't affect you however, unless you include multiple preferred style sheets in a page, which is inadvisable anyway.

style attribute
Bug 3: wrong specificity

According to the CSS specification, the style attribute has specificity of 100, and thus style sheets can override inline style. Opera doesn't apply this, instead giving the style attribute effectively infinite specificity. This should not be fixed, even though it is a bug, because it is what every reasonable CSS author would expect.

Bug 4: not parsed as CDATA

The style attribute uses CDATA, and so therefore color: red should result in a red color. Opera fails to convert character references and hence this won't be so.

Section B - Bugs relating to the application of style to elements

ID and class
Bug 1: certain valid characters not allowed

Although Unicode characters "161 and above" are permitted in the nonascii macro, Opera does not permits them all. This excludes such characters as the £ sign. However, I strongly recommend that you stick to letters of the alphabet and numbers (remembering of course that classes and IDs cannot start with numbers).


Opera only supports the CSS 1 way of combining classes and pseudo-classes - .class:link is o.k., but :link.class is not.

Bug 2: :hover always treated as occurring after :link and :visited

Opera 4 incorrectly treats :hover as always occurring after :link and :visited. This is incorrect since :hover, :link and :visited have equal specificity, and as such :hover {color: red} :link {color: blue} :visited {color: blue} should result in hovered-over links being blue at all times. In Opera, however, it treats :hover as occuring after the later declarations, and as such will allow it to override them.

Bug 3: only supported on anchor elements

Opera 4 only supports the :hover on anchor elements - not on all elements (such as P) as it should, and not on forms (because it doesn't support form styling at all).

Bug 4: doesn't work properly

Although Opera's parsing (below) indicates that it supports :active, exhaustive testing failed to elicit any kind of support for :active.

Pseudo-class combinations
Bug 5: dynamic pseudo(s) disregarded and applied to link pseudo

Opera destroys pseudo-class combinations. For example, A:link:hover, which should apply to hovered-over unvisited links, is instead applied to A:link. However, the effect of this is lessened somewhat by the fact that it gives such selectors that use such combinations lower specificity than any other selector that also matches a given link. Thus :link {color: red} would be applied over #id #id #id :link:hover {color: blue}, but in the absence of :link, the selector would be applied.


Opera only supports classes and IDs before the pseudo-element (.class:first-line), and not :first-line.class, which is valid CSS 2 (although invalid CSS 1).

The child combinator (>)
Bug 6: given specificity of 1

Even though combinators have specificity of 0, Opera gives the child combinator specificity of 1. This shouldn't cause any problems, but given BODY > .class {color: red} P.class {color: green}, red would be the result, not green.

The adjacent sibling combinator (+)
Bug 7: multiple adjacent sibiling combinators incorrectly handled

If you include multiple adjacent sibling combinators in a selector, Opera handles it incorrectly. For example, P + P + P would match the second and third P element in <P></P><P></P><P></P>, not just the third as it should. However, P + H1 + P wouldn't match them in Opera, so it is at least checking that the elements occur, if not in the right order.

Section C - Bugs relating to key concepts

SGML comments (<!-- -->)
Bug 1: destroys CSS unless followed by line break

Opera will ignore <!--selector {color: red}, unless you follow the <!-- with a line break. (As in <-- P {color: red}).

Bug 2: only works on inherited properties and vertical-align

Inherit only works on inherited properties and vertical-align i.e., not margin, padding, width, height, borders).

Bug 3: doesn't work on links

Inherit doesn't work on links (e.g., :link, :visited {color: inherit}).

Backslash (\)
Bug 4: not supported

Although the CSS spec states that the backslash can be used (e.g., to refer to otherwise invalid characters), Opera doesn't support this.

Bug 5: selector productions treated as tokens

According to the CSS spec, tokens are valid anywhere between tokens, Opera treats most selectors productions as tokens instead of the tokens themselves. For example, instead of treating P.class as three tokens - 'P', '.' and 'class', it treats it as two, only permitting a comment in P/* comment */.class, but not P./* comment */class. Equally so for IDs - P/* comment */#id is o.k. in Opera, P#/* comment */id is not. Similarly for pseudo-classes and pseudo-elements - before the ':' but not after.

Bug 6: not permitted inside rgb()

Opera does not allow comments inside rgb(). For example, rgb(/* */100, 100, 100), which is valid since the comment appears there between FUNCTION and NUMBER, will result in the rgb() being ignored in Opera.

Section D - Unit bugs

Bug 1: destroyed

Opera treats 1ex as 0.5em, which is very badly buggy, given that it varies from font to font, and it can be as much as 3/5, or as little as 1/3.

Part 1 - Property-specifc issues - must read if you use the elements involved

Section E - background and color bugs

Background concepts
Background attachments
Bug 1: destroyed on all but BODY and HTML

Opera destroys background-attachment on all but BODY and HTML. When background-attachment is used on any other element, it will fail to render the background image (or at least render it initially, but later lose it). See test page.

Background images
Bug 2: none doesn't override background attribute

According to the CSS-1 specification, HTML formatting attributes form the start of the style sheet with a specificity of 1. Thus BODY {background-color: green} and <BODY bgcolor="#FFFFFF">, then the background-color would be green. Opera (and other browsers) apply this correctly for colors but not for background images. Thus BODY {background-image: none} <BODY background="back.jpg">. Both Opera and IE 3 (even when background-image is changed to background:) do this wrong, displaying the background image.

Bug 3: shorthand doesn't reset background image

Although the background property sets all of color, image, attachment and position (if any is not specified they are reset to their initial values), in Opera it doesn't - background-image: url(back.gif); background: red would still result in a background image.

Bug 4: not supported on inline elements

Opera doesn't support background images on inline elements. This emphasizes why you should always specify a color with image.

Bug 5: avoid animated

You are strongly advised to avoid using animated backgrounds with Opera, since it doesn't animate them, instead rendering them next to the element .

Bug 6: transparent doesn't work over HTML background

Given the following code:

<TR class=x bgcolor=black>

, TR.x {background: transparent} wouldn't work to override it. However, TR.x {background: red} TR.x {background: transparent} would make it red.

Section F - font bugs

Font concepts
Font families
Bug 1: some fonts refused

Opera refuses to use some fonts (chiefly, it seems, those that lack a full complement of upper and lowercase glyphs).

Bug 2: multiple font lists not supported inline

When a font list is specified inline and the first is not available, Opera will not use the second or subsequent ones. For example. style="font-family: notAvailable, Arial" wouldn't be honored, and neither would style="font: 12px notAvailable, Arial".

Font sizes
Bug 3: smaller and larger

When an inherited font size corresponds to one of the seven font size keywords (e.g., large) and smaller or larger is specified, then the result should be the next larger font size keyword. In Opera it is not, although the difference is never more than a couple of pixels, so this bug is not serious. If you would like to see a demonstration, here is the appropriate test page.

Bug 4: font sizes in percentages on elements that are differently sized to normal, they are related to one pixel less than the default value for normal text rather than to the inherited value

When you specify a font size as a percentage on the elements that default to non-'normal' font sizes (TT, CODE, PRE, H?, BIG, SMALL, etc.), Opera relates it to one pixel less than the default size for normal text rather than to the inherited value.

Font styles
Bug 5: oblique

Opera applies italic instead of oblique - oblique should only match oblique fonts whereas italic both italic and oblique.

Font weights
Bug 6: bolder and lighter

These doesn't always apply the next boldest or lightest font - they seem to miss out steps without reason. For example, with MS Arial, which has four weights, corresponding to 100-500, 600, 700-800 and 900, bolder from 600 gives 900, whereas correct would be 700-800. Similarly, lighter than 700-800 gives 500, not 600.

Bug 7: height of line boxes that contain replaced elements wrong

The CSS spec states (although in rather more words) that the height of a line box is that of the tallest box in it. Although Opera correctly follows this for non-replaced elements, it does not do so for replaced elements. This is so even if line-height > height of the image (although if line-height is much larger, it is not so). This is only a glitch (see test page demonstration) rather than a major bug, since pages won't be destroyed, but it is a bug nonetheless.

Bug 8: absolute line-heights of following line 'inherited' back up to previous line and down to following line

For some reason, Opera 4 will 'inherit' inline absolute (as well as pixels) line height declarations back up to the previous line. Thus if you specify line-height: 200px on an inline element, it will also affect text on the previous and following lines.

Bug 9: line heights in percentages have one pixel deducted from the calculated value

When you specify a line height as a percentage in Opera 4, it will deduct one pixel from the calculated value before rendering it. Thus given a font size of 20 pixels, line-height: 100% would result in a line height of 19 pixels. This doesn't apply to line heights in ems or in <number> (e.g., line-height: 1.2).

Information regarding normal

Opera applies line-height: normal as line-height: 1.2.

Property-specific bugs
Font property
Bug 10: destroyed when line height specified inline

Opera will ignore inline font declarations that specify a line height (e.g., style="font: 12px/24px Arial").

Bug 11: normal destroys font declarations

When you specify 'normal' on a font declaration (e.g., font: 16px/normal sans-serif), Opera will treat it as if there were no font declaration at all. This is not a problem, however, since Opera will (correctly) treat font: 16px sans-serif as resetting line-height to normal.

Section D - text bugs

Bug 1: inherited to block descendants

Opera inherits text-decoration to block descendants, whereas the CSS spec states it is only 'inherited' to inline descendants.

Bug 2: buggy when applied to line boxes that have differing font-sizes in the line box

When text-decoration is applied to line boxes (i.e., lines) that contain text at different sizes in them, some truly horrendous bugs are triggered whereby the text has the text-decoration applied too high, thus looking a horrendous mess, and the child text has its text-decoration applied twice (three times if two values are specified on text-decoration and four times if three are specified), thus looking even worse.

Bug 3: buggy when applied to line boxes that have differing vertical-aligns in the line box

When text-decoration is applied to lines that contain text that is vertically aligned differently through the line, bits of the text is chopped off, extra text-decoration is applied, it is all applied in completely the wrong place, the vertical-align is ruined, and the whole thing looks a horrendous mess.

Bug 4: not applied with the thickness of the ancestor

Although Opera correctly applies text-decoration with the color of the ancestor elements, it does not apply the thickness implied by the ancestor. For example, P {text-decoration: underline; font-size: 100px} should 'inherit' an underline to SPAN {font-size: 10px} of the size appropriate for the P.

Bug 5: text-decoration: strike-through not in browser style sheet on S

Although the browser style sheet should have text-decoration: strike-through on the S (but it does on STRIKE) element, it doesn't in Opera, so you'll have to add it yourself.

Bug 6: fails to underline alt text

Opera fails to underline the alt text of images.

Bug 7: overline not blinked when applied inline

Opera does not blink the overline of text when the text-decoration is applied inline; for example, <p style="text-decoration: blink overline">Blink would blink the overline, but: <span style="text-decoration: blink overline">Blink</span> would not (this doesn't apply to underline).

Bug 8: values close to 100% overflow containing block

If a value is specified for text-indent less than 100% (or length equivalent), it will be honored, regardless of the length of the word. For example, given a word whose width is 5% of the containing block, text-indent: 97% would result in part of the word overflowing the containing block, rather than the program checking this, and placing it on the next line.

Bug 9: values that cause overflow extend block width

If you specify a text-indent value that cause the word to overflow the block (>= 100%), the block will be extended in width, which is incorrect, since it should simply overflow. This glitch doesn't occur with negative text-indents.

Bug 10: sub and super move box, not baseline

Although the CSS specification clearly states that sub and super move the baseline, not the box, in Opera they move the whole box. This results in line box heights being distorted somewhat. There is a demonstration in one of RichInStyle.com's test pages.

Bug 11: bottom broken

Opera's 'bottom' implementation is completely broken, being applied as 'top'. To see a demonstration, click here.

Bug 12: super broken on images

Vertical-align: super is broken on images - instead of superscripting the element, it instead subscripts it.

Letter-spacing and word-spacing
Bug 13: destroys all subsequent elements if used on inline elements

If an inline element is not closed on the same line as the last bit of its content with these specified, Opera goes crazy, reducing the width of block elements to about 25% unless they contain inline elements, in which case they get full width but massive left margins around the inline elements

Try the following code:

<em style="letter-spacing: .1in; word-spacing: 1cm">
This is a paragraph.
This is a paragraph.
This is a paragraph.
This is a paragraph.
This is a paragraph.
This is a paragraph, <span>too</span>.
This is a paragraph, <span>too</span>.
This is a paragraph, <span>too</span>.
This is a paragraph, <span>too</span>.

This bug is very easily fixed by simply closing each such element on the same line as the last bit of its content.

Bug 14: markup taken into account for determining a word

Opera doesn't apply word-spacing before and after the element tags. For example, if you, like me, prefer your emphasized (italic) words to have a little extra word spacing, you might have I, EM {word-spacing: 2px}, but given <I>emphasized</I>, the word spacing won't be applied to the right or left of the I element, Opera failing to apply word-spacing at these places.

Bug 15: destroys text justification

If you set word-spacing to a value other than normal and text-align to justify, it destroys both, resulting in the element being reduced to half its normal size (this is wrong because since Opera doesn't adjust kerning for justification purposes, word-spacing should be ignored in order to honor the text-align: justify declaration). You can view a demonstration in RichInStyle.com's test page section.

Bug 16: if the line contains words that overflow the right of the element, text-align is treated as left

If a line contains words that overflow the right of the element, text-align is treated as left. For example:

<p style="text-align: right; background: red; margin-left: 99%">
Hello w

In this case, rather than right-aligning the word Hello (and therefore causing it to overflow the left rather than the right of the P), it left-aligns it, thus causing it to overflow the element. However, the 'w' would be right-aligned (on the next line) - this bug only applies to lines that contain words that overflow.

Because this file would otherwise be very long, and would take a long time to download, it has been split into two parts. To view the next section, click here.