Re: [cssom] Author-defined at-rules

On Mon, Jul 1, 2013 at 12:31 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> 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.

Not particularly, actually.  Can you explain why you think so?  The
same restriction applies to custom properties, and I think they're all
right with it.

>> > 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.

You can't really do these with preprocessors, unless you're really
intrusive and generate and link into the document a JS file containing
the data you embedded into CSS.

Avoiding having to re-request the file (which only works same-origin
anyway, unless you go to the additional effort of turning on CORS
headers) and reparse the entire thing yourself is one of the reasons
we added custom properties.  The same reasoning applies to entire
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).

One of the great values of building extensibility in correctly is that
you only need JS, which is trivial to add to a page.  Requiring
additional programs on the server side is actually a large impediment
to most people.

(Note that preprocessing to JSON isn't enough, since you want to know
when it stops/starts applying based on containing conditional rules.
This is *not* a trivial thing to shim in; you need a decent bit of
specialized CSS knowledge/parsing, and need to do a decent bit of
non-trivial work on the JS side.  This is one of the factors that go
into whether or not we should build something into the language.)

~TJ

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