RE: [cssom] Directions for better OM expansions

Unless I've missed it, all the use-cases so far have to do with 
reading/writing properties. Any use-cases for selectors ? Enumerating
them ? Enumerating all the selectors that match a given node ?
Editing them ?

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Tab Atkins Jr.
> Sent: Tuesday, September 14, 2010 10:47 AM
> To: Anne van Kesteren
> Cc: www-style list
> Subject: 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 Wednesday, 15 September 2010 23:53:11 UTC