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

On Thu, 12 Sep 2013 18:36:15 +0200, Zack Weinberg <zackw@panix.com> wrote:

> 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.

I wouldn't say it was ignored since it was known by the people in the  
discussion.


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

Fair enough.


>> 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!

No.

> 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.)

My intent is what the requirements say.

> 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.

I haven't seen this being stated as a requirement, but maybe I've missed  
it. It would be good if David could clarify his position here.

>>> 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.)

Gecko currently supports -moz-margin-start.

Since the order is observable in scripts even without margin-start, I  
don't think it's quite irrelevant.

>>> 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.

Ah. I think we should require one or the other since it is observable for  
all properties in the API.

>>> 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.

I agree.

-- 
Simon Pieters
Opera Software

Received on Thursday, 12 September 2013 19:53:30 UTC