Re: [cssom] Proposal for obtaining robust style information via Javascript - getStyle()

On Tue, 07 May 2013 18:47:20 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Tue, May 7, 2013 at 8:33 AM, Simon Pieters <simonp@opera.com> wrote:
>> The spec currently has getComputedStyle which returns "resolved value"  
>> which
>> can be computed style or used style.
>>
>> Recently I added a method getDefaultComputedStyle which returns the  
>> computed
>> value but ignores author CSS.
>>
>> The use case presented above asks for specified style. Are there use  
>> cases
>> for the other kinds of values? Would cascaded value instead of specified
>> value be better (i.e. return 'initial', 'inherit' and 'default' instead  
>> of
>> specified value)?
>
> There's definitely use-cases for always getting used styles, due to
> them being "close enough" to the final values used in rendering.  For
> example, see the Grid spec, which is currently trying to specify that
> getComputedStyle() must return used values for its grid-definition-*
> properties.

Thanks. However, the grid spec doesn't state use cases for getting used  
value, as far as I can tell. If it is documented somewhere else, please  
give a pointer.

>> With my proposal above it would be
>>
>> console.log(getSpecifiedStyle(elem).marginRight)
>> console.log(getComputedStyle(elem).values.marginRight.px);
>>
>> In this case getComputedStyle probably gives you the used value -- are  
>> there
>> cases where you want the used style instead of computed style and
>> getComputedStyle returns computed style? Or vice versa?
>
> Yes, as I showed above - if specs are actually trying to opt into the
> legacy "used value" behavior, then clearly used values have value.
> ^_^

Without knowing the reasoning behind the grid spec, I can't evaluate its  
usefulness.

>>> Computed and specified are totally worth doing.
>>
>> OK. Is getComputedStyle good enough for computed value?
>
> As Boris points out, it's forever tainted by legacy behavior.  We
> should make a clean break in syntax and get a re-do on computed
> values.

That sounds reasonable, but I still want use cases stated for everything  
new introduced so we don't end up specifying and implementing things that  
don't get used.

>> I haven't seen any use case for getting the initial value. The default  
>> value
>> is addressed by getDefaultComputedStyle, I think.
>
> Yes, "initial value" is almost never what people actually want - most
> people consider the "initial value" of 'display' on <div> to be
> "block".  They really want the style that would be applied if there
> were no author styles, which is what "default" provides.

OK.

>
>> On Fri, 01 Feb 2013 03:25:44 +0100, L. David Baron <dbaron@dbaron.org>
>> wrote:
>>> I'd actually rather have separate methods or (probably preferably)
>>> getters for each sort of value we'd want to return (the set is
>>> pretty small) than have string arguments for "specified",
>>> "computed", etc.
>>>
>>> For example, maybe something like:
>>>   element.specifiedStyle.color
>>>   element.computedStyle.color
>>>   element.usedStyle.color
>>>   element.pseudoStyle("::before").specifiedStyle.color
>>
>>
>> If we go with this API style, should we change
>> getDefaultComputedStyle(element) to element.defaultComputedStyle? Or  
>> should
>> we stick to the current API style?
>
> Switch, please.  I'm much in favor of David's proposal.  It also lets
> us provide a .computedStyle property which is free of the gCS() legacy
> pain.

Any objection from Mozilla for changing this? (Gecko supports  
getDefaultComputedStyle.)

>> Does this mean that CSSOM Values would only work for used values, not
>> specified or computed?
>
> Depends.  Some type conversions clearly need to work in used-value
> space.  You *can't* obtain the .px value of something specified in
> percentages without being in used-values, for most properties.  Some
> conversions can be done with computed-value information.

OK.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 7 May 2013 21:27:11 UTC