204826 - Inconsistent handling of non-standard color keywords between CSS and HTML

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Ernest Cline]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425

I was playing around with the X11 color keywords that did not make it into the
CSS3 color spec, so I could see what Mozilla would make of them. While doing so,
I discovered that it handles them differently (and in neither case, generating
the X11 color) depending upon whether an HTML attribute or a CSS rule was used.

Reproducible: Always

Steps to Reproduce:
1. Use a CSS rule to apply a non-standard color keyword to an element.
2. Use an HTML attribute to apply the same non-standard color keyword to another
element of the same type and with the same content.
Actual Results:  
The two elements were handled differently.

Expected Results:  
The two elements should be rendered the same.

This bug is not asking that Mozilla understand the extra X11 colors (altho that
would be nice, that would probably be Bug 121738 or an offshoot thereof). This
bug asks that when a color keyword is encountered that Mozilla does not
understand, that it be handled the same regardless of whether the source is a
CSS style rule or an HTML attribute.
One method of fixing this would be once the CSS3 Color Module reaches CR stage
and Mozilla supports the attr(x,color) function to handle color assignments from
HTML attributes via rules such as:
 [bgcolor] {background-color:attr(bgcolor,color)}
This would seem to be the easiest method of ensuring that equivalent handling is
done for either case.

Comment 1

[Ernest Cline]

Attachment: HTML file that illustrates the differences

Comment 2

[Hixie (not reading bugmail)]

This is invalid. LightGoldenrod is ignored if specified in CSS, as it is invalid.
In HTML we use legacy interpretation algorithms, which make LightGoldenrod
equivalent to #000ded. (The algorithm is: ignore any letter that isn't in the
range [0-9 a-f A-F], then using those left, pad the resulting string with zeros
on the left.)

Comment 3

[Ernest Cline]

REOPENED since the reason given for marking this bug as INVALID is incorrect.

As the discussion in Bug 121738 makes clear, Mozilla is not using the legacy
algorithm that Netscape 4.x used but a different one. It has also been
determined that using the legacy algorithm is something that will not be done. I
would argue that lacking the justification that Mozilla is following legacy, the
logical thing for Mozilla would do would be for it treat the two cases
identically. It certainly would reduce the amount of code that Mozilla uses.

(BTW, if one uses the DOM inspector, on my test case, one will see that the
color code Mozilla assigns to LightGoldenrod is #0000de, not #000ded, so the
algorithm Mozilla is using is not the one described in Comment 2.)

Comment 4

[Hixie (not reading bugmail)]

Ok, in that case this is a dup of bug 121738.

*** This bug has been marked as a duplicate of 121738 ***

Comment 5

[Ernest Cline]

While similar, I am unconvinced that this bug is a duplicate of Bug 121738. (If
I were, I would have filed this bug as a comment on that bug in the first
place.) That bug is asking for non-standard color keywords to be treated as they
were in pre-Gecko Netscape and in current IE. This bug is asking that
non-standard color keywords be treated the same by Mozilla in CSS and HTML
without reference to legacy implementations. If that is not going to be done
then either mark this as INVALID because of a design decision that Mozilla will
treat color keywords differently in CSS and HTML (my objection to INVALID
earlier was because the given reason, legacy, was incorrect) or mark this as
WONTFIX.

Comment 6

[Hixie (not reading bugmail)]

In CSS, we IGNORE invalid colours. In HTML attributes, we don't, instead we use
our (admittedly less than perfect) legacy parsing code. This is intentional.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

wontfix.  There is generally a good reason that quirks are added.  If you go
back to when it was added and find that there was not, and you have reason to
believe that this quirk is not needed for "the web", then reopen.  We don't have
the resources to do a general evaluation of the need for all our quirks
(although that would probably be a good thing), and I don't see any reason to
spend the time evaluating this particular one (which doesn't bother me that much
compared to many of the others).

Comment 8

[Anne (:annevk)]

*** Bug 227072 has been marked as a duplicate of this bug. ***