Closed Bug 110762 Opened 23 years ago Closed 21 years ago

element.style.backgroundColor = '#00ff00' is converted to rgb(0, 255, 0)

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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)

bug demo
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>
Attached file bug demo — 

    
    

    
  
>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?

    
    

    
  
FWIW, Ian's canonicalization rules are located here:
http://www.damowmow.com/playground/canon.txt

    
    

    
  
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

    
    

    
  
If 'red' isn't converted, that's a bug too, btw.
Whiteboard: INVALID? → INVALID? [please hold, your call is important to us...]

    
    

    
  
'red' is in fact not converted, because that would make any CSS editing
capabilities we have pretty useless...

    
    

    
  
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: 21 years ago
Resolution: --- → INVALID

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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...

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
  
Blocks: 310903
Depends on: 308214

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: