I just learned about HTML redirects (2020)(apitman.com) |
I just learned about HTML redirects (2020)(apitman.com) |
It's kind of amazing how parts of the spec that seem dated or obsolete can still be useful today and are even widely used in corner cases.
I made a demo of this about 20 years ago but I think it just confused people. One of my early flops that I thought was cool. It was all in perl and I think there was some JS in there as well but I don't remember anymore. No idea where it is now.
Rewrite it and make a hyped up pitch page. People will call you a genius and I'll pretend not to care
<script>{setInterval(function(){document.location.reload();},5000)}</script>
now
for example, I tried out view-source:https://archive.fo/wip/RpDSg
does anyone else remember seeing meta refresh? if so, any idea why they switched to javascript reload
For the pioneers the most difficult part of learning CS was to get hardware needed. This mostly determined the technological stack they would then learn.
Nowadays hardware is commodity and the main problem is to determine what the hell you should start learning first because you can't learn everything it has now became humanely impossible.
I was born somewhen in the middle. Because of my first field I wish I could have mastered python. But at that time the python2/3 war was at the highest and you couldn't find reliable documentation. Hell even python3 tutorial kept on blabbering about how python2 concept translated. What was i supposed to do? learn both?
That is why I focused on SQL because at least documentation was quite stable (special thanks to PostgreSQL documentation teams).
I can only imaging the nightmare that must endure rookies frontend dev nowadays.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirectio...
So all these suggestions below to use server side generated HTTP headers and 302 (or 301) redirects are incorrect...because you won't know, on the first page hit, if the client has scripting enabled. At this point in time only the client knows if scripting is available. Also browser capability sniffing based on headers sent from the client in the first request is not reliable.
For more info see:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/no...
Also recently deployed it as a very simple server side denounce: when the client first accesses page X a long running operation is dispatched. Subsequent requests for the same resource before it's done processing return a plain HTML response that says "Still thinking about it" and meta refresh after 1 second.
<meta http-equiv="refresh" content="300"> to do speed test from fast.com
see:
view-source:https://angularten.github.io/
> You may sometimes hear about "new HTML5 elements", or find HTML5 described as a new version of HTML. HTML5 was the successor to previous HTML versions and introduced new elements and capabilities to the language on top of the previous version, HTML 4.01, as well as improving or removing some existing functionality. However, as a Living Standard HTML now has no version.
Even though it may cover a lot of basic and familiar topics, I think the following is the best (re)introduction to HTML:
HTML: HyperText Markup Language - https://developer.mozilla.org/en-US/docs/Web/HTML
HTML5 is just the common name of the living standard. It's clear, unambiguous, and what everybody uses. It is not a "buzzword".
It makes me look stupid in code interviews because I commit very little to memory but professionally it's helped me catch a lot of syntactical upgrades.
Perhaps I’m misunderstanding you, but do you think that the HTTP approach only works when JavaScript is enabled? That isn’t the case.
Go ahead and use HTTP 3xx responses; they work in all cases. Don’t use the <meta> element or the <noscript> element. Just redirect with HTTP. If you try to use HTML for this, you’ll be serving up 200 OK responses and things that understand HTTP but not HTML won’t understand there’s a redirect.
Serve a "shitty" page by default, redirect with JS to "enriched" page. Or tinker with server configuration to depend on 'Host: nojs.plz.fqdn'.
ChatGPT is a life saver for me though. I looked all over to try to find how to just see the history of a branch and got a million wrong results, but ChatGPT on GPT4 told me right away it was git log --first-parent <branch_name>.
https://github.com/mdn/content/pull/5116/files#diff-7cfca62e...
I agree that it's unnecessarily dismissive.
And document.location is pointless if the client has turned off scripting.
A) “how do people redirect”, to which the point about noscript sounds like irrelevant whining
B) “how do people redirect only visitors who don’t have scripting” to which most of the answers are trivially wrong
This is why the noscript tag exists and should be used.
Yes I'm aware there are various sniffing techniques you could use to work out if scripting is enabled but these are not always reliable. Only the browser knows authoritatively if scripting is available and hence you should use the noscript element to respond to clients that disabled scripting.
In that case I would completely reposition the argument: you shouldn’t do this at all, so it doesn’t matter how you redirect. It’s basically never the right move to try to sort your users into JavaScript and non-JavaScript and have two different pages for each.
<noscript> is an ancient design assuming that JavaScript is a binary enabled/disabled state, however this simply is not reflective of the real world. The vast majority of cases in which JavaScript does not execute will happen in the context of somebody using a browser with JavaScript enabled, so <noscript> can’t help you. You can use the latest version of the most popular browser, with all the settings enabled, no firewall or filtering, using a perfect Internet connect, no extensions getting in the way, with bug-free JavaScript delivered flawlessly, and still not have the JavaScript execute. And of course, if any of those factors vary, that can also lead to the JavaScript not executing.
If you want to handle this situation reliably, you need to build the page so that it works without JavaScript and then have the JavaScript that ends up executing progressively enhance the page.
the alternative was a whole computer plus modem per user.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
CGI:IRC used an early frame approach, no JS required.
At some point JSONP became popular, even for 3rd party APIs.
<script src="http://dont-xss-me/please?format=jsonp&callback=lol">
lol({ ... })
lol({ ... })I think the wiki page is wrong that it involved chunked encoding
Another term you don't see too often these days is the "holy grail" layout. I definitely remember the days of messing with negative margins and clearfix to get my page layouts to look nice while still working in IE 6 :)
I think you're right that Comet refers more to the JavaScript techniques that came from those "forever frames".. but to me it was all about the streaming HTTP hack at the heart of it.
I guess it's academic now :-)
Regarding holy grail layout and IE6.. so you're telling me you're a masochist!