NEW 102691
when pasting into a contenteditable div or setting a color style of any element via javascript using #xxx color notation, color styles are translated to rgb(,,) notation 
https://bugs.webkit.org/show_bug.cgi?id=102691
Summary when pasting into a contenteditable div or setting a color style of any eleme...
Ariel Kroszynski
Reported 2012-11-19 08:26:39 PST
Created attachment 174987 [details] demo html file demonstrating copy paste of snippet with color attribute changes Using a contenteditable=true div, when pasting an HTML fragment containing #xxx color notation, the newly created elements will contain rgb(x,y,z) color notation. Also when updating a color attribute using elemnet_foo.style['border-color'] = '#xxx', the element will contain rgb(x,y,z) color notation. This short snippet reproduces the style change after setting the style using javascript: <html> <div id="foo" style="border: 2px solid #ddd;"> foo bar </div> <script> var div = document.getElementById('foo'); document.write('before: ' + div.getAttribute('style') + '<br>'); div.style['border-color'] = '#ddd'; document.write('after: ' + div.getAttribute('style') + '<br>'); </script> </html> attached is a test file that demonstrates both cases: to show copy paste issue: 1. click [select all] button 2. use shortcut key for copy (ctrl-c) 3. move caret down using down arrow 4. use shortcut key for paste (ctrl-v) 5. click [show style attributes] button two style attributes are shown: the original with #ccc color and the copy with rgb(221, 221, 221)
Attachments
demo html file demonstrating copy paste of snippet with color attribute changes (1.07 KB, text/html)
2012-11-19 08:26 PST, Ariel Kroszynski 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Glenn Adams
Comment 1 2012-11-19 08:37:27 PST
i'm not sure this is a bug... when setting a style using a shorthand rule and then querying the resulting longhand components, there is no well defined standard for canonicalization of property values... in other words, your bug report assumes that the UA must maintain the original author specified value '#ddd' and cannot convert it to an equivalent canonical form rob(221,221,221) how do other browsers behave with this input?
Ariel Kroszynski
Comment 2 2012-11-19 11:08:40 PST
Other browsers (FF 16.02, IE 8, Opera 12.10) preserve the style attribute on the above conditions.
Jeremy Moskovich
Comment 3 2012-11-19 11:27:50 PST
Ryosuke: Looks like we're the only browser with this behavior, wdyt?
Ryosuke Niwa
Comment 4 2012-11-19 12:00:38 PST
(In reply to comment #2) > Other browsers (FF 16.02, IE 8, Opera 12.10) preserve the style attribute on the above conditions. Our behavior does not violate the specification, and I don't think we can fix this bug due to how style attribute is implemented.
Ariel Kroszynski
Comment 5 2012-11-20 03:25:13 PST
(In reply to comment #4) > (In reply to comment #2) > > Other browsers (FF 16.02, IE 8, Opera 12.10) preserve the style attribute on the above conditions. > > Our behavior does not violate the specification, and I don't think we can fix this bug due to how style attribute is implemented. webkit does behave like all others when using named colors like 'yellow', meaning the 'yellow' color is preserved...
Ahmad Saleem
Comment 6 2022-07-26 12:40:42 PDT
I am able to reproduce this bug in Safari 15.6 on macOS 12.5 using attached test case. I know from Comment 04 that it is not web-spec defined but I think web-spec issue can be raised to clarify this and it can be also part of InterOp 2022 for Editing. Safari 15.6 matches with Chrome and show following output: original with #ccc and copy with rgb(204,204,204) Only Firefox Nightly 104 preserve the style element details and show #ccc for both. I just wanted to share updated results. Thanks!
Radar WebKit Bug Importer
Comment 7 2022-07-26 20:40:36 PDT
<rdar://problem/97643869>
Note You need to log in before you can comment on or make changes to this bug.