Re: [cssom] Author-defined at-rules

On 01/07/2013 18:10, Tab Atkins Jr. wrote:
> "Why not?" is never the right question.  ^_^  Even if a new primitive
> seems obvious, it still has to justify itself with uses.

I didn't mean to say features shouldn't require uses, but that providing 
extensibility should be an ambient use case throughout the platform: 
what Alex Russell calls use case zero [1]. The "why not?" question isn't 
about introducing features without justification, but that if features 
exist, they should be available for reuse and extension by authors 
unless there are good reasons not to do so.

> Anyway, I'm convinced of the utility of this. Just for fun, let's
> throw some ideas at the wall.  Note, I don't intend this to show up in
> a spec immediately, and any ideas here are very preliminary.  This
> kind of thing might show up in Variables 2 or something.
>
> For example, might it be useful to constrain the prelude to an ident
> that gives its name, so we can automatically collapse multiple
> definitions of the same thing and provide an easy way to access rules
> of a given type by their ident?  Or is it better to just let it be
> completely unconstrained, and let script query the list and set up
> maps on its own?  (Further thought leads me to believe that we
> shouldn't make any assumptions - let the prelude be whatever, and let
> the script do the collapsing by itself, with us providing enough
> information to make it not too hard.)

I wondered about this myself. I think the prelude should be 
unconstrained. Statement at-rules wouldn't be much use without this ability.

> I'm thinking a possiby more useful querying API would be to expose a
> list of all the custom at-rules in a given document, as a map keyed by
> their at-keyword.  Each entry would have its prelude and value as a
> string, a scoping element if they're in a scoped stylesheet, a bool
> indicating whether they're currently active or not, and two listeners
> for when the rule gets activated and deactivated.  (God, we could
> really use reactive values. Having to constantly write up
> attribute+change-event combos is getting tiresome.)  Something like:
>
> partial interface CSS {
>    readonly attribute CSSCustomRuleMap customRules;
> }
>
> [MapClass(DOMString, sequence<CSSCustomRule>)]
> interface CSSCustomRuleMap {
> }
> (The map entries for CSSCustomRuleMap are all the custom at-rules in
> all stylesheets in the document, with the custom rule's name (the
> at-keyword, minus the leading @) as the key and the rule itself as the
> value.)
>
> interface CSSCustomRule {
>    attribute DOMString name;
>    attribute DOMString prelude; /* strip whitespace tokens from the
> start/end of the prelude */
>    attribute DOMString? value; /* null if the rule is ended with a
> semicolon rather than a block */
>    readonly attribute Element? scopingElement; /* scoped style rule */
>    readonly attribute boolean active; /* either top-level, or in an
> active conditional rule */
>    EventTarget onactive; /* I can't remember the exact WebIDL for this,
> and don't want to look it up right now. */
>    EventTarget oninactive;
> }
>
> ~TJ

I like this. I think there'd need to be a way to listen to changes in 
the map, so your library could set up the appropriate listeners on the 
custom rules as stylsheets are added and removed from the document.

[1] http://infrequently.org/2013/05/use-case-zero/

Jon Rimmer

Received on Tuesday, 2 July 2013 10:42:34 UTC