- From: François REMY <francois.remy.dev@outlook.com>
- Date: Sat, 29 Jun 2013 11:17:12 +0200
- To: "Simon Sapin" <simon.sapin@exyr.org>, "Jon Rimmer" <jon.rimmer@gmail.com>
- Cc: "www-style list" <www-style@w3.org>
> 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 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:17:36 UTC