[righthand]

> since it didn't just go away.

But do you see how removing a feature from a major browser makes it seem like RSS did just go away and how RSS will eventually go away?

What a terrible disingenuous argument. Anyone not in line with big tech deserves to be pushed aside eh?

[shadowgovt]

RSS hasn't gone anywhere. Every podcast my podcast player downloads is announced to it either via RSS or Atom feeds. It has just fallen by the wayside as the way people become aware of updates to websites with serial publication of content (in general: because most people get that information from peer-to-peer link sharing, like Facebook, Twitter, Mastodon, Fark, Reddit, Slashdot, or even this website).

They're not even removing the ability for the browser to render XML. They're just removing an in-browser formatter for XML (a feature that can be supported by server-side rendering or client-side polyfill).

[righthand]

Yes while their chosen formats directly aligned with their business get first class citizenship and suffer many larger and well known security issues. Xml will be next just wait.

[shadowgovt]

What would that mean? XML is just text on the wire. If a browser stops supporting it... It's text on the wire. I slurp it in with JavaScript and parse it how I want.

... Actually, that seems like a fine idea...

[righthand]

Great lets remove the Html and Css renders too then. I can just slurp it in with Javascript and parse it how you want. No standards, do what you want!

[shadowgovt]

The language in the browser for specifying what should show up and in what format is HTML and CSS. We can't remove them because we don't have anything to substitute; without them, there's just no displayable content.

Is your proposal that we replace those relatively heavyweight standards with something more primitive that we could then build the behavior on top of? I think there's meat on those bones. Quite frankly, the amount of work we do to push intent to fit the constraints of HTML and CSS in web apps is a little absurd relative to the frameworks and languages we have to do that in non-web widget toolkits. I'm not actually convinced that "Tk as an abstraction in the browser that we build HTML and CSS on top of" would be a bad thing (although we probably want to use something better than Tk, with more security guarantees).

... However, if we did that, we would really damage the accessibility story as it currently stands (since accessibility hinting is built on top of the HTML spec) and that's probably a bridge too far. We already have enough site developers who put zero thought into their accessibility; removing even the defaults HTML provides with its structure would be a bad call.