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

341–350 of 362 posts

Re: Google is killing the open web, part 2

#341

Post by wizzwizz4 »

rerdavies wrote: post #304
wizzwizz4 wrote: post #235

Earlier quoted context omitted.

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.

Is an XLST page a valid atom feed? Is it really so terrible to have to two different pages -- one for the human readable version, and one for the XML version?

Yes, an directive is valid in every XML document. You can use CSS to get many of the benefits of XSLT here, but it doesn't let you map RSS @link attributes to HTML a/@href attributes, and CSS isn't designed for interactivity. That's a rather significant gap in functionality.

It is rather terrible to have two different pages, because that requires either server or toolchain support, and complicates testing. The XSLT approach was tried, tested, and KISS – provided you didn't have any insecure/secure context mismatches, or CORS issues, which would stop the XSL stylesheet from loading. (But that's less likely to spontaneously go wrong than an update to a PHP extension breaking your script.)

Re: Google is killing the open web, part 2

#342

Post by microtherion »

jillesvangurp wrote: post #47
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.

> This is a lot more concerning. I'm not so sure that's problematic. Probably browser just aren't a great platform for doing a lot of XML processing at this point. Preserving the half implemented frozen state of the early 2000s really doesn't really serve anyone except those maintaining legacy applications from that era. I can see why they are pulling out complex C++ code related to all this. It's the natural conclus…

SVG is XML based.

Re: Google is killing the open web, part 2

#343

Post by basscomm »

ndriscoll wrote: post #332
basscomm wrote: post #325

Earlier quoted context omitted.

> but it would have been trivial to do with JS Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution? > the hundreds of lines of XSL you wrote. Those hundreds of lines are the same copy/pasted if statement with 5 different conditions. For each game, I create a table by: alphabetizing the XML > going through the list searching for figures that match the game > each time I fi…

Aside: you could factor that out by making an that does the choose on element, then your repeated code can just expand that template. The immense power in XSLT comes from xpath to make it easy to match on things like "all figures that contain a ": Skylanders figure Note If you further refactor the XML, you could do e.g. ... And then you can entirely eliminate the verbosity in your XSL. The templates become: Skylander…

> Using for-each or choose should be a sign you're doing it wrong.

I wouldn't say that I did it wrong, I just didn't do it efficiently. And I knew that at the time.

I appreciate the work, but I've said it elsewhere: I'm not a programmer. This was something I spent a couple of afternoons on five years ago and never looked at again after getting the results I wanted.

Re: Google is killing the open web, part 2

#344

Post by shadowgovt »

James_K wrote: post #340
shadowgovt wrote: post #277

Earlier quoted context omitted.

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.

So in other words, no more static sites?

A static site can inspect headers. Static sites still have a web server.

Re: Google is killing the open web, part 2

#345

Post by ndriscoll »

basscomm wrote: post #343
ndriscoll wrote: post #332

Earlier quoted context omitted.

Aside: you could factor that out by making an that does the choose on element, then your repeated code can just expand that template. The immense power in XSLT comes from xpath to make it easy to match on things like "all figures that contain a ": Skylanders figure Note If you further refactor the XML, you could do e.g. ... And then you can entirely eliminate the verbosity in your XSL. The templates become: Skylander…

> Using for-each or choose should be a sign you're doing it wrong. I wouldn't say that I did it wrong, I just didn't do it efficiently. And I knew that at the time. I appreciate the work, but I've said it elsewhere: I'm not a programmer. This was something I spent a couple of afternoons on five years ago and never looked at again after getting the results I wanted.

Sorry, I communicated poorly there, and was kind of replying more to the other commenter. I actually meant to reinforce your point that you didn't need some complex hundreds-of-lines-of-code template (and that what you had wasn't complex), and if you wanted to put in that effort, you could've condensed it here too to just 2 small templates.

The thing about doing it wrong was meant as a reply to the comment upthread about for-each etc. being necessary. For something like you have, they're absolutely not. It's fine if that was the easiest way for you to do it though. My whole point was that I've always seen XSLT as much more of an approachable, enabling technology than modern JS approaches.

Re: Google is killing the open web, part 2

#346

Post by James_K »

shadowgovt wrote: post #344
James_K wrote: post #340

Earlier quoted context omitted.

So in other words, no more static sites?

A static site can inspect headers. Static sites still have a web server.

A static site cannot inspect headers. There is no HTML, or even JavaScript function you can put in a file to inspect the headers before the file is sent to the client.

A static site is a collection of static files. It doesn't need a server, you could just open it locally (in browsers that don't block file:// URI schemes). If you need some special configuration of the server, it is no longer a static site. The server is dynamically selecting which content is served.

Re: Google is killing the open web, part 2

#348

Post by fithisux »

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.

Why keep XSLT if the huge majority of devs use the HTML5+CSS+Javascript combo? Why pump money on a standard which will not be used?

Are XML technologies better or safer? Probably. However practice sets the standards. Is it a good thing? It remains to be seen.

Personally I am not satisfied with the "Web" experience. I find it unsafe, privacy disrespecting, slow and non-standards compliant.

Re: Google is killing the open web, part 2

#349

Post by fithisux »

jillesvangurp wrote: post #47
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.

> This is a lot more concerning. I'm not so sure that's problematic. Probably browser just aren't a great platform for doing a lot of XML processing at this point. Preserving the half implemented frozen state of the early 2000s really doesn't really serve anyone except those maintaining legacy applications from that era. I can see why they are pulling out complex C++ code related to all this. It's the natural conclus…

They don't reduce complexity. They translate C++ (static complexity) to JS (dynamic complexity).

Also it is not complexity if XSLT lives in a third-party library with a well defined interface.

Thei problem is control. They gain control in 2 ways. They will get more involved in xml code base and the bad actors run in the JS sandbox.

That is why we have standards though. To relinquish control through interoperability.

Re: Google is killing the open web, part 2

#350

Post by shadowgovt »

James_K wrote: post #346
shadowgovt wrote: post #344

Earlier quoted context omitted.

A static site can inspect headers. Static sites still have a web server.

A static site cannot inspect headers. There is no HTML, or even JavaScript function you can put in a file to inspect the headers before the file is sent to the client. A static site is a collection of static files. It doesn't need a server, you could just open it locally (in browsers that don't block file:// URI schemes). If you need some special configuration of the server, it is no longer a static site. The server…

Oh, difference in definitions. You mean "non-configurable web server." Because you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted.

But agreed; if your web server is just reflecting the filesystem, add this to the pile of "things that are hard with that kind of web server." But perhaps worth noting: even Apache and Python's http.server can select the file to emit based on the Accept header.

Post reply on HN