Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.
I'm mostly in favour of the "principle of least power", but I think the requirements for CSS would be a good fit for something like DSSSL:
- Designers/developers will, as a general rule, always max-out the system; as long as the performance is at an acceptable level, the features and bloat will increase. If it becomes unacceptable, those features and bloat will be trimmed accordingly. Hence, no matter the underlying technology, performance will almost always hover around "barely acceptable". The difference would be how much "bang for the buck" we would get for that performance; presumably a "barely acceptable" page using CSS would be capable of more than a "barely acceptable" page using DSSSL, since DSSSL would exhaust the performance budget more quickly.
- Trying to dictate which stylistic elements can/cannot be used seems like a thankless task, since many will disagree and either come up with awkward workarounds or lobby to get their desired features included (which may or may not disrupt the coherence of the provided elements). Providing a full programming language is effectively pre-empting those workarounds, and giving the community control over the available elements (e.g. via libraries). This would lead to lots of awful code, but some good ideas would emerge and become widely adopted. Browsers might specialise their evaluators to speed up common usages, etc. Very similar to Javascript, polyfills, etc.
- CSS is, after all, "just" styling information, and is applied progressively on top of HTML. The document is still machine-readable, even if we might not be able to answer particular questions about its layout and visuals. It's conceivable that some people might, for example, obfuscate their document content, and re-assemble them using styles, e.g. to prevent crawling; that's more of a cultural/social issue than a technical one though, and that cat's already out of the bag with Javascript, single page apps, etc.
In any case, the current trend of working around CSS's limitations with Javascript is the worst of both worlds. At least we might attempt to evaluate DSSSL, to see what it might look like, whilst any attempts to evaluate Javascript will quickly run into barriers like side-effects (should we run AJAX calls? What should "alert" do? etc.)
Well, slower and then faster. Virtual selectors mean that CSS is now also Turing-complete (in a horrible, horrible way). And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript.
CSS is only Turing-complete in pathological cases. Pathological cases do not make a good basis for policy decisions. In reality, the loss in performance from losing the style sharing cache alone would probably swamp any gains you'd get from DSSSL.
The point is virtual selectors and using Javascript for styling both have very poor performance characteristics, and both are A. ubiquitous and B. hacky kludges driven by the excessively limited nature of CSS as originally designed.
I'm probably out of my depth here, but what do you mean by the style sharing cache? I mean, any kind of file can be cached by the browser, including Javascript. And presumably browsers could've implemented optimizations (with or without the aid of hinting annotations) to identify those DSSSL functions that need only be evaluated once.
(BTW, like the author of the article seems to, I actually think that PSL looks like the best of the CSS alternatives he lists).
> And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript.
I severely doubt that. JavaScript can inspect attributes of anything on the entire page, run remote HTTP queries and inspect their attributes, and make styling decisions based on those, on the fly, and in response to user GUI events.
Granted, I'd probably be really okay with these features no longer existing. Just saying, I don't think any DSSSL could have taken them on.
I should've been more clear — DSSSL might've been able, possibly in conjunction with later extensions (just as XJAX was not originally part of Javascript), to provide a similar end-user experience in many cases as CSS+Javascript currently does, albeit with very different semantics for the developer.
Not sure it would be better (it probably erred on the side of too much mixing of program logic and styling rather than too little), but it would certainly be different.
Stylesheets would be smaller, and only execute slightly slower on the client due to the expansions needed. Trading rendering speed for network speed is a good choice.
Not only do I think the stylesheets would not end up appreciably smaller after gzip, I also disagree with that argument. Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web. Making the Web even slower at rich interactive apps is not doing the Web any favors.
> Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web.
Except this is an argument against JavaScript driven behaviour, not against a restricted styling language slightly more expressive than CSS. The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a domain-specific language where optimizing redraw is loads easier would yield performance improvements, not regressions.
> The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a domain-specific language where optimizing redraw is loads easier would yield performance improvements, not regressions.
No, it wouldn't. "Optimizing redraw" isn't difficult, and to the extent that it is it has nothing to do with the expressiveness of CSS.
You've seemingly ignored the main thrust of my point in order to quibble over what I meant by optimising redraw. Seems dishonest at best.
Do you agree or disagree that a domain-specific layout language with would be faster to render and animate than a general purpose programming language interacting with the DOM? This seems like an undeniable yes.
Do you agree or disagree that such a layout language could supplant some of the uses of JavaScript over the years? This too seems to be an undeniable yes.
So it seems undeniable that modern browsers would be faster than they currently are on the metrics you criticised them as compared to native apps, which seems to be your primary concern.
And you can claim gzip is good enough to eliminate any space savings a more expressive language would yield, but the fact is people still minify their JS and CSS for significant savings, which means even small differences matter; further, domain specific optimisations have significant effects, and a precompiler could perform advanced common subexpression elimination passes to further compress beyond what gzip could dream of without affecting the semantics your layout.
So theoretically and empirically it seems my point that trading off rendering speed for network speed is not only well motivated, but already settled in my favour.
> Do you agree or disagree that a domain-specific layout language with would be faster to render and animate than a general purpose programming language interacting with the DOM? This seems like an undeniable yes.
No. I don't believe this is true. With CSS as a declarative language, we can do global optimizations that are much harder to do than with a general programming language (especially one that's as hostile to static analysis as Scheme!)
> Do you agree or disagree that such a layout language could supplant some of the uses of JavaScript over the years? This too seems to be an undeniable yes.
Sure, but that's not worth slowing down so many Web sites for.
> And you can claim gzip is good enough to eliminate any space savings a more expressive language would yield, but the fact is people still minify their JS and CSS for significant savings, which means even small differences matter
Sure, but it's not worth trading off the rendering performance.
> a precompiler could perform advanced common subexpression elimination passes
Not with Scheme, it sure can't! You can do those dynamically, but not statically.
DSSSL is not Scheme, it's a domain-specific language, which solves nearly all of your objections that aren't conjecture. Domain-specific languages are obviously much more amenable to optimization. Such a stylesheet language can be trivially cache JIT compiled stylesheets, and because they're more expressive, you'd see more reuse across pages, and possibly even across sites. The bandwidth savings are non-linear.
