objection re: RESOLVED: setProperty's handling of importance logically behaves same as appending a declaraiton (like IE/WebKit)

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