insertRule does not preserve color type

VERIFIED INVALID

Status

()

Core
CSS Parsing and Computation
VERIFIED INVALID
16 years ago
16 years ago

People

(Reporter: Dylan Schiemann, Assigned: dbaron)

Tracking

({testcase})

Trunk
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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
(Reporter)

Comment 1

16 years ago
Created attachment 53976 [details]
testcase
(Reporter)

Updated

16 years ago
Keywords: testcase
Created attachment 53980 [details]
testcase _not_ using insertRule but just having the rule in the stylesheet
> 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.

Component: DOM Style → Style System
er... reassign for real
Assignee: jst → dbaron
(Assignee)

Comment 5

16 years ago
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.

Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

16 years ago
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.
http://www.damowmow.com/mozilla/canon.txt for one (Ian's proposal)
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

16 years ago
named colors are stored by their name... why are they not also converted to an
rgb triplet like the hex colors?
(Reporter)

Comment 9

16 years ago
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?
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....
You need to log in before you can comment on or make changes to this bug.