Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Wed, 25 Mar 2015 21:31:51 +0100, Jonas Sicking jo...@sicking.cc wrote: Is this really something we should tie to the pushState/replaceState API? It seems like websites that lazily add more content as the user scroll down, like the facebook feed or twitter feed, might not use pushState/replaceState, but would still like to handle restoring scroll position themselves. Yeah... also consider navigating back and forth between two different sites/apps, without navigating within each site/app. Should they be able to turn off scroll restore? Is this something that should be toggled on a per-page basis or on a per-navigation basis? If per-page, is it enough to just be able to turn it off (i.e. not turn it on again)? e.g. history.restoreScroll = false; or history.disableRestoreScroll(); -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
On Thu, 26 Mar 2015 01:47:57 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 16:08 Uhr, schrieb Simon Pieters sim...@opera.com: […] It seems to me that there are two use cases: 1. variable-size image map 2. art direction image map (1) is more common than (2). Yes, you're right. If there is implementor interest, I think it makes sense to make map address use case (1) first, and after that maybe also use case (2). Is there? :-) I'd say there's a good chance that a solution for (1) could also cover (2). So it might be helpful to keep (2) in mind while working on (1) in order not to miss that chance … If there is implementor interest. How? Consider the AMC Networks image map in the footer of http://www.wetv.com/ . Make the window narrower than 600px, the image map will have a different layout. -- Simon Pieters Opera Software
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] Responsive image maps
Am .03.2015, 11:10 Uhr, schrieb Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 01:47:57 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 16:08 Uhr, schrieb Simon Pieters sim...@opera.com: […] It seems to me that there are two use cases: 1. variable-size image map 2. art direction image map (1) is more common than (2). Yes, you're right. If there is implementor interest, I think it makes sense to make map address use case (1) first, and after that maybe also use case (2). Is there? :-) I'd say there's a good chance that a solution for (1) could also cover (2). So it might be helpful to keep (2) in mind while working on (1) in order not to miss that chance … If there is implementor interest. How? Consider the AMC Networks image map in the footer of http://www.wetv.com/ . Make the window narrower than 600px, the image map will have a different layout. Ah, I see. I didn't understand correctly what art direction meant here. Mea culpa.
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] MetaExtension and Dublin Core revision
On Tue, 17 Mar 2015, Andrea Rendine wrote: Changes to make: - The properties dc.created, dc.date.issued, dc.dateCopyrighted, dc.dateSubmitted, dc.license, dc.mediator, dc.medium, dc.modified, dc.provenance, dc.references, dc.temporal, dc.valid are to be REMOVED because not defined by the specification. Are they used by people? If so, it seems like it's the DC specification that should be fixed. + The properties [...] are to be INTRODUCED [...] That should be non-controversial. + all dc.prefixed properties should present a note advising authors NOT to use them when a value in the proper range is to be provided (/elements/1.1/ namespace is maintained for legacy reasons, as some properties could have a value not fitting the range as it was defined in 2008 revision; however, now specific ranges have been defined, so it is auspicable that authors conform to them; in that case the more specific /terms/ namespace properties: http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces). I'm not sure what you're saying here. Isn't the DC spec a more appropriate place for such warnings, though? - The property dcterms.collection is to be REMOVED as it defines a class of properties in DCMI specification, not a real property Is it used by anyone? - The properties dcterms.hasFormat, dcterms.hasPart, dcterms.hasVersion, dcterms.isFormatOf, dcterms.isPartOf, dcterms.isReferencedBy, dcterms.isReplacedBy, dcterms.isRequiredBy, dcterms.isVersionOf, dcterms.references, dcterms.relation, dcterms.replaces, dcterms.requires, dcterms.source, dcterms.subject are to be REMOVED, because per spec these properties are meant to define non-literal values and as such meta@name is not suitable. Again, are they used by anyone? + Properties whose value can reasonably be either a literal or a non-literal surrogate should be marked with a note stating that, if a resource non-literal reference is to be provided, it is better to use a link rel=dcterms.property href=reference title=literal definition / rather a meta element whose content is a string. I don't really understand this either, but it seems also like something that should be done in the relevant spec, not the registry. + Prefix structures, both in namespace definition link rel=schema.DCTERMS/DC and in properties meta name=DCTERMS/DC should be capitalised both in existing properties and in those defined in this message (I wrote them lowercase for the sake of uniformity). Aren't these values case-insensitive? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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] Proposal: Allow disabling of default scroll restoration behavior
On Thu, Mar 26, 2015 at 1:22 AM, Majid Valipour maji...@google.com wrote: My only concern is to make sure that these new methods replace history.pushState() and history.replaceState() in the spec. Otherwise I feel the benefits of a cleaner API is not worth the additional confusion of having different methods for doing (almost) the same thing. Well, I doubt that they can, maybe over a very long period of time but I wouldn't count on it. However, if MDN describes them as more capable methods (and without the useless second argument), I doubt there will be much confusion. Having four required arguments is no picnic either. -- https://annevankesteren.nl/
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] HTML6 single-page apps without Javascript proposal now on Github
On Mar 24, 2015, at 10:57 PM, Matthew Sotoudeh matthew...@outlook.com wrote: Hello! By way of introduction, I'm an author who reads some of these mailing lists but (almost) never replies. This proposal is quite interesting, wanted to throw in my two cents as well: 1. Would you consider writing a polyfill/Javascript framework for this? It seems to me that the fundamentals of the proposal could be fairly simply written into a small Javascript polyfill by intercepting a[mref] clicks and filling up templates. A working polyfill would give people a chance to play around with the proposal, give you (and others who like the idea) a working implementation of it in case it doesn't become a standard, and provide an otherwise-necessary polyfill for older browsers if it does become a standard. I see the other Javascript MVC frameworks as solving the same problem. I’m also coming in from the author side and don’t really want to make another framework, but it is something I’m considering.. 2. You've mentioned before that this would be more useful for beginners (who only know HTML, not Javascript), but I don't necessarily agree. With this proposal you would need to explain how the browser downloads JSON data from the mref attribute's location, then somehow parses into a model, and then fills up and displays a template (making what the page is actually showing extremely different from what they write in their editor, not exactly intuitive). IMO the biggest hurdle for a beginner to get over would be conceptually understanding the models and templates, which HTML's declarative nature seems to make more difficult to understand. I would prefer having a Javascript library where the user could write something along the lines of link.onclick = fillTemplate(loadData()), making what's actually happening when a user clicks a link much clearer. The person would still need to understand some Javascript, but not much more than what's necessary for the model attributes in your proposal currently. Writing HTML templates would still be a lot easier than writing Javascript, since people start with HTML first, and understand that before going into Javascript. And besides, you have to write templates anyways with any modern framework. Also, people find declarative concepts easier to understand than imperative languages. Your “link.onClick = fillTemplate(loadData())” is an imperative script that authors have to figure out from infinite possibilities available in Javascript, which is disconnected from the structure of the HTML document. You have to duplicate the “link” reference in your Javascript, and would mostly likely have to traverse the DOM hierarchy to find that link to assign the onClick. How would a author even know how to select the element to assign? Do they have to make sure to include an ID tag to help search through the hierarchy? So many problems there.. Compare your version to: A mref=‘http://api.mysite.com/article-1' receiver=“myArticle” H1 model=“myArticle.headline” where the elements and properties have clearly defined fixed roles that assign actions. And, they operate on those elements, because they were assigned right there. There’s no duplication of hierarchy. You don’t have to go back through the document to find the elements again, because it was assigned when you built the document in the first place. It’s just as how: A href=“www.mywebsite.com/article' clearly defines a link that loads a new page action. Assigning actions via Javascript just makes the system so much more complex. With this proposal, it falls in line with the use model of static HTML pages, with the added benefits of dynamically loaded content without learning a separate Javascript framework. (or trying to figure out which framework to use.) I'm also curious as to how many beginners would *want* to do a SPA with templates and models like this, I would imagine that by the time you have a real need to load data from a backend API into models and templates without reloading the page that you'd have a workable understanding of Javascript enough to use an existing MVC framework of your choice. For APIs, the “MODEL” definitions could be supplied by the API vendor. I don’t list it in my example, but the model definitions could come in from an external source. For example: MODEL src='http://api.mywebsite.com/article' would load in model definitions (and possibly fixtures) from an API vendor. The web page's author would then just pick and choose model elements to put in their website’s template. There are 75+ million Wordpress sites and 200+ million Tumblr pages that could benefit from this scenario, at the very least. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com twitter.com/futureclaw
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] Proposal: Allow disabling of default scroll restoration behavior
On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour maji...@google.com wrote: That is fair. Assuming clear documentation helps alleviate potential confusion I am fine with deprecation route. I suppose the purpose of the spec is to not only document the current recommended behavior but also capture any legacy ones until it is fully removed. Yeah, we don't want any new user agents such as Spartan or Servo run into pages that only work with history.replaceState(). They'd then have to reverse engineer it rather than simply reading a specification which is not nice. -- https://annevankesteren.nl/
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
