Re: meta refresh (3.7.5.3. Pragma directives)

At 17:13 +0200 UTC, on 2007-08-07, Anne van Kesteren wrote:

[...]

> It seems better to focus on improving user agents
> by adding features that allow the user to block redirects or refreshes
>  from happening.

Unless I'm overlooking something, the current META Refrsh spec, it says "UAs
must [...]". I understand that that applies to the steps considering how to
support it. But it would be good to precede that with "If a UA supports META
Refresh, it must [...]". In other words, allow UAs to dicard Refresh, and say
so explicitly in the spec so authors can be aware that they cannot rely on it.

Use-case: many sites use this not as a poor man's http 30x, but to reload the
same page every n seconds. "Latest news" sites for example. But it sucks when
you're still reading halfway through it. Especially so with for instance a
speech browser, I would think. So there's a need to allow UAs to not support
refresh,or to allow the user to disable it (ideally on a per site/domain/page
basis, but I see no need to spec that).

Note that as much as I personally detest almost every Refresh I encounter, I
actually *do* use it on a (non-public, sorry) site myself, where a Refresh
does make good sense. Problem is: because (AFAIK) most UAs do not allow
people to switch it off, I resorted to a javascript-dependant approach, just
to offer people at least the option to switch off javascript and thus the
Refresh. (Thus the lack of UA configurability turns into an argument for
javascript-dependancy... {sigh})

> Maybe we should discourage redirects or refreshes with a
> really low value though (such as zero or one), but I'm not sure how to do
> that nicely.

[I'm guessing you mean "suppress those cases where a really low value is
authored", and not "suppress Refreshes by overriding their value with a
reallly low one".]

Yes, zero or one might make sense, but where to set the boundary...? If you
set the thresholf to 1, authors will use 2. By a threshold of 10, you'd be
getting into the domain of potentially sensible use.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Tuesday, 7 August 2007 22:19:06 UTC