|
|||||||
|
|||||||
|
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.
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).
Section E - Color and background bugs (11 bugs).
Section F - Font bugs (15 bugs).
Section G - Text bugs (20 bugs).
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)
Section M - Table bugs (11 bugs)
Section O - Form bugs (6 bugs)
Section P - List item bugs (10 bugs)
Section Q - Error correction bugs (44 bugs)
Total bugs = 7 + 22 + 7 + 1 + 11 + 15 + 20 + 6 + 7 + 4 + 5 + 3 + 11 + 4 + 6 + 10 + 44 = 183.
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.
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.
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.
Although Opera supports media, it only supports screen and all - not print.
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.
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).
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.
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.
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.
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.
All properties except for color are ignored on :visited/A:visited; color is correctly applied.
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.
Opera does not support :active.
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).
Opera does not support vertical-align on :first-line.
Opera does not support background on :first-line.
Opera does not support line-height on :first-line.
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.
Opera does not support margin or padding on :first-letter.
Opera does not support line-height on :first-letter.
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.
Opera does not apply backgrounds to :first-letter.
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.
Opera treats both HTML and BODY as the root of the document tree, thus meaning that HTML > P would match P.
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.
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">
</DIV>
Some anonymous content.
<DIV id="two">
</DIV>
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.
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.
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").
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 does not support background-attachment.
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 or IMG. 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 a single frame (probably wrongly) in an ugly way.
This bug was fixed between Opera 3.6 and 3.62.
Opera frequently fails to load (or at least display) background images unless the page is reloaded.
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.
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.
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.
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.
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.
Opera refuses to use some fonts (chiefly, it seems, those that lack a full complement of upper and lowercase glyphs).
Opera renders cursive as serif by default.
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.
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.
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.
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'
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.
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.
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.
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.
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.
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.
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.
Opera doesn't support text-decoration: blink.
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.
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.
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.
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.
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 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.
Opera doesn't correctly apply bottom, aligning too far down. To see a demonstration, click here.
Opera doesn't correctly apply text-bottom. It is very mildly glitchy, aligning with a point about 2 pixels too far down.
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.
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.
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.