Re: [whatwg] Page refresh interface

On Tue, 24 Mar 2015 02:41:30 +0100, Andrea Rendine  
<master.skywalker.88@gmail.com> wrote:

> Hi everybody!
> A request starting from <meta> element and its refresh state: why doesn't
> the document interface expose the refresh timeout?

Because nobody implemented it and nobody asked for it (until now).

> The ideal would be to
> expose it in read/write mode, as authors have evolved several variants of
> location.href/replace/refresh/reload. And for "several" I mean 534:
> 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.

> Having a writable property would allow e.g. to delay the refresh

Why is that useful?

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

How about providing a link that the user can follow?

> But even without a writable property, it would be useful to just have
> "read"-level properties such as document.refreshTime and
> document.refreshUrl . Consider that refresh time (along with a refresh  
> URI)
> can be set by (non-standard (why non-standard?)) header response, a  
> <meta>
> element already present (and there can be more than one, as UAs know how  
> to
> handle this error) or even being inserted at runtime. So it is difficult  
> to
> access this information without a proper interface.

Why is it useful to read the timeout and url?

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.

> Besides that, the spec says that UAs may expose the time (and other
> aspects) for a refresh event of the document and it also refers to the
> possibility for a user to "cancel the redirect", while as of now users
> aren't even informed, let alone allowed to interact with this event.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 25 March 2015 13:28:10 UTC