- From: Zack Weinberg <zackw@panix.com>
- Date: Wed, 11 Sep 2013 10:38:26 -0400
- To: www-style list <www-style@w3.org>
I object to this resolution > RESOLVED: setProperty's handling of importance logically behaves same as appending a declaraiton (like IE/WebKit) for the following reasons: 1) At the level of script-author-visible behavior, this resolution means that setProperty establishes a new value and priority for any property, *except* when there was already a value for that property with priority !important. In that case it silently has no effect. This is surprising and inconsistent. I'm going to draw a table of all the cases to underline this point: old state --> | absent | present, | present, ------------------\ | | normal | !important setProperty request\+---------------+---------------+--------------- | | | normal priority | new value and | new value and | silently | priority | priority | has no | established | established | effect | | | !important priority | new value and | new value and | new value and | priority | priority | priority | established | established | established That this behavior "naturally falls out" of an internal semantic of appending a new declaration to the style rule and then letting the chips fall where they may, *does not excuse* an inconsistency in the author-visible semantics. 2) If we add more priorities in the future, the author-visible inconsistency will become worse. The above table will have to be expanded with new rows and columns for each priority, specifying under what circumstances setProperty will actually do anything. 3) There is an alternative internal semantic that avoids the author-visible inconsistency while preserving the "style rules are ordered lists of declarations" behavior that seems to be dbaron's primary concern. That semantic is: setProperty behaves as if it first calls removeProperty, and then proceeds to append a new declaration to the style rule with the specified value and priority. This is consistent with the current Gecko/Presto behavior, should be a trivial change to Webkit, and still permits in-place update where browsers can prove it is semantically equivalent. ---- For avoidance of doubt, I do not object to setProperty(prop, value) === setProperty(prop, value, "") nor to the addition of setPropertyPriority and setPropertyValue with always-update-in-place semantics. zw
Received on Wednesday, 11 September 2013 14:38:50 UTC