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

On Thu, 12 Sep 2013 22:27:47 +0200, François REMY  
<francois.remy.dev@outlook.com> wrote:

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

Yeah, true.

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

OK.

> The function description doesn't talk about it anywhere. The algorithm  
> may, but we don't expect web authors to read algorithms, right?

There is no function description in the spec. Just the algorithm. I agree  
that I don't expect web authors to read and understand algorithms aimed  
for implementors, so it would be good for the spec to have descriptions  
aimed for web authors like the HTML spec has, but this hasn't been high on  
my priority list yet.

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

Thanks for doing this! This is new information. I will have a look myself  
also and see if I can reason about what assumptions are made by existing  
code.


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

-- 
Simon Pieters
Opera Software

Received on Thursday, 12 September 2013 20:47:51 UTC