Re: [cssom] Directions for better OM expansions

* Tab Atkins Jr. 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.

There are actually more relevant interfaces, for instance .runtimeStyle,
.currentStyle, and the "traits" API in SVG Tiny 1.2. Also note that any
interface to manipulate style sheets will be somewhat crazy as you can't
manipulate the objects as you can manipulate the plain text style sheets
unlike, say, the Document Object Model when dealing with XML documents
(how for instance do you work with features that are supported by some,
but not all, web browsers?)

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

Consider that requested. Not having a frame of reference will quickly,
especially on this list, result in "My syntax is better than your syn-
tax!" "But your syntax doesn't do X!" "We never talked about X!" style
discussions. The requirements you derive from the use cases you don't
provide for instance do not indicate if you are looking to address only
the needs of web page authors, or also those of authors of editors and
other tools.

(I also have some doubts that having an interface to manipulate style
sheets, as opposed to an interface to manipulate style properties of
elements and groups of elements, beyond what we already have, is such
a sound proposition in general.)

>Notice that *not* listed above is a specific segregation between
>specified/computed/used values.  This distinction between specified,
>computed, and used is completely useless to authors in general.  When
>they're getting at decl blocks or @style (from #1 or #2), sure, stick
>with the specified value in the form that was provided.  But when
>you're accessing the "real style" (#3 above), they shouldn't have to
>care - they should be able to ask for the value in px, em, or percent
>(or keyword, rgb, or hsl, for that matter) no matter what the original
>value was specified in.  Using Anne's Values API for this seems great.

I assume this will be after web browsers implement a proper type for,
say, Color objects so authors don't start abusing the style sheet API
to do color computations like hue rotations?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 14 September 2010 03:26:55 UTC