On Wed, 25 Mar 2015 15:08:41 +0100, Andrea Rendine
<master.skywalker...@gmail.com> wrote:
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)
OK.
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.
I think extremely few actually care about XHTML, but the other issue is
probably more relevant.
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.
OK.
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).
OK. I don't think it is worth the cost of adding an API for this. You can
access the information by reading the attribute on the <meta>. You can't
read the Refresh header, but then just use <meta> instead.
I think it would be reasonable to make changes to the http-equiv or
content attributes stop the timeout and re-process the <meta>. Also,
removing the <meta> from the document could stop the timeout. This would
address the use cases and avoids the problems with <noscript>.
You still haven't demonstrated that anyone but you want the ability to
stop a meta refresh, though.
--
Simon Pieters
Opera Software
