Re: [whatwg] Page refresh interface

> You still haven't demonstrated that anyone but you want the ability to  
> stop a meta refresh, though.

I think it's a matter of proper design philosophy to say no to this. Meta refresh is an ancient quick hack from the Netscape/IE4 era to declaratively specify a reload/redirect intent, *without programming*. Interfering with it at runtime, after page load, implies you'll be writing Javascript to do so. If you're writing Javascript anyway, why not use window.setTimeout with window.location.reload() in the first place. Which returns a perfectly fine numerical ID to be used in window.clearTimeout subsequently.

Meta refresh is perfectly well defined in standards though: http://www.w3.org/TR/html5/document-metadata.html#attr-meta-http-equiv-refresh. In step 24 we read:

 After the refresh has come due (as defined below), if the user has not canceled the redirect [...]

It is explicitly defined that only the user can cancel the redirect, not the browser. This conforms to the fact that only user configuration options and dialogs exist (in some browsers) to influence this behaviour.

I understand the argument that <meta> is mainly still supported as a fallback mechanism for non-JS-supporting UAs, but see more graceful degradation issues and unexpected behaviours if you're going to invite developers to count on a JS mechanism to tinker with a non-JS mechanism. Even if that means implementing the same behaviour twice, or requiring <noscript> for it.

From an audience standpoint I'm tempted to say that someone who actively elects to use a non-JS UA does so to prevent *any* automatic behaviour, including refreshes and redirects, and thus UX benefits from doing JS only instead of both, but that's speculation on my end. The W3C Accessibility group apparently agreed with that view over 14 years ago already as per http://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh:

 "Content developers sometimes create pages that refresh or change without the user requesting the refresh. This automatic refresh can be very disorienting to some users."


Niels

-----Original Message-----
From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Simon Pieters
Sent: donderdag 26 maart 2015 10:43
To: WHATWG List; Andrea Rendine
Subject: Re: [whatwg] Page refresh interface

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)

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

Received on Thursday, 26 March 2015 10:17:08 UTC