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

Re: [whatwg] Page refresh interface

From: Niels Keurentjes <niels.keurentjes@omines.com>
Date: Thu, 26 Mar 2015 15:38:02 +0000
To: Andrea Rendine <master.skywalker.88@gmail.com>, WHATWG List <whatwg@whatwg.org>
Message-ID: <ee5dca337a1d47218bac29c0e3e977d7@omines-srv-002.omines.corp>
> The point is, what happens to the JS-only solution in cases where JS is not
> usable for any reason?

It will not run. The user has chosen to either disable JS or use a non-supporting UA. Therefore he gets a site without non-declarative interactivity, from complex form validations and animations to complex page refresh logic.

> Does this mean that meta refresh should be avoided altogether and replaced by JS?

I would argue yes, but that's a different discussion. Much like browsers still probing for /favicon.ico on every site, it's a legacy mechanism that survives because it's being used. Having said that meta refresh is an ugly solution that has far better solutions, but as it's well-documented and well-supported it's fine to use for the simple use cases it was designed for.

If there's a more complex use case, such as pausing/postponing/cancelling/prolonging the delay before the refresh, it makes no sense in my opinion not to use setTimeout in the first place. I just don't see why you would want 2 rich mechanisms to solve the same problem, one of which is inherently unwieldy because it requires extra properties/APIs to be exposed.

As said: if you want to modify the refresh, you're using JS. If you can use JS, you can use setTimeout. If you want to use `meta` as a fallback, it's only a worthy fallback if it exposes the exact same behaviour. It only does so if you're not modifying the timeout after load, which makes the whole discussion moot about being able to modify it.


Niels

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

..Simon, there's no use case where <meta> cannot be substituted by a
JS-only solution. The point is, what happens to the JS-only solution in
cases where JS is not usable for any reason? Usually fallback content can
be hidden or removed somehow, but <meta> makes it impossible. Does this
mean that meta refresh should be avoided altogether and replaced by JS?

2015-03-26 14:48 GMT+01:00 Simon Pieters <simonp@opera.com>:

> On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine <
> master.skywalker.88@gmail.com> wrote:
>
>  Some fellow people who want to stop the power of <meta>, then. (the first
>> 2
>> questions for sure, and even more below)
>>
>
> http://stackoverflow.com/questions/28435865/can-i-stop-

> a-meta-refresh-using-javascript
> http://stackoverflow.com/questions/16289798/button-to-

> temporarily-disable-stop-meta-tag-refresh
>
> These can be solved with JS-only refresh, as far as I can tell.
>
> Any others?
>
>
> --
> Simon Pieters
> Opera Software
>
Received on Thursday, 26 March 2015 15:39:06 UTC

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