Re: [whatwg] Page refresh interface

Simon:
> I think extremely few actually care about XHTML, but the other issue is
probably more relevant.
I think that the spec takes care of XHTML and that there's a W3 candidate
recommendation spec about "polyglot markup". XHTML addresses some issues
and creates others, but actually I trust it for some reasons (it's too
offtopic to discuss it here).

> 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.
My issue was to read both, but as <meta> scenario is standard, you're
probably right. Still no way to stop it, though.
I like your proposal of modifying behavior by acting on <meta> tag very
much, it's what I tried to do initially, only to discover that things don't
change. Yes!

> You still haven't demonstrated that anyone but you want the ability to
stop a meta refresh, though.
I guess it's extremely difficult to demonstrate what people want to do when
a feature is not currently available. In order to do this I should analyse
all the scripts containing a window.setTimeout refresh and tell whether
there's an event stopping the timeout (currently the only option for
achieving a similar result). In addition to this, I hoped someone in the
mailing list could tell if it's useful or not.

To Niels:
> Meta refresh is an ancient quick hack from the Netscape/IE4 era to
declaratively specify a reload/redirect intent, *without programming*...
<meta> is not ancient stuff at all. It allows a refreshing where scripts
have been disabled. There's a lot of reasons for a user to disable
javascript and I don't think stopping refresh is the primary goal. Maybe
s/he wants to prevent popups or cookie interaction or anything similar. Or
yes, s/he wants to get rid of refreshing. But there's a separate
instruction for that.

> 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.
If by "not the browser" you mean that stopping refresh is not meant to be
automated, then I agree. Why stopping a feature that is instrumental to the
page (as the author has set it for a reason), UNLESS the user him/herself
has chosen that for UX it's better to stop reloading? If I said "the
browser" above, I meant that the browser should provide users a way (dialog
etc.) to achieve that. As you say, to achieve that where it's needed and on
a specific case-basis (I think IE is wrong when it prompts authors to
disable refreshing everywhere).

> <meta> is mainly still supported as a fallback mechanism for
non-JS-supporting UAs, but see more graceful degradation...
Not for non-JS-supporting, but for JS-disabled too. And, yes, the idea
behind my proposal was to rely on a nonscript native feature and to build
on it, so that when JS-enhanced solutions fail (for whatever reason), a
native fallback is provided. As the spec says (for the <noscript> case, but
I guess it's a good thumb rule):
"it's generally better to [...] instead design the script to change the
page from being a scriptless page to a scripted page on the fly"

> someone who actively elects to use a non-JS UA does so to prevent *any*
automatic behaviour
Does disabling JS stops CSS animations, form validation, <details>
expansion, <table@sortable> reordering (when it will be supported), video
elements, plugin instantiation via <object>, and label-control association
as well?
I think that in modern scenarios a lot of "automatic" behaviours can be
achieved in several ways. Stopping JS is stopping JS. What WCAG approved 14
years ago is reasonable, but it came before some of these features. Unless
each of them is disabled separately, or unless there won't be a command
prompting users to "disable all automation" and turn a page into a static
document, I don't think that disabling JS means anything more than that.
It's authors' responsibility to make refresh accessible (either with JS or
with native http(-equiv) refresh). And in addition to this, I have to point
out that native <meta refresh> can be stopped in some UAs without
preventing all nice things JS can do.

Received on Thursday, 26 March 2015 12:19:21 UTC