RichInStyle.com bug guide - Opera 3

If a negative margin-left declaration is made on an element, it will result in the element inheriting the width value for its parent, and padding-right adjusted so as to make the outer width of the element that of the containing block. For example:

Would result in the calculated value that results from the width: 50% implied by the ancestor DIV's margin-left: 50% being inherited, and padding-right being set to such a value as to make the inner DIV's outer width that of the ancestor.

Margin: auto

Bug 5: auto on margin-right or margin-left sets width: auto to an outer width of 100% on replaced elements

If you set auto on margin-right or margin-left (or both) and width: auto, the outer width of the element (i.e., the width from margin-left to margin-right) is set to 100%. For example, <IMG style="margin-left: auto; margin-right: 10%"> results in the margin-right being honored and a width of 90% being given, where correct would be to use the intrinsic width and then calculated margin-left based on this - margin-left/right: auto shouldn't affect the width of images, but in Opera it does. The way to avoid this is to avoid auto on replaced elements, or to specify an explicit width in CSS (NB not HTML - Opera overrides this with the CSS).

There is a very similar bug on tables; see below.

Padding

Bug 6: padding not applied to empty elements

Padding is not applied to empty elements unless they are given a height (i.e., using the height property).

Section I - border bugs

Border widths

Bug 1: Borders extend line box height

When specified on inline elements, borders increase the line box height if they would otherwise result in overlap, which is incorrect - they should simply be placed over the line box. For example, given P {line-height: 20px; font-size: 16px} SPAN {border-top: 3px}, the border will increase the line box to 21 pixels in Opera since it would otherwise overlap, whereas P {line-height: 20px; font-size: 16px} SPAN {border-top: 2px} doesn't extend the line box because the top of the border exactly coincides with the top of the line box. There is a demonstration in one of RichInStyle.com's test pages.

Bug 2: borders not applied to empty elements

Borders are not applied to empty elements unless they are given a height (i.e., using the height property).

Images

Bug 3: borders destroyed

Borders are destroyed on images, being applied from the center of the image but without adjusting the size of the image. For example, given <IMG width="50" style="border: 50px solid">, the border would be applied around the center of the image and then the image would be rendered on top of that. In addition, since the width of the element is less than the width of the border, there would be a 25 pixel of border on each side, which would overlap with adjacent elements. There is a demonstration in one of RichInStyle.com's test pages.

Borders on HTML/BODY

Bug 4: borders destroyed

Borders are not usable on HTML or BODY, destroying the whole page by causing massive overflow and ugly compression of content. There is a demonstration in one of RichInStyle.com's test pages.

Bug 5: minimum border height is that of the canvas

If the document is less tall than the canvas, Opera applies the border around the canvas, which is incorrect since the height should be that of the content.

Border styles

Bug 6: hidden destroyed

The hidden border style (and indeed all other styles that are unbeknownst to Opera - all future border styles) is destroyed by applying the border as a transparent border, overriding the border color.

Border colors

Bug 7: transparent unsupported

Opera does not allow you to specify transparent borders.

Section J - width and height bugs

Width

Bug 1: clipped to avoid overflowing viewport

Opera clips width declarations to avoid them overflowing the viewport.

Bug 2: when specified on images, transforms them into block elements

When specified on images, the CSS width property transforms them into block elements (see a demonstration in one of RichInStyle.com's test pages).

Height

Bug 3: elements that overflow containing block extend height

If you set a height declaration on a containing block, then it will be extended if its content overflows it, rather than allowing the content to overflow. For example:

Would result in the border-bottom being placed at the bottom of the content, rather than 1px down as it should be.

Bug 4: height doesn't work on BODY or HTML

Opera ignores height on BODY and HTML.

Section K - Float bugs

Block elements

Bug 1: can't follow floated block elements with non-floated, non-cleared block elements when the float is the first thing in the page

If you follow a floated block element that is the first element on the page with a non-floated block element, severe problems will be induced. For example:

<P style="float: left; width: 20%">
A run-in heading
</P>
<P>
And some text
</P>

That would result in 'And some text' overlapping the 'A run-in heading', instead of wrapping round it as it should. This means that you should always have content before such elements - o.k. is:

<BODY>
<HR> <-- Or any element -->
<H1 style="float: left; width: 20%">
A run-in heading
</H1>
<P>
And some text
</P>

but bad is:

<BODY>
<H1 style="float: left; width: 20%">
A run-in heading
</H1>
<P>
And some text
</P>

Bug 2: floats allowed to overflow their containing block

Even though the CSS spec states that floats adjacent to current floats that overflow their containing block should be placed below the float, Opera doesn't follow this, but instead allows them to overflow the containing block. For example:

This would have the fourth DIV overflowing the containing block, but it actually should be placed below the other DIVs.

This is not catastrophic because you can simply use the clear property to achieve what the browser should do for you.

This bug also applies to non-floating elements that follow floats. E.g.:

<DIV style="width: 50%; float: left">
</DIV>
<DIV style="width: 50%; float: left">
</DIV>
<P>
Placed to the right of the other two floats.

Bug 3: text-align doesn't work on floats that were originally inline

Text-align doesn't work on floats that were originally online. This is signficant because of:

<P style="font-size: 16px; line-height: 24px">
(a) What were the causes of the Great Depression? <span style="float: right; width: 4em; text-align: right">(12)</span><br>
(b) What, if any, were its lasting effects on American society? <span style="float: right; width: 4em; text-align: right; background: blue">(13)</span><br>
<span style="float: right; width: 2em; text-align: right">
<span style="border-width: medium 0; border-style: solid">25</span>
</span>

In this example, designed to give a reproduction of standard examination question layout with the marks to the right, text-align: right is essential because the width of the float is unknown and so therefore it is necessary to specify a width for it. 4 ems and 2 ems are specified because it is not possible to know the true values and these are likely to be the maximum values. Since these values are certain to be too high, in order to align along the right, text-align: right is necessary, but in Opera text-align has no effect on elements that are inline. The effect of this bug is negligible however, because of:

Bug 4: right floats that were originally inline right-aligned

Opera right-aligns right-floated inline elements. This is incorrect since the initial value of text-align is left. This has the effect of obviating the previous bug because it is almost always desired to right-align right-floated inline elements.

Bug 5: non-floating elements don't flow on both sides of a floated inline element

Although non-floating block elements should flow around both sides of a floated inline element, Opera only makes them flow on one side. For example:

<p style="margin-right: 100px">
Text<IMG src="stars.gif" style="float: right">
<P>
This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image.

Text.

This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image. This text should flow around the image - text should flow around with some to the image's left and some to its right - effectively two lines, one on each side of the image.

Similarly:

Text.

The problem is not a common one - it only occurs when text should flow on both sides of a float.

Section L - display and white-space bugs

Display

Bug 1: inline destroyed

Opera destroys display: inline, suppressing the line break before the element but not after. For example P {display: inline} would suppress the </p> line break but not the <P> one. This makes it entirely useless.

Bug 2: list-item not supported

Opera doesn't support display: list-item.

White-space

Bug 3: not supported

Opera does not support white-space.

Part 2 - Element-specific bugs

Section M - Table bugs

Bug 1: text-align not inherited into table cells

Opera fails to inherit text-align into table cells, instead applying text-align: left.

Bug 2: borders ignored

Opera ignores border properties on table elements.

Bug 3: margins don't work on captions

Opera ignores margin properties on captions, preferring to set use its own, unchangeable, values.

Bug 4: padding not applied to table rows or tables

Opera doesn't apply padding to table rows or tables.

Bug 5: padding-top and padding-bottom not applied to table cells

Opera doesn't apply padding-top or padding-bottom to table cells.

Bug 6: padding-left and padding-right destroyed on table cells

Opera destroys horizontal padding by applying the sum of padding-left and padding-right as a padding-right on the content (it only does this if the table cell only contains anonymous boxes - <TD style="padding: 100px">Content</TD> will trigger the bug, but <TD style="padding: 100px"><PContent</TD> will not).

Bug 7: captions not made descendants of tables

Although CAPTIONs are descendants of tables (but not inside their block), Opera doesn't inherit styles to them, so TABLE {color: red} won't affect the color of the CAPTION. It does treat them as descendants for contextual selectors (e.g., TABLE CAPTION {color: red}) however, so you can avoid this bug in that way.

Bug 8: height and width not applied to table elements

Opera does not support the CSS height and width properties on table elements.

Bug 9: vertical-align not applied to table elements

Opera does not support the CSS vertical-align property on table elements.

Bug 10: background images not supported on table elements

Opera does not support background images on table elements.

Bug 11: auto on margin-right or margin-left sets width: auto to an outer width of 100%

If you set auto on margin-right or margin-left (or both) and width: auto, the outer width of the element (i.e., the width from margin-left to margin-right) is set to 100%. For example, <TABLE style="margin-left: auto; margin-right: 10%"> results in the margin-right being honored and a width of 90% being given, where correct would be to assign width by the browser's table width algorithm and then calculated margin-left based on this - margin-left/right: auto shouldn't affect the width of tables, but in Opera it does. The way to avoid this is to specify a width in HTML (CSS won't work; see above), which causes Opera to ignore the horizontal margin: auto entirely.

Section N - HR bugs

Note - need to use background to set color

To set the color of horizontal rules using CSS in Opera, it is necessary to use the background property.

Bug 1: border properties don't work

Even though Opera applies horizontal rules as a border, the border properties have no effect on it. As a result, you are probably best off using HTML to set the characteristics of horizontal borders.

Bug 2: height doesn't work.

Height doesn't work on HR

Bug 3: vertical margins around horizontal rules incorrect

The size of vertical margins around horizontal rules is simply that of the horizontal rule, not the collapsed value as would be correct. For example, given P.beforeHR {margin-bottom: 100px} and HR {margin-top: 10px}, the margin between them would be 10 pixels - P's margin would be ignored.

To see a demonstration of this in one of RichInStyle.com's bug pages, click here.

Bug 4: horizontal rules that overlap with floats are rendered in front of the floats

Although non-floated elements should be rendered behind floats, Opera renders them in front of them; for example, <P style="width: 50%; border: solid blue"><HR> would render the rule on top of the blue border.

Section O - Form bugs

Bug 1: style doesn't work

Style doesn't work on form elements in Opera, except for FORM itself, INPUT type="image" and about a 1 pixel wide glitchy bit (between the text box and the browse button) when color is set on INPUT type="width".

Bug 2: line-height glitchy on INPUT type="image"

Line-height is glitchy on INPUT type="image" with alt text applying all the line height below the text, instead of have above and half below.

Bug 3: border buggy on INPUT type="image"

You shouldn't specify borders on INPUT type="image" because Opera applies the border from the center of the button, but not increasing the width of the button to compensate, therefore meaning that large borders will overlap with adjacent elements. There is a demonstration in one of RichInStyle.com's test pages.

Bug 4: padding unsupported on INPUT type="image"

Opera does not support padding on INPUT type="image".

Bug 5: display: block destroyed on INPUT type="image"

Opera destroys display: block on INPUT type="image" by not allocating any space for the image and therefore overlapping subsequent text. There is a demonstration in one of RichInStyle.com's test pages.

Bug 6: width and height unsupported on INPUT type="image"

Opera does not support width or height on INPUT type="image".

Section P - List bugs

List-style-type

Bug 1: '.' placed after ordered list markers

Although the CSS specification states that list numbers should be a, b, c; 1, 2, 3, Opera renders a., b., c. instead.

List-style

Bug 2: doesn't reset longhands

Although the list-style property should reset all unset values to their initial value, in Opera i does not. For example, list-style-image: url(image.gif); list-style: decimal should reset the image, but doesn't.

Note this is not a serious bug and will never occur in practice.

List-style-image

Bug 3: image not always loaded

Opera often requires a reload or to be in the cache (i.e., via use in IMG) to load list images.

List styling

Bug 4: marker boxes not correctly floated

Opera does not float list items correctly, failing to float the marker box to the left of the float but instead having them associated with the content.

Bug 5: the inheritable styles of a block element inside a LI are 'inherited' back up to the marker

Given, for example, <LI><P style="color: red">, the list marker of the LI would be red. This wouldn't apply if the P was preceded by anonymous content (such as <LI>content<P>) or un-inheritably styled block-level elements.

Bug 6: ADDRESS destroys LI

If you have an ADDRESS element inside LI, the ADDRESS's left margin is placed with respect to the left of the OL and the marker glyph of the LI is not rendered.

Bug 7: :first-letter doesn't work on LI the first block descendant thereof

:first-letter doesn't work on LI or its first block-level descendant (unpreceded by anonymous inline content). This bug is almost certainly related to bug 4 above. The exception to this is that the box model property bug still occurs (e.g., P:first-letter {border: solid} is applied to the whole P).

Bug 8: baseline of marker boxes aligned with baseline of text-free principal boxes

Although the baseline of marker boxes, if the principal box lacks textual content, should be aligned with the top content edge of the principal box (the spec says that it should be aligned with the top outer edge, but this is wrong, and in any case Opera doesn't do this either), Opera instead aligns it with the baseline. E.g., <LI><P style="margin-top: 100px"><IMG>, the marker would be aligned with the bottom of the IMG.

Bug 9: negative text-indent inside LI doesn't work

Opera will ignore negative text-indents inside LI (or its first block-level child not preceded by anonymous content).

Bug 10: if LI and its first block-level child have different font sizes, the marker will be misaligned.

If LI and its first block-level child not preceded by anonymous content have different font sizes, the marker won't be aligned correctly - it won't be aligned with the baseline of the first line of text in the principal block box.

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

Section Q - Error correction bugs

Opera renders negative (illegal) line-heights as 16*(abs(line-height)). E.g., line-height: -12px would be rendered as line-height: 192px or line-height: -1em as 16em.
Opera fails to treat the first instance of </ as terminating the STYLE block.
Opera incorrectly does something strange when :first-line is (illegally) applied to any non-replaced inline element.
The element is given a negative top margin and thus moved up. In addition, the bottom half of the element is chopped off when the page is loaded, but an alt-tab to another program and then back again restores the text (but it is still moved up a bit).

The following will trigger the bug: Setting any valid value for InlineElement:first-line on the following only:
- any background property
- text-decoration
- line-height, but not via the font shorthand
- text-transform
- vertical-align
- word-spacing
- letter-spacing
- font-family, but not via the font shorthand; note that with this property the value need not be valid.
- font-variant, but not via the font shorthand
- font-size, but not via the font shorthand
- font-weight, but not via the font shorthand
- clear
Opera incorrectly allows (ignores) white space in the string1 and string2 macros.
Opera permits the omission of the end quote (but not the beginning quote) in the string1 and string2 macros.
Opera doesn't support simple_selector correctly - it is (partly) defined as element_name?, so , .class should work, but it doesn't - if simple_selector is a null token, then it will destroy the whole ruleset except when it is the last in the selector list - it supports selector, {}, but not , selector {} or selector, , selector {}.
Opera doesn't support the nmchar macro correctly, allowing certain invalid characters in it; for example, Œ.
Opera doesn't support the nmstart macro correctly, allowing certain invalid characters in it; for example, '-'.
It parses color declarations as the first word after the color: - color: red all will apply red, but this isn't valid.
It will have serious problems with any future extensions to CSS that have [] inside properties - it will not make .after3 red as a result of .after3 {bob: []; color: red}.
It doesn't ignore background declarations where part is invalid (e.g., containing invalid colors (such as aliceblue)).
It allows integers to be mixed with percentages on rgb(), which isn't valid.
It doesn't allow comments between '!' and 'important', which is incorrect since !important is DELIM IDENT - two tokens - comments are valid anywhere between tokens.
Opera incorrectly allows !important other than after the property value (e.g., in background: red !important url(green.gif).
Opera incorrectly allows character references in IDs.
It allows generic font family names (such as monospace) to be included in quotes, but as these are under the control of CSS, this isn't valid.
It parses font families that include white space but aren't quoted incorrectly - Times New Roman should be parsed as TimesNewRoman, but Opera applies it as is.
Opera permits the enclosing of the type selector (e.g., P) in < and > - a very serious bug, since it will lull those who know no better into a false sense of security.
Opera permits the separation of margin values by commas, but this isn't valid.
It doesn't treat missing values as invalid (e.g., margin-left: ).
Opera tolerates more than 1 decimal place on the percentage rgb format, but this isn't valid.
Opera permits combining background-position keywords and lengths, but this isn't valid.
CSS defines a DELIM token as containing all characters not matched by other tokens, and states that if a set of selectors contains one of these characters that isn't a valid combinator, the whole ruleset should be ignored, but for certain such characters, Opera doesn't.
Opera allows {} in inline (via the style attribute) style.
Although to all intents and purposes @media is unsupported in Opera, it does, bizarrely, apply @imports inside @media (which is invalid) (although it correctly only uses @media screen and @media print), provided it precedes all rulesets.
P {text-decoration: anyvalue; text-decoration: blink} should apply text-decoration: anyvalue (e.g., underline), since blink is an unknown value to Opera, and hence should be ignored, but it doesn't, instead applying P {text-decoration: none}.
Opera disregards the case of fonts (e.g., applying Arial when aRial is specified).
An @import loop will crash the program (e.g., where filename.css is @import url(filename.css);
If a page LINKs to itself as a style sheet (e.g., <LINK href="thispage.html">), the program will crash.
It allows % to be mixed with position keywords on background, but this is invalid and should be ignored.
If you specify an unknown border style, Opera treats it as giving the element a transparent border (see demonstration in a test page), which is wrong since it should be ignored.
Although there is in reality no requirement to close SGML comments that occur within the STYLE element, if you fail to do so, Opera will destroy the whole page (note this only applies to the first such comment tag - <-- --> <-- won't destroy; <-- will - there must be at least one close tag for all the open ones). This is non-serious because to do this would destroy older user agents anyway.
If you include ASCII character 27h, 39 decimal in a id or class token (') it destroys everything after it in the style sheet.
Although this is not a valid token character, it should only result in the ruleset being ignored, not the whole of the rest of the style sheet.
Opera incorrectly treats /*/ as a complete comment.
Very long (40kb is enough, 4kb is not) classes cause display glitches - see demonstration.
It permits classes to begin with hyphens, which is invalid.
It tolerates ' as quotes in the META http-equiv Link header, but HTTP only allows ".
It will parse height: 200px; height: 100% with a containing block without an explictly set height as no declaration, since although it (correctly) ignores height: 100%, it fails to remember that there was an earlier height declaration that it needed to keep track of.
It will parse padding: 200px; padding: -200px as no declaration, since although it (correctly) ignores padding: -200px, it fails to remember that there was an earlier padding declaration that it needed to keep track of.
It performs media truncation on @import, which is wrong since media are only truncated on the HTML 'media' attribute.
It allows font weights that aren't divisible by 100, but they aren't valid.
It allows ANCESTOR_OF_UL_OR_OL (such as BODY) {list-style: any} to affect the list marker of UL and OL, which is incorrect since the (necessary) browser style sheet declarations, OL {list-style: decimal} and UL {list-style: disc}, should override it.
It allows :link:link to match :link.
It will ignore rulesets that are associated with incorrectly placed pseudo-elements, which is incorrect since the sole criterion for ignoring rulesets is that the selectors cannot be parsed; i.e., they are grammatically incorrect. .this-should-not-be-ignored, P:first-letter.class {color: red} does not satisfy this criterion, and therefore it should be red, but won't be in Opera.

Part 4 - other problems

HTML 4

Opera doesn't support it - but then it doesn't claim to. Particularly affected are Q, ACRONYM and ABBR. Thus no CSS can be applied to them.

'Missing' colors

According to the CSS specification, only 16 colors are defined. However, both Internet Explorer and Netscape define far more, and these are used by many designers. For example, BODY {color: white; background: darkgray} would work perfectly in Netscape and Internet Explorer, but would be invisible in Opera, the darkgray being ignored for Opera's default (usually white).