Re: [cssom] Directions for better OM expansions

On Tue, Sep 14, 2010 at 12:32 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 14 Sep 2010 03:36:19 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> We've been mostly discussing Anne's proposed Values API.  I think it's
>> a great start, but doesn't address the larger problem that the shape
>> of the APIs surrounding CSS is somewhat crazy.  They don't work
>> together - you've got el.style pointing to the @style attribute on an
>> element, el.ownerDocument.defaultView.getComputedStyle('someproperty')
>> to get a resolved value (sometimes a 'computed', sometimes a 'used'
>> value), and the stylesheet-based API.  These all work *completely*
>> differently, with vastly different access patterns, some being
>> writable while other are readonly, etc.  It's just a bad situation
>> overall.
>
> Why? They have vastly different use cases. It seems perfectly logical to me,
> too, that the resolved values are readonly. They are after all based on all
> the rules in the style sheet. What would it even mean to edit them?

They really don't have different use-cases.  An ordinary web author
can, in the course of doing ordinary style manipulation, want to get
at the used value of a property for an element, set something in the
@style attribute, and edit the stylesheet decl block providing the
value for another property.  These are all perfectly natural actions,
and should be doable in a reasonably consistent and easy way.

(Used style should indeed be readonly, actually.  My note about
combining #3 (used styles) and #5 (override styles) expresses my
desire to maybe merge them together, but I don't think that's really
doable, for several reasons.  It should still be simpler to get at
than it is currently.)


> Most of your proposals have been planned as additions to the CSSOM for a
> long time and have been discussed to on www-style as well. Basically by
> providing different accessors, e.g. ele.cascadedStyle, ele.usedStyle, and
> maybe also what IE has already implemented for override style sheets,
> ele.runtimeStyle.

Sure; I intentionally wasn't referencing any previous work or
discussion in this space, so I could just talk about the shape of the
solution that I wanted to see.


> However, before we add these I think we should first sort
> out how we want to do value manipulation. Otherwise people will still be
> stuck with string manipulation.

Right; like I said to Sylvain, I'm taking a Values API for granted.
It's an orthogonal (but necessary!) part of the solution.


>> So, I've boiled down the use-cases I think are useful to address (not
>> included in this email for brevity, but can be provided upon request)
>
> Please do email these.

All right, here they are, expressed in terms of user stories:

1. I'm writing a CSS editting tool, and I want to present to the user
all the rules that apply to a particular element, and where they come
from, ordered by specificity.

2. I'm writing a CSS editting tool, and I want to let the user edit
arbitrary CSS that may come from @style attributes or author
stylesheets.

3. I'm writing a CSS editting tool, and I want to present the "actual
values" of all properties to the user, so they can see exactly what's
happening at that exact moment even if they don't understand the
cascade process.

4. I'm writing a CSS editting tool, and I want to present a "metrics"
display visually illustrating all the box-model dimensions (width,
height, padding, border, margin) in both their specified value and
what that translates to in absolute dimensions (that is, px).

5. I'm a page author, and I want to read/write the value of a property
in the @style attribute of a page.

6. I'm a page author, and I want to read/write the value of a property
in the style-sheet block that's providing the value (or just the first
one that *would* provide the value, if it wasn't being overridden by
@style or something) so that the change will propagate to all similar
elements.  (Possibly this requires a bit more smarts from the author,
like examining selectors?)

7. I'm a page author, and I want to set a style to a specific value
without worrying about whether I'm killing something that was
specified in a stylesheet or a @style rule (often occurs when you're
wanting to hide something - you want to display:none it, but then
restore it to whatever display value it had previously, which may have
been set in @style).

8. I'm a page author, and I want to see what the value of a property
is, regardless of what its source is.

9. I'm a page author, and I want to see what the value of a property
is in a particular unit, regardless of what unit it's provided in.

10. I'm a page author, and I want to see what the value of a property
is while an animation is running and affecting the value.

11. I'm a page author, and I want to see the values of various
properties while the element is affected by a transform (that is,
width should be 2x while a scale(2) is in effect).

Again, I'm taking for granted that a Values API will exist to make
reading and manipulating all these values easy, so I didn't mention
that in anything here.

~TJ

Received on Tuesday, 14 September 2010 17:47:20 UTC