Re: [cssom] Author-defined at-rules

> > The point is: you'll have to build a parser anyway. If you're up to the 
> > trouble of making a parser, the cost of making a preprocessor out of it 
> > is close to 0.
>
> You need to build a parser for the syntax of your custom rule, but there's 
> no reason to think that needs to be a full CSS parser, or even a CSS 
> parser at all.

By the time browsers all support this custom at-rule thing, all existing 
preprocessors will have a plugin system that does that work for you, and 
there will be tons of bootstraps available. I'm pretty sure some already 
are.



> Placing a single reference to the polyfill is a lot simpler than 
> installing a preprocessor, integrating it into a workflow, and configuring 
> it to search every CSS, HTML, PHP, ASPX, etc. file in a project for 
> instances of your custom syntax to generate the style JS file.

You're not objective. You have to do this already to install your polyfill. 
If you can do it for your polyfill, there's no reason you can't do it for 
your customized build of the polyfill including the json data.



> I preprocess on my computer for the project I'm working on, and it 
> requires a Grunt workflow to minify, concatenate and otherwise mangle and 
> process things in the right order as required by the various tools and 
> frameworks I'm using. It took an age to get working properly and it's 
> complicated and fragile, with the result that adding new tools is 
> burdensome enough not to bother anymore and I'm increasingly removed from 
> the edit-refresh-test cycle has always been a singificant value 
> proposition of web development.

It probably has more to do with your needs & setup than with the 
requirements of preprocessors. I never used such complex and fragile 
architecture nor do I intend to.



> > This is not to say I'm completely against it, but everything that could 
> > be preprocessed on the server should be preprocessed on the server. 
> > There's no reason in forcing two parsers to analyse the same information 
> > every time you reload the page. Also, there's no way to know when the 
> > CSS is done with parsing so when do you start looking for your custom 
> > at-rules?
>
> By that argument, we should remove all declarative APIs from the browser, 
> HTML, CSS, SVG, etc., process everything into JavaScript calls, and just 
> have the platform consist of imperative APIs.

Not at all. Whether we speak about HTML, CSS or SVG, the declarative syntax 
is a very effective way to transmit information & the browser actually 
*understand* it (and much faster than a script could communicate it).

Using those declarative tools in a way they just can't understand the data 
you give them, however, is a waste.

Received on Tuesday, 2 July 2013 12:16:50 UTC