105323 - insertRule does not preserve color type

Status: VERIFIED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Dylan Schiemann]

Using insertRule to add a color to a style sheet converts hex and other color
types to rgb.  My understanding of the spec is that insertRule is to preserve
the authors declarations and not convert between types, which is acceptable for
getComputedStyle, for example.

Testcase to follow which shows that:
document.styleSheets[0].insertRule("body
{color:#0054aa;}",document.styleSheets[0].cssRules.length);
results in a style sheet with 
body { color: rgb(0,84,170); }
instead

Comment 1

[Dylan Schiemann]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase _not_ using insertRule but just having the rule in the stylesheet

Comment 3

[Boris Zbarsky [:bzbarsky]]

> My understanding of the spec is that insertRule is to preserve
> the authors declarations and not convert between types

It does not when the types are actually different.  In this case they are not. 
But that's beside the point here.  

What's actually going on is that there is _one_ internal representation for the
color.  .cssText shows it as rgb(A,B,C).  If this is a bug at all it's a bug in
.cssText, but note that all that's supposed to return is a string that when
parsed gives you the original rule.  It certainly does that.

If this is a bug at all, the issue is just that we don't store the "original"
representation with the rule.... over to style system.

Comment 4

[Boris Zbarsky [:bzbarsky]]

er... reassign for real

Comment 5

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

The DOM 2 Style spec defines cssText as:

    cssText of type DOMString
        The parsable textual representation of the rule. This reflects the current 
        state of the rule and not its initial value.

This implies that we have to convert the DOM representation of the rule back to
text -- and there's no requirement for us to store how the color was written
(and CSS data doesn't need to take even more memory than it already does).  I
think this bug is invalid, although if you point to something in the spec or
what other browsers do that says we should be doing things differently, please
reopen.  Also note that there have been some proposals on canonicalization of
CSSOM back to text.

Comment 6

[Dylan Schiemann]

Per the spec., I agree that it is invalid.  As far as other browsers, IE5 Win
cssText returns the value in the same type as declared in the style sheet.  I
don't know what IE5 Mac does.  Could you refer me to the proposals on
canonicalization of CSSOM back to text if you have them handy.

Comment 7

[Boris Zbarsky [:bzbarsky]]

http://www.damowmow.com/mozilla/canon.txt for one (Ian's proposal)

Comment 8

[Dylan Schiemann]

named colors are stored by their name... why are they not also converted to an
rgb triplet like the hex colors?

Comment 9

[Dylan Schiemann]

getComputedStyle returns colors as hex values, even when set as rgb triplets. 
Should mozilla return different types for the cssRules object and the
getComputedStyle method?

Comment 10

[Boris Zbarsky [:bzbarsky]]

That has already been discussed in another bug that I can't find at the moment.
 The short answer was, "why not"?

That said, I will most likely be converting getComputedStyle to rgb triplets....