W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] Page refresh interface

From: Simon Pieters <simonp@opera.com>
Date: Thu, 26 Mar 2015 10:43:07 +0100
To: "WHATWG List" <whatwg@whatwg.org>, "Andrea Rendine" <master.skywalker.88@gmail.com>
Message-ID: <op.xv3ml5puidj3kv@simons-mbp>
On Wed, 25 Mar 2015 15:08:41 +0100, Andrea Rendine  
<master.skywalker.88@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)


>>> 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.


>> 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
Received on Thursday, 26 March 2015 09:43:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:29 UTC