Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

[Fwd: RichInStyle.com]

0 views

Skip to first unread message

Erik van der Poel

unread,

Mar 7, 2000, 3:00:00 AM3/7/00

to mozilla...@mozilla.org

According to this message, Mozilla appears to have fewer CSS bugs than
the other major browsers.

Erik

Robert Kaiser

unread,

Mar 7, 2000, 3:00:00 AM3/7/00

> According to this message, Mozilla appears to have fewer CSS bugs than
> the other major browsers.

For a not-even-beta that's very good - but what build did he use? Would be
great to know.

And, if Mozilla should really be the best browser for a longer time, the list
at http://richinstyle.com/bugs/mozilla.html should be minimized to (almost)
zarro boogs.

If there are unreported bugs there, they should make their way into
BugZilla... Perhaps someone familiar with CSS should run through the list and
reports "unknown" bugs... (and perhaps someone familiar with current CSS bugs)

Robert Kaiser

Scott A. Colcord

unread,

Mar 7, 2000, 3:00:00 AM3/7/00

Wow...it seems they've done some hefty testing. Perhaps we could
work their test suites into the testing process for Mozilla somehow?

Take a look at the bug list they have for us...

http://www.richinstyle.com/bugs/mozilla.html

David Baron

unread,

Mar 7, 2000, 3:00:00 AM3/7/00

In article <38C519C8...@StarTrekMail.com>, Robert Kaiser wrote:
> And, if Mozilla should really be the best browser for a longer time, the list
> at http://richinstyle.com/bugs/mozilla.html should be minimized to (almost)
> zarro boogs.
>
> If there are unreported bugs there, they should make their way into
> BugZilla... Perhaps someone familiar with CSS should run through the list and
> reports "unknown" bugs... (and perhaps someone familiar with current CSS bugs)

I took a quick (about 10 minutes) look at the list of bugs. I think a
majority of the issues known are already in Bugzilla, but a good number
are not. However, I suspect a sizable proportion of those that are not
in Bugzilla (it's hard to tell excatly without looking in much more
detail) are not really bugs. I examined one test (character escapes)
in detail and I think only 2 of the 7 bugs listed are really bugs (and
I think those 2 are a regression from when I last tested escapes).

I might have a chance to go through this list sometime, although it
might be easier to split it between a bunch of people. However, I
could probably come up rather quickly with a list of the bugs in the
list that are already filed.

-David

--
L. David Baron Sophomore, Harvard (Physics) dba...@fas.harvard.edu
Links, SatPix, CSS, etc. <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC <URL: http://www.webstandards.org/css/ >

Matthew Brealey

unread,

Mar 7, 2000, 3:00:00 AM3/7/00

David Baron <dba...@is02.fas.harvard.edu> wrote in article
<slrn8caf2s...@is02.fas.harvard.edu>...

> However, I suspect a sizable proportion of those that are not
> in Bugzilla (it's hard to tell excatly without looking in much more
> detail) are not really bugs.

I don't think so. You mention one example, which has now been fixed. I
don't think you'll find any more

Matthew Brealey

unread,

Mar 7, 2000, 3:00:00 AM3/7/00

Robert Kaiser <Ka...@StarTrekMail.com> wrote in article
<38C519C8...@StarTrekMail.com>...

> For a not-even-beta that's very good - but what build did he use?
Would be
> great to know.

Sorry. I had meant to include this. The answer is the 15th November
Milestone. FYI, just as soon as I have written a Mozilla bug sheet (see
the IE4 and 5 ones for an example), I will update it within a day or
two of each milestone.

Matthew Brealey

unread,

Mar 8, 2000, 3:00:00 AM3/8/00

David Baron wrote:
> However, I suspect a sizable proportion of those that are not
> in Bugzilla (it's hard to tell excatly without looking in much more
> detail) are not really bugs.

Apart from the one example you cite, I'm pretty confident that all
(possibly I'm mistaken on one or two of the others as well) the rest are
bugs.

----------------------------------------
Please visit http://www.richinstyle.com
Featuring: CSS bug guides (more than 1000 CSS bugs) CSS Masterclass
HTML 4 guide CSS 1 guide CSS 2 guide Web-safe colorizer
CSS bug table More than 300 CSS test pages

Eric Krock

unread,

Mar 8, 2000, 3:00:00 AM3/8/00

to Matthew Brealey

Matthew, your site and list rock!!!

An idea: since
- all of Mozilla's bug reports are public and viewable as URLs, and
- your readers would probably love to be able to immediately check status
for each bug, and
- we'd like to make sure that all bugs you've found are reported and
resolved

... any chance that, perhaps in cooperation with some of our CSS1 bug gurus
who track the compliance bugs (e.g. dba...@fas.harvard.edu,
py8...@bath.ac.uk, and jr...@netscape.com), you could add for each bug a
link to the relevant bugzilla report?

BTW, if you do a query for the css1, css2, or css3 keyword, you'll get back
a list of known bugs for that spec (thanks to Ian's patient maintenance of
the list, among others'). Useful for cross-checking vs. your list.

Matthew Brealey wrote:

--
What have *YOU* done for web standards today?
http://www.mozilla.org/newlayout/bugathon.html

Are your JavaScript and CGIs ready for Nav5, IE5, and
HTTP 1.1 CONTENT_TYPE? Get the latest info at
http://developer.netscape.com/viewsource/krock_v5.html

Hints on upgrading web pages to support W3C standards:
http://sites.netscape.net/ekrock/standards.html

Have a question? Before you email me, first please check
http://sites.netscape.com/ekrock/answers.html

Robert O'Callahan

unread,

Mar 8, 2000, 3:00:00 AM3/8/00

David Baron wrote:
> The page <URL: http://www.richinstyle.com/bugs/mozilla.html
> contains:
> | Bug 2: cursor: url() unsupported
> |
> | Mozilla does not support cursor: url().
>
> IMO, not a bug, since there's no XP cursor format. What format did
> you test? Why would you expect mozilla to support that format?

If standard image formats were supported, with the hotspot assumed to be
in the centre, that would be simple and useful. In fact, I can't think of
any reasonable cursor effect that one couldn't achieve.

Rob
--
[Robert O'Callahan http://www.cs.cmu.edu/~roc 6th year CMU CS PhD student
"I have seen the burden God has laid on men. He has made everything
beautiful in its time. He has also set eternity in the hearts of men; yet
they cannot fathom what God has done from beginning to end."
--- Ecclesiastes 3:10-11]

Troy Chevalier

unread,

Mar 8, 2000, 3:00:00 AM3/8/00

David Baron wrote:

> | Canvas backgrounds
> |
> | Bug 2: don't cover the whole of the canvas when HTML {margin != 0}
> |
> | When HTML has a margin greater than 0, backgrounds will not fully
> | cover the canvas. This is correct because although the spec is unclear
> | and wrong on this subject, the one thing that it does say with
> | certainty is that 'the background of the root element covers the whole
> | of the canvas.'
>
> Bug 13473 (WONTFIX).

I am going to fix that bug one of these days. :-)

-Troy

David Baron

unread,

Mar 9, 2000, 3:00:00 AM3/9/00

In article <38C6A7...@richinstyle.com>, Matthew Brealey wrote:
> David Baron wrote:
> > However, I suspect a sizable proportion of those that are not
> > in Bugzilla (it's hard to tell excatly without looking in much more
> > detail) are not really bugs.
>
> Apart from the one example you cite, I'm pretty confident that all
> (possibly I'm mistaken on one or two of the others as well) the rest are
> bugs.

There have been a number of large CSS test suites, developed by people
such as Eric Meyer, Haakon Lie, Tim Boland, Daniel Glazman, Ian
Hickson, and me, and all of these suites have had large numbers of
errors in their early versions (and probably still have a fair
number). It's impossible for one person a test suite of this size
without errors. You have a lot of good tests in the suite, and the
usual number of errors along with them.

Anyway, I went through the list of mozilla bugs and looked at some of
the test pages, but not all. Below are just quick comments connecting
these statements to bugs that I'm aware of, and commenting on some
errors in the comments or in the pages that I looked at. There are
bugs that I don't know about, so my "should be filed" comments aren't
final.

I do *not* have time to analyze, simplify, and file these bugs now.
Someone else needs to help here.

-David

The contents of the page are posted with Matthew Brealey's permission,
so that I can comment on them.

The page <URL: http://www.richinstyle.com/bugs/mozilla.html > contains:
|

(2) This and another bug (the last test) on that page should be filed.

| Alternate style sheet
|
| Bug 2: title attribute treated as case-insensitive
|
| Mozilla treats the title attribute, as used on LINK, as
| case-insensitive (it also treats it as case-insensitive for the
| attribute selector).

This may be covered by bug 12386, but perhaps should be a separate bug.

| Bug 3: incomplete selection mechanism
|
| Mozilla does not provide an adequate means of selecting alternate
| style sheets - it does not give the user access to their titles. In
| addition, it appears to allow the selection of preferred style sheets,
| which is wrong.

Bug 6782

I think mozilla should match implementations here, and the spec should
be changed. I've proposed this.

Not a bug (CSS2 5.2).

Should be filed, I think.

Should be filed, I think.

Bug 12398 and -unsupported CSS2 features should not be filed as bugs,
unless you think there's a compelling need for the feature-.

| ___________________________________
|
| Key concepts
|
| Escapes
|
| Bug 8: escapes not fully supported
|
| The following cases have been found to be problematic:
| 1. This should be red({lands-end: \}; color: red;}).
| 2. This should not be red (P\.class: red").
|
| When used to cancel newlines, it seems to be entirely non-problematic.

(2) Needs to be filed.
(5 removed) Not bugs.

| Comments
|
| Bug 9: not supported inside simple selectors
|
| Mozilla does not support comments inside simple selectors (e.g., P/*
| */.class).

Should be filed, I think.

|
| URIs
|
| Bug 10: line feeds not permitted around URIs
|
| Mozilla does not permit line feeds around URIs (which are valid in the
| {w} macro); for example, background: url(
| gif.gif);. It notably does support spaces, tabs, etc.

Should be filed, I think.

|
| Unclosed P elements
|
| Bug 11: HR and TABLE elements treated as inside them
|
| Mozilla treats HR and TABLE elements as inside unclosed P elements,
| which is incorrect because they are block elements, thereby implying
| the end of the P.

There is/was an existing bug on this, I think - it should probably be
fixed in strict mode, but not compat mode. Your testcases trigger
compat mode. It should be tested in strict mode.

| _________________________________________________________________
|
| Section B - Bugs with units
|
| Exes
|
| Bug 1: support unreliable
|
| Although Mozilla's ex is in some measure commensurate to the x-height
| of the font, it does not always seem to represent the true x-height.
| See [36]one of RichInStyle.com's test pages for a demonstration.

Probably should not be filed since font metrics are even less reliable
than Mozilla (or so I've heard).

| _________________________________________________________________
|
| Part 1 - Topic related issues - must read if you use the section involved
|
| Section C - Color and background bugs
|
| Background positions
|
| Bug 1: when only one <length> or <percentage> provided, declaration
| ignored
|
| Although CSS states that when only one value is provided on
| background-position, the other is set to 50%, in Mozilla, when a
| length or % is specified on its own, 50% is not implied for the other
| as it should be, but instead the declaration is ignored.

This should be filed, I think.

| Canvas backgrounds
|
| Bug 2: don't cover the whole of the canvas when HTML {margin != 0}
|
| When HTML has a margin greater than 0, backgrounds will not fully
| cover the canvas. This is correct because although the spec is unclear
| and wrong on this subject, the one thing that it does say with
| certainty is that 'the background of the root element covers the whole
| of the canvas.'

Bug 13473 (WONTFIX).

| _________________________________________________________________
|
| Section D - Fonts
|
| Font sizes
|
| Bug 1: larger doesn't result in next largest in font size table
|
| Although larger with an inherited font size corresponding to one of
| the 7 font size keywords should result in the next largest of these,
| in Mozilla it does not - there is a small difference. Note that
| smaller works fine.

This could be filed, although one could argue whether it's a bug or not.

Not a bug.

|
| Bug 3: numeric font weights 600-900 rendered as plain bold
|
| Mozilla does not support the numerical font weights, instead rendering
| 600-900 as bold and 100-500 as normal.

Bug 972.

| Bug 4: lighter gives next lower number, not next most bold font
|
| Although Mozilla renders the font weights 600-900 as the same bold, it
| increments and decrements the weight number linearly, so font-weight:
| lighter with an inherited 900, which Mozilla renders as bold, will
| result in 800, which Mozilla also renders as bold. Note that this bug
| does not apply to bolder - bolder than inherited 100 results in bold,
| as it should.

Bug 12453.

|
| Font styles
|
| Bug 5: oblique rendered as italic
|
| Mozilla renders font-style: oblique as italic. This is wrong because
| the CSS spec states that "'italic' will be satisfied if there is
| either a face in the UA's font database labeled with the CSS keyword
| 'italic' (preferred) or 'oblique'. Otherwise the values must be
| matched exactly or font-style will fail."

I think the spec, as currently written, says either that no character
should be displayed or that the character should be displayed in the
inherited or UA default font. That's ridiculous, so I'd say this isn't
a bug unless you have a better interpretation of the spec.

| UI fonts
|
| Bug 6: destroyed
|
| Mozilla destroys all invalid font declarations - instead of ignoring
| them, it applies font-family: serif. Thus font-family: captiontext,
| which is valid CSS would be treated as font-family: serif.

Bug 3371. The parsing should be disabled if the support doesn't
materialize.

Bug 30127.

| Line heights
|
| Bug 8: % and <number> interpreted relative to default line-height, not
| to font-size
|
| Mozilla completely ruins line heights in % or <number>, interpreting
| the values relative to the default line height for the font size,
| instead of relative to the actual value for font size as it should.
| The way to avoid this is to use the em.

I would argue that this is the correct interpretation for <number>,
which I think should depend on the actual value of the font-size, but
not for %. However, I think erik is planning to fix it in both cases,
anyway, although I don't know if there is a bug.

| Bug 9: height of line boxes containing replaced elements wrong
|
| Mozilla gets the height of line boxes that contain replaced elements
| wrong (but only minorly - it won't affect non-precision applications)
| - it tends to get them a couple of pixels wrong; to see a
| demonstration, have a look at [37]one of RichInStyle.com's test pages.

I don't see which test has the problem.

| Bug 10: zero line heights not supported
|
| Mozilla does not support zero line heights, insisting on increasing
| them slightly.

This has since been fixed (bug 15428).

| Section E - Text bugs
|
| text-align
|
| Bug 1: justify destroyed
|
| Text-align: justify is destroyed. Although it does not implement
| text-align: justify, it does ignore word-spacing when it is set; while
| word-spacing should be ignored when text-align: justify is set, it
| should not be unless text-align: justify is actually supported.

Bug 588.

|
| Text-decoration
|
| Bug 2: size of text decoration that of descendant element, not ancestor
|
| Mozilla determines the size of text decoration by that of the
| descendant element, not that of the ancestor. For example, <P
| style="text-decoration: underline; font-size: 12px"><SPAN
| style="font-size: 100px">, which should result in the text decoration
| being the size appropriate for the ancestor, actually results in the
| size appropriate for the descendant.

Bug 1777.

| Bug 3: inherited to block descendants
|
| Although the CSS specification states that text-decoration is only
| inherited to inline descendants, Mozilla inherits it to block
| descendants.

I don't see the test with the problem.

| vertical-align
|
| Bug 4: sub and super move box, not baseline
|
| In Mozilla, vertical-align: sub and super move the box, not the
| baseline - the spec states that sub and super move the baseline to the
| appropriate place for subscripts/superscripts of the parent box, but
| in Mozilla it moves the box so that the baseline is in the appropriate
| place for subscripts/superscripts.

I don't see the test with the problem. I also think you said something
backwards here. However, the test seems to be changing under my feet...

| Text-transform
|
| Bug 5: f uppercased results in nothing
|
| f uppercased results in nothing. This is incorrect because although
| part of Latin Extended-B, which need not be text transformed (only
| Latin-1 is required), it should, at worst (if the UA doesn't want to
| text-transform it), be left as-is rather than hidden. Note,
| incidentally, that Mozilla does tranform Greek letters (which are
| optional), but leaves Latin Extended-A as-is.

There are some bugs here. They should be filed against i18n.

| _________________________________________________________________
|
| Section F - Margins and padding
|
| Padding
|
| Bug 1: vertical padding not applied to inline text elements
| Mozilla does not apply vertical padding to inline text elements.

Not a bug: error in test (part) and unjustified assumptions about
painting order (part), I think. I didn't look in that much detail.

| Bug 2: padding applied as margins to replaced elements
|
| Mozilla applies padding as margins for replaced elements; i.e., it
| makes them transparent rather than the color of the element's
| background.

Not a bug. Test is invalid HTML.

| _________________________________________________________________
|
| Section G - Borders
| _________________________________________________________________
|
| Section H - Floats
|
| Bug 1: inline right floats moved down a line unless they are the first
| thing in their line
|
| Mozilla does not float right floats to the right of their line unless
| they are the first thing in their line; for example, Some text <SPAN
| style="float: right; width: whatever"> doesn't work correctly, but the
| same thing with the right-float as the first thing on its line works
| fine. There is a demo of this [38]in one of RichInStyle.com's test
| pages.

There is general (?) consensus that the CSS float rules should be
changed to allow this.

| Bug 2: text only flows around one side of a float
|
| Mozilla only supports text flow.

I don't think this is a bug. There are multiple ways that are possible
for text to flow around a float that ends up in the middle (because of
other, shorter, floats next to it). But I'm not sure exactly what test
page this is.

| Bug 3: non-floated elements interacting with floated ones buggy
|
| The interaction of floated and non-floated elements is badly buggy.
| There are probably many bugs here. There is a demonstration of these
| bugs [39]in one of RichInStyle.com's test pages.

There are probably a few bugs here. There are also a number of bugs
filed on floats.

| Bug 4: empty floated elements overlapped with by non-floated elements
| place top of non-floated content at top of empty floated element
|
| There is a bug whereby empty floated elements assigned a height with
| height are not overlapped with correctly by subsequent non-floating
| elements, the non-floating content is placed inside the floated
| element; there is a demonstration [40]in another of RichInStyle.com's
| test pages.

I can't tell which test you're talking about.

|
| Bug 5: horizontal rules shortened
|
| When horizontal rules overlap with floats, instead of overlapping,
| they are shortened where they overlap.

Bug 18754.

| _________________________________________________________________
|
| Section I - Positioning
|
| Bug 1: fixed positioning badly broken
|
| Fixed positioning is badly broken. There are some demonstrations of
| this in RichInStyle.com's test pages - [41]1, [42]2 and [43]3. Many
| examples completely destroy pages due to horrendous display bugs;
| others destroy them due to parts of the page being thrown to odd
| locations or not rendered.

Fixed positioning has been improved recently. The following bugs
remain: 4209, 5195, 28742. I don't know if these cover the problems
described.

In other words, 'outline-color: invert' isn't supported yet. A bug
should be filed if outlines are to stay in. I don't think it would be
hard to implement.

| Cursors

|
| Bug 2: cursor: url() unsupported
|
| Mozilla does not support cursor: url().

IMO, not a bug, since there's no XP cursor format. What format did
you test? Why would you expect mozilla to support that format?

(8) bug 1916

|
| Overflow
|
| Bug 10: scrollbar on scroll and auto buggy
|
| The scrollbar on overflow: scroll and auto is always initially at the
| top and left. This means that when content overflows to the left or
| top of an element, it cannot be viewed.

I've been meaning to file a bug on this for about a year, but I haven't
yet...

| Bug 11: scroll and auto break clip
|
| Mozilla breaks clip when overflow: scroll or overflow: auto, treating
| the clipping region as no clipping region at all when either setting
| is set.

The spec doesn't define the correct behavior. What behavior do you
expect? See bug 11159, which covers some related issues.

Are you sure the problem isn't really bug 10915? Is it fixed now? I
don't see the example.

|
| Visibility
|
| Bug 13: collapse not supported on elements other than tables
|
| Although the CSS spec states that on elements other than tables,
| visibility: collapse should be treated as visibility: hidden, Mozilla
| simply ignores it.

Bug 21701.

Bug 4522, I think.

| List style types
|
| Bug 2: dot placed after marker on ordered list types
|
| Mozilla places a dot after the list marker on ordered list types; for
| example, it renders 1., 2., 3. instead of 1, 2, 3. This is incorrect
| according to the spec (because to do so wrecks the content property).

Not a bug. How does it wreck the content property?

Should be filed, I think.

| Bug 4: lower-latin causes display glitch
|
| For some reason, list-style: lower-latin causes an annoying display
| glitch. There is a [47]demonstration of this in one of
| RichInStyle.com's test pages.

Works for me.

|
| List styling
|
| Bug 5: text-align moves list marker
|
| Mozilla allows text-align to move the list marker. This is incorrect
| because list markers are placed in the marker box, whose position is
| not affected by the text-align of the principal box.

Bug 25291. Mozilla also incorrectly moves list markers around floats.
This was done to "fix" bug 802. This may be legal in CSS3 based on
changes in a UA stylesheet.

|
| Bug 6: clear not supported on LI
|
| Mozilla does not support clear on LI.

Should be filed, I think.

| _________________________________________________________________
|
| Section L - Horizontal rule bugs
|
| Bug 1: padding applied incorrectly to horizontal rules
|
| Mozilla does not apply padding correctly to horizontal rules -
| vertical padding should increase the height of horizontal rules
| because it implements them as a border around whitespace, but doesn't,
| instead being treated as a margin.
|
| Bug 2: border-color not applied to horizontal rules
|
| Mozilla does not apply border-color to horizontal rules.

(2) Not a bug. HR does not fit within the CSS formatting model (it
does not act like a block), so it's really perfectly reasonable for
color to apply, rather than border-color. See also bug 2590 (REMIND).

| _________________________________________________________________
|
| Section M - Table bugs
|
| Inheritance
|
| Bug 1: inheritance into TD and TH
|
| Mozilla inherits all properties from BODY into TD and TH instead of
| from the ancestor; for example, <DIV style="font-size:
| 100px"><TABLE></DIV> would result in BODY's font-size being inherited
| instead of the parent element. This would apply equally to color or
| any other inheritable property.

Bug 1044.

|
| Bug 2: inheritance into CAPTION
|
| Mozilla doesn't inherit into CAPTION at all, instead always applying
| its browser-default values.

Bug 1044 (perhaps this should be a separate bug, though?).

| Margins
|
| Bug 3: on captions, cause crash
|
| When specified on captions, margins cause the browser to crash. There
| is a [48]demonstration of this in one of RichInStyle.com's test pages.

Works for me.

It's done this way in quirks mode, because 4.x didn't support columns.
I think that's silly, and a bug should be filed. See bug 4510 for a bit
of the previous discussion.

Not a bug.

| Bug 6: buggy on tables
|
| Mozilla makes table padding transparent instead of giving it the
| table's background-color.

Eh? Tables can't have padding. If they do, that's a bug.

Bug 2479, bug 1289.

| Text-align
|
| Bug 8: affects tables
|
| Mozilla allows text-align: center to affect the position of tables.
| This is wrong. Tables are block elements, and text-align only affects
| inline content inside block elements - not the block itself.

Bug 11384, bug 7112 (FIXED). Is this fixed?

| Display
|
| Bug 9: display: block not correctly honored on table elements
|
| Mozilla does not correctly honor display: block on table elements. For
| example, TABLE, TR, TD, TH {display: block} is not ignored (as is an
| option) or honored as display: block, but instead results in the
| elements being made unreadable.

Bug 2479.

|
| Bug 10: table keywords destroyed
|
| Mozilla destroys the table keywords, not honoring them and also
| suppressing inheritance into these elements when they are specified.

I don't understand this sentence at all. However, I think it's bug
2479.

There may or may not already be a bug on this.

| Bug 12: widths clipped to avoid overflowing BODY
|
| Mozilla clips table element widths to prevent them overflowing BODY
| unless the width specified is actually needed; for example, TD {width:
| 1000px} would be clipped to prevent the table overflowing the BODY. It
| does not, however, clip widths when the width of the content requires
| it.

I guess a bug should be filed.

How does it act in strict mode?

See bugs 2436, 3000, 9191, 12462, 15248, 22897. Does that cover it?

| _________________________________________________________________
|
| Section N - Form bugs
|
| Bug 1: background not applied to SELECT, TEXTAREA, INPUT type="password"
|
| Mozilla does not apply backgrounds to SELECT (although it does on
| OPTION, strangely), TEXTAREA, INPUT type="password" or the text box or
| submit button of INPUT type="file".
|
| Bug 2: background colors not supported on TEXTAREA
|
| Mozilla only applies background images to TEXTAREA - not background
| colors.
|
| Bug 3: line heights do not increase the size of INPUT type="text"
|
| If you specify a line height that is too large on INPUT type="text",
| it will be honored but the height of the line box won't be increased
| to compensate, thereby rendering the text invisible.
|
| Bug 4: line heights unsupported on INPUT type="password" or the text box
| on INPUT type="file"
|
| If you specify a line height on INPUT type="password", Mozilla will
| ignore it. In addition, it does not apply them to the text box on
| INPUT type="file" (but it does not on the button.
|
| Bug 5: text-decoration applied in green on TEXTAREA
|
| For some reason, when TEXTAREAs are text decorated (e.g., underlined),
| they are underlined in green.
|
| Bug 6: white-space and text-align not supported on TEXTAREA
|
| Mozilla does not support white-space or text-align (i.e., to affect
| the alignment of the contents) on TEXTAREA.
|
| Bug 7: vertical-align unsupported on form elements
|
| Mozila does not support vertical-align on form elements.
|
| Bug 8: padding destroyed on SELECT, OPTION and TEXTAREA
|
| Mozilla destroys padding on SELECT, TEXTAREA and OPTION, resulting in
| the elements being broken. There is a [50]demonstration in one of
| RichInStyle.com's bug pages.
|
| Bug 9: borders destroyed on INPUT type="password", type="text" and
| TEXTAREA
|
| Mozilla destroys borders on INPUT type="password", type="text" and
| TEXTAERA, destroying these controls when it is used. There is a
| [51]demonstration in one of RichInStyle.com's bug pages.

(9) These should probably be filed, although some may already be filed.

| Bug 10: display: inline on OPTION destroys
|
| Mozilla destroys SELECT controls when an OPTION in them has display:
| inline.

What do you mean by destroys? This may or may not be a bug.

| Bug 11: width and height buggy on INPUT type="file"
|
| Width and height are not correctly honored on INPUT type="file" - they
| appear to only set the size of the button, not the text box. In
| addition, even the button is not set to the requested height and
| width.

What should they set? Everyone will probably have a different opinion.
CSS is not well designed to handle some form controls.

Should probably be filed, although it's rather obscure (as are many
of these)...

| _________________________________________________________________
|
| Part 3 - Error correction bugs - bugs, but inconsequential unless you produce
| invalid style sheets
|
| Section O - validation bugs
|
| 1. Mozilla fails to treat </ as terminating the STYLE element, as is
| specified by HTML.
| 2. Mozilla allows character references in IDs, but they aren't valid
| there.

(2)Bugs should probably be filed, although I'm not sure whether fixing them
will cause problems.

| 3. Mozilla allows classes to begin with hyphens.

Bug 12385 (LATER). This will likely be changed in CSS3.

| 4. It allows attribute="any " to be matched by [attribute=any ],
| which is incorrect since the space there is an S token, which does
| not (and cannot) form part of the IDENT - around IDENTs spaces
| have no meaning.
| 5. It allows attribute="any" to be matched by [attribute="any "],
| which is incorrect since the spaces inside the string have
| meaning.
| 6. It allows attribute="any" to be matched by [attribute="any "],
| which is incorrect since the spaces inside the string have meaning
| and should not be ignored.

(3) I think these should be filed.

| 7. It applies letter-spacing to :first-letter, but it shouldn't have
| an effect.

Should be filed.

| 8. It fails to ignore P elements (i.e., ignore them from its document
| tree for the adjacent sibling combinator).

You mean empty P elements? The spec says "should", not "must". And
I think the current hacks to do this should be taken out - I think
all that was intended was that margins collapse through P elements. I
should ask on www-html.

| 9. It will render rulesets with missing closing braces

Should be filed, I think.

| 10. It treats missing units as pixels.

I think it does this only in compat mode. If it does it in strict mode,
file a bug.

| 11. It renders font-family: "monospace", an invalid declaration, in
| Times New Roman.

Why is this a bug? The declaration is not invalid, it just requests that
the browser use a font *with the name* monospace, and if no such font
exists, the browser should use the default or inherited font.

| 12. It applies white-space to inline elements, but it should only
| apply to block ones.

Should be filed, I guess, although this may be changed for CSS3.

| 13. It ignores rulesets that contain null selectors; for example, it
| ignores .class1, , .class2 {color: red}, which is incorrect
| because simple_selector is (partly) defined by element_name.

Not a bug (CSS2 5.2 and 5.3).

| 14. It disregards the case of proprietary font names.

This is probably needed for compatibility with different systems and
with current use of CSS. I think it would be a bug to consider case on
any operating system that cannot have multiple fonts that have the same
name but differ only in capitalization. Can any operating systems have
such fonts?

| 15. It allows comments between ! and important, which is incorrect
| because IMPORTANT_SYM is a single token and the whitespace between
| it is {w}, a macro not a token - comments are only valid between
| tokens - not inside them.

I think you're crossing the chapter 4 grammar and the appendix D
grammar. I don't think this is a bug. The appendix D grammar
(which defines IMPORTANT_SYM) handles comments in the tokenizer.

| 16. x

| 17. It allows comments inside the URI token, which isn't valid -
| comments are only valid between tokens - not inside them.

Same comment as on 15.

| 18. It allows more than one decimal place on rgb% (e.g., rgb(99.99%,
| 0%, 0%), but this isn't valid.

Where does the spec say this isn't valid?

| 19. It allows the % to be omitted when 0% on rgb%, but this isn't
| valid - PERCENTAGE is {num}%.
| 20. It allows mixing of numbers and percentages; for example, it will
| render rgb(0%, 100, 100) as rgb(100, 100, 100).

These two are the same bug, which should be filed.

| 21. It allows non-integer values on rgb(nnn, nnn, nnn).

This should be filed.

| 22. It allows spaces before and after / on the font shorthand, but
| this is invalid.

What says that this is invalid?

| 23. It allows white-space on inline elements, on which they are not
| valid. I suspect that this might be because of an error in the W3C
| test suite, which incorrectly states that they are valid on these
| elements.

Already listed above

| 24. It allows hidden (as none) on outline-style, but this isn't valid.

This should be filed.

| 25. It applies table-layout: fixed even when the table hasn't been
| given a specified width.

Bug 10269 (FIXED).

| 26. It allows URIs other than first on the the HTTP Link header, which
| is invalid since Link is defined as "Link" ":" #("<" URI ">" *(
| ";" link-param ) ; i.e., URI MUST come first.
| 27. It allows ' to be used as quotes around the REL value on the HTTP
| Link header, which is invalid (only " may be used).

These should be filed.

Pierre Saslawsky

unread,

Mar 9, 2000, 3:00:00 AM3/9/00

to Matthew Brealey

Matthew,

Of course, I'm joining Eric to congratulate you for your site. Sincerely I
do. Now, the critics...

As a programmer trying to fix the bugs in the browser, I'm finding the site
rather difficult to use, especially compared to the W3C test suite.

The main problem is that all the test pages import large stylesheets, some of
these importing child sheets, and it makes it painful to isolate a bug and
create a testcase. This aspect is not negligible when you have to deal with
more than 100 bugs. On a secondary note, the size of the style sheets also
raises doubts on the accuracy of some of the bugs you report since they may
very well result from a combination of other problems.

The navigation through the test pages is a bit awkward:
- Half the screen (on a 21" monitor) is used by the banner and the index. The
font sizes in most test pages are really big too, as well as many images or
block elements. It forces you to scroll a lot. A very few pages actually fit
in one screen.
- The index doesn't show which Core Test, Advanced Test or particular Test is
currently displayed. A system with 2 frames would be much better (1 for the
index shown as a tree + 1 for the test page itself).
- In the bug pages, each bug should be linked to the corresponding test page.

Finally, it may be subjective but I find some descriptions in the test pages
a bit verbose and it's not as obvious as on the W3C Test Suite to tell
whether the test is rendered correctly. The choice of some colors (black on
blue background) doesn't help too.

--
Overall, I find your site appealing but it doesn't sustain very well the
heavy use that a Test Suite calls for. On the different points I mentioned
above, the W3C test suite is more appropriate as an everyday tool. It's
easier to navigate through the test pages, spot a bug and pinpoint it since
the page itself can be used as a testcase in the bug report.

I hope these notes will help you to make your site even better. It certainly
represents an impressive amount of work and you deserve a round of applause
from the community.

Pierre

Eric Krock wrote:
>
> Matthew, your site and list rock!!!
>
> An idea: since
> - all of Mozilla's bug reports are public and viewable as URLs, and
> - your readers would probably love to be able to immediately check status
> for each bug, and
> - we'd like to make sure that all bugs you've found are reported and
> resolved
>
> ... any chance that, perhaps in cooperation with some of our CSS1 bug gurus
> who track the compliance bugs (e.g. dba...@fas.harvard.edu,
> py8...@bath.ac.uk, and jr...@netscape.com), you could add for each bug a
> link to the relevant bugzilla report?
>
> BTW, if you do a query for the css1, css2, or css3 keyword, you'll get back
> a list of known bugs for that spec (thanks to Ian's patient maintenance of
> the list, among others'). Useful for cross-checking vs. your list.
>

--
Pierre Saslawsky <pie...@netscape.com>
French Style

Matthew Brealey

unread,

Mar 9, 2000, 3:00:00 AM3/9/00

Yes, sorry. I was going purely on the grammar.

> |
> | Dash-match selector
> |
> | Note: Mozilla does not support the dash-match or :lang selector
> |
> | Mozilla does not support the dash-match selector (e.g., :lang|=fr) or
> | the :lang selector (e.g., :lang()).
>
> Bug 12398 and -unsupported CSS2 features should not be filed as bugs,
> unless you think there's a compelling need for the feature-.

It's noted as a 'Note' not a bug. Bugs are signified by 'Bug'. However,
its inclusion was erroneous. (My) General testing policy is that any
incompliance with CSS1 is a bug, but CSS2 features are only noted if
they are partially supported are buggy. However, in general 'Note's are
only used where you might expect something to happen but it doesn't, but
where the noted behaviour is not a bug. In fact this probably doesn't
even deserve a Note, because you wouldn't necessarily expect support (to
see whether it is supported you should look at the bug table
[http://richinstyle.com/bugs/table.html]); I will remove this from the
next version of the document.

> | Unclosed P elements
> |
> | Bug 11: HR and TABLE elements treated as inside them
> |
> | Mozilla treats HR and TABLE elements as inside unclosed P elements,
> | which is incorrect because they are block elements, thereby implying
> | the end of the P.
>
> There is/was an existing bug on this, I think - it should probably be
> fixed in strict mode, but not compat mode. Your testcases trigger
> compat mode. It should be tested in strict mode.

Yes. The whole suite needs a redesign.

It is:
<relative-size>
A <relative-size> keyword is interpreted relative to the table of
font sizes and the font size of the parent element. ...

For example, if the parent element has a font size of 'medium', a
value of 'larger' will make the font size of the current element be
'large'. If the parent element's size is not close to a table entry, the
user agent is free to interpolate between table entries or round off to
the closest one. The user agent may have to extrapolate table values if
the numerical value goes beyond the keywords.

> | Font weights
> |
> | Bug 2: bolder rendered as bold
> |
> | Mozilla renders bolder as bold.
>
> Not a bug.

It is, because bolder should result in the next boldest weight in the
font. In Mozilla it _always_ results in plain (700) bold - never 600 or
800/900.

> | Bug 5: oblique rendered as italic
> |
> | Mozilla renders font-style: oblique as italic. This is wrong because
> | the CSS spec states that "'italic' will be satisfied if there is
> | either a face in the UA's font database labeled with the CSS keyword
> | 'italic' (preferred) or 'oblique'. Otherwise the values must be
> | matched exactly or font-style will fail."
>
> I think the spec, as currently written, says either that no character
> should be displayed or that the character should be displayed in the
> inherited or UA default font. That's ridiculous, so I'd say this isn't
> a bug unless you have a better interpretation of the spec.

The spec is plain that oblique isn't matched by italic. The result
suggested might be absurd, but there isn't an alternative option.

> | Line heights
> |
> | Bug 8: % and <number> interpreted relative to default line-height, not
> | to font-size
> |
> | Mozilla completely ruins line heights in % or <number>, interpreting
> | the values relative to the default line height for the font size,
> | instead of relative to the actual value for font size as it should.
> | The way to avoid this is to use the em.
>
> I would argue that this is the correct interpretation for <number>,

Why? The spec is quite plain. <number> is calculated wrt the font size.

> | Bug 9: height of line boxes containing replaced elements wrong
> |
> | Mozilla gets the height of line boxes that contain replaced elements
> | wrong (but only minorly - it won't affect non-precision applications)
> | - it tends to get them a couple of pixels wrong; to see a
> | demonstration, have a look at [37]one of RichInStyle.com's test pages.
>
> I don't see which test has the problem.

This one:
Some text here
And some more here.

Some text here
And some more here.
There are two elements above; it should be apparent as such (the blue
text should be below the green) - although there is a margin-top: -100px
on the lower element, because it is baseline-aligned, this won't work -
see the diagram below:

+---------+
|iiiiiiiii|
|iiiiiiiii|
|iiiiiiiii|
|iiiiiiiii|
|iiiiiiiii|
|iiiiiiiii|
+---------+
|iiiiiiiii|
|iiiiiiiii|
|iiiiiiiii|
|iiiiiiiii|
|---------|
|---------|

The one in http://www.richinstyle.com/test/text/textdecoration.html just
above the 'Advanced tests' heading, which reads 'This should not be
underlined, since t-d only spans descendant inline elements.'

> | vertical-align
> |
> | Bug 4: sub and super move box, not baseline
> |
> | In Mozilla, vertical-align: sub and super move the box, not the
> | baseline - the spec states that sub and super move the baseline to the
> | appropriate place for subscripts/superscripts of the parent box, but
> | in Mozilla it moves the box so that the baseline is in the appropriate
> | place for subscripts/superscripts.
>
> I don't see the test with the problem.

The first few on http://www.richinstyle.com/test/text/linebox.html

> I also think you said something
> backwards here.

> However, the test seems to be changing under my feet...

What?

> | Section F - Margins and padding
> |
> | Padding
> |
> | Bug 1: vertical padding not applied to inline text elements
> | Mozilla does not apply vertical padding to inline text elements.
>
> Not a bug: error in test (part) and unjustified assumptions about
> painting order (part), I think.

It is a bug. Padding has a background colour, and regardless of painting
order, that should be rendered. In Mozilla, no padding, whether on top
or underneath the text, is rendered.

In addition, the unjustified assumptions are not unjustified at all -
the only 'assumption' is that the text is rendered from top to bottom,
which is necessarily true.

Furthermore, I don't know what you think the error is, so I can't
correct it.

Really? How so?

> | Section H - Floats
> |
> | Bug 1: inline right floats moved down a line unless they are the first
> | thing in their line
> |
> | Mozilla does not float right floats to the right of their line unless
> | they are the first thing in their line; for example, Some text <SPAN
> | style="float: right; width: whatever"> doesn't work correctly, but the
> | same thing with the right-float as the first thing on its line works
> | fine. There is a demo of this [38]in one of RichInStyle.com's test
> | pages.
>
> There is general (?) consensus that the CSS float rules should be
> changed to allow this.

Allow what? The text to be floated to the wrong line, which means that
you have to use illogical markup that doesn't degrade gracefully?

>
> | Bug 2: text only flows around one side of a float
> |
> | Mozilla only supports text flow.
>
> I don't think this is a bug. There are multiple ways that are possible
> for text to flow around a float that ends up in the middle (because of
> other, shorter, floats next to it). But I'm not sure exactly what test
> page this is.

I disagree. It is not possible to justify Mozilla's behaviour, which is
to only permit flow on the opposite side to the float value (e.g., flow
to the right of left floats); the test cases are on
http://www.richinstyle.com/test/positioning/inlinefloat.html, cases 6
and 7.

> | Bug 4: empty floated elements overlapped with by non-floated elements
> | place top of non-floated content at top of empty floated element
> |
> | There is a bug whereby empty floated elements assigned a height with
> | height are not overlapped with correctly by subsequent non-floating
> | elements, the non-floating content is placed inside the floated
> | element; there is a demonstration [40]in another of RichInStyle.com's
> | test pages.
>
> I can't tell which test you're talking about.

> | Cursors

> |
> | Bug 2: cursor: url() unsupported
> |
> | Mozilla does not support cursor: url().
>
> IMO, not a bug, since there's no XP cursor format. What format did
> you test? Why would you expect mozilla to support that format?

Cur and ani; probably not.

>
> | Bug 3: cursor: help unsupported
> |
> | Mozilla does not support cursor: help.
> |
> | Bug 4: cursor: crosshair unsupported
> |
> | Mozilla does not support cursor: crosshair.
> |
> | Bug 5: cursor: north-east unsupported
> |
> | Mozilla does not support cursor: north-east.
> |
> | Bug 6: cursor: south-east unsupported
> |
> | Mozilla does not support cursor: south-east.
> |
> | Bug 7: cursor: south-west unsupported
> |
> | Mozilla does not support cursor: south-west.
> |
> | Bug 8: cursor: north-west unsupported
> |
> | Mozilla does not support cursor: north-west.
> |
> | Bug 9: cursor: auto buggy
> |
> | Cursor: auto, which should reset the cursor to the default for that
> | element doesn't. You can see this demonstrated [46]in one of
> | RichInStyle.com's test pages.
>
> (8) bug 1916

> | Bug 11: scroll and auto break clip
> |
> | Mozilla breaks clip when overflow: scroll or overflow: auto, treating
> | the clipping region as no clipping region at all when either setting
> | is set.
>
> The spec doesn't define the correct behavior. What behavior do you
> expect?

A scrollable clipping region of the specified size (I suggest scrollers
inside the clipping region, to prevent any overflow with adjacent
elements).

In addition, although precised behaviour is not specified, this does not
imply that UAs may ignore the statement that clip applies to scroll and
auto.

> | List style types
> |
> | Bug 2: dot placed after marker on ordered list types
> |
> | Mozilla places a dot after the list marker on ordered list types; for
> | example, it renders 1., 2., 3. instead of 1, 2, 3. This is incorrect
> | according to the spec (because to do so wrecks the content property).
>
> Not a bug. How does it wreck the content property?

Yes it is.

> |
> | Section L - Horizontal rule bugs
> |
> | Bug 1: padding applied incorrectly to horizontal rules
> |
> | Mozilla does not apply padding correctly to horizontal rules -
> | vertical padding should increase the height of horizontal rules
> | because it implements them as a border around whitespace, but doesn't,
> | instead being treated as a margin.
> |
> | Bug 2: border-color not applied to horizontal rules
> |
> | Mozilla does not apply border-color to horizontal rules.
>
> (2) Not a bug. HR does not fit within the CSS formatting model (it
> does not act like a block), so it's really perfectly reasonable for
> color to apply, rather than border-color. See also bug 2590 (REMIND).

Have you seen the entry in Mozilla's style sheet, which seems to
contradict this?

> | Bug 6: buggy on tables
> |
> | Mozilla makes table padding transparent instead of giving it the
> | table's background-color.
>
> Eh? Tables can't have padding. If they do, that's a bug.

Yes, they can. The spec is quite clear about this, and I have pointed it
out to you before on www-style.

> | Bug 10: display: inline on OPTION destroys
> |
> | Mozilla destroys SELECT controls when an OPTION in them has display:
> | inline.
>
> What do you mean by destroys? This may or may not be a bug.

Breaks the menu; see http://richinstyle.com/test/boxes/forms.html

> | Bug 11: width and height buggy on INPUT type="file"
> |
> | Width and height are not correctly honored on INPUT type="file" - they
> | appear to only set the size of the button, not the text box. In
> | addition, even the button is not set to the requested height and
> | width.
>
> What should they set? Everyone will probably have a different opinion.
> CSS is not well designed to handle some form controls.

The width of the INPUT type="file", which is what was specified; in
addition, whatever behaviour is implemented, it should be logical.

> | 11. It renders font-family: "monospace", an invalid declaration, in
> | Times New Roman.
>
> Why is this a bug? The declaration is not invalid, it just requests that
> the browser use a font *with the name* monospace, and if no such font
> exists, the browser should use the default or inherited font.

This is related to the bug I mentioned before about destroying UI fonts.

> | 13. It ignores rulesets that contain null selectors; for example, it
> | ignores .class1, , .class2 {color: red}, which is incorrect
> | because simple_selector is (partly) defined by element_name.
>
> Not a bug (CSS2 5.2 and 5.3).

It is. The criterion for ruleset ignoring is that the accompanying
selector cannot be parsed. The only section relevant for ignoring is the
grammar. 5.* does not come into it.

> | 14. It disregards the case of proprietary font names.
>
> This is probably needed for compatibility with different systems and
> with current use of CSS. I think it would be a bug to consider case on
> any operating system that cannot have multiple fonts that have the same
> name but differ only in capitalization.

Yes. You're right. I've seen many style sheets on big sites that don't
observe correct capitalization. Just as Netscape and Microsoft have
created a legacy with allowing unitless lengths, and therefore have a
duty to maintain the buggy behaviour, so too they have a duty to retain
this particular bug (it is a bug, just won't (or shouldn't) fix).

> | 15. It allows comments between ! and important, which is incorrect
> | because IMPORTANT_SYM is a single token and the whitespace between
> | it is {w}, a macro not a token - comments are only valid between
> | tokens - not inside them.
>
> I think you're crossing the chapter 4 grammar and the appendix D
> grammar. I don't think this is a bug. The appendix D grammar
> (which defines IMPORTANT_SYM) handles comments in the tokenizer.

Yes. You're right. It's not one of the core tokens:
IDENT
{ident}
ATKEYWORD
@{ident}
STRING
{string}
HASH
#{name}
NUMBER
{num}
PERCENTAGE
{num}%
DIMENSION
{num}{ident}
URI
url${w}{string}{w}$
|url${w}([!#$%&*-~]|{nonascii}|{escape})*{w}$
UNICODE-RANGE
U\+[0-9A-F?]{1,6}(-[0-9A-F]{1,6})?
CDO

;
;
{
\{
}
\}
(
$
)
$
[
\[
]
\]
S
[ \t\r\n\f]+
COMMENT
\/\*[^*]*\*+([^/][^*]*\*+)*\/
FUNCTION
{ident}\(
INCLUDES
~=
DASHMATCH
|=
DELIM
any other character not matched by the above rules

It works out as DELIM IDENT

> | 16. x
>
> ?

I think this comes of my HTML editor - a couple of mispressed keys can
result in this sort of thing. This is gone from the latest version (not
updated as yet).

>
> | 17. It allows comments inside the URI token, which isn't valid -
> | comments are only valid between tokens - not inside them.
>
> Same comment as on 15.

This time you're wrong. URI is a core token.

>
> | 18. It allows more than one decimal place on rgb% (e.g., rgb(99.99%,
> | 0%, 0%), but this isn't valid.
>
> Where does the spec say this isn't valid?

It says:
EM { color: rgb(255,0,0) } /* integer range 0 - 255 */
EM { color: rgb(100%, 0%, 0%) } /* float range 0.0% - 100.0% */

> | 22. It allows spaces before and after / on the font shorthand, but
> | this is invalid.
>
> What says that this is invalid?

Maybe not.

PS What's with the footnotes? I didn't see any.

Matthew Brealey

unread,

Mar 9, 2000, 3:00:00 AM3/9/00

Matthew Brealey wrote:
> > | List style types
> > |
> > | Bug 2: dot placed after marker on ordered list types
> > |
> > | Mozilla places a dot after the list marker on ordered list types; for
> > | example, it renders 1., 2., 3. instead of 1, 2, 3. This is incorrect
> > | according to the spec (because to do so wrecks the content property).
> >
> > Not a bug. How does it wreck the content property?
>
> Yes it is.

Sorry, I failed to explain why - from CSS 2:

decimal
Decimal numbers, beginning with 1.
decimal-leading-zero
Decimal numbers padded by initial zeros (e.g., 01, 02, 03, ..., 98,
99).
lower-roman
Lowercase roman numerals (i, ii, iii, iv, v, etc.).
upper-roman
Uppercase roman numerals (I, II, III, IV, V, etc.)

Note no '.'.

The reason it breaks it is that counter functions use the output from
list-style; so if you wanted (1), then you wouldn't be able to if '1.'
was the output - that would give you (1.).

John Morrison

unread,

Mar 10, 2000, 3:00:00 AM3/10/00

Matthew Brealey wrote:
>
> David Baron wrote:
> >

> > | 18. It allows more than one decimal place on rgb% (e.g.,
> > | rgb(99.99%, 0%, 0%), but this isn't valid.
> >
> > Where does the spec say this isn't valid?
>
> It says:
> EM { color: rgb(255,0,0) } /* integer range 0 - 255 */
> EM { color: rgb(100%, 0%, 0%) } /* float range 0.0% - 100.0% */

A small point but ...

http://www.w3.org/TR/REC-CSS2/syndata.html#percentage-units

The format of a percentage value (denoted by <percentage> in this
specification) is an optional sign character ('+' or '-', with '+'
being the default) immediately followed by a <number> immediately
followed by '%'.

http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-number

... A <number> can either be an <integer>, or it can be zero or more
digits followed by a dot (.) followed by one or more digits. Both
integers and real numbers may be preceded by a "-" or "+" to indicate
the sign.

Cheers,
John

Matthew Brealey

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

John Morrison wrote:
> > > Where does the spec say this isn't valid?
> >
> > It says:
> > EM { color: rgb(255,0,0) } /* integer range 0 - 255 */
> > EM { color: rgb(100%, 0%, 0%) } /* float range 0.0% - 100.0% */
>

> A small point but ...
>
> http://www.w3.org/TR/REC-CSS2/syndata.html#percentage-units
>
> The format of a percentage value (denoted by <percentage> in this
> specification) is an optional sign character ('+' or '-', with '+'
> being the default) immediately followed by a <number> immediately
> followed by '%'.
>
> http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-number
>
> ... A <number> can either be an <integer>, or it can be zero or more
> digits followed by a dot (.) followed by one or more digits. Both
> integers and real numbers may be preceded by a "-" or "+" to indicate
> the sign.

Surely the more specific statement (namely that percentages must be to
1dp on rgb%), overrides the general?

John Morrison

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

Matthew Brealey wrote:

>
> John Morrison wrote:
> > > > Where does the spec say this isn't valid?
> > >
> > > It says:
> > > EM { color: rgb(255,0,0) } /* integer range 0 - 255 */
> > > EM { color: rgb(100%, 0%, 0%) } /* float range 0.0% - 100.0% */
> >

[snip]
> > http://www.w3.org/TR/REC-CSS2/syndata.html#percentage-units
> > http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-number

>
> Surely the more specific statement (namely that percentages must be to
> 1dp on rgb%), overrides the general?

Sure, but "EM { color: rgb(100%, 0%, 0%) } /* float range 0.0% - 100.0% */"
is labelled as an example in the spec. I think you are reading too much
significance into '100.0'. I don't think there is enough evidence to support
the assertion that this example was intended to imply 'one decimal place'
behaviour.

Cheers,
John

Matthew Brealey

unread,

Mar 30, 2000, 3:00:00 AM3/30/00

First of all:

the bug page is updated to M14
the Mozilla bug sheet is now available

And also:

Pierre Saslawsky wrote:
> The main problem is that all the test pages import large stylesheets, some of
> these importing child sheets, and it makes it painful to isolate a bug and
> create a testcase.

Fixed.

> The navigation through the test pages is a bit awkward:
> - Half the screen (on a 21" monitor) is used by the banner and the index. The
> font sizes in most test pages are really big too, as well as many images or
> block elements. It forces you to scroll a lot. A very few pages actually fit
> in one screen.

Fixed. Tests made shorter, it's easier to see whether the result is
correct, and if you use frames for navigation the index is hidden.

> - The index doesn't show which Core Test, Advanced Test or particular Test is
> currently displayed.

This was a hangover from having not updated the HTML to match the CSS
before launching - it was so big a task I opted to leave it as it was.

Fixed.

> - In the bug pages, each bug should be linked to the corresponding test page.

The bug sheet has test cases.

> Finally, it may be subjective but I find some descriptions in the test pages
> a bit verbose

Fixed in all, or almost all cases (note that some tests cannot be
simplified any more than they are already, simply because the tests are
so complex). If you have any particular tests that you feel are too
long, please tell me which ones.

> and it's not as obvious as on the W3C Test Suite to tell
> whether the test is rendered correctly.

Fixed where possible (in the tests of linking style, applying style and
so on this is easier than other cases); note that the tests verbosity is
often due to the fact that they go into more detail as to the correct
result than the W3C test suite; for example, rather than just saying
'This LI is flowing around a float', it explains what the correct result
is - precisely where marker boxes should be.

> The choice of some colors (black on
> blue background) doesn't help too.

Fixed.

All other complaints are very much welcomed :-).

0 new messages