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

On 2013-09-12 3:59 AM, Simon Pieters wrote:
> On Wed, 11 Sep 2013 16:38:26 +0200, Zack Weinberg <zackw@panix.com> wrote:
>
>> 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.
...
>
> This information was already known before the resolution.

Yes.  It was repeatedly stated as a key issue, by me and others. 
However, as far as I can tell, this point was ignored in the actual 
decision-making process, which seems to have been mostly about choosing 
between two internal algorithms based on perceived elegance and 
desirable side effects for other scenarios.  I reiterate that no amount 
of internal elegance excuses inconsistent behavior in the visible API.

>> 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.
>
> That's true with the alternative proposal as well, no?

No.  With the alternative proposal (always removeProperty first), there 
is only one possible outcome: the value and priority passed to 
setProperty are always applied.

>> 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.
>
> The order is preserved and exposed in the spec and in implementations,
> so I don't understand that 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.
>
> That would mean that the set declarations are always moved to the end,
> which is different to what all implementations do today.

Always moving a set declaration to the end is exactly what the spec was 
just changed to require!  setProperty is now defined in terms of "append 
a CSS declaration", which, like the name implies, _appends_ the 
declaration; that may or may not cause an old declaration to be 
superseded, depending on their relative priorities.  (Close reading of 
the new text suggests that the new wording may not actually entail this, 
but - for reasons given below - I think the _intent_ was 
always-move-to-end.)

Further, my understanding of dbaron's issue with "always replace in 
place" semantics for setProperty is that it _doesn't_ always move set 
declarations to the end.  From related discussion with him offline, I am 
under the impression that the main thing he cares about is

   selector {
       margin-left: 10px;
       margin-start: 5px;
   }

being rewritten as

   selector {
       margin-start: 5px;
       margin-left: 10px;
   }

after `setProperty("margin-left", "10px", "")`, so that order can 
control which of these related properties actually applies.

>> This is
>> consistent with the current Gecko/Presto behavior,
>
> Not quite, as Gecko/Presto don't move the declaration to the end if one
> is already in the list.

For Gecko, true but irrelevant, as _at present_ there is no semantic 
dependence on the order of declarations; the logical box properties 
(specifically, the explosion in the number of logical box properties due 
to vertical writing, rendering our current method of disambiguation 
impractical) are about to change that.  (In the six-months-to-a-year 
timeframe, AIUI.)

>> and still permits in-place update where browsers can
>> prove it is semantically equivalent.
>
> I don't follow.

If moving an existing declaration to the end of the property has no 
effect on the rendering (== if moving the declaration to the end does 
not change whether it is trumped by a related property, as in the case 
of the physical/logical box property pairs), then browsers can avoid 
doing so; it's a pure optimization.

>> 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.
>
> Understood. David Baron objects to setProperty(prop, value, "")
> overriding an !important declaration, as I understand it.

This is the crux of the issue.

1) I specifically object to setProperty(prop, value, "")
    _not_ overriding an !important declaration.  All else is negotiable.

2) I don't think David's position is actually incompatible with mine.
    I don't wish to put words in his mouth, but as I said above, I am
    under the impression that what he actually cares about is the
    always-move-the-new-declaration-to-the-end side effect.  Hence my
    alternative proposal of behaving as if removeProperty() were always
    called first.

I think we need to hear directly from David at this point.

zw

Received on Thursday, 12 September 2013 16:36:44 UTC