Re: [cssom] Author-defined at-rules

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

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.



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

This is the idea, indeed. I don't think this is that complex. People can 
even to it themselves. They'll need to link their polyfill anyway 
otherwhise.

  <!-- both generated from style/main.hyper-css -->
  <link rel="stylesheet" href="style/main.css />
  <script defer src="style/main.js"></script>



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

The custom at-rule solution suffers from the exact same issue. If it wasn't 
the case, you could use that to read content out of some website by adding 
"@abc {" into its content by XSS and by reading the content of the at-rule.

However, a preprocessor doesn't have this problem.



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

I preprocess on my own computer using using Visual Studio or 
http://alphapixels.com/prepros/ when I use Brackets/Notepad++.

There's no requirement on the server.



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

It doesn't seem very complex to me to understand nested at-rules, and all 
are easily hookable from JS.

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?

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