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

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

This information was already known before the resolution.

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

> 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. I don't see the  
argument to move away from that piece of interop.

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

> should be a trivial
> change to Webkit,

Any behavior is relatively trivial to implement in browsers, that's not an  
argument either way.

> and still permits in-place update where browsers can
> prove it is semantically equivalent.

I don't follow.

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


On Wed, 11 Sep 2013 18:53:38 +0200, François REMY  
<francois.remy.dev@outlook.com> wrote:

>>> RESOLVED: setProperty's handling of importance logically behaves same  
>>> as appending a declaraiton (like IE/WebKit)
>
> Hi Zack,
>
> I'm not 100% sure I really understood what you meant, but if what you  
> say is that the resolution means that:
>
>
>     var backup = { value: style.getPropertyValue(prop), priority:  
> style.getPropertyPriority(prop) }
>        style.setProperty(prop, tempValue, 'important');
>        doSomeStuff();
>       style.setProperty(prop, backup.value ? backup.value : '',  
> backup.priority);
>    
> doesn't work as expected (ie the backup may be restored at important  
> priority) I'm leaning toward the 'bad idea' side.
>
>
>
> I'm using this in existing code already,

Then it doesn't do what you expect in IE/Blink/WebKit. That's either an  
argument for you to fix your code, or an argument that the spec doesn't  
match your expectations and we should change the spec and IE/Blink/WebKit  
to do what you expect.

> and never noticed any issue with it (most probably because in fact no  
> one use inline style and therefore the latest declaration usually reset  
> the property to its undeclared state, and the inline style wins over any  
> stylesheet in all the remaining cases)

Inline style without !important doesn't win over !important in a  
stylesheet.

> but if we've to resolve to a proper behavior here, I would tend to say  
> setProperty should be a shortcut for both setPropertyValue and  
> setPropertyPriority.

i.e. behavior (B).

> I'm at least able to confirm that
>        style.setProperty('color', 'blue', 'important')
>     style.setProperty('color', '', '')
>
> resets the property in IE which seem to be the reference that has been  
> chosen as the way to go.

The empty string as value has the semantic to call removeProperty(), so  
that's not a good test.


>
> As a reminder, the current specification says:
>            setProperty: Used to *set* a property value *and* priority  
> within this declaration block.

I can't find that text in the editor's draft. But in any case, what the  
spec currently says isn't an argument either way.

> It seems to me a sane implementation of this sentence does not involve  
> the fiddling with the current values of a property declaration.
>
>
>
>
> If, however, the resolution only applies to the case where the priority  
> is not defined (ie: setProperty(p,v) != setProperty(p,v,'')) then I  
> don't mind, since this is an extension of what's already defined in the  
> spec. Actually, in this specific case I think it even makes sense. If  
> you don't set the priority, the browser can reuse the current one.

That's behavior (C) which was what the spec had before this resolution.


> PS: By the way, it's usually a bad idea to contest resolutions based on  
> raw notes and not polished minutes, because there are parts of the  
> discussion you cannot see all the details. It would probably have been  
> better to start by asking some clarification before ;-)

I think there wasn't any new information presented at the meeting, it was  
basically David Baron presenting the issue to the group and Tab and I  
ended up agreeing with behavior (A). It is of course a problem that the  
people who care strongly against (A) weren't present at the meeting to  
defend themselves; that's a problem inherent with making decisions at  
face-to-face meetings.

So at this point it's still not clear what the spec should say. There are  
valid arguments on both sides, and people objecting on both sides. Since  
the mental models are incompatible, I don't see any proposal that would  
remove the objection on either side. The WG has resolved on one side, so  
that's what the spec currently says. If new information gets presented,  
such as IE, Blink and/or WebKit have implemented what Gecko does, or if it  
is demonstrated that the spec's current behavior doesn't match what  
existing Web content expect (despite it being the traditional behavior  
that was implemented by all browsers except Presto until a few years ago),  
or if David Baron has a change of heart, or some such, that would be a  
reason to reopen the resolution.

-- 
Simon Pieters
Opera Software

Received on Thursday, 12 September 2013 08:00:20 UTC