W3C home > Mailing lists > Public > www-style@w3.org > August 2011

Re: Could CSSOM provide constructors and factory methods?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 11 Aug 2011 13:13:51 -0700
Message-ID: <CAAWBYDBLj7828O-guZoNmhB7ozUYHC+DwejxBcp2E73BBMkOSg@mail.gmail.com>
To: Dominic Cooney <dominicc@google.com>
Cc: www-style@w3.org
On Tue, Aug 9, 2011 at 6:57 PM, Dominic Cooney <dominicc@google.com> wrote:
> The CSSOM seems to have a preponderance of parsing for creating objects. For
> example, to create a MediaList, I bounce a string off a stylesheet:
>
> s.media = 'print';
> s.media  // MediaList appears!
>
> What do you think about separating parsing, creation, and setting? For
> example, applied to rules:
>
> Specific CSS*Rule subtypes have Constructor(…) metadata.
> insertRule is overloaded to accept CSSRule instances as well as DOMString.
> Static CSSRule.parse(DOMString) can parse strings to produce CSSRules, so
> you don’t have to abuse setters to do it.
>
> Since there is not a detailed hierarchy for CSS values, maybe factory
> methods instead of constructors make sense, so:
>
> Static CSSPrimitiveValue.parse(DOMString)
> Static CSSPrimitiveValue.px(unsigned int)
> etc.
>
> Having specific constructors and methods seems better than relying on
> strings alone, because it is easier to find syntax errors (because mistyping
> these result in JavaScript errors, which have stacktraces and tools support)
> and it is easier to discern what the possible uses of a value are, whereas a
> string could be anything.

This is closely linked with the object-based CSSOM API for
reading/manipulating values.  Since we'll be returning objects, it
definitely makes sense to have them directly creatable too.

It's not actually possible to parse an arbitrary string of CSS into an
appropriate value, though.  For example, "blue" would be parsed as a
keyword, where it could be a color, or a font name, or a counter name,
or a counter style name.  There's probably a few other user-created
identifiers that I'm missing, too.  Variables has the exact same
problem when exposing its values to script via the proposed
object-based API.

You either need to explicitly specify the type it should be, or
specify a property to evaluate the string in the context of.  (That's
how the CSS engine normally disambiguates, obviously.)

I think both are useful.  We can directly provide the primitive types
as constructors, and also provide the ability to evaluate it for an
arbitrary property.

For example, CSS.Color('blue') would return a Color object as
expected, which exposed .r, .g, .b, .a, .h, .s, .l, etc..

CSS.parse("blue",'background'), on the other hand, would return an
object with the same properties as what you get out of the
'background' property, which I think means it exposes the
sub-properties (.image, .color, .repeat, etc.) corresponding to the
uppermost layer and numbered properties corresponding to each layer
(including the one exposed directly).

~TJ
Received on Thursday, 11 August 2011 20:14:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT