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

231–240 of 362 posts

Re: Google is killing the open web, part 2

#231

Post by basscomm »

shadowgovt wrote: post #163
Fileformat wrote: post #131

Earlier quoted context omitted.

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that. I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user? https://www.rss.style/

RSS and Atom feeds are at this point a solution looking for a problem. I use RSS all the time... To keep up-to-date on podcasts. 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.

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

Re: Google is killing the open web, part 2

#232

Post by themafia »

dewey wrote: post #119
echelon wrote: post #100

Earlier quoted context omitted.

Then standards body is Google and a bunch of companies consuming Google engine code.

I guess you mean except Mozilla and Safari...which are the two other competing browser engines? It's not like a it's a room full of Chromium based browsers.

Do Mozilla and Safari _not_ take money from Google?

Re: Google is killing the open web, part 2

#233

Post by ndriscoll »

basscomm wrote: post #224
munificent wrote: post #86

Earlier quoted context omitted.

> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortabl…

> Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? Hi! I'm a non-programmer who picked up XSLT of my own volition and spent the last five-ish years using it to write a website. I even put up all the code on github: https://github.com/zmodemorg/wyrm.org I spent a few weeks converting the site to use a static site generator, and there were a lot o…

For what it's worth, you can still run an XSL processor as a static generator. You of course lose some power like using document() to include information for a logged in user, but if it's a static site then that's fine.

Re: Google is killing the open web, part 2

#234

Post by basscomm »

coldpie wrote: post #7
andsoitis wrote: post #2

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.

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Y…

I've been running a small hobby site using XML and XSLT for the last five or so years, but Google refused to index it because Googlebot doesn't execute XSLT. I can't be the only one, but good luck Googling it

Re: Google is killing the open web, part 2

#235

Post by wizzwizz4 »

rwmj wrote: post #147
zekica wrote: post #35

Earlier quoted context omitted.

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable. It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

I would just do this on the server side. You can even do it statically when generating the XML. In fact until all the stuff about XSLT in browsers appeared recently, I didn't even know that browsers could do it.

Converting the contents of an Atom feed into (X)HTML means it's no longer a valid Atom feed. The same is true for many other document formats, such as flattened ODF.

Re: Google is killing the open web, part 2

#236

Post by shadowgovt »

zzo38computer wrote: post #228
shadowgovt wrote: post #143

Okay, I was entertaining the author's position to a point, but I have to get off the train where they sing the praises of NPAPI. Hey fam. I remember NPAPI. I wrote a very large NPAPI plugin. The problem with NPAPI is that it lets people run arbitrary code as your browser. it was barely sandboxed. At best , it let any plugin do its level best to crash your browser session. At worst, it's a third-party binary blob you…

> put binary blobs in your browser outside the security sandbox There are reasons to do this sometimes, but usually it would be better to put them inside of the security sandbox (if the security sandbox can be designed in a good way). The user (or system administrator) could manually install and configure any native code extensions (without needing to recompile the entire browser), but sandboxed VM codes would also b…

We already have two infrastructures to do that: the JavaScript engine and wasm.

And, indeed, part of the deprecation of XSLT proposal involves, in essence, moving XSLT processing from the browser-native layer to wasm as a polyfill that a site author can opt into.

Re: Google is killing the open web, part 2

#237

Post by glenstein »

akerl_ wrote: post #209
glenstein wrote: post #197

Earlier quoted context omitted.

I would disagree, corporate open source involves corporate dominance over governance that fits internal priorities. It meets the legal definition rather than the cultural model which is community driven and often multi-stakeholder. I would put Debian, VLC, LibreOffice in the latter camp.

Is it often multi-stakeholder? Debian has bureaucracy and a set group of people with commit permissions. VLC likewise has the VideoLAN organization. LibreOffice has The Document Foundation. It seems like most open source projects either have: 1. A singular developer, who controls what contributions are accepted and sets the direction of the project 2. An in-group / foundation / organization / etc that does the same.…

A lot of the governance structures with "foundation" in their name, e.g. Apache Foundation, Linux Foundation, Rust Foundation, involve some combination of corporate parties, maintainers, independent contributors without any singularly corporate heavy hand responsible for their momentum.

I don't know that road maps are any more or less "community driven" than anything else given the nature of their structures, but one can draw a distinction between them and the degree of corporate alignment like React (Facebook), Swift (Apple).

I'm agreeable enough to your characterization of open source projects. It's broad but, I think, charitably interpreted, true enough. But I think you can look at the range of projects and see ones that are multi stakeholder vs those with consolidated control and their degree of alignment with specific corporate missions.

When Google tries to, or is able to, muscle through Manifest v3, or FLoC or AMP, it's not trying to model benevolent actor standing on open source principles.

Re: Google is killing the open web, part 2

#238

Post by basscomm »

Analemma_ wrote: post #14
coldpie wrote: post #7

Earlier quoted context omitted.

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Y…

Another bit of ridiculousness is pinning the removal on Google. Removing XSLT was proposed by Mozilla and unanimously supported with no objections by the rest of the WHATWG. Go blame Mozilla if you want somebody to get mad at, or least blame all the browser vendors equally. This has nothing to do with Chrome’s market share.

Shouldn't the users of the Web also get a say? There's been a lot of blowback on this decision, so this isn't as cut and dried as it's being made out to be

Re: Google is killing the open web, part 2

#239

Post by zzo38computer »

spankalee wrote: post #45

This page makes some wild claims, like Google wants to deprecate MathML, even though it basically just landed. Yeah, the Chrome team wasn't prioritizing the work and it came through Igalia, but the best time for Chrome to kill MathML would have been before it was actually usable on the web. The post also fails to mention that all browsers want to remove XSLT. The topic was brought up in several meetings by Firefox re…

XHTML does have some advantages compared with ordinary HTML, such as the parsing being more consistent, since the file will specify where literal text is used and which commands are or are not a block that is expected to contain other things.

(It could still try to render in case of an error, but display the error message as well, perhaps.)

Re: Google is killing the open web, part 2

#240

Post by basscomm »

Evidlo wrote: post #229

Why can't the polyfill be enabled by default? It would fix the security issues and we wouldn't have to worry about breaking websites. The JS polyfill also makes supporting modern XSLT feasible.

I tried the JS polyfill on some of the basic XSLT that I wrote, and it only kinda worked. I can't imagine how it would fail on anything with any complexity.
Post reply on HN