RichInStyle.com bug guide - Opera 4.01

Bugs - continued

Bugs by type

Total bugs = 6 + 8 + 7 + 1 + 5 + 10 + 15 + 1 + 2 + 6 + 15 + 5 + 3 + 4 + 10 + 59 = 137.

Section I - border bugs

Border styles

Bug 1: 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 2: transparent unsupported

Opera does not allow you to specify transparent borders.

Section J - Float bugs

Bug 1: rather than moving non-floating text that won't fit next to a float down a line box at a time, it is moved below the float

Given the following code:

<div style="font-size: 22px; line-height: 22px; text-align: right">
<img src="green.gif" vspace=0 width="200" height="52" style="float: left"> <span style="background: red">This text</span> </div>

rather than attempting to place the text next to the image as it should, failing at this and then moving it down a line box at a time (and thus moving it to the first empty line box, which is 22 * 3 = 66 pixels down), it instead places it below the bottom of the image - 52 pixels down.

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

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.

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

Bug 3: clear on BR treated as margin-top

Opera treats 'clear' on it as giving the BR sufficient margin-top such that the first line box is below the previous float, which is incorrect, since BR is not a block-level element - the effect of clear on BRs is to create sufficient line boxes to move it below previous floats.

Section K - display, white-space and positioning bugs

Display

Bug 1: text-align doesn't work on display: compact

Opera 4 doesn't allow text-align to work on display: compact.

Bug 2: background doesn't work on display: compact elements that, when block elements, have non-zero margin tops

Opera 4 doesn't allow background to work on display: compact when the element has a non-zero margin-top (as, for example, is typical with P).

Bug 3: inheritable properties 'reverse inherited' into display: compact

Opera 4 'reverse inherits' inheritable properties into display: compact.

Thus 'color' on an element following a compact box would be applied to the compact box. To override this, you can simply set the property on the compact box.

Bug 4: elements won't run-in unless the elements are adjacent siblings

Opera 4 will only run-in boxes when the elements are adjacent siblings. Thus <DIV><DIV style="display: compact"></DIV></DIV><P>Should follow on would not run-in. This is incorrect since boxes should run-in to the next block box (including anonymous).

Bug 5: run-in boxes don't interact with floated boxes correctly

Opera 4 does not run-in boxes to floated boxes correctly. See http://richinstyle.com/test/boxes/runin.html

Bug 6: all ordered list types always display 1 on display: list-item

All ordered list types render the number '1.' (or the equivalent (such as a.)) on display: list-item. Thus instead of P {display: list-item} rendering 1, 2, 3, it instead renders '1.'.

Absolute positioning

Bug 7: 'auto' completely broken

Opera's support for 'auto' is non-existent. Instead it prefers to throw the image to odd locations, not render at all or worse. There is a test page that demonstrates this. The effect of this is that you must only use the 'top' and 'left' properties - never 'right' or 'bottom' (since to use these requires that you set left or top respectively to auto), and that you must always set both of left and top to non-'auto' values.

Bug 8: height of absolutely positioned elements buggy

Opera does not get the height of absolutely positioned elements correct. Although it (unfortunately - I believe the spec is suboptimal) follows the spec insofar as it makes the height of absolutely positioned elements with height: auto equal to that from the top of the element to the bottom of the viewport to a certain extent, it does not do entirely - it seems, for example, to give different amounts of document painted depending on where the element is in the markup. See a test page, where the two different elements extend different distances down the page.

Fixed positioning

Bug 9: completely broken

Opera 4's support for fixed positioning is completely broken. See:

1. http://richinstyle.com/test/positioning/positionfixed1.html
2. http://richinstyle.com/test/positioning/positionfixed2.html
3. http://richinstyle.com/test/positioning/positionfixed3.html
4. http://richinstyle.com/test/positioning/positionfixed4.html (paint problems when the document is scrolled.
5. http://richinstyle.com/test/positioning/positionfixed5.html (paint problems when the document is scrolled.

Content

Bug 10: url() not supported

Opera does not support content: url().

Z-index

Bug 11: buggy

Opera's support for z-index is buggy. See http://richinstyle.com/test/positioning/zindex.html

Page-break-before; page-break-after

Bug 12: avoid unsupported

Opera does not support the 'avoid' value of page-break-before or page-break-after.

Printing support

Completely broken, which means that support cannot be tested

There are currently two bugs very serious printing bugs in Opera. Although these are not CSS-related, they make testing difficult or impossible in some cases. These bugs are:

1. only the first page of a document will print
2. only the left frame of a frameset will print.

Thus orphans and widows might be supported, but this cannot be verified at present.

Overflow

Bug 13: only hidden supported

Opera only supports the 'hidden' value of overflow - not any other value (except hidden, which applies automatically).

Part 2 - Element-specific bugs

Section L - Table bugs

Bug 1: text-align and font-size not inherited into table cells

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

Bug 2: padding destroyed on table rows

Opera destroys padding on table rows by applying it as a kind of absolute positioning statement on the content of the tables. Thus for example <TABLE border><TR style="padding: 10px"> would result in the row being 'positioned' outside the TABLE border.

Note that this bug is applied in exactly the same way as margin is (incorrectly) applied to table rows.

Bug 3: border: none on CSS doesn't override HTML

Even though CSS has greater specificity than HTML (later order if used with the universal selector), Opera does not allow TABLE {border: none} to override the border attribute on <TABLE>.

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

Section M - 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: text-align allowed to affect HR

Opera allows text-align to affect HR, which is incorrect since HR is a block-level element and text-align affects only inline-level content.

Bug 2: except for border-color, border properties don't work on HR

Even though Opera applies horizontal rules as a border, with the exception of border-color, 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 3: margin-top on HR buggy

Try the following code:

<div style="float: left; margin-top: 0; background: yellow; width: 50%; height: 100px">
</div>
<HR style="margin-top: 100px">

The top of the HR should be below the DIV, but won't be in Opera.

Section N - Form bugs

Bug 1: style doesn't work

Style doesn't work on form elements in Opera, except for FORM itself, borders, horizontal margins (not vertical), on 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="text".

Bug 2: run-in treated as block

On form elements Opera treats run-in as block. This is useful in a way, since it doesn't support block, so this a workaround.

Section O - List bugs

List style types

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 styling

Bug 3: 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 4: 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 or un-inheritably styled block-level elements.

Bug 5: 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 6: 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 7: 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 P - Error correction bugs

1. Opera fails to treat the first instance of </ as terminating the STYLE block.
2. 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
3. Opera incorrectly allows (ignores) white space in the string1 and string2 macros.
4. Opera permits the omission of the end quote and beginning (only on @import) quote in the string1 and string2 macros.
5. 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 {}.
6. It allows Π(and similar characters) in tokens, which isn't valid.
7. It parses color declarations as the first word after the color: - color: red all will apply red, but this isn't valid.
8. It doesn't ignore background declarations where part is invalid (e.g., containing invalid colors (such as aliceblue)).
9. It allows integers to be mixed with percentages on rgb(), which isn't valid.
10. It doesn't allow comments between '!' and 'important', which is incorrect since !important is DELIM IDENT - two tokens - comments are valid anywhere between tokens.
11. Opera incorrectly allows !important other than after the property value (e.g., in background: red !important url(green.gif).
12. Opera incorrectly allows character references in IDs.
13. 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.
14. 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.
15. 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.
16. Opera permits the separation of margin values by commas, but this isn't valid.
17. Opera tolerates more than 1 decimal place on the percentage rgb format, but this isn't valid.
18. Opera permits combining background-position keywords and lengths or %, but this isn't valid.
19. Opera fails to ignore .class, :1invalid {color: red} (although it does ignore :1invalid, .class {color: red}).
20. Opera allows {} in inline (via the style attribute) style.
21. Opera disregards the case of fonts (e.g., applying Arial when aRial is specified).
22. 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.
23. 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.
24. 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.

25. Opera incorrectly treats /*/ as a complete comment.
26. It permits classes to begin with hyphens, which is invalid.
27. It tolerates ' as quotes in the META http-equiv Link header, but HTTP only allows ".
28. 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.
29. 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.
30. It performs media truncation on @import, which is wrong since media are only truncated on the HTML 'media' attribute.
31. It allows font weights that aren't divisible by 100, but they aren't valid.
32. It allows :link:link to match :link.
33. 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.
34. It disregards the case sensitivity of the media attribute.
35. It fails to observe the case sensitivity of classes (but it does of IDs, strangely).
36. It applies :first-letter to elements other than block-level ones
37. It applies clear to :first-line (badly IMHO) but it shouldn't apply (the spec is in error on this point) since clear applies only to block-level content, and :first-line is inline-level content.
38. It doesn't match [attribute] by attribute="".
39. It allows units that are missing the length (such as font-size: 50).
40. It applies white-space to inline-level elements whereas it should only apply to block-level ones.
41. It has specificity problems if ten or more of a selector is used in a selector.
42. It will honor color declarations that omit the '#' (but only if they begin with a number, which makes this particular bug addition rather useless).
43. It will honor percentages on 'top', 'left', 'right' and 'bottom' even when the containing block's dimensions are unknown. This is incorrect and should instead be treated as 'auto'.
44. It honors width on display: compact, which is incorrect since display: compact is initially treated as an inline box and width has no effect on inline boxes.
45. It fails to allow empty compact elements to affect the height of line boxes in the associated principal box.
46. It honors percentage heights when the height of the containing block has not been set.
47. It does not render empty elements on :before or :after.
48. It fails to imply </P> before <TABLE>s.
49. It will apply horizontal margins to table rows (buggily), and bottom margins if the row is the last one in the table.
50. Opera allows text-align: center to affect the position of tables, which is incorrect since text-align only affects the alignment of text within block boxes - not the position of the block boxes themselves.
51. It allows :first-letter:first-line, but that isn't valid.

Part 4 - other problems

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

Part 5 - support for CSS2

In addition to the bugs listed, the following CSS2 concepts are completely unsupported:

1. marks
2. clip
3. display: marker
4. caption-side
5. UI colors
6. UI fonts
7. The 'attribute contains' (~=) selector
8. The 'dash match' (|=) selector
9. :first-child
10. :focus
11. font-stretch
12. text-shadow
13. size
14. page
15. :left and :right
16. table-layout: fixed
17. border-spacing

Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.