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

On Thu, Sep 12, 2013 at 12:36 PM, Zack Weinberg <zackw@panix.com> wrote:
> 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.

Two weeks later, we're still waiting to hear directly from David.  (I
should have cc:ed him on the quoted message, my apologies.)

zw

Received on Monday, 30 September 2013 23:47:41 UTC