RE: [cssom] Directions for better OM expansions

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, September 13, 2010 7:48 PM
> To: Sylvain Galineau
> Cc: www-style list
> Subject: Re: [cssom] Directions for better OM expansions
> 
> On Mon, Sep 13, 2010 at 7:20 PM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> > I'm so excited to read about new CSSOM directions I might have missed
> it
> > but a big fat one is: authors should not have to parse values such as
> > numbers or lengths. The browser has already parsed "100px"; having
> browsers
> > re-serialize it to a string so authors can break it apart with JS, do
> > something with it - likely assuming the unit is px - and then re-
> serialize
> > it is too inefficient and fragile.
> >
> > So I'll be brutal and claim that if a new API could do everything you
> list but
> > still made me deal parse string values - or worse, shorthand string
> values - I'd
> > still consider it a fail.
> >
> > Given that you mention Anne's Values API, I could assume you take
> this as granted.
> > But it's such a pain point I don't want to take it as granted :)
> 
> Hah, yes, I take it as granted that the Values API or something with
> similar capabilities will exist to expose values directly as numbers
> and maps and such.  (I'm quite happy with the feel of the Values API
> as currently imagined.)

- Same here. 

- I also think the use-cases should be evaluated based on
who the author is. Daniel or the people who build Firebug-type tools
have much different priorities from people who build apps. Serialization
matters a lot to the former group, less so to the latter. 

I think keeping which kind of author we're talking about in mind will help
us understand whether a particular solution addresses the use-case. For 
example, walking back from a cascaded style to its selector, specificity 
etc. is very cool but something I could personally live without. Daniel 
would say I'm crazy to be saying such a thing and stop talking to me for
a month.

So the specified/computed/used segregation is not useless to all authors.
For some features, being able to easily edit the specified value could
be useful to all authors e.g. changing a calc() expression without overwriting
the whole thing.

- I'd also like to break this down to a level where we know what use-cases
are covered - however imperfectly - by the current API. This is important
in terms of prioritizing those scenarios that are possible today.

- Re: #3 and used style. I think many authors expect computed style to be the
used style, not element.style. The latter was always the element's 
style attribute afaik ?

- The ability to serialize the computed/used style of an element to a declaration 
block and vice-versa, to turn a declaration block into a style object, may also 
be useful for editor-type functionality. 

- #5 sounds a lot like IE's runtimeStyle. 

- Another aspect is media queries: whether/how styles that do not match are surfaced
in the OM, whether/how one can override media feature values...

- Yes to unit conversions.

Received on Tuesday, 14 September 2010 03:33:50 UTC