This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23066 - Opinions wanted: preferred behavior of setProperty
Summary: Opinions wanted: preferred behavior of setProperty
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-26 13:18 UTC by Simon Pieters
Modified: 2014-10-02 07:59 UTC (History)
8 users (show)

See Also:


Attachments

Description Simon Pieters 2013-08-26 13:18:46 UTC
It seems that different people have different opinion about what setProperty should do when the property is already specified, and in particular if the existing property has its important flag set.

There are two axes of cases: third argument omitted/""/"important" and property not present/present with important unset/present with important set. That gives us the following cases to consider (using 'color' as example):

1. setProperty("color", "blue") and color is not present.
2. setProperty("color", "blue", "") and color is not present.
3. setProperty("color", "blue", "important") and color is not present.
4. setProperty("color", "blue") and color is present with important flag unset.
5. setProperty("color", "blue", "") and color is present with important flag unset.
6. setProperty("color", "blue", "important") and color is present with important flag unset.
7. setProperty("color", "blue") and color is present with important flag set.
8. setProperty("color", "blue", "") and color is present with important flag set.
9. setProperty("color", "blue", "important") and color is present with important flag set.

There are three behaviors on the table for how to handle these. For most cases the result is identical:

A, B, C:
(1) append a new declaration with the given value and important flag unset.
(2) append a new declaration with the given value and important flag unset.
(3) append a new declaration with the given value and important flag set.
(4) update the value, leave the important flag unset.
(5) update the value, leave the important flag unset.
(6) updates the value and sets the important flag.    
(7) ???
(8) ???
(9) updates the value, leaves the important flag set.

For cases (7) and (8), the proposed behaviors are:

A:
(7) no-op
(8) no-op

B.
(7) updates the value, unsets the important flag.
(8) updates the value, unsets the important flag.

C:
(7) updates the value, leaves the important flag set.
(8) updates the value, unsets the important flag.

The status in browsers and the spec is as follows:

* IE/WebKit/Blink implement A.
* Gecko/Presto implement B. (Originally Gecko implemented A.)
* The spec had B until recently but changed to C, because there was a use case for it [1] and it was argued to be saner behavior than B [2].

bz argues [3] that A is preferable since he thinks the mental model if setProperty should be "append a declaration" and let it have the same behavior as it would have declaratively.

Tab argues that C is preferable since the author just wants to change the value and usually doesn't care about the priority, especially not when omitting the priority argument.

I'd like to get some more opinions on this issue, especially from relevant developers from non-Gecko browsers.

For context, see this thread http://lists.w3.org/Archives/Public/www-style/2013Aug/thread.html#msg134

[1] http://lists.w3.org/Archives/Public/www-style/2013Aug/0168.html
[2] http://lists.w3.org/Archives/Public/www-style/2013Aug/0240.html
[3] http://lists.w3.org/Archives/Public/www-style/2013Aug/0431.html
[4] http://lists.w3.org/Archives/Public/www-style/2013Aug/0433.html

(Note that I'm not asking how to address the use case in that thread, but what setProperty should do. When we have that established we can revisit the use case and see if and how it should be addressed.)
Comment 1 Simon Pieters 2013-08-26 13:23:21 UTC
(In reply to comment #0)

> bz argues

Oops. I meant David Baron. Sorry for misattribution.
Comment 2 Zack Weinberg 2013-08-26 18:21:53 UTC
I said some things about this on www-style, but to make my position 100% clear: I object to semantic A and am indifferent between B and C.  More specifically, I think that the behavior in case 8 definitely should be "update the value and unset the important flag", and likewise I think case 7 definitely should update the value, but I don't have a strong opinion on whether case 7 should affect the important flag.
Comment 3 L. David Baron (Mozilla) 2013-08-27 16:51:24 UTC
I'd also note that setting element.style.foo (where foo is the camel-cased version of any property) is defined to be equivalent to a setProperty call (though the spec has changed which setProperty call it's equivalent to).
Comment 4 Simon Pieters 2013-08-28 08:10:35 UTC
Rune Lillesveen (Opera):

[[
I think B or C. A means that if you have a style rule with an !important declaration, you'd have to do an explicit removeProperty before setting it to a non-important one. That sounds wrong to me.
]]
Comment 5 Simon Pieters 2013-09-11 12:13:06 UTC
[[
RESOLVED: setProperty's handling of importance logically behaves same as appending a declaraiton (like IE/WebKit)  
RESOLVED: add a setPropertyValue and setPropertyPriority api  
]]
http://krijnhoetmer.nl/irc-logs/css/20130911#l-535

https://dvcs.w3.org/hg/csswg/rev/d44ebeae0dc4
Comment 6 Jonas Sicking (Not reading bugmail) 2013-09-11 20:34:44 UTC
Sounds like you defined setProperty to behave like A, which everyone that commented objected to?
Comment 7 L. David Baron (Mozilla) 2013-09-11 21:16:54 UTC
There was also a whole bunch of traffic on the topic on www-style, which is the preferred discussion forum.
Comment 8 Simon Pieters 2014-10-02 07:59:42 UTC
[[
RESOLVED: change the behaviour of setProperty() according to last week’s proposal following Rossen’s approval
]]
http://krijnhoetmer.nl/irc-logs/css/20141001#l-276

https://dvcs.w3.org/hg/csswg/rev/befbfb8e871e