Why is CSS extended in JavaScript files instead of in CSS files?

[chriseppstein]

I just don't understand why CSS files would be extended from JS files instead of by the CSS files themselves. If the behaviors are defined in CSS files, then there is a natural scope for which the custom behaviors would be defined, puts the behavior closer to where it is used, and makes delivering the stylesheets with their dependencies much easier (via css @import or inline).

Furthermore, when we put code that is essential to the CSS developer's experience in a file of a completely different type, we create a boundary that can feel scary for them to cross. If we put the logic for custom behaviors in CSS we are telling those developers "This is for you. you can do this." which is very empowering.

Lastly, I think it would be great if the scripting ability that is used for extending css was not JavaScript, but actually a scripting language that is designed and allowed to be used throughout the CSS file, but also within the extensible constructs provided by houdini. I'm sure this is a non-starter, but we've seen this approach be very successful in Sass, and the scripting syntax we've developed there would make a good starting point for a CSS-specific script.

[tabatkins]

There's a limit to how much can be done in CSS, similar to how there's a decent limit to how much can do done in pure Sass before you have to move into Ruby.

If you make CSS scripting powerful enough to obviate JS, you've just reimplemented most of JS, and then what's the point? Adding a second scripting language to the platform seems like a lot of trouble for very little benefit.

Note: I'm totes fine with minor stuff, on par with what Sass currently does, allowing conditionals and looping and basic string manipulation and such. That seems legit useful without having to define how CSS interfaces with the CanvasRenderingContext API, etc.

and makes delivering the stylesheets with their dependencies much easier (via css @import or inline).

Delivering a bundle via <link rel=import> makes this quite a bit easier. But also, if it proved useful, we could allow importing worklets from within a CSS file, either with @import or a new at-rule.

[FremyCompany]

The issue with extensions-in-css (that would not be JavaScript code but a special scripting language) is that you cannot use tools like npm or browserify to bundle your apps and share code between your css extensions and your page, which limits an in-house scripting to what a casual css author needs, and not what a polyfill author needs. It also brings questions about the scope of the work we do: how do you distribute your polyfills if they have to be included in the authors stylesheet directly? (at)import is a bad practive on the web because you have to download the stylesheet to find out what the dependencies are, which make you loose precious time up to rendering.

However, I'm a big proponent of allowing more lightweight scripting in css directly, for things where it makes sense. I hate not being able to provide my own javascript math function for animation-function, for instance. Or being able to use more complex math expression in calc(...). Or being able to create my own pseudo-classes. Etc, etc, etc...

Small javascript islands in css files would be immensely useful for those cases, and I always have been a huge supporter of the idea of extending css scripting capabilities towards what javascript offers (initially through strict subsets like basic expression only, then eventually to a full javascript engine running a bit like a worklet and cooperating with the engine).

That being said, this is still different from what Sass can offer, because Sass is a preprocessor that runs before the browsers starts understanding the CSS. I think we should have something like that, but I'm not entirely sure browsers vendors are the best location to work on this; communities like Sass are far better at evolving those things and responding to user feedback. Over time, maybe some features will transition to css directly, at least I hope so.

Does this and Tab's answer address your questions?

[therealglazou]

I tend to agree with Chris. Let me explain: the three bricks of the OWP are html, CSS and JS. We put JS in html, a super-successful framework puts html in JS, Components happily mix everything and only CSS remains isolated like an ivory tower. This does not totally feel right to me.
Custom Queries would make more sense if defined in CSS using JS code or targeting a boolean JS function. Property and values extensions would also make more sense if they were defined by the CSS embedding those extensions and not by an extra script. This does not say APIs purely on the JS side are not needed. But having everything on the JS side will probably add complexity to the model instead of removing complexity: the parser will have to be extended before the CSS sheets are read.

[tabatkins]

Custom Queries would make more sense if defined in CSS using JS code or targeting a boolean JS function.

That's already the plan of record.

Property and values extensions would also make more sense if they were defined by the CSS embedding those extensions and not by an extra script.

I'm not sure what you mean here.

the parser will have to be extended before the CSS sheets are read.

??? We're not offering the ability to customize the core parser. We can parse everything, and then later figure out which things are being handled by JS (and which ones are just mistakes or non-supported blocks, to be thrown out).