> 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.
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.
How so? You're just generating static pages. Generate ones that work.
It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.
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.
I had also defined a "hashed:" scheme for specifying the hash of the file that is referenced by the URL, and this is a scheme that includes another URL. (The "jar:" scheme is another one that also includes other URL, and is used for referencing files within a ZIP archive.)
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.
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.
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, 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?
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
Nonetheless, by that same argument you could just kill HN off. A lot of projects have a benefit that far outweighs their raw usage numbers.
Come up with the worst possible way to present information over a web page.
What device with 2kB of RAM is going to generate any kind of useful RSS feed? Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?
Such devices usually don't generate RSS feeds, but e.g. sensor measurements as XML (which can be processed directly, or opened in a browser with XSLT to generate a website and an SVG chart from it)
> Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?
Because anything else will have >100× more power consumption?
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.
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.
>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
And this web-server configuration would not exist within the static site. The static site generator could not output it, therefore it is not a part of the static site. It is not contained within the files output by the static site generator. It is additional dynamic content added by the web server.
It breaks the fundamental aspect of a static site, that it can be deployed simply to any service without change to the content. Just upload a zip file, and you are done.
I get your meaning; I've just heard "static site" used to refer to a site where the content isn't dynamically computed at runtime, not a site where the server is doing a near-direct-mapping from the filesystem to the HTTP output.
> Just upload a zip file, and you are done.
This is actually how I serve my static sites via Dreamhost. The zipfile includes the content negotiation rules in the `.htaccess` file.
(Perhaps worth remembering: even the rule "the HTTP responses are generated by looking up a file matching the path in the URL and echoing that file as the body of the GET response" is still a per-server rule; there's no aspect of the HTTP spec that declares "The filesystem is directly mirrored to web access" is a thing. It's rather a protocol used by many simple web servers, and most of them allow overrides to do something slightly more complicated while being one step away from "this is just the identity function on whatever is in your filesystem, well, not technically the identity function because unless someone did something very naughty, I don't serve anything for http://example.com/../uhoh-now-i-am-in-your-user-directory").