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

On Wed, Jul 3, 2013 at 3:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, May 7, 2013 at 2:56 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > On Tue, May 7, 2013 at 2:26 PM, Simon Pieters <simonp@opera.com> wrote:
> >> 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.
> >
> > The use-case is figuring out how wide your tracks actually ended up,
> > after the grid layout algorithm was run, so you can, for example,
> > position abspos things around it, size canvases, etc.
>
> Talking this over with fantasai on Monday, we've come to the
> conclusion that it's probably not a good idea to expose .usedStyle at
> this point, for two reasons:
>
> 1. Not all properties *have* a used style.  If a property doesn't
> apply to an element, we don't define what the used value is.  You
> could just say that it's the same as the computed value in that case,
> but that's just filling in a hole with something meaningless; there's
> still not really any concept of "used value" for the property.


This may be the wrong place to ask this, but what do you mean by "If a
property doesn't apply to an element"? I was under the impression that an
empty string would indicate this if I'm understanding correctly. For
example, the used and computed values of a detached element are all empty
strings because none of the properties apply to the element. I could be
misunderstanding here.


> 2. We can do *so much better* at used-value time. At that point we
> have all the necessary information to expose lengths in *any* unit you
> ask for, rather than just px.


> Because of this, fantasai and I think we should hold on doing
> .usedStyle, in favor of pursuing the long-discussed idea of the Values
> API, which allows asking rules for their values in various units.
>

My original naive proposal begs for the values API as well. As long as I
can get "auto" vs. "50%" vs. "50px" whenever I want for the "actual" value
of the property on an element, I think we're good. What would that look
like?


>
> ~TJ
>



-- 
Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com