Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

281–290 of 362 posts

Re: Google is killing the open web, part 2

#281

I don’t know. The author makes some arguments I could get entertain and get behind, but they also enumerate the immense complexity that they want web browsers to support (incl. Gopher). Whether or not Google deprecating XSLT is a “political” decision (in authors words), I don’t know that I know for sure, but I can imagine running the Chrome project and steering for more simplicity.

If you really want to improve the simplicity, there are better ways to do so rather than excluding Gopher. (Also, they could make XSLT (and many other things that are built-in) into an extension instead, therefore making the core system more simpler.)

> (Also, they could make XSLT (and many other things that are built-in) into an extension instead, therefore making the core system more simpler.)

This appears to be what they are doing, in fact!

Re: Google is killing the open web, part 2

#282
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.

You’re doing a lot of sideways handwaving to say killing off this specific technology is not killing the open web, but others are.

XSLT is not a source of security errors and this is your disingenuous argument from last time, (please state if you work for any of these companies). Libxslt has security vulnerabilities not XSLT itself. Futhermore there are replacement processors they could contribute and implement to and a myriad of other solutions, but they have chosen to kill instead.

That is killing the Open web.

Re: Google is killing the open web, part 2

#283

Earlier quoted context omitted.

> But for keeping up to date on news, people use social media. 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 Facebook. I guess if you don't use social media or facebook you're out of luck?

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?

Re: Google is killing the open web, part 2

#284
post #257

Earlier quoted context omitted.

Furthermore, you can’t polyfill USB support. It’s something that the browser itself must support if it’s going to be used at all, as by definition it can’t run entirely inside the browser. That’s not true for XSLT, except in the super-niche case of formatting RSS prettily via linking to XSLT like a stylesheet, and the intersection of “people who consume RSS” and “people who regularly consume it directly through the b…

> Furthermore, you can’t polyfill USB support. You can't polyfill many things. Should we just dump everything into the browser? Well, Google certainly thinks so. But that makes the question about "but this feature is unused, why support it" moot. And Google has no intention to support a polyfill, or ship it with the browser. The same person who didn't even know that XSLT is used on podcast sites scribbled together so…

The distinction in my mind is that if a browser doesn’t ship with XSLT, then devs have to go through the hassle of adding support for it themselves, but if a browser doesn’t support a device driver, it’s completely impossible for devs to do that themselves.

Without built-in support, XSLT is inconvenient. Without built-in support, things like WebUSB cannot possibly exist.

That’s why I think they can’t be compared directly.

Re: Google is killing the open web, part 2

#285

Earlier quoted context omitted.

> The relevant use case is you come here to see links people share and comment on them. That's sufficiently "social" in this context. Just having users submit links that other users can comment on doesn't make it social media. I can't follow particular users or topics, I can't leave myself a note about some user that I've had a positive or negative experience with, I can't ignore someone who I don't want to read, etc…

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?

Re: Google is killing the open web, part 2

#286

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived…

> Actually, you can make an RSS feed user-browsable by using JavaScript instead Say I have an XML document that uses XSLT, how do I modify it to apply your suggestion? 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. But with the implementation available today, I see no way to provide a first-class XS…

For RSS/Atom, you put this in the XML, right inside the document element (the element or the element):

    
You can also put CSS in there, like this:

    
      * { color: red; }
    
Or like this:

    

Re: Google is killing the open web, part 2

#287

Earlier quoted context omitted.

Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.

The problem wasn't that FTP got deprecated, but that we never got a proper successor. With FTP you could browse a directory tree like it was a real file system. With HTTP you can't, it has no concept of a directory. rsync is the closest thing to a real successor, but no Web browser support that either.

There would be WebDAV which adds such features to HTTP but that's also not supported by web browsers.

Re: Google is killing the open web, part 2

#288
post #19
post #9

Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.

Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH. Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.

By many scientific and educational organizations for distribution of data. Places where the outcome matters and the way to achieve it doesn't. An FTP client in a browser is incomparibly smaller attack surface than, say, executing every random program sent to you by arbitrary third parties (javascript).

Re: Google is killing the open web, part 2

#289
post #262
post #54

Earlier quoted context omitted.

Can you cite where this "servant-oriented" mentality is from? I don't recall a part of the web where browser developers were viewed as not having agency about what code they ship in their software.

It's literal W3C policy: https://www.w3.org/TR/html-design-principles/#priority-of-co... --- start quote --- In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight…

I could argue that W3C didn’t follow that policy when they attempted to push xhtml, which completely inverts that priority order, as xhtml is bad for users and great for purity.

But instead I’ll point out that W3C no longer maintains the html spec. They ceded that to the WHATWG which was spun by the major browser developers in response to the stagnation and what amounted to abandonment of html by the W3C.

Re: Google is killing the open web, part 2

#290

Earlier quoted context omitted.

> Actually, you can make an RSS feed user-browsable by using JavaScript instead Say I have an XML document that uses XSLT, how do I modify it to apply your suggestion? 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. But with the implementation available today, I see no way to provide a first-class XS…

For RSS/Atom, you put this in the XML, right inside the document element (the element or the element): You can also put CSS in there, like this: * { color: red; } Or like this:

How's the support for the first option? If that reliably works, I'm gonna stop being angry, as it solved all my needs (and would allow polyfilling xslt anyway)

On second thought, that wouldn't allow me to modify the DOM before it's being parsed, I'd have to wipe the DOM and polyfill the entire page load, right?

Post reply on HN