Re: [cssom] Author-defined at-rules

> No, I wouldn't. With the feature I've proposed, the polyfill would only 
> have to register the receive notifications of the custom rules that it is 
> interested in. The browser itself would take care of parsing the rest of 
> the CSS for conditional rules, parsing the HTML for embedded <style> tags, 
> recognising scoped stylesheets and determining the element they applied 
> to, registering the appropriate conditional handlers, handling styles in 
> <template>s, web components, dynamically inserted stylesheets, etc. using 
> the infrstructure already in place to do this. The polyfill would simply 
> have to deal with the contents of the rule itself.

According to me, this is still a way to trade a bit of preprocessing work 
for a fair amount of extra complexity on the polyfill side (or, and this is 
much more likely, a sharp decrease in overal quality of the available 
polyfills) as well as a whole lot of wasted resources. Why do 100.000 times 
what you can do once?

Firstly, to enable the kind of magic you want, your polyfill will have to 
run on top-level context, so it will have a hard time working great inside 
web components & templates. You'll have to handle dynamic contexts, creation 
& deletion of contexts, and make sure you never globally leak. However, if 
your polyfill is embedded right after the style-sheet it was compiled from, 
it will run independently inside each web components and template, will be 
self-contained, much simpler and far less prone to leak because it doesn't 
mix contexts. Also, it may only include the parts you're actually using in 
your stylesheets, not all of them, and it will be much faster because it can 
generate code instead of iterating over objects and arrays.

Secondly, you'll have to deal with the fact you cannot be sure when the 
style is ready, potentially having to support "cancel what I did before 
because new information contradicts it" and "let's already try to apply the 
style we have" which requires non-trivial setups, particularly if your use 
case is dynamic. If you preprocess, you can wait before all required 
information is ready in the current context before taking actions which 
reduces complexity. You certainly trade a bit of flexibility there, but you 
reduce by a huge amount the number of possible bugs.

Last but not least, if you're invading CSS at a page level, you're 
potentially hooking into someone's else code which may not want to use your 
polyfill: this opens the way to conflicts. That's most probably an issue for 
Web Components that may want to use a different implementation of the 
feature. By embedding the data in the implementation, you make sure there's 
no two polyfills which will try to interpret at the same time your data. You 
may want to use v2 for most purposes app, but v1 for a very complex animaion 
nobody wanted to update to the new version.



> The custom syntax needs itself to be processed, either on the server or on 
> the client. Again, you may have a philosophical objection to performing 
> this processing on the client. I don't. I think the gains in 
> ease-of-experimentation, ease-of-deployment and ease-of-use are worth the 
> "waste" of doing some parsing in script, and just saying, "we shouldn't do 
> this" is not going to convince me in the absence of any other evidence.

Performance immediately comes to mind here: you page load will take a hit. 
Also: wasting battery life of devices.

To sum up: "Friends don't let friends compile their stylesheets in the 
browser" ~ Chris Eppstein [1]



> This proposal makes it easier for developers to write polyfills that 
> introduce new syntax, and easier for developers to use them by simply 
> dropping in a script tag and using the new syntax within their CSS.

But if it promotes easier-but-subpar prollyfills, what's the point?



Anyway, I'm not in favor of this change for now because I don't think it 
will greatly improve polyfilling capabilities and there are other, much more 
important areas where CSS is lacking critical extensibility hooks. This is 
not an objection or anything, this is just a notice I don't support that 
feature at this time. If browser vendors want to pursue this I've no issue 
with it, but I can see a lot of more important features we simply cannot 
emulate efficently in JavaScript right now, and think we should focus on 
that.


__________________________
[1] https://twitter.com/chriseppstein/status/337577059519979520

Received on Tuesday, 2 July 2013 16:22:15 UTC