Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

Post reply on HN
Print view View original

291–300 of 362 posts

Re: Google is killing the open web, part 2

#291

Post by kuschku »

shadowgovt wrote: post #277
kuschku wrote: post #173

Earlier quoted context omitted.

> So put them on separate pages because they are separate protocols Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? It's the same content, just supplied in a different format. It should be the same URL.

Then the server should supply the right format based on the `Accept` header, be it `application/rss+xml` or `application/atom+xml` or `text/xml` or `text/html`. Even cheaper than shipping the client an XML and an XSLT is just shipping them the HTML the XSLT would output in the first place.

That's not exactly cheap on an arduino uno 3 with 2kb ram.

But regardless, someone suggested just including a script tag with xmlns of xhtml as alternative, which should work well enough (though not ideal).

Re: Google is killing the open web, part 2

#292

Post by kuschku »

righthand wrote: post #270
kuschku wrote: post #199

Earlier quoted context omitted.

Fair, but that shows the issue at hand, doesn't it? XSLT is a general solution, while most alternatives are relatively specific solutions. (Though I've written repeatedly about my preferred alternative to XSLT)

> (Though I've written repeatedly about my preferred alternative to XSLT) Link to example?

I've previously suggested the XML stylesheet tag should allow
which would then allow the script to use the service-worker APIs to intercept and transform the request.

Re: Google is killing the open web, part 2

#293

Post by dpark »

righthand wrote: post #282
dpark wrote: post #127

This has nothing to do with the “open web”. I don’t know if the people saying this just don’t have a meaningful definition of what open means or what. “Open” doesn’t mean “supports everything anyone has ever shipped in a browser”. (Chrome should support Gopher, really? Gopher was literally never part of the World Wide Web.) What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to…

Open wen doesn’t mean WHATWG gets to decide what is and isn’t useful in the browser. > What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to drop support for xslt. If you want to argue that this is bad because it “breaks the web”, that’s fine, Not only does it not break the web, they are flat out lying about that being the reason they’re doing it. That is also very dangerous. Y…

In the last thread about this, I tried to have a constructive conversation with you, and you jumped to ad hominem attacks multiple times and then when I tried to actually get clarity on what it means to be part of the “open web”, you explicitly said you didn’t want to engage anymore (and then continued your accusations elsewhere in the thread). Now you’ve chimed in here to essentially call me a paid shill and to repeat your baseless “killing the open web” soundbite.

Your definition of “open web“ appears to be “never deprecating a feature ever”. And it’s fine that you want browsers to support features forever. I don’t think that has anything to do with the open web though. Exactly like the author of this blog post, you believe things that were never even part of the “web”, such as gopher, should be supported in the name of an “open web”.

> Not only does it not break the web, they are flat out lying about that being the reason they’re doing it.

The library is known to have multiple security vulnerabilities. They have declared that it is not sustainable to maintain this dependency. And they have also declared that it’s not worth replacing it. I don’t see the lie in that. I don’t think anyone is claiming that they actually cannot support xslt. They are saying that it requires more investment to support, and the ROI is too low.

I also clarified this exact point last time. You are willfully misunderstanding the messaging because acknowledging the engineering trade offs here would force you to consider that this isn’t just an issue of lazy developers or evil PMs as you also claimed.

> please state if you work for any of these companies

I work for Microsoft who I don’t believe has chimed in on this conversation, though if Chromium removes it, Edge presumably will too. I have no visibility into the Edge position on this feature, though.

Re: Google is killing the open web, part 2

#294

Post by shadowgovt »

righthand wrote: post #285
shadowgovt wrote: post #275

Earlier quoted context omitted.

A rose by any other name. If you'd prefer I'd have said "But for keeping up to date on news, people use link aggregation boards where other users post links to stuff on the web and then talk to each other about them. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Hac…

Do you work for one of the companies involved deprecating Xslt?

I do not. Why do you ask?

Re: Google is killing the open web, part 2

#295

Post by shadowgovt »

righthand wrote: post #283
shadowgovt wrote: post #246

Earlier quoted context omitted.

I don't see why. You can always subscribe to a newspaper. Or just use RSS and a subscription tool since it didn't just go away. What I'm saying, though, is if you don't use social media at this point you're already an outlier (I am, it should be noted, using the term broadly: you are using social media. Right now. Hacker News is in the same category as Facebook, Twitter, Mastodon, et. al. in this context: it's a plac…

> 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?

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).

Re: Google is killing the open web, part 2

#296

Post by righthand »

shadowgovt wrote: post #295
righthand wrote: post #283

Earlier quoted context omitted.

> 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?

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 e…

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.

Re: Google is killing the open web, part 2

#297

Post by jjkaczor »

zzo38computer wrote: post #183
nwellnhof wrote: post #20

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

I think it might make more sense to use WebAssembly and make them as extensions which are included by default (many other things possibly should also be made as extensions rather than built-in functions). The same can be done for picture formats, etc. This would improve security while also improving the versatility (since you can replace parts of things), if the extension mechanism would have these capabilities. (How…

Yeah, when I first heard about this a month or so ago, my thoughts were exactly this - a WebAssembly polyfil.

Re: Google is killing the open web, part 2

#298

Post by Forgeties79 »

bigyabai wrote: post #167
Forgeties79 wrote: post #153

Earlier quoted context omitted.

Safari yes Mozilla…are they actually competing? Like really and truly.

Mozilla has proven they can exist in a free market; really and truly, they do compete. Safari is what I'm concerned about. Without Apple's monopoly control, Safari is guaranteed to be a dead engine. WebKit isn't well-enough supported on Linux and Windows to compete against Blink and Gecko, which suggests that Safari is the most expendable engine of the three.

I really can’t imagine Safari is going anywhere. Meanwhile the Mozilla Foundation has been very poorly steering the ship for several years and has rightfully earned the reputation it has garnered as a result. There’s a reason there are so many superior forks. They waste their time on the strangest pet projects.

Honestly the one thing I don’t begrudge them is taking Google’s money to make them the default search engine. That’s a very easy deal with the devil to make especially because it’s so trivial to change your default search engine which I imagine a large percentage of Firefox users do with glee. But what they have focused on over the last couple of years has been very strange to watch.

I know Proton gets mixed feelings around here, but to me it’s always seemed like Proton and Mozilla should be more coordinated. Feel like they could do a lot of interesting things together

Re: Google is killing the open web, part 2

#299

Post by downsplat »

I'm sure there are plenty of problems with the open web, and that Google is not entirely a stranger to them... but removing an ancient language that basically failed to get traction is not one of them. No matter how elegant and advanced a certain class of nostalgic XML programmers find it.

And no, XSLT doesn't have much to do with how much RSS thrives or not. RSS is basically consumed by RSS reader backends, not directly by users on their browser.

One of the web platform's problems, is that it accumulates untold cruft from every failed experiment. The entire XHTML exercise turned out to be an expensive mistake, but we can't remove that because too many pages depend on it, and it ended up in a whole lot of places, including the EPUB definition. But at least XSLT could get removed. Yay for that.

Re: Google is killing the open web, part 2

#300

Post by veeti »

jerf wrote: post #28
Aurornis wrote: post #16

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning. But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.

It has nothing to do with the specifics of the technology. As a consumer of online content, I don't care one bit if it is styled with XSLT or CSS (though as a developer my condolences are with the author, if they worked with XSLT).

However, what I do care about is that it _remains viewable and usable_. Imagine if Microsoft Word one day decided you couldn't open .doc or .rtf files from the early 2000's? The browser vendors have decided that the web is now an application delivery platform where developers must polyfill backwards compatibility, past documents be damned.

And just as the article drives the point home, it doesn't have to be this way. They could just provide the polyfill within the browser, negating any purported security issues with ancient XML libraries.

Post reply on HN