Re: [cssom] Directions for better OM expansions

On Mon, Sep 13, 2010 at 8:33 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
> - 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.
>
> [snip]
>
> - 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.

All right, I'll send the use-cases in the morning.  I have them
written down on my whiteboard right now.

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

Right, you should be able to get the specified value easily through
whatever #1 is.  Being able to edit the value specified *in a style
sheet* can definitely be useful to normal authors, too - if I want to
change the font-size of all the headings of each news story on my
page, I want to do so directly, not by touching each one's @style
attribute.


> - 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 personal experience of me and Alex Russell, plus many novice
authors we've worked with, has been that el.style looks like it should
give us, well, the style of the element, not the @style of the
<element>.  I *still* slip up and try to treat it like that sometimes
(especially since jQuery lets me cheat and just use .css() to read the
current style, no matter where it's from).


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

Hmm, I'm not certain I understand the use-case.  Can you elaborate?


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

Yeah, I think it's covering basically identical ground.


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

Yeah; I'm not addressing that right now, but it should definitely be
integrated into here somehow.  I'm not sure of the use-cases for
programmatic control of MQ-related stuff, though.


> - Yes to unit conversions.

Excellent.

~TJ

Received on Tuesday, 14 September 2010 03:44:46 UTC