|
|||||||
|
|||||||
|
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.
0These 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.
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).
Section E - Color and background bugs (6 bugs).
Section F - Font bugs (11 bugs).
Section G - Text bugs (16 bugs).
Section I - Border bugs (2 bugs)
Section J - Float bugs (3 bugs)
Section L - Display and whitespace bugs (13 bugs)
Section M - Table bugs (4 bugs)
Section O - Form bugs (2 bugs)
Section P - List item bugs (7 bugs)
Section Q - Error correction bugs (51 bugs)
Total bugs = 4 + 7 + 7 + 1 + 6 + 11 + 16 + 2 + 3 + 13 + 4 + 3 + 2 + 7 + 51 = 137.
Opera does not support alternate style sheets.
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 attributeAccording 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.
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.
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.
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.
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).
Although Opera's parsing (below) indicates that it supports :active, exhaustive testing failed to elicit any kind of support for :active.
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).
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.
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.
Opera will ignore <!--selector {color: red}, unless you follow the <!-- with a line break. (As in <-- P {color: red}).
Inherit only works on inherited properties and vertical-align i.e., not margin, padding, width, height, borders).
Inherit doesn't work on links (e.g., :link, :visited {color: inherit}).
Although the CSS spec states that the backslash can be used (e.g., to refer to otherwise invalid characters), Opera doesn't support this.
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.
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.
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.
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.
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.
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.
Opera doesn't support background images on inline elements. This emphasizes why you should always specify a color with image.
You are strongly advised to avoid using animated backgrounds with Opera, since it doesn't animate them, instead rendering them next to the element .
Given the following code:
<TABLE>
<TR class=x bgcolor=black>
</TABLE>
, TR.x {background: transparent} wouldn't work to override it. However, TR.x {background: red} TR.x {background: transparent} would make it red.
Opera refuses to use some fonts (chiefly, it seems, those that lack a full complement of upper and lowercase glyphs).
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".
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.
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.
Opera applies italic instead of oblique - oblique should only match oblique fonts whereas italic both italic and oblique.
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.
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.
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.
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).
Opera applies line-height: normal as line-height: 1.2.
Opera will ignore inline font declarations that specify a line height (e.g., style="font: 12px/24px Arial").
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.
Opera inherits text-decoration to block descendants, whereas the CSS spec states it is only 'inherited' to inline descendants.
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.
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.
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.
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.
Opera fails to underline the alt text of images.
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).
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.
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.
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.
Opera's 'bottom' implementation is completely broken, being applied as 'top'. To see a demonstration, click here.
Vertical-align: super is broken on images - instead of superscripting the element, it instead subscripts it.
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:
<p>
<em style="letter-spacing: .1in; word-spacing: 1cm">
Anything
</em>
</p>
<p>
This is a paragraph.
This is a paragraph.
This is a paragraph.
This is a paragraph.
</p>
<p>
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>.
</p>
This bug is very easily fixed by simply closing each such element on the same line as the last bit of its content.
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.
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.
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.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.