Let's not forget DRM. Now that framebuffer can be delivered via an encrypted EME module, thereby killing the open web permanently for the purposes of scraping.

Thanks a bunch, W3C!

I for one would welcome the death of HTML and CSS. Unfortunately I suspect they will merely be re-used for this.

HTML and CSS are fantastic; when used what they were designed for. Document markup and display. I blame webapp developers for the scope creep and subsequent denigration of a perfectly reasonable set of standards.

I find it really hard to rationalise this thought with the thread...

- WebAssembly + Canvas rendering is bad because it turns the web into a bunch of opaque blobs and removes user freedoms and abilities

- The web should only be for documents, not applications

- So it follows that... all the applications which are currently "open" websites should be opaque native app executables where you can't have extensions or adblockers or anything?

To be clear, I agree with the first point. Websites moving to opaquely rendered canvases is terrible. They should remain "normal" DOM/HTML.

I'm not a web developer, so keep this in mind as I clarify.

Application development for browsers is, in a way, a stack of huge hacks on the top of huge hacks. Developers are using HTML and CSS for purposes they were never intended (e.g. a WYSIWYG word processor), and doing some really gnarly hacks to make it all work.

Those gnarly hacks required to make their applications work prejudice web application developers against HTML and CSS, since they don't work worth a damned for those developers.

But HTML and CSS work remarkably well for what they were designed for: Documents.

Applications have, historically, usually been distributed in a different format than documents. Perhaps they should resume that trend; targeting the browser just being the OS, and leaving the document standards for documents.

My knee jerk response to the original article was, "this is making the web less free," but a bit of thought raises the question, "I can't interact this way with Microsoft Word, so why do I expect to interact this way with Google Docs?"

CSS has absolutely never been good at what it was designed for.

It is meant to display a document. It took TWENTY YEARS before it got support for showing text in columns, the most basic of basic things in how text is often displayed.

It is only now, after twenty-five years, getting a way to specify the aspect ratio of an element.

It's an awful, awful joke.

CSS was originally intended to consolidate document style information, so you didn't have to repeat "24 point bold, blue" for all your section titles. It's pretty good for that, but then we somehow decided that it should also handle the entirely separate job of page layout. Which led to years of standards people yelling at us to use CSS and not tables, and then plugging their ears when asked how to implement complex designs like vertically centered text.

HTML and css are great for making application GUIs. I used a bunch of frameworks like qt and Java <some kind of verb> and wpf and they were all worse than php, css and HTML.

I would argue that Tk is even better for making GUIs.

Here is a simple Tcl/Tk application: https://rkeene.org/viewer/projects/tkweb/test1.tk.htm

And here's what that application looks like (in a web browser, as well as natively, bear in mind that this from 2003): https://rkeene.org/viewer/projects/tkweb/tkweb-test1-2.png.h...

Can you describe the resulting layout as well as interactions as well in HTML ?

HTML and CSS were never denigrated. There's not one superficial feature which doesn't make sense. Most of it is barebones. If I had to pick one feature the blows the scope out of proportion, it would be the `is` selector, but that's the only one I can think of

Denigrated ~= put down.

And there's plenty of examples within the comments of this article where people - webapp developers - harp on how bad HTML and CSS are, because HTML and CSS weren't designed for webapps.

CSS is the worst layout language, except for all the others.

Why? They are the best layouting tools we have to this day. Or do you want to go back to

  TextElement textElement = new TextElement(); 
  textElement.position(100, 100);
  textElement.color(Colors.RED);
  textElement.alignment(Alignment.CENTER);
  ...

and the likes? These kind of descriptional ui tools are horrible in my opinion.

I find those tools much easier to get a decent GUI layout with. Getting the same layouts with HTML and CSS seems to involve a pile of hacks, because they were designed as document markup, not button and panel layout tools. (that said, a markup system for constraint based layout would probably be better, and CSS does seem to be growing some of the features, it still just seems to be hard to get something that works as consistently as e.g. Qt).

...and yet we still have these things, like Gtk, Tk, ImGUI, some parts of Qt, etc, and they work reasonably well. I just spent time building a new widget set for small LCD screens (~160x40) and built the set in as simple a way as I could, and this was the easiest method to do so. Sure, it's not great from a designer perspective, but it gets the job done -- more or less what HTML + CSS do now, but (frankly) in a far less verbose way.

We had layout managers by the early 90s, and Java was not the only choice. Delphi, wxPython, and Qt were/are pretty good. Do not use pixel positioning or hardcode colors was right in the docs.

I don't, we are going to have hundreds of different accessibility and IME implementations, all with different quirks and bugs and many websites won't care at all so even writing letters with accents will be a hassle (if possible at all). Or think about websites assuming your keyboard layout is US QWERTY. Or websites not properly handling subpixel rendering or retina displays (and looking upscaled and blurry). Those are all solved problems with HTML and CSS that will have to be solved again, this time not by 3 rendering engine dev teams but by each web dev for each website.

It’s not like the w3c provides us all with rendering engines. We still use browsers which do it for us. If these canvas techs spread, everyone will rely on canvas framework toolkits that do it for them. Still not great for user power

Input methods are managed by the OS, the browser delegates control. It can't do that over a simulated input control rendered on a canvas. Also what I mean is that all these are problems already solved by browsers that follow w3c recommendations, custom rendering solutions will have to reimplement everything without access to OS APIs that make many of those things possible in a unified way.

What would you replace it with? Keeping in mind that web pages are supposed to be accessible to people in the sense that anyone with an interest to do so can put up a marked document for display because it's displaying material, not programming an interactive environment. If you take away the accessibility of HTML from people, then you're also taking away a significant portion of the "open" Internet and moving toward a more closed corporate-curated model due to the higher barriers to entry if you want to publish something.