Tutorials Bugs Masterclass Free stuff Test pages Proposals

RichInStyle.com bug guide - Opera 3

Although Opera's support for CSS is generally good, it still has serious problems, and as such you should make sure that you bear them in mind in developing your page.

This page presents an exhaustive list of Opera bugs; but more than that it gives a bug-by-bug guide to avoid them - it is useless knowing the bugs but not knowing how to fix them.


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

Section B - Bugs relating to associating style with elements (22 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 (11 bugs).

Section F - Font bugs (15 bugs).

Section G - Text bugs (20 bugs).

Topics to be found in part 2 of this bug guide

Section H - Margin and padding bugs (6 bugs)

Section I - Border bugs (7 bugs)

Section J - Width and height bugs (4 bugs)

Section K - Float bugs (5 bugs)

Section L - Display and whitespace bugs (3 bugs)

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

Section M - Table bugs (11 bugs)

Section N - HR bugs (4 bugs)

Section O - Form bugs (6 bugs)

Section P - List item bugs (10 bugs)

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

Section Q - Error correction bugs (44 bugs)

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


Missing colors

Total bugs = 7 + 22 + 7 + 1 + 11 + 15 + 20 + 6 + 7 + 4 + 5 + 3 + 11 + 4 + 6 + 10 + 44 = 183.

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.

Disabling style sheets
Bug 3: not totally disabled

Although CSS states that you should be able to disable all style sheets, Opera doesn't disable inline style.

This bug is only relevant to users, not authors.

Bug 4: media buggy

Although Opera supports the CSS 2 @import syntax, it has bugs - @import "css.css" MediaOtherThanAllOrScreen, all works, but @import "css.css" MediaOtherThanAllOrScreen, screen, does not. This means that if you have a list of media that includes screen, screen must be the first on the list. Thus, @import "css.css" screen, print;, not @import "css.css" print, screen.

Media support
Bug 5: print not supported

Although Opera supports media, it only supports screen and all - not print.

style attribute
Bug 6: 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 7: 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

The universal selector
Bug 1: only useful when the selector is simple

This only works properly when the selector is simple. Other than that, it is buggy. For example, LI * will be treated as LI, BODY * P as BODY P. As a result, its ONLY use in Opera 3.6 is as in * {color: red} (it also works as in *.class, but this use is pointless).

ID and class
Bug 2: 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 3: destroys box model properties

Where padding, margin or border applied to :link, they are instead applied to all elements, thus meaning that you should avoid them on :link. When applied to A:link, on the other hand, they are buggily applied to A instead of A:link.

Bug 4: all properties except color destroyed

All properties applied to A:link/:link are applied to all A elements, except for color, which is correctly applied. To make matters worse, such properties (i.e., all except for color) are given specificity of 0. For example, given A {background: red} :link {background: blue}, whereas the specificity sort should result in a blue background, the actual result is a red background because properties other than color are given specificity of of 0.

Bug 5: specificity wrong

Opera gets the specificity of :link wrong. For example, given:

:link {background: yellow}
.class {background: white}

and <A class="class" href>, it would make the link yellow rather than white.

Bug 6: all properties except color

All properties except for color are ignored on :visited/A:visited; color is correctly applied.

Bug 7: local hrefs occasionally not marked as visited prior

Opera applies local hrefs as visited links (e.g., <A href="#local">). This is fine. However, what is not fine is its habit of occasionally failing to mark local hrefs as visited, either on first loading a page, or when another application is Alt-Tabbed in front of it; a problem in both cases cured by a reload. This is a glitch rather than a bug that will cause any serious problems.

Bug 8: unsupported

Opera does not support :active.

Browser settings
Bug 9: sometimes override author style sheet

Opera is very badly buggy on links, with the browser setting sometimes overriding the author style sheet. This is a very serious bug, since with certain backgrounds, the browser settings will make the links entirely invisible. As a result, with certain background colors, there is a high chance that with Opera, your links will be invisible. To get around this, when I use background colors that when they have Opera's link colors on top (unvisited links = #00f (blue) #008 (purple), result in illegible links, I enclose my links in a SPAN. Thus I have: <A href="whatever"><SPAN class="operafix"> . . . </SPAN></A>. Note that the SPAN must be inside the A. If you are using separate style sheets for each browser, just add SPAN.operafix {color: color for your unvisited links} to your Opera style sheet. If not, add HTML SPAN/* comment */.operafix {color: desiredcolor !important}. This will hide the comment from all but Opera.

This is only necessary when your background color is one that would make the links illegible otherwise - if your background color is white, this is not necessary. (Note that this bug seems to always be triggered when text-decoration is set to a value other than none).


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

Bug 10: vertical-align not supported

Opera does not support vertical-align on :first-line.

Bug 11: background unsupported

Opera does not support background on :first-line.

Bug 12: line-height unsupported

Opera does not support line-height on :first-line.

Bug 13: letter and word-spacing destroyed

Opera destroys letter and word-spacing on :first-letter by applying it as a margin on all inline elements in the element on which :first-letter is applied. In the case of word-spacing, due to Opera's bug with this property whereby it doesn't check whether the element makes a word, word-spacing won't even be applied on the elements to which it should be applied.

Bug 14: margin and padding unsupported

Opera does not support margin or padding on :first-letter.

Bug 15: line-height unsupported

Opera does not support line-height on :first-letter.

Bug 16: border applied to whole element

If border is applied to :first-letter, the border is applied to the whole element, unless the element has a border, in which case the element's own border is used, and :first-letter's disregarded.

Bug 17: background unsupported

Opera does not apply backgrounds to :first-letter.

The descendant combinator
Bug 18: with BODY and a class or id

Opera does not support contextual selectors with BODY with a class or id as their subject. E.g., .dog P wouldn't work with <BODY class="dog"> <P>. BODY.dog P would never work. Nor would BODY#dog P or HTML.class P.

The child combinator (>)
Bug 19: HTML and BODY treated as equivalent

Opera treats both HTML and BODY as the root of the document tree, thus meaning that HTML > P would match P.

Bug 20: 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 21: matched on a markup basis, not a document tree basis

Although selectors should match elements on a document tree basis, Opera fails to do this, instead matching them on a markup basis. For example:

<DIV id="one">
Some anonymous content.
<DIV id="two">

This example should produce a document tree with DIV#one as an adjacent sibling of DIV#two, but Opera fails to follow this, instead taking the anonymous intervening content into account, and not matching DIV#two with DIV#one + DIV#two, as would be correct.

Bug 22: 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.

HTML formatting attribute specificity
Bug 7: on FONT element, given greater specificity than CSS

Although the CSS specification states that HTML formatting attributes are of lesser specificity than CSS, Opera does not apply this on the FONT element.

For example, FONT face="Courier" with FONT {font-family: sans-serif} should result in a sans serif font, not Courier, because the CSS has greater specificity. The only time Opera gives the CSS greater specificity on FONT is when it is specified via the style attribute (e.g., FONT face="Courier" style="font-family: Courier").

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: unsupported

Opera does not support background-attachment.

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 or IMG

Opera doesn't support background images on inline elements or IMG. 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 a single frame (probably wrongly) in an ugly way.

This bug was fixed between Opera 3.6 and 3.62.

Bug 6: browser sometimes requires a reload to load backgrounds

Opera frequently fails to load (or at least display) background images unless the page is reloaded.

Background colors
Bug 7: applied behind box, not em square

Opera applies backgrounds the inline box on inline elements, not the em square. For example, SPAN {line-height: 100px; font-size: 10px; background: red} should result in a 10 pixel background, but in Opera results in a 100 pixel one.

Note that this is a good bug since this approach is better than the 'correct' one; there is no chance that it will cause any problems.

Background repeats
Bug 8: repeat-x

If a background is specified on an element whose content is less tall than the image, then the image won't be reduced in height if repeat-x is specified, and hence it may overlap with subsequent elements.

Bug 9: repeat-y

If a background is specified on an element whose content is less wide than the image, the image won't be reduced in width if repeat-y is specified, and hence it may overlap with subsequent elements.

Bug 10: no-repeat

If a background is specified on an element whose content is less tall than the image, then the image won't be reduced in height or width if no-repeat is specified, and hence it may overlap with subsequent elements.

Canvas backgrounds
Bug 11: background of BODY used for whole canvas

Although the CSS specification states that if BODY and HTML have different backgrounds, two different backgrounds should be used, Opera instead prefers to give the whole canvas the background set on BODY; if that is not set, it uses HTML. For example, given HTML {background: red} BODY {margin: 5%; background: blue}, it just makes the whole canvas blue.

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: cursive rendered as serif by default

Opera renders cursive as serif by default.

Bug 3: 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 4: 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 5: not supported on BIG, SMALL, SUB or SUP

Opera does not support font-size on SUB, SMALL, BIG or SUP. This is not a major blow since it applies reasonable sensible values to these anyway.

Bug 6: very badly buggy on very large font sizes.

Opera destroys very large font sizes by cutting the bottom or top off. This doesn't always occur, but can be triggered/fixed by scrolling up and down a page. The sizes affected are not generally used (probably > 100px) however, so it isn't a major problem. There is a demonstration in one of RichInStyle.com's test pages.

Font styles
Bug 7: oblique

Opera applies italic instead of oblique. This is a very serious bug, because it means that there is no way to say 'oblique if you've got it, nothing if you haven't' - font-style: italic; font-style: oblique would be the correct way to request 'oblique if you've got it, italic if you haven't'

Font weights
Bug 8: 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.

Line heights
Bug 9: placed on bottom, not on baseline

Opera's application of line-height is mildly glitchy. Instead of placing text on the baseline, it places it on the bottom of the line box. This means that it aligns text within line boxes in such a way as to mean that backgrounds don't fully cover the area when line-height is close to font-size, and the descenders of glyphs go outside borders when line-height is close to font-size.

This means the descenders of glyphs on the bottom line box of an element will not be covered. While this is not serious, it is a glitch that should be fixed.

Bug 10: 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 11: zero line heights wrong

When you set line-height to 0, Opera doesn't correctly honor it, generally instead using a pixel or two. For example, P {line-height: 0; background: red}, which should result in no red being visible, results in a pixel-high bit of red.

Bug 12: BR element decreases line box heights

Bizarrely, the BR element seems to reduce the height of line boxes when specified on lines that have line-height set to smaller than font-size. Note that there is no chance that this will affect you, simply because no-one sets line-height to a lesser value than font-size, but it is a bug nonetheless. There's a demonstration in one of RichInStyle.com's test pages.

Bug 13: line-height of block-level element fails to set minimum height of each box within that line box

Although the CSS spec states that the line-height of a block-level element sets the minimum height of each box within that line box, so that P {line-height: 30px} would give a minimum line-height of 30 pixels, Opera doesn't observe this, so something like <P style="line-height: 30px"><SPAN style="line-height: 15px">Content</SPAN></P> would give a line-height of 15 pixels rather than 30 as it should.

Information regarding normal

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

Property-specific bugs
Font property
Bug 14: 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 15: normal ignored on 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: blink unsupported

Opera doesn't support text-decoration: blink.

Bug 5: 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 6: 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 7: fails to underline alt text

Opera fails to underline the alt text of images.

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: capitalize applied to first letter of each inline box, as well as to each word

Opera applies text-transform: capitalize to the first letter of every inline box (including anonymous boxes) in addition to each word. For example, <P style="text-transform: capitalize"><SPAN>t</SPAN><SPAN>h</SPAN>e is rendered as THE, since the first letter of each inline box, plus the anonymous 'e' box are all capitalized. In practice this bug is unlikely to occur.

Bug 11: sub, super, text-top, text-bottom, length, percentage values relative to line box, not parent box

In Opera, all values are relative to the line box, not the parent box. For example, given <SPAN style="vertical-align: sub">, <SPAN style="vertical-align: baseline">, it will align the inner element with the baseline of the line box, not the baseline of the parent element. Although this is incorrect, it should not be changed - the specification should.

Bug 12: 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 13: middle

Opera doesn't correctly apply middle - it should align with the middle plus half the x-height of the parent, but instead aligns with the top of the font.

Bug 14: bottom

Opera doesn't correctly apply bottom, aligning too far down. To see a demonstration, click here.

Bug 15: text-bottom

Opera doesn't correctly apply text-bottom. It is very mildly glitchy, aligning with a point about 2 pixels too far down.

Bug 16: vertically aligning a child box doesn't retain the background of the parent box

When you vertically align a child box differently from usual, the background of the parent box should remain constant behind the text since vertical-align does not move the outer box. In Opera, however, the background is only drawn behind the child box. For example, given <SPAN style="background: red">Some text <SPAN style="vertical-align: 20px; background: blue">up</SPAN></SPAN>, the red background should remain constant behind the element, but in Opera it willl not be rendered behind the inner SPAN.

Bug 17: 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 18: 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 19: 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 20: 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.

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.