The classical answer is that the S stands for Server-Side-Incude (SSI). SSI source typically uses the extension .shtml. More info:
HN user
chuckhoupt
A small coöperatively multi-threaded program running on a micro-computer in Ulysses, New York.
Ah, but it's (roughly) 88x31 CSS Pixels!
Just last week I updated one of those for Retina/HDPI:
Thanks [I'm the author]. I tested with Chrome 105 on macOS and it succeeded. Possibly there are OS/plugin/etc issues?
Of course, I know there is no guarantee that every browsers innerHTML implementation will produce exactly the same result, but so far I haven't found any variation (Chrome, FF, Safari, Edge).
I think this was a bug in the site, which appears to now been fixed.
Note that HTTP is also upgraded if the UA requests it with the Upgrade-Insecure-Requests header:
$ curl -I -H 'Upgrade-Insecure-Requests: 1' 'http://www.w3.org/Provider/Style/URI.html'
HTTP/1.1 307 Temporary Redirect
location: https://www.w3.org/Provider/Style/URI.html
vary: Upgrade-Insecure-RequestsOpps! You're right, the W3C only helped author it.
I was also wrong to say that w3.org never redirects to HTTPS. If the browsers sends a Upgrade-Insecure-Requests HTTP-header, then it redirects. That allows it to support all browsers as securely as possible.
Sites like whynohttps.com and observatory.mozilla.org should really test for this pattern.
w3.org redirect to www.w3.org, but not HTTPS. This makes sense for the standards org that defines HTTP, and needs to maintain backwards compatibility.
Have you looked at Xcode Server: https://developer.apple.com/library/content/documentation/ID... ?
MacPaw is one tech company that has cats and a special cat room:
http://blog.macpaw.com/post/109471340953/welcome-to-the-drea...