[danielvaughn]

Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route.

Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.

[toast0]

A clean break is hard to manage because of chicken and egg things. If you want to deploy it to your web pages, either you need to ship the required viewer too (and have the user buy in for that), it needs to translate into something today's browsers can use, or you need to do the work both ways.

If your new system is translatable to the old system, it's often not clear what that brings you. And you often end up in the trap that the new system never quite matches the abilities of the old system, so it's hard to abandon the old ways.

[onion2k]

You could do it like picture tags do for images. Define a list of sources inside a new tag, and let the browser pick up the first one it understands with a default old style link tag placed last.

[RheingoldRiver]

That's kinda what something like TailwindCSS is, no? Use their reset & their shorthands, and many of these problems are solved; then your build system translates to the actual CSS standard.

[danielvaughn]

No what I'm referring to is much, much broader. I'm talking about literally a different file extension + rendering engine + execution context. There are a whole host of issues that are outside the scope of just CSS.

[jerf]

We're getting there, slowly but surely. WebGL + WASM will eventually let you simply drop down a custom rendering engine, but we've got a long way to go to get there. We're creeping up on being able to sensibly render an entire UI that way, but that UI will not have good accessibility until the browser exposes that more generically, and a lot of other little details.

Then you can do whatever you want, or, more realistically, grab an open source alterna-rendered that does something close to, but not quite exactly, what you want, but close enough.

It's a lot of work to get there from here, but all the forces push that way and I expect it will happen, even if it takes another decade.

Reserve your seats now for the inevitable progression of HN stories, roughly by year:

1. Show HN: My Alterna-render Renders Text Around Arbitrary Images

2. Layout.rs: A Minimal Alterna-Renderer In Rust

3. Layout.rs Has Gotten Too Bloated

4. Why You Should Stop Using Alterna-Renderers And Just Use HTML+CSS

5. Facebook's App Reaches 5 Gigabytes of Rendering Code

6. When to use and not use an alternative renderer

[chrismorgan]

You’re far too optimistic.

The pure-canvas approach is currently very bad, and most of what makes it so is fundamentally unfixable, because fixing it would require exposing unacceptable details (for privacy or functionality). I’ve written about this quite a few times on HN. A few of the things I tend to mention could conceivably be fixed, but browser-makers have shown absolutely no inclination to address any of it.

No, for at least the rest of this decade, doing things properly will absolutely require using the HTML DOM. And I’m very sceptical that browser-makers will ever seek to make the pure-canvas approach a viable alternative, there are just way too many problems with it.

If you reduce the scope to custom layout and such for CSS, there are interesting experiments in the CSS Houdini project.

[Nathanael_M]

7. Mistakes in the Design of Layout.rs (2030)

[giantrobot]

First you need buy-in which means essentially Google needs to support the format in Blink. It needs to be sufficiently specified so Apple supports it in Safari on iOS as well (which means support on Mac and iPad).

Second you'll need a good reason for the new format instead of just implementing it in current browsers. Lots of fancy stuff on the web today is just something that draws to a <canvas> tag and ignores a lot of actual HTML or CSS. We're already seeing a lot of traditionally "desktop" code being able to target WASM as a compile target.

[rusk]

You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.

[fiddlerwoaroof]

The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.

[rusk]

Still the same problem. You’ve to get people to use the extensions. You mentioned a few “back in the day” examples and nobody uses these. CSS got the push and gained critical mass initially and that’s that. There’s been plenty of improvements since of course and if you can disregard legacy platforms it all gets a lot easier but that’s where the experts you want to sway define their value.

[fiddlerwoaroof]

Browsers update quickly enough now that you can adopt new features relatively aggressively for desktop sites. Wasm might even let us ship these extensions to the script and style tags through a separate distribution channel, enabling better adoption of alternate languages in the browser.

Finally, CSS itself is starting to get some more programmability via the Houdini APIs.

[rusk]

Like I say, if that was the solution it would have worked already. We have several iterations of CSS at this stage each solving the problems of the previous but if you want to develop a layout that people can actually use you still need to support the old browsers and you have to get the vast community of web developers who are “happy enough” with CSS to get on board and learn your toy alternative. If you want something more advanced there are plenty of well established macro languages atop CSS that you can use , much as you don’t need to know assembler to write modern applications

[danielvaughn]

This sounds interesting - what do you mean by the "built-in extension points"?

[fiddlerwoaroof]

I already listed them: doctypes, the lang/type attribute for script/style/link tags, and custom elements/attributes.

Back in the day, you could use alternate scripting languages in IE: VBScript shipped by default, but there was also the ability to install an ActiveX extension to enable Python and some others in the script tag.

[maxloh]

That was what Flutter was initially built for IIRC.

Google would like to have Dart replace JavaScript too.