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.
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.
"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")
Maybe, but I'm looking at my brand-new Samsung Galaxy Book 3 Pro 360, and lamenting that it is impossible for me to select text using a stylus in a natural fashion in the popular web browsers.
and while Seamonkey and K-meleon work properly, they aren't usable with Discourse, which is a big part of what I need to do on the web.
If backwards compatibility is so great, why can't I select text as I've been accustomed to since Go Corp. PenPoint and Windows for Pen Computing? It's not even good UI from a discoverability standpoint --- I handed a stylus and my Samsung Galaxy Book 12 running Windows build 1703 to a tech at Best Buy and asked them to select text and they were successful, but when prompted to select text on a similar system running Windows 11 they were stymied.
Aren't you describing forwards compatibility? The Web is "backwards compatible" in the sense that old sites render on new browsers. But it sounds like you're describing new sites failing to render on old browsers (in the case of Discourse). For your stylus issue, that is slightly different since it's about input devices, but it still sounds like a forward compatibility issue to me, but I guess you could argue it either way.
I want to be able to select text as I have since Go Corp.'s PenPoint.
When using my Samsung Galaxy Book 12 running Windows Build 1703 to browse the web, it works to select the text in a natural fashion, no press-hold and fiddling w/ extension hooks necessary.
I just want a contemporary browser on Windows 11 w/ a stylus to work thus --- what do I need to do? I've tried disabling Windows Ink, and I can't find any flags/settings in Chrome or Edge or Firefox which have a meaningful effect.
I empathize with your frustration, but it sounds like an issue with your operating system and/or hardware vendor. I suppose it's fair to expect Chrome/Firefox to allow you to configure your input device to act like this, too. But the problem is not with the Web platform or any standard - it's some combination of your operating system and browser that's deciding how to translate "tap and hold" into Web API events like onClick or onTouch (which are notoriously annoying to implement cross-platform).
The problem is dragging with the stylus is converted into scrolling, which was changed in Fall Creator's Update, _and_ implemented in Chromium.
I just want a way to turn it off --- I've turned off Windows Ink, but I can't find any options which affect this behaviour in Chrome/Edge --- I've disabled every option there is for scrolling --- what else can be turned off?
Yeah, I'm not a windows user nor a stylus user. Best I can suggest is to check your OS input device settings. At least on Mac, that's where I can configure settings related to scrollbars, which propagate through to browsers.
I've enabled the one option which is supposed to affect this:
Settings | Bluetooth & Devices | Additional Pen Settings | Let me use my pen as a mouse when it's available
and I have disabled every flag for Microsoft Edge related to scrolling.
It's robustly, and intentionally broken, and I rue the day that I found it necessary to update, and I really wish someone would make a tablet w/ a Wacom EMR stylus which would run the Mac OS.
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
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.
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...
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".
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/
(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.)
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 ;)
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.
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.
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.
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.
> 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.
idk how you experience the last 20 years in the web without seeing a proof that we solved and evolved. the dom is in fact so successful and popular for ui that not only is it used for _more_ of what's on the web than it was 20 years ago, but that web ui's only "escape" has been onto the desktop, phones, tvs, embedded, etc
The DOM was standardized, and became ubiquitous. From thereon, people built upon that not because it was great but because it was all there was. JavaScript is also all there is and was, and everyone agrees that it is everything but great. Even the inception of nodejs and demo is due to the fact that the infrastructure was already there.
Being pervasive is not the same thing as being good or decent.
Just because adoption spit off of it’s initial purpose doesn’t mean it’s a good technological plinth, not even in its initial intended scope — nor that it doesn’t.
There are other consideration in technological spread that by far outweigh "being the pinnacle of technological achievement in its field".
Of course, when you phrase it as "only available in the browser" then there are no alternatives. That's why Figma had to "create a browser inside the browser" because the tech is just so, so amazing: https://www.figma.com/blog/building-a-professional-design-to...
No, not really. HTML was from the start and always has been designed to specify UIs. From the very start HTML had support for specifying UI element trees, including higher-level UI design patterns like buttons, combo boxes, radio buttons, etc, and also supported running scripts as part of events triggered from those UI elements.
> Most added features solve real problems.
That's debatable, both with regards to "solve", "real", and "problems".
> HTML was from the start and always has been designed to specify UIs.
Of course it wasn't. These attempts to retcon hitory of the web are more and more prevalent these days.
Sir Tim Berners-Lee invented world wide web and the first versions of HTML for a very specific goal in mind: to share and link textual documents (specifically, research papers).
From the man himself:
"We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities. The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards
It was designed in order to make it possible to get at documentation and in order to be able to get people — students working with me, contributing to the project, for example — to be able to come in and link in their ideas, so that we wouldn’t lose it all if we didn’t debrief them before they left. Really, it was designed to be a collaborative workspace for people to design on a system together.
This is what people mean about DSLs needing to be small in scope.
If you go past that scope, you need to completely redesign, or create two separate DSLs. Surely not taking a super small, specific, DSL like "what if we made redundant styles automatic by cascading them down the DOM tree?" and try to extend that for every conceivable styling, layout, rendering, and animation need.
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.
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.
The animation examples have an significant impact on CPU and GPU usage. On a i7 CPU the overall utilization is going 10%+ and both GPUs are used 30% more. Different browsers have a different footprint. But at least the plus only happens if the animation is visible.
