Closed
Bug 110762
Opened 24 years ago
Closed 22 years ago
element.style.backgroundColor = '#00ff00' is converted to rgb(0, 255, 0)
Categories
(Core :: DOM: CSS Object Model, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: martin.honnen, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Whiteboard: INVALID? [please hold, your call is important to us...])
Attachments
(1 file)
|
1.26 KB,
text/html
|
Details |
When I set the inline style with JavaScript e.g.
element.style.backgroundColor = '#00ff00'
and then read that property back with JavaScript I find that Mozilla returns
'rgb(0,255,0)'
instead. This is very annoying when you try to compare color values later, e.g.
if you want to check
if (element.style.backgroundColor == '#00ff00')
It is my understanding that a
element.style.cssProperty
is just a string value that is assigned and should be stored that way and not
converted to another format.
The conversion to rgb(...) is not happening if you assign a color name say 'red'.
Here is a test page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>
reading of color values
</title>
</head>
<body>
<div id="aDiv">
Kibology
</div>
<script type="text/javascript">
document.write('Setting document.getElementById(\'aDiv\').style.backgroundColor
= \'#00ff00\';<br \/>');
document.getElementById('aDiv').style.backgroundColor = '#00ff00';
document.write("document.getElementById('aDiv').style.backgroundColor: " +
document.getElementById('aDiv').style.backgroundColor + '<br \/>');
document.write("document.getElementById('aDiv').style.getPropertyValue('background-color'):
" + document.getElementById('aDiv').style.getPropertyValue('background-color') +
'<br \/>');
document.write('Setting document.getElementById(\'aDiv\').style.backgroundColor
= \'red\';<br \/>');
document.getElementById('aDiv').style.backgroundColor = 'red';
document.write("document.getElementById('aDiv').style.backgroundColor: " +
document.getElementById('aDiv').style.backgroundColor + '<br \/>');
document.write("document.getElementById('aDiv').style.getPropertyValue('background-color'):
" + document.getElementById('aDiv').style.getPropertyValue('background-color') +
'<br \/>');</script>
</body>
</html>
|
Reporter | |
Comment 1•24 years ago
|
||
|
||
Comment 2•24 years ago
|
||
>It is my understanding that a
> element.style.cssProperty
>is just a string value
It is not. It's _set_ from a string and is completely equivalent to having a
'style="prop: value"' on the element. The value returned when getting the value
of the property should be subject to the CSS canonicalization rules. At the
moment these rules are undefined, and the only proposal on the table
canonicalizes colors specified by rgb triplets in any form (#rgb, #rrggbb,
rgb(R,G,B)) to rgb(R,G,B).
The only hard requirement on the value you get out is that it should lead to the
same value when parsed as the original value you put in.
See also the discussion in bug 93431....
Whiteboard: INVALID?
|
|
||
Comment 4•23 years ago
|
||
FWIW, Ian's canonicalization rules are located here:
http://www.damowmow.com/playground/canon.txt
|
||
Comment 6•22 years ago
|
||
If 'red' isn't converted, that's a bug too, btw.
Whiteboard: INVALID? → INVALID? [please hold, your call is important to us...]
|
|
||
Comment 7•22 years ago
|
||
'red' is in fact not converted, because that would make any CSS editing
capabilities we have pretty useless...
|
|
||
Comment 8•22 years ago
|
||
bz: Why?
Regarding the issue that this bug was originally filed for, rgb() is indeed the
canonical format we want to use. -> INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
|
|
||
Comment 9•22 years ago
|
||
Ian, because loading a document that has <foo style="color: red"> in composer
and saving it, and having composer save <foo style="color: rgb(255, 0, 0)">
would be viewed as dataloss by most people I've talked to who use wysiwyg HTML
editors.
|
|
||
Comment 10•22 years ago
|
||
bz: loading a file that says:
<span style="behaviour: url(#user#prefs)"> ... </span>
...and having it write out:
<span style=""> ... </span>
...when you save is dataloss too, yet we do that. As I've mentioned before, the
right solution is to cache the string representation of the "style" attribute,
and only reserialize our style declaration to that cached representation when
the style declaration is changed. That would also solve other bugs.
|
|
||
Comment 11•22 years ago
|
||
Ian, Composer includes a stylesheet editor. I used inline style as an example,
but I could just as easily have used a style declaration in a stylesheet...
I agree that we have other forms of dataloss too. At the same time, we would
sort of like to minimize dataloss as much as possible.
I don't have particularly strong views on it one way or another in the end, but
I bet glazou does...
|
|
||
Comment 12•22 years ago
|
||
Don't we also drop comments in stylesheets? And lots of other stuff? Our CSSOM
wasn't designed for editing. It shouldn't be used for editing. If people are
going to insist on using an inappropriate API instead of rolling their own as
they should, then I'm sorry but they're going to have to deal with the problems.
According to CSS there is no difference between 'red', '#FF0000', '#F00',
'rgb(255, 0, 0)', etc. We should therefore canonicalise them to the same thing.
|
|
||
Comment 13•22 years ago
|
||
Ian, mind filing a bug on the named color issue and ccing dbaron and glazou? I,
for one, would be quite happy to do what you suggest (since it would also speed
up style resolution, if nothing else -- at the moment the color name is
converted to the RGB triple on every style resolve instead of being converted at
parse time), but glazou and/or dbaron may have issues with the idea.
> Don't we also drop comments in stylesheets? And lots of other stuff? Our CSSOM
> wasn't designed for editing. It shouldn't be used for editing. If people are
> going to insist on using an inappropriate API instead of rolling their own as
> they should, then I'm sorry but they're going to have to deal with the
> problems.
Ian has been constantly repeating this opinion for the last 3 years and I still
have the same answer: this is a short-term, deliberately narrow,
counter-productive and overall fanatic point of view. Our DOM support is
POINTLESS if we are not able to make sure that
the web authors and application builders can rely on it. I fully agree with bz
when he says that typing 'red' and getting in return '#ff0000' is bad, wherever
it is. And the CSS OM may be badly designed, but it STANDS. Until we have
STANDARD canonicalization rules, we have no reason to change what the author
has chosen.
Gecko is a layout engine. If its design model makes it only fittable into a
browser, Mozilla.org would better dissolve itself right now. Fortunately,
mozdev.org is here to prove that people want to do more than a browser
using Gecko. And guess what, they even do XML editors!
About editing, considering that clean editing is outside of the scope for Gecko
or Mozilla is just silly and shows a total misunderstanding of the market.
We ***need*** a solution for the current bug, whatever it is. Almost 3 years ago,
we got rid of the string representation of the style attribute for perf/memory
reasons. That was a reasonable move at that time. Now, this happens to be
a too strong limitation for the applications we want to build over Gecko.
And yes, we also ***need*** to preserve comments because web authors WANT it.
I want this bug to be reopened, and treated as a valid request. It is OBVIOUSLY
not an INVALID bug. Could have been a WONTFIX but I strongly object to that.
The current bug is caused by OUR IMPLEMENTATION CHOICES, not imposed by a spec.
Canonicalization should impact CSS OM calls, but I strongly disagree it should
also affect query of the STYLE attribute or the text data into a STYLE element.
Bz, up to you or anyone else to reopen, that's not my module.
|
|
||
Comment 15•22 years ago
|
||
glazou: Yes, I agree we need a better API, one designed for editing. However, it
is unacceptable to make editing requirements force a reduction in the memory
footprint or performance of the browser component.
bz: Will do.
|
||
Comment 16•22 years ago
|
||
*** Bug 235279 has been marked as a duplicate of this bug. ***
|
|
||
Comment 17•21 years ago
|
||
*** Bug 266931 has been marked as a duplicate of this bug. ***
|
|
||
Comment 18•21 years ago
|
||
bz: actually, caillon and I discussed this and decided #RRGGBB was better as the
canonical format. This is all still just in the not-a-standard proposal stage,
but it seems most authors prefer #RRGGBB to be returned, despite the
inconsistency with rgba(r, g, b, a) which is required for RGBA.
|
|
||
Comment 19•21 years ago
|
||
*** Bug 268405 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•