Re: [cssom] Author-defined at-rules

> Yes.  You can't actually parse the insides of custom rules, since you
> don't know what they are.  They could be something that's not CSS at
> all.  The only constraint we place is that it parse as generic CSS
> tokens, so no unpaired quotes, etc.

This is a pretty strong restriction.



> > This is just my personal point of view, but I believe we should restrict 
> > CSS
> > post-processing to things that just cannot be done in the pre-processing
> > world. Creating SVG via CSS is really on the edge because you can 
> > generate
> > your data url using a preprocessor, but that's not super-cool either.
>
> Read Jon's second message, and mine.  This isn't about "creating SVG
> via CSS".  It's about making it low-friction to fill things in via JS,
> for experimentation and extension.

I understood it perfectly. But this will not enable any new ground for 
experimentation. You can perfectly do this already using a preprocessor. You 
can even load your CSS file with a JS again and run a custom parser on it 
that only looks to your at-rules and their parent at-rules.



> I'm of the opinion that virtually every part of CSS deserves to be
> ripped open and exposed directly to authors, in some way.

Well, I've a more conservative approach on extensibility. I'm in favor of 
opening extension points to location where it would be a worse practice to 
do the same thing using another way (ie: it would be a waste of resource or 
of deloper time), but not especially all the other possible hooks.

In my opinion, the easiest way to do something should always be the best 
one, and in this specific case I believe preprocessing the custom at-rules 
and export them to a JSON file is actually much better than relying on the 
browser's CSS parser to return something you're gonna parse again in JS. Not 
adding the easier-but-worse option is just a way to make sure people choose 
the right option (and in this case do the preprocessing on the server).

Received on Monday, 1 July 2013 19:31:51 UTC