6 ms·

It would have been cool if, some 20 years ago, the CSS designers had realized they were designing a programming language and started on that basis. Instead we g

It would have been cool if, some 20 years ago, the CSS designers had realized they were designing a programming language and started on that basis. Instead we get mostly adhoc extensions slowly adding these features over decades.

tannhaeuser 4y ago
CSS has been a job security/browser lock-in club for the longest time. It's one of the last areas of influence W3C (now W3C, Inc.) has over web standardization, with Google paying and pulling the strings, their other puppet being a loose group of individuals having a long term investment in writing web specs on github called whatwg. There is/was the Houdini API proposal as a way to plug JavaScript into CSS low-level layout already rather than invent a thousand microsyntaxes for CSS equivalents of programming language constructs such as CSS custom properties, calc(), trigonometric functions, degenerative uses of media queries, and other crap. The idea being to return to reasonable coverage for document presentation, and an extension API for web apps (as opposed to sites) requiring JavaScript anyway as a 80/20 trade-off. But any notion of mental discipline is lost on CSS heads really. It already starts with the very invention of CSS as a redundant syntax for markup attributes, then declaring an unsound structure/presentation dichotomy as a syntactic feature after the fact. A plausible explanation for CSS absurdity might be that evolution of HTML the markup language was organizationally blocked so many years that everything around it had to cater for its stagnancy and ossification. Even the inventor of CSS had opposed against custom properties already, formally questioning their necessity.
- chatmasta 4y ago
  "Job security" seems like an unfair way to describe backwards compatibility. Most of the quirks of the Web platform are due to it having some of the strictest backwards compatibility standards of any software. For the most part, you can view a GeoCities site from 2005 in the latest Chrome browser and it will render the same as it did 18 years ago, assuming all the assets are still loadable. IMO, the Web as a platform has done a great job maintaining this standard, and it's only been in recent years that all the browsers became "evergreen" and are able to add new changes at a rapid pace. I definitely wouldn't hold this against the people responsible for maintaining (!) the CSS spec. Now, should there be some entirely new design language that starts fresh without any of these assumptions, and free from technical debt? Well, maybe, but then again that's kind of what each new version of the CSS spec does when it introduces new rules, which is much easier now with all browsers evergreen. (edited to replace "green field" with "evergreen")
  - tannhaeuser 4y ago
    I'm willing to concede backwards compat, but how is browser tech "green field" when we haven't seen new browsers developed from scratch for well over a decade (^1) and have even lost two long-standing browser codebases (MS, Opera) during that time period? ^1 with laudable exceptions that haven't reached any reportable status/alignment with specs yet after years of work however, and possibly never will as browser tech scope expands every day like the frontier of the universe is expanding faster than the speed of light
    - chatmasta 4y ago
      I think I might be misremembering the term. It's not "greenfield," but "green" something, and is used to refer to browsers updating relatively simultaneously, which only began in the past few years. EDIT: I love ChatGPT. The term I meant to use is "evergreen." It refers to browsers that automatically update in the background, so everyone is using the latest version of their chosen browser. I'll edit my original comment.
      - tannhaeuser 4y ago
        Ah ok, you mean evergreen, in that case everything is ok in browser land ;) > it's only been in recent years that all the browsers became "evergreen" and are able to add new changes at a rapid pace The "rapid pace" is due to basically only three browsers left, and the only winner is the browser cartel we're enduring.
        chatmasta 4y ago
        > the only winner is the browser cartel As a user, I sympathize and agree wholeheartedly with this argument. But as a developer, I feel like one of the winners. I certainly don't miss the days of adding complexity to my build tooling or limiting which features I can use, just because I still need to support some inexplicably popular browser that last received updates half a decade ago. I'm not sure what the answer is, but perhaps some crazy person out there should consider building their own browser from scratch. That's the only way we'll get more open competition in the market...
samwillis 4y ago
I disagree, it's still exactly what it set out to do, to be a declarative UI layout and styling language. That decision to be declarative rather than a procedural/imperative language is its biggest strength and one of the reasons the HTML/CSS/JS/HTTP platform is the dominant application platform today. The level of thought and attention to detail that has gone into each addition to CSS should be commended. I wouldn't describe its growth as anywhere close to "adhoc".
- noelwelsh 4y ago
  I agree that imperative programming is not the right thing for CSS. Browser layout is basically a constraint solving problem, and there are languages that take constraint solving as their core computational model. Mercury is an example of this approach: https://mercurylang.org/ https://mercurylang.org/ (I'm not saying Mercury is the best language for CSS. It's just an example of a constraint logic programming language, which are programming languages that have constraint satisfaction as a core part of the language.)
  - tannhaeuser 4y ago
    Mercury is a Prolog-derived language with static types and clause determinism annotations for static compilation. In Prolog slang, Prolog SLD resolution wouldn't be called "constraint solving" though it certainly can solve constraints over finite domains via exhaustive search. Constraint solving as a term is typically associated with finite and interval constraint propagation methods on top of Prolog. Actually, Prince (fka Prince XML) is a commercial CSS renderer for paged media that has been implemented using Mercury, and I'd say is even a major showcase for Mercury. But unfortunately, Prince isn't open source, and what little is known of its internals is that it doesn't use much Prolog-style indeterminism/backtracking but is quite procedural in nature. Maybe CSS matching is implemented using Prolog-style unification/pattern matching but CSS selector matching uses eg. priorities whereas Prolog matches applicable clauses in document order, so I don't know about that. Actually, I'd love to hear about that from Prince developers hanging around here ;)
nicoburns 4y ago
IMO the CSS syntax is actually pretty well designed. The meaning of some of the the properties (e.g. float) is screwy, but that has little to do with the language itself.
hajile 4y ago
We wouldn't be in this situation if Brendan Eich had been allowed to ship a scheme like he was hired to do. Had that happened, we'd be free of the perpetual JS feature churn (and all the weirdness). Performance would have gotten better much faster. HTML templating like React offers with JSX would have happened 15 years earlier. We'd be sending S-expressions over the wire instead of JSON. As to CSS, we would have gone with the S-expression proposal instead of the current one and promptly integrated it into the language, so most of the modern weirdness around CSS simply wouldn't need to exist.
- Slackwise 4y ago
  Couldn't upvote this hard enough. I fundamentally blame Sun and Java for this. I guess I blame James Gosling for Java, and Sun's aggressive marketing of Java in the 90s, along with the naming/marketing deal with Netscape that resulted in JavaScript being created instead of Scheme being adopted. One of the greatest tragedies in tech history.
megaman821 4y ago
What would that look like? Most modern UI frameworks on other platforms look an awful lot like CSS to me. These new frameworks have no baggage and they still choose to be very CSS-like.
simplotek 4y ago
CSS sounds like the poster child of feature creep. It started as the right way of specifying styling (colors, fonts, line weights, spacing, etc) and now it's so extensive it looks like it's competing with OpenGL.
- andix 4y ago
  The scope of HTML/CSS shifted vastly. It started as framework for formatting text and evolved to a interactive UI library. Most added features solve real problems.
  - illiarian 4y ago
    > and evolved to a interactive UI library. It didn't, not really. We've bolted interactive UI on top, and it's held there by spit, out-of-date duct tape, and wasted lives > Most added features solve real problems. They are very ad-hoc post-factum solutions to a subset of real problems that solve those problems very poorly. You can't escape the fact that the core of the system is made to display a single page of static text. To actually solve and evolve that you need to actually rethink things from scratch. That's why UI is slowly but surely escaping into Canvas and WebGL.
    - andix 4y ago
      It’s the best thing we have and it gets the job done.
      - illiarian 4y ago
        > It’s the best thing we have Oh, it's not even close to being the best thing we have.
        erklik 4y ago
        > Oh, it's not even close to being the best thing we have. What's the best thing we have then? Because I am not aware of any alternatives to CSS that I can use in the browser.

tannhaeuser 4y ago

CSS has been a job security/browser lock-in club for the longest time. It's one of the last areas of influence W3C (now W3C, Inc.) has over web standardization, with Google paying and pulling the strings, their other puppet being a loose group of individuals having a long term investment in writing web specs on github called whatwg. There is/was the Houdini API proposal as a way to plug JavaScript into CSS low-level layout already rather than invent a thousand microsyntaxes for CSS equivalents of programming language constructs such as CSS custom properties, calc(), trigonometric functions, degenerative uses of media queries, and other crap. The idea being to return to reasonable coverage for document presentation, and an extension API for web apps (as opposed to sites) requiring JavaScript anyway as a 80/20 trade-off. But any notion of mental discipline is lost on CSS heads really. It already starts with the very invention of CSS as a redundant syntax for markup attributes, then declaring an unsound structure/presentation dichotomy as a syntactic feature after the fact. A plausible explanation for CSS absurdity might be that evolution of HTML the markup language was organizationally blocked so many years that everything around it had to cater for its stagnancy and ossification. Even the inventor of CSS had opposed against custom properties already, formally questioning their necessity.

chatmasta 4y ago
"Job security" seems like an unfair way to describe backwards compatibility. Most of the quirks of the Web platform are due to it having some of the strictest backwards compatibility standards of any software. For the most part, you can view a GeoCities site from 2005 in the latest Chrome browser and it will render the same as it did 18 years ago, assuming all the assets are still loadable. IMO, the Web as a platform has done a great job maintaining this standard, and it's only been in recent years that all the browsers became "evergreen" and are able to add new changes at a rapid pace. I definitely wouldn't hold this against the people responsible for maintaining (!) the CSS spec. Now, should there be some entirely new design language that starts fresh without any of these assumptions, and free from technical debt? Well, maybe, but then again that's kind of what each new version of the CSS spec does when it introduces new rules, which is much easier now with all browsers evergreen. (edited to replace "green field" with "evergreen")
- tannhaeuser 4y ago
  I'm willing to concede backwards compat, but how is browser tech "green field" when we haven't seen new browsers developed from scratch for well over a decade (^1) and have even lost two long-standing browser codebases (MS, Opera) during that time period? ^1 with laudable exceptions that haven't reached any reportable status/alignment with specs yet after years of work however, and possibly never will as browser tech scope expands every day like the frontier of the universe is expanding faster than the speed of light
  - chatmasta 4y ago
    I think I might be misremembering the term. It's not "greenfield," but "green" something, and is used to refer to browsers updating relatively simultaneously, which only began in the past few years. EDIT: I love ChatGPT. The term I meant to use is "evergreen." It refers to browsers that automatically update in the background, so everyone is using the latest version of their chosen browser. I'll edit my original comment.
    - tannhaeuser 4y ago
      Ah ok, you mean evergreen, in that case everything is ok in browser land ;) > it's only been in recent years that all the browsers became "evergreen" and are able to add new changes at a rapid pace The "rapid pace" is due to basically only three browsers left, and the only winner is the browser cartel we're enduring.
      - chatmasta 4y ago
        > the only winner is the browser cartel As a user, I sympathize and agree wholeheartedly with this argument. But as a developer, I feel like one of the winners. I certainly don't miss the days of adding complexity to my build tooling or limiting which features I can use, just because I still need to support some inexplicably popular browser that last received updates half a decade ago. I'm not sure what the answer is, but perhaps some crazy person out there should consider building their own browser from scratch. That's the only way we'll get more open competition in the market...

samwillis 4y ago

I disagree, it's still exactly what it set out to do, to be a declarative UI layout and styling language. That decision to be declarative rather than a procedural/imperative language is its biggest strength and one of the reasons the HTML/CSS/JS/HTTP platform is the dominant application platform today. The level of thought and attention to detail that has gone into each addition to CSS should be commended. I wouldn't describe its growth as anywhere close to "adhoc".

noelwelsh 4y ago
I agree that imperative programming is not the right thing for CSS. Browser layout is basically a constraint solving problem, and there are languages that take constraint solving as their core computational model. Mercury is an example of this approach: https://mercurylang.org/ https://mercurylang.org/ (I'm not saying Mercury is the best language for CSS. It's just an example of a constraint logic programming language, which are programming languages that have constraint satisfaction as a core part of the language.)
- tannhaeuser 4y ago
  Mercury is a Prolog-derived language with static types and clause determinism annotations for static compilation. In Prolog slang, Prolog SLD resolution wouldn't be called "constraint solving" though it certainly can solve constraints over finite domains via exhaustive search. Constraint solving as a term is typically associated with finite and interval constraint propagation methods on top of Prolog. Actually, Prince (fka Prince XML) is a commercial CSS renderer for paged media that has been implemented using Mercury, and I'd say is even a major showcase for Mercury. But unfortunately, Prince isn't open source, and what little is known of its internals is that it doesn't use much Prolog-style indeterminism/backtracking but is quite procedural in nature. Maybe CSS matching is implemented using Prolog-style unification/pattern matching but CSS selector matching uses eg. priorities whereas Prolog matches applicable clauses in document order, so I don't know about that. Actually, I'd love to hear about that from Prince developers hanging around here ;)

nicoburns 4y ago

IMO the CSS syntax is actually pretty well designed. The meaning of some of the the properties (e.g. float) is screwy, but that has little to do with the language itself.

hajile 4y ago

We wouldn't be in this situation if Brendan Eich had been allowed to ship a scheme like he was hired to do. Had that happened, we'd be free of the perpetual JS feature churn (and all the weirdness). Performance would have gotten better much faster. HTML templating like React offers with JSX would have happened 15 years earlier. We'd be sending S-expressions over the wire instead of JSON. As to CSS, we would have gone with the S-expression proposal instead of the current one and promptly integrated it into the language, so most of the modern weirdness around CSS simply wouldn't need to exist.

Slackwise 4y ago
Couldn't upvote this hard enough. I fundamentally blame Sun and Java for this. I guess I blame James Gosling for Java, and Sun's aggressive marketing of Java in the 90s, along with the naming/marketing deal with Netscape that resulted in JavaScript being created instead of Scheme being adopted. One of the greatest tragedies in tech history.

megaman821 4y ago

What would that look like? Most modern UI frameworks on other platforms look an awful lot like CSS to me. These new frameworks have no baggage and they still choose to be very CSS-like.

simplotek 4y ago

CSS sounds like the poster child of feature creep. It started as the right way of specifying styling (colors, fonts, line weights, spacing, etc) and now it's so extensive it looks like it's competing with OpenGL.

andix 4y ago
The scope of HTML/CSS shifted vastly. It started as framework for formatting text and evolved to a interactive UI library. Most added features solve real problems.
- illiarian 4y ago
  > and evolved to a interactive UI library. It didn't, not really. We've bolted interactive UI on top, and it's held there by spit, out-of-date duct tape, and wasted lives > Most added features solve real problems. They are very ad-hoc post-factum solutions to a subset of real problems that solve those problems very poorly. You can't escape the fact that the core of the system is made to display a single page of static text. To actually solve and evolve that you need to actually rethink things from scratch. That's why UI is slowly but surely escaping into Canvas and WebGL.
  - andix 4y ago
    It’s the best thing we have and it gets the job done.
    - illiarian 4y ago
      > It’s the best thing we have Oh, it's not even close to being the best thing we have.
      - erklik 4y ago
        > Oh, it's not even close to being the best thing we have. What's the best thing we have then? Because I am not aware of any alternatives to CSS that I can use in the browser.