- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 1 Jul 2013 10:10:21 -0700
- To: Jon Rimmer <jon.rimmer@gmail.com>
- Cc: Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
Please don't top-post. <http://wiki.csswg.org/tools/www-style> On Fri, Jun 28, 2013 at 5:52 PM, Jon Rimmer <jon.rimmer@gmail.com> wrote: > I see this as a way of putting any declarative, presentational configuration > for libraries/polyfills within CSS itself. For example, consider the > following example: Yes, that's all it is. You're doing literally nothing more than putting some data into the stylesheet to be received by a listener later. It's just moving the data from JS into the stylesheet, but without actually taking advantage of any properties of the stylesheet. > #panel { > var-janimation: bounce; > var-dragzone: four-corners; > } > > @var-jtimeline bounce { > 0s { > top: 10px !timing(ease) > } > > 1s { > top: 10px !timing(ease) > } > } > > @var-dragzone four-corners { > rect(0, 0, 5%, 5%) > rect(95%, 0, 100%, 5%) > rect(0, 95%, 5%, 100%) > rect(95%, 95%, 100%, 10%) > } > > Here, imagine I have a couple of JS libraries: One for animation, perhaps > built atop Web Animations, that lets you define a keyframed animation where > keyframes have a time value and properties support an independently > specified timing function. The second allows a drag zone to be specified via > a configured group of hot-spots. These are good examples. I see the value in being able to embed this sort of information into the stylesheet rather than in script, particularly when the JS that is actually processing the vars is part of a library, and thus not as easily alterable as hand-written code. (I actually started writing this email on Friday, but wanted to give it more thought over the weekend. During that time, I thought of an at-rule I'd like to add, but which would benefit very strongly from prototyping first, using exactly the form and abilities you thought of here. It's *substantially* different from anything you've brought up so far, so I'm convinced this idea has legs.) (The idea was about either embedding SVG directly in CSS, or translating some subset of SVG into a CSS-based syntax for embedding. It's a problem today that your SVG images are required to either be data urls, or be independent of your stylesheet.) > Frankly, I think it's less a question of "why allow this?" and more "why > not?". The platform should default to providing hooks and extension points > into capabilities like properties and at-rules, unless there are significant > security or performance risks to doing so. Custom properties were a good > start, and I think this would be an excellent continuation. Everyone agrees > new declarative syntaxes are needed for things like animations, so help > people experiment with them by providing the low level tools necessary. "Why not?" is never the right question. ^_^ Even if a new primitive seems obvious, it still has to justify itself with uses. 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'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
Received on Monday, 1 July 2013 17:11:08 UTC