←back to thread

Google is killing the open web, part 2

(wok.oblomov.eu)
418 points akagusu | 3 comments | 17 Nov 25 15:41 UTC | HN request time: 0s | source
Show context
Aurornis ◴[17 Nov 25 16:31 UTC] No.45955140[source]▶
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.

replies(10): >>45955238 #>>45955283 #>>45955351 #>>45955795 #>>45955805 #>>45955821 #>>45956141 #>>45956722 #>>45956976 #>>45958239 #
James_K ◴[17 Nov 25 17:31 UTC] No.45955821[source]▶
I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.
replies(2): >>45955882 #>>45958444 #
matthews3 ◴[17 Nov 25 17:36 UTC] No.45955882[source]▶
Could you run XSLT as part of your build process, and serve the generated HTML?
replies(4): >>45955943 #>>45955956 #>>45956760 #>>45959294 #
James_K ◴[17 Nov 25 17:43 UTC] No.45955943{3}[source]▶
No because then it would not be an Atom feed. Atom is a syndication format, the successor to RSS. I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked.

This is why so many people find this objectionable. If you want to have a basic blog, you need some HTML docments and and RSS/Atom feed. The technologies required to do this are HTML for the documents and XSLT to format the feed. Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website.

replies(2): >>45955974 #>>45956484 #
ErroneousBosh ◴[17 Nov 25 17:46 UTC] No.45955974{4}[source]▶
> Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website.

How so? You're just generating static pages. Generate ones that work.

replies(1): >>45956162 #
James_K ◴[17 Nov 25 18:06 UTC] No.45956162{5}[source]▶
You cannot generate a valid RRS/Atom document which also renders as HTML.
replies(1): >>45956531 #
shadowgovt ◴[17 Nov 25 18:40 UTC] No.45956531{6}[source]▶
So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader.

It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.

replies(1): >>45956725 #
kuschku ◴[17 Nov 25 18:57 UTC] No.45956725{7}[source]▶
> 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.

replies(3): >>45956969 #>>45958694 #>>45959471 #
ErroneousBosh ◴[17 Nov 25 21:43 UTC] No.45958694{8}[source]▶
> Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response?

The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.

> It's the same content, just supplied in a different format. It should be the same URL.

So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format.

replies(1): >>45958861 #
1. kuschku ◴[17 Nov 25 22:01 UTC] No.45958861{9}[source]▶
> The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.

Just like protocol negotiation, HTTP has format negotiation and XML postprocessing for exactly the same reason.

> So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format

Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.

Similarly, it makes sense to return an XML with XSLT for most browsers and a degraded experience with just a simple text file for legacy browsers such as NCSA Mosaic or 2027's Google Chrome.

replies(1): >>45962941 #
2. ErroneousBosh ◴[18 Nov 25 09:03 UTC] No.45962941[source]▶
> Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.

So, you need a lot of cleverness on the browser to detect which format the client needs, and return the correct thing?

Kind of not the same situation as emitting an XML file and a chunk of XSLT with it, really.

If you're going to make the server clever, why not just make the server clever enough to return either an RSS feed or an HTML page depending on what it guesses the client wants?

replies(1): >>45963478 #
3. kuschku ◴[18 Nov 25 10:42 UTC] No.45963478[source]▶
> If you're going to make the server clever, why not just make the server clever enough to return either an RSS feed or an HTML page depending on what it guesses the client wants?

There's no cleverness involved, this is an inherent part of the HTTP protocol. But Chrome still advertises full support for XHTML and XML:

    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
But importantly, for audio/video files, that's still just serving static files, which is very different from having to dynamically generate different files.