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-boun...@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...@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 noscriptmeta .../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
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 08:28:37 +0100, Karl Dubost k...@la-grange.net wrote: Andrea, Simon, Le 25 mars 2015 à 23:08, Andrea Rendine master.skywalker...@gmail.com a écrit : 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. Indeed. It was Netscape-specific but it's widespread now (that's why we have a meta http-equiv=refresh surrogate). I was not so sure about the interest of documenting it, but after [digging into it][1]. There seems to be many Web Compatibility hacks around it. [1]: http://www.otsukare.info/2015/03/26/refresh-http-header Most of what you bring up seems to apply equally to meta refresh, and we have a spec for that. That there are issues with interop is why we have specs... :-) The space thing is interesting. meta http-equiv=refresh content=0 url=http://example.com/there; / The spec says to skip the rest of the string if ; or , is not present (step 10, https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh ), but it looks like IE11 and Gecko will instead continue parsing as if ; had been seen. That is, remove Otherwise, jump to the last step. from step 10 in the spec to align with IE11/Gecko. I don't see this in webdevdata, but since webkit/blink have had bugs filed about it, I think it seems reasonable to match IE11/Gecko. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28338 Do we have stats on how frequent the `Refresh:` header is on the Web? HTTP Archive maybe? In webdevdata.org-2015-01-07-112944 I see 58 pages with a Refresh HTTP header. I see 4336 pages with meta refresh. 22 have both. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28339 httparchive is going to be a bit misleading since the data is fetched using IE with the pref to follow meta refresh enabled, so zero-timeout meta refresh to a different url will not be in the data set, I think. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Wed, 25 Mar 2015 15:08:41 +0100, Andrea Rendine master.skywalker...@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 noscriptmeta .../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
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.
Re: [whatwg] Page refresh interface
That's evidence that I'm not smart enough. I never search on StackOverflow, I usually g***le it out. Some fellow people who want to stop the power of meta, then. (the first 2 questions for sure, and even more below) If meta were changeable or removable before the refresh action is fired, then it would become a very powerful native instrument on its own and a useful fallback for scriptless cases (i.e. where script is not supported or disabled). And I guess this would remove the need for a standardisation of HTTP refresh header, which is not declared, and perhaps not evident/useful e.g. on page caching. 2015-03-26 14:09 GMT+01:00 Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 13:11:15 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: 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. Alternatively you could check stackoverflow. http://stackoverflow.com/ search?q=stop+meta+refresh Would any of those benefit from being able to stop meta refresh, and JS-only redirect or noscript are not enough? -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 13:11:15 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: 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. Alternatively you could check stackoverflow. http://stackoverflow.com/search?q=stop+meta+refresh Would any of those benefit from being able to stop meta refresh, and JS-only redirect or noscript are not enough? -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
Therefore he gets a site without non-declarative interactivity, from complex form validations and animations to complex page refresh logic. Native form validation, CSS animations, still keep working with JS disabled. Again, disabling JS does not mean refusing animations. Does this mean that meta refresh should be avoided altogether and replaced by JS? I would argue yes, but that's a different discussion. It was retorical. I think not. It's just a powerful mechanism that can work when users want to disable JS for other reasons which are *not* necessarily to avoid refresh, as said before. http://stackoverflow.com/questions/3252743/using-javascript-to-override-or-disable-meta-refresh-tag This thread is quite full of examples with authors trying to remove meta after it is loaded or to hide it inside noscript, two not viable solutions. I'm not looking for a native solution for *all* use cases. I like using JS in several scenarios, but I also like providing pages with a fallback as you said. Among the worthy points of this discussion there's probably this: it's not important to modify meta refresh timeout, as that would need JS to be changed and so a window.setTimeout is enough. So let's put it simple: can refresh be stopped when removing meta refresh element? No. Could it be requested? I wish so. 2015-03-26 16:38 GMT+01:00 Niels Keurentjes niels.keurent...@omines.com: 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-boun...@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 sim...@opera.com: On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine master.skywalker...@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
Re: [whatwg] Page refresh interface
Someone also said that once it used to work or that it no longer works, even if I don't feel I can trust it. Also consider that noscript is somehow blunt as it detects whether JS is disabled, but its content is not parsed if JS is enabled but for any reason it doesn't work. 2015-03-26 20:21 GMT+01:00 Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 17:10:56 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: http://stackoverflow.com/questions/3252743/using- javascript-to-override-or-disable-meta-refresh-tag This thread is quite full of examples with authors trying to remove meta after it is loaded or to hide it inside noscript, two not viable solutions. It looks like the person who asked the question in that thread would be happy with noscript had it worked in the cell phone browser he was interested in. But it would be better without noscript, certainly. Also several people assumed that it would work to remove the element to stop the timeout, which is entirely reasonable. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 17:10:56 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: http://stackoverflow.com/questions/3252743/using-javascript-to-override-or-disable-meta-refresh-tag This thread is quite full of examples with authors trying to remove meta after it is loaded or to hide it inside noscript, two not viable solutions. It looks like the person who asked the question in that thread would be happy with noscript had it worked in the cell phone browser he was interested in. But it would be better without noscript, certainly. Also several people assumed that it would work to remove the element to stop the timeout, which is entirely reasonable. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine master.skywalker...@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
Re: [whatwg] Page refresh interface
Andrea, Simon, Le 25 mars 2015 à 23:08, Andrea Rendine master.skywalker...@gmail.com a écrit : 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. Indeed. It was Netscape-specific but it's widespread now (that's why we have a meta http-equiv=refresh surrogate). I was not so sure about the interest of documenting it, but after [digging into it][1]. There seems to be many Web Compatibility hacks around it. Do we have stats on how frequent the `Refresh:` header is on the Web? HTTP Archive maybe? [1]: http://www.otsukare.info/2015/03/26/refresh-http-header -- Karl Dubost http://www.la-grange.net/karl/
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 16:15:21 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: ..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? A JS-only solution does not address use cases where you want to fallback to meta when JS is enabled but still fails to run. I didn't see that being a requirement in the stackoverflow threads. -- Simon Pieters Opera Software
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 sim...@opera.com: On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine master.skywalker...@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
Re: [whatwg] Page refresh interface
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-boun...@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 sim...@opera.com: On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine master.skywalker...@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
Re: [whatwg] Page refresh interface
why doesn't the document interface expose the refresh timeout? Because nobody implemented it and nobody asked for it (until now). I don't know whether to feel proud or guilty about that. 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. Overwriting meta refresh is pointless, as the Refresh timeout doesn't change. Writing it would perhaps be impractical as it cannot be changesd once set. This list only shows a bunch of ways to achieve the same behavior. 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) 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 noscriptmeta .../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. 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. 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). 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. Indeed. It was Netscape-specific but it's widespread now (that's why we have a meta http-equiv=refresh surrogate).
Re: [whatwg] Page refresh interface
On Tue, 24 Mar 2015 02:41:30 +0100, Andrea Rendine master.skywalker...@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 noscriptmeta .../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
Re: [whatwg] Page refresh interface
Now I tested the interface. Here the results, just for completeness. - IE does have such a command. I had a bad time looking for it, because I'm Italian and the Italian translation is really poor (Consenti aggiornamento metadati, i.e. Allow metadata to be refreshed instead of Allow meta refresh). However, it does not prompt at all whether the specific site you are browsing has a refresh directive. - FF has a better interface, as it prompts the user about the specific site. However, if the Prompt user command is checked, the user is notified only when meta refresh directive is present, and if confirmed the page is refreshed at once, not on timeout. On the other hand, if a refresh header directive has been sent and the command is checked, the interface disappears instantaneously and the refresh is aborted altogether. - Opera (last version) has the same settings interface of Chrome and I didn't succeed in finding the mentioned command. Can't test on Safari (I'm a Win user), but I confirm about Chrome. However the bulk of my issue remains: wouldn't it be useful if there were a refresh property to be accessed for the document? 2015-03-24 10:49 GMT+01:00 Andrea Rendine master.skywalker...@gmail.com: Thank you, I'll have to test on IE and Opera. Does that interface interact with refresh instruction given by the header too? (The answer could also be negative, as the refresh response header has been introduced by Netscape for what I know) 2015-03-24 5:17 GMT+01:00 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net: Andrea Rendine master.skywalker...@gmail.com writes: 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. FYI, Firefox has a “Warn me when web sites try to redirect or reload the page.” option, Internet Explorer has “Allow META REFRESH” and Opera had a similar feature. AFAIK, Chrome and Safari do not have these options. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Page refresh interface
Thank you, I'll have to test on IE and Opera. Does that interface interact with refresh instruction given by the header too? (The answer could also be negative, as the refresh response header has been introduced by Netscape for what I know) 2015-03-24 5:17 GMT+01:00 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net: Andrea Rendine master.skywalker...@gmail.com writes: 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. FYI, Firefox has a “Warn me when web sites try to redirect or reload the page.” option, Internet Explorer has “Allow META REFRESH” and Opera had a similar feature. AFAIK, Chrome and Safari do not have these options. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Page refresh interface
Andrea Rendine master.skywalker...@gmail.com writes: 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. FYI, Firefox has a “Warn me when web sites try to redirect or reload the page.” option, Internet Explorer has “Allow META REFRESH” and Opera had a similar feature. AFAIK, Chrome and Safari do not have these options. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
