When it comes to the <meta> element acting as a pragma directive for page refresh, HTML spec says that
user agent may … inform the user of any and all aspects of its operation, including the state of any timers, the destinations of any timed redirects, and so forth.
It also says that users may be allowed to cancel timed redirect. I suppose the two things are related, as the user should be notified of the imminent refresh, in order for him to decide if it must be stopped.
For what I know, at present no UAs allow users to stop meta refresh, even though for some of them there are “extensions” which state they can (and it’s not true).
In addition to this, authors wishing to use other ways to refresh a web page (e.g. location.replace or AJAX) cannot use meta refresh as a fallback solution without recurring to <noscript>, which is an obsolete way of doing things (and not always possible).
I’d rather suggest a little change in the spec. There should be an interface control for pragma “refresh” directive, so that the refresh time can be retrieved and the action itself can be stopped. Or at the very least, the possibility to stop meta refresh by simply removing the <meta refresh> node (as a lot of authors used to ask whether it is possible or not). This would allow extensions to actually stop it (in addition to retrieving time and destination directly from the element itself). It would also allow authors to program a fallback refresh, working together with JS advanced solutions (a script could allow the user to choose a different time, or provide an update for specific parts of page content, while meta refresh could allow a basic non-scripted solution).
EDIT: in the hope that anyone answers this topic (either positively or negatively), it should be noted that:
several “extensions” for various UAs promise to cancel <meta http-equiv="refresh" />, which is obviously impossible
every now and then, some newbie author pops out of nowhere asking in forums how meta refresh can be stopped. I think it’s high time UAs allowed for this.
Also consider this: meta refresh has historically been considered such a poor solution, that search engines were said to assign a “bad score” to meta-auto-refreshed pages. Which is a non-solution, of course, as the same result can be achieved with either a timed-out location.href (or location.replace if available), or with a timed-out integration of contents through an AJAX call. The former poses the same threat to usability than a meta refresh, the latter is currently used by fa… er… famous websites, let’s say. With a big difference, however. Scripted solutions can be modified, if necessary, even without recurring to a dialog prompting user to “stay on the page” on unload event; meta refresh cannot. But while finding the precise part of the script calling for refresh can be tricky, a meta element is part of the DOM itself and as such it is trivial to find it.
<meta http-equiv="refresh"> is another example of useful feature inefficiently exploited, and I think there should be a change, in order to allow it to live together with other solutions (also, but not only, as a fallback).
It probably makes sense to clearly separate the subject from user perspective and from web-developer perspective.
It may be questionable whether many users could really benefit from having a GUI option to cancel meta refresh (probably not many of them know what is the meta refresh itself).
But it would certainly be useful for web developer to be able to cancel refresh by simple removal of the meta element. Currently, this does not work — even if the meta element has a nonzero delay, redirection happens anyway even if the element is removed from DOM before the delay time is reached.
You’re right, most users do not know what a <meta http-equiv="refresh"> is. What they do know is what a reload means; at least they learn it when the page is reloaded under their own eyes without them being allowed to do anything. And of course no authors would waste time making an extension which says “dear user, the page is going to reload in X seconds, you will see page www.yyy.zz and you cannot do anything with that!” (I’d consider it a bad joke).
I mentioned users because nowadays extensions allow page interface to be improved not only by website author, but also by external authors (through extensions). This means that it’s the users, with their own preferences, who influence their own experience adding anything they consider useful from extension store. For example they can look for something that stops their favourite pages to reload inadvertently. Except for the fact that, if such reload is obtained through “refresh” HTTP header or meta refresh pragma directive, this is impossible (and users cannot even understand why “the extension does not work”, as you can see in said extensions reviews).
UI stuff, like browsers offering users control over a refresh, are the domain of the browsers themselves, not specs - any browser can do this on their own, and it doesn’t affect the webpage itself. I recommend filing bugs on browsers arguing for this.
I perfectly agree on that. But UAs don’t consistently do it (only Firefox does), and it isn’t even a bug, as the spec says user agents may expose such an interface.
Now, authors would appreciate it (see the extensions I wrote about), so I thought that there should be another way to achieve the same result, acting directly on the element or, even better, on an interface attribute represented by the element itself.
It doesn’t need to be a spec bug to be a reasonable browser bug - you’re asking for the browser to change behavior. It’s reasonable to ask for things that arent’ required!
I’m not asking browsers to change any behavior, indeed, or at least this is just a small part of my purpose. I’ve just acknowledged that browsers have never supported refresh interface (with the possible, buggy exception of FF), as part of my reasoning.
I’m not going to discuss it any further, as I would only repeat what I said. There’s just a last thing I’d like to point out: <meta http-equiv="refresh" /> substitutes a “refresh” header, but with a large and obvious difference: it doesn’t need being present when document is loaded. It can be inserted into the document, and as such its insertion starts the refresh timeout. It seems just reasonable that it is removed as well, thus interrupting said timeout. This would allow scripts to interact with it, independently from active or passive interface exposed by browsers.
https://github.com/whatwg/html/issues/459 seems like a decent place, but you might need to @mention the relevant implementors directly (e.g. look in bug database for related fixed bugs, or find the relevant code in the browser and use git blame).
