Re: [cssom] Author-defined at-rules

On Mon, Jul 1, 2013 at 10:35 AM, Fran├žois REMY
<> wrote:
>> [Tab Atkins giving a more formal proposal]
> My concern is that this does not solve the problem at all, because what do
> you do if you want to nest some newly-generated at-rules? Do you have to
> parse again their content, recursively? If you goal is to end up parsing
> things in JavaScript at the end, you're better do it once, and have all your
> data JSON formatted and easy to load via your prollyfill thereafter. Putting
> things the browser cannot possibly understand in the CSS is probably not a
> very good idea.

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 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.  There are lots of lots of things
that can potentially be done with this kind of ability.  Many of them
will be bad ideas.  Some will be okay, but never good enough to make
it into the language.  Some will be good, and the prototyping will
provide the necessary experience and social proof to get them into CSS
when they wouldn't have otherwise done so.  I'm willing to accept the
first category in order to cater to the second and third, as long as
we can do it in a sufficiently high-quality and low-impact way.

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


Received on Monday, 1 July 2013 17:55:08 UTC