Re: [cssom] Author-defined at-rules

> > Again, I sympathize with everything you say about extensibility, but I 
> > am not really moved by this specific proposal. If this is just about 
> > storing stuff in CSS files remember that you can have whole at-rules in 
> > variables in you feel like it:
>
> While I don't think abusing custom properties to define at-rules-like 
> things is a good idea (both performance-wise and conceptually-wise), I'm 
> still leaning towards the idea that the best way to deal with this is to 
> preprocess some "HyperCSS" files (SASS, LESS, ...) where you can introduce 
> any at-rule you may want to generate a browser-understandable CSS file and 
> a companion JavaScript file containing user-defined things. There's no 
> point in keeping in CSS format data that you'll need to convert to 
> JavaScript understandable information just after if you cannot harness the 
> CSS power at some point in a way that would be impossible or cumbersome in 
> CSS. As Tab

I meant "impossible or cumbersome in JS", of course...

> and Simon noted, you can already use in JavaScript the conditional 
> features of CSS, it's just a matter of rewriting.
>
> As far as extensibility goes, I'd be far more interested in getting a 
> "querySelectorLive" function which would fire asynchronously a function 
> when an element starts or stops to match a selector. Right now, the only 
> way to do it is to make diffs from "qSA" and "qSA" is not even guaranteed 
> to use a cache so you may end up reexecuting the query all the times 
> instead of making a true diff.
>
> Then, a function that fires when the computed value of a property changes 
> on an (displayed) element would be awesome. But both are approximately 
> prollyfillable from each others so the easiest should be prioritized and 
> we can deemphasize the other.

Received on Saturday, 29 June 2013 09:26:45 UTC