Re: [cssom] Author-defined at-rules

On 01/07/2013 21:17, François REMY wrote:
>> 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.
>

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. You could accept a different or much simpler syntax. 
With a preprocessor, you have to process all the CSS to extract the 
conditional rules that affect your custom rules, represent them as JSON, 
then consume them on the client and create the appropriate conditional 
handlers. You also need to provide integration with the various build 
tools and module formats to let people use your preprocessor in a real 
workflow.

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

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.

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

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.

>
>
>> (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?

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.

Being able to write declarative code, serve it up as-is, and have the 
browser deal with parsing and interpreting it has always been one of the 
biggest benefits of web development. Extensions to the platform should 
be able to work in the same manner.

Jon Rimmer

Received on Tuesday, 2 July 2013 11:35:09 UTC