text
|
|||||||
|
|||||||
|
This should be green (because two preferred style sheets are specified, and, in the absence of any applicable Default-Style, the first preferred style sheet should be used). However, in Mozilla it will be red because it treats the title attribute as case-insensitive, and is allowing Default-Style: preferred to match a style sheet with a title of Preferred.
This should be red, once an alternate style sheet called 'RichInStyle' has been selected, but Mozilla will either offer an incomplete selection mechanism or none at all.
This should be blue, because the style attribute has specificity of 100, whereas P#blue has specificity of 101. However this bug should not be fixed, because the spec is bad on this count.
Mozilla does not allow style sheets to be disabled; this is required by the CSS specification.
Mozilla treats the media attribute as case-insensitive - this shouldn't be red.
The first letter of this element should have a right margin of 50 pixels, but won't in Mozilla.
Here: is a local link. It has been specified as being blue when unvisited and red when visited. However, it will not be marked as visited, until clicked (although I am firmly of the view that it should be marked as visited _all_ the time) and then rloaded.
This should be red (P/* */.simpleselector {color: red} - because comments are valid anywhere between tokens, and 'P', '.' and 'simpleselector' are three separate tokens), but won't in Mozilla.
As should this (P./* */simpleselector2 {color: red}).
However, this should not (P#/* */simpleid {color: red}, since, unlike class, HASH is a single token (becase it is shared with color: #fff and similar declarations)).
However, this should (P/* */#simpleid2 {color: red}).
This is tested in a special strict document.
Normal bolderbolderbolder.
Assuming, as will be the case on most OS's, that your font has more than one bold weight, the bold text above should appear at different weights.
600700900.
The three weights above, 600, 700 and 900, should, with most fonts, be rendered differently; not so in Mozilla.
serif italic
serif oblique
sans-serif italic
sans-serif oblique
Since, although italic is matched by oblique, oblique is not matched by italic, the italic and oblique fonts should not be rendered the same - if no oblique style is available, the font should not be italic.
This should have massive overlap - not mere descender overlap (assuming the two pieces of text are rendered on different lines):
The code is:
<div style="margin: 100px 0; line-height: 0">
<span style="line-height: 5px; font-size: 205px">gggg</span>
<span style="font-size: 205px; line-height: 205px">AAAA</span>
</div>
Here it is with a forced (BR) line break:
text
text
The two pieces of text (and the two images) above should appear as one, since the font-size of the the DIV is 1 pixel, the line-height is 16px, and the image height is 15 pixels; since the bottom of the image is placed on the baseline, it is possible for the image to increase the size of the line box; however, since the font-size of the DIV is 1 pixel, the baseline of the DIV will not exceed this, and so the image shouldn't affect the line box height, and as a result the margin-top: -16px will be effective to place the two bits of text exactly on top of one another.
Mozilla requires generic font families (e.g., sans-serif) to be in lower case, even though, as with all CSS, they are case-insensitive - this should be monospace.
This text shouldn't have massive word-spacing; since letter-spacing is explicitly set and text-align: justify, the UA should ignore word-spacing in order to justify.
This should have the underline appropriate for a 200-pixel-high font (since text-decoration is 'inherited' but with the characteristics of the ancestor) - not so in Mozilla.
This should not be underlined because text-decoration only inherits to inline-level descendants, but it will be in Mozilla.
Text super.
The background of the element should be constant - vertical-align: super only moves the baseline of the box, not the box itself.
Here's ƒ uppercased: ƒ - in Mozilla the result is nothing.
Should have big word-spacing: word (single-word element with word-spacing).
1. (a) Find the order of Dijkstra's algorithm (4)
(b) Explain the significance of this. (6)
In the example above, Mozilla destroys the logical markup provided and moves content down a line.
This text should flow on both sides of the previous image; in Mozilla it will only flow to the opposite side to the float type; for example, in this case the opposite of float: left is to allow flow to the right of the float.
Mozilla has problems with the alignment of floats. See test page and also: test page 2.
When certain fixed positioning examples are scrolled, the text scrolls but the old text doesn't move so the appearance is of an ever growing blur. See: one of RichInStyle.com's test pages.
Even though BODY's margins should not apply to fixed elements since these are positioned relative to the left of the viewport, in some cases they are. See: one of RichInStyle.com's test pages.
For some reason when certain scrollbars are clicked, they disappear, or else the menu appears on top of the document (i.e., File/Edit (or local/platform-equivalent)). See: one of RichInStyle.com's test pages (the footnotes section at the bottom, which should have a scroller - try clicking it).
Under certain circumstances the specified content simply won't be rendered - see one of RichInStyle.com's test pages.
See one of RichInStyle.com's test pages, which has the fixed elements overlaying content that occurs later (the content that says 'This is filler') than them in the document tree, which is wrong since default stack order is document tree order in the absence of a contrary declaration.
This element, which is specified as having a solid inverted outline, will instead have a black one
This element, which is specified as having a solid outline, won't have one at all, since outline resets outline-color to its initial value, invert, which is rendered as transparent by Mozilla.
The content of this inline element spans several formatted lines (at least it should, provided that you haven't got some absurdly high resolution and vast monitor that means that almost any paragraph of non-Dickensian proportions will be rendered on a single line), and its outline should be rendered as the minimum connector that surrounds the text, but in Mozilla it will be rendered as an enclosed border on a per line box basis.
This has been specified as having an animated 'RichInStyle' cursor, and failing that a static one, but in Mozilla will have neither.
This is a control.
There is a DIV below with a P inside it. The DIV has overflow: scroll, the P, margin-left: -10px. As a result, the scroller should allow you to scroll to the left to view the 10 pixels of P (probably the 'T') that overflow the left of the DIV.
The left of this should be scrolled.
This is the control image:
The above image should have the same width as the first image except there should be a scroll bar with which to view the remainder.
The above image should either
This, which should have a '1' for a list-item, will instead have '0.'
This list marker will be aligned with the bottom of the collapsed margin between it and the previous element rather than with the first line box in the principal box of the P element.
The rule below has 50 pixels of top padding and 50 pixels of bottom padding. This means that there should be 100 pixels of space inside the border - not so in Mozilla - it is instead applied as a margin.
Bugzilla entry: 2590.
Mozilla does not apply border-color to horizontal rules.
Bugzilla entry: 2590.
| This has font-size: 100px on the DIV that encloses this TABLE; however, because Mozilla is in 'compatibility' mode (thanks to the use of the transitional dtd), it will be the same size as the rest of the document. |
Bugzilla entry: 1044
Bugzilla entry: 1044 (only en passant).
| This column is specified as having a red background, but in Mozilla it won't be red since it doesn't support backgrounds on columns in compatibility mode. |
| This table has been specifed as having 100 pixels of padding and a red background, but the padding won't be red in Mozilla since it makes table padding transparent in compatibility mode. |
| This table row has been specified as having a 50 pixel padding, but in Mozilla it won't have. |
| This table cell should be relatively positioned 100 pixels above its normal position, but in Mozilla it won't be, since it doesn't support positiong on table cells. |
| This table row should be relatively positioned 100 pixels below its normal position, but in Mozilla it won't be, since it doesn't support positiong on table rows. |
| This table cell has width: 2000px, but that width won't be honored in Mozilla. |
The reason is that it clips table element widths to BODY if the width isn't actually needed.
| Cell 1 | Cell 2 |
The border-spacing of the table above should be red, but won't be in Mozilla because it makes border-spacing transparent in compatibility mode.
Mozilla's border-collapse: collapse implementation is completely broken. You can see a demonstration of this in one of RichInStyle.com's test pages.
This upload control has a red background: - not so in Mozilla.
This text box has a 100 pixel line height; this will cause Mozilla to make the initial content invisible:
This password box has a 100 pixel line height - not so in Mozilla: .
This upload control has a 100 pixel line height - not so in Mozilla: .
Here's a TEXTAREA with 100 pixels of padding; this will cause the destruction of the element:
The first letter of this shouldn't have any letter-spacing because letter-spacing does not apply to :first-letter, but it will have in Mozilla.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.