Re: [whatwg] Page refresh interface

>> why doesn't the document interface expose the refresh timeout?
> Because nobody implemented it and nobody asked for it (until now).
I don't know whether to feel proud or guilty about that.

>> http://www.phpied.com/files/location-location/location-location.html .
> This list does not show that anyone wants to read or write to meta
refresh.
Overwriting meta refresh is pointless, as the "Refresh" timeout doesn't
change.
Writing it would perhaps be impractical as it cannot be changesd once set.
This list only shows a bunch of ways to achieve the same behavior.

>> Having a writable property would allow e.g. to delay the refresh
> Why is that useful?
Let's say, for example, that Refresh could be delayed if another timed
event is happening on the page (say, for example, the page has a video
which is paused or has a buffer delay)

>> or even to stop the pragma "refresh" instruction and replace it with a
timed AJAX recall of specifi contents, maintaining a nonscript whole page
refresh for cases where scripts are disabled/unavailable.
> You can use <noscript><meta ...></noscript>. Is that sufficient? (It
fails when scripting is enabled but the script fails to run for other
reasons.)
No, it isn't at all e.g. in XHTML syntax where <noscript> cannot be used.
And in general <noscript> has the issue you underlined: if script is
enabled but it fails, then <noscript> is not considered.

> How about providing a link that the user can follow?
This is indeed my solution. The classic "See if there's something new.
Click here!" link. But users are also getting used to auto-refreshing
content and I think that for this specific case it could be more useful to
have a stoppable timeout, rather than a link to be specifically navigated.

> Why is it useful to read the timeout and url?
This is a little bit of a personal choice. Let's say I have a page with a
specific content which is updated at specific intervals of 80 seconds (or
at least it is useless to check for updates in shorter periods). This
interval is set with a Refresh "header" (http or meta). In js-capable UAs I
can specify a timed AJAX to update the specific content. The time for that,
of course, is the same: 80*1000 milliseconds. Now, of cours I can specify
both things. But I usually hate writing properties twice, and I also hate
hardcoding properties in scripts: if next month timed updates start being
served every 40 seconds I have to change the timeout in 2 different places.
On the other hand, if a document.refreshTimeout existed, I could use it
directly inside the AJAX call (timeout = 1000 * document.refreshTimeout).

> I think Refresh as an HTTP header is not specified anywhere, so per spec
it shouldn't work. However I think browsers all support it, so it would be
good to specify it.
Indeed. It was Netscape-specific but it's widespread now (that's why we
have a <meta http-equiv="refresh"> "surrogate").

Received on Wednesday, 25 March 2015 14:09:06 UTC