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

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

More precisely, it's either both or just the first one. I cannot really leave my code as is even if I consider it a bug in the browsers, technically.




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

Sure. But !important is not very common, which is why I said that.



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

The function description doesn't talk about it anywhere. The algorithm may, but we don't expect web authors to read algorithms, right? To me, this behavior is simply described as "{ color: blue !important }" becoming "{ color:; }" and therefore "{}" which is what the function description says the function does.


However, I would consider looking at real-life usage and see what behavior is usually expected there, because this is exactly what the API should do. I'm not an absolute reference but my expectations may be shared by more developers. And the only way to tell is to look for it on actual web source code. So this is what I did. And I'm somewhat glad to see I'm not the only one that had this expectation:

    var style = sidebarBox.style;
    var value = style[aTarget.name] || '';
    var important = style.getPropertyPriority(aTarget.CSSName);
    style.setProperty(aTarget.CSSName, aTarget.default, 'important');
    return {
        value : value,
        important : important
    };
    
    ...
    
    sidebarBox.style.setProperty(
        this.sizeBackupTargets[aIndex].CSSName,
        aValue.value,
        aValue.important ? 'important' : ''
    );

    https://github.com/piroor/unifiedsidebar/blob/267402ac9b589218c04f066ffa733cf42b9f8a5b/content/unifiedsidebar/unifiedsidebar.js#L306

The whole thing works, as I said, because it's pretty rare in practice to have anything specified in the style so the backup ends up setting '' and properly reset the property.

You can see this as some codes just do not take care of restoring the original value, supposing that there was no:

   https://github.com/epiphanydigital/FlixShare/blob/8fdc1f8084f8257c38aab601cd365ce67cfd1b3a/sencha-touch-2.0.0-pr1/src/fx/runner/CssTransition.js#L131

As a result of this, and because of the name and description of the function, people like me end up using setProperty as a backup-restoring function and we never noticed it didn't work as expected in all browsers. Making this actually working would be something to take in consideration. 




More generally, concerns about stuff that previously had no impact in CSS should not enter in consideration when deciding on the final algorithm of a function defined prior the introduction of the concept because people using the function could not care about the ordering issue before and could not possibly forsee it would impact the function's algorithm given it simply didn't exist at the time. 

If the behavior implied by the function name - SET - is an issue, it's always possible to define a new function - like appendDeclaration - that would cover the new use case.

Received on Thursday, 12 September 2013 20:28:17 UTC