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

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.

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

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

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


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

> On Fri, 01 Feb 2013 03:31:51 +0100, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>> On Thu, Jan 31, 2013 at 6:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>
>>> Oh, used values?
>>>
>>> Why does translating between units need those, except for a very small
>>> set
>>> of properties?
>>
>>
>> There are a lot of properties with values that don't become px until
>> used-value time, for example.  This covers most properties with
>> percentages, a number of properties with 'auto', and a smattering of
>> other types of values.
>
> 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.

~TJ

Received on Tuesday, 7 May 2013 16:48:10 UTC