Trigonometric Functions in CSS
web.dev
web.dev
Most added features solve real problems.
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.
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.
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
There are other consideration in technological spread that by far outweigh "being the pinnacle of technological achievement in its field".
I'm not sure this means what you think it means.
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.
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".
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
https://www.w3.org/History/1989/proposal.html
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.
https://achievement.org/achiever/sir-timothy-berners-lee/#in... "
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.
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.
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")
^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
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.
> 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.
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...
https://support.google.com/chrome/thread/207650291?hl=en
https://support.mozilla.org/en-US/questions/1409055
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.
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.
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'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.)
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 ;)
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.
One of the greatest tragedies in tech history.
your code golf assignment, should you choose to accept it: a webassmebly interpreter written entirely in CSS.
https://accodeing.com/blog/2015/css3-proven-to-be-turing-com...