Re: [whatwg] hit regions: limited set of elements for fallback content
First a high-level thought. I'm happy to keep chasing after legitimate use-cases instead of contrived ones, but just because we can't think of one, doesn't mean it doesn't exist. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. Maybe the vast majority of web apps that use canvas for a grid, or a slider, or a list box would be better off using standard html5 objects. But what if there's one app that can't, for some reason we haven't anticipated? If we wait until that app appears to allow that control to have a hit region, then it will be months or years before that app can be accessible. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Well for example, is the use case one of the controls on Bugzilla's advanced search page?: https://www.w3.org/Bugs/Public/query.cgi?format=advanced If so, I feel comfortable saying that we don't need to make canvas support that, since that use case is already handled very well by the select element. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. I'll try, though: what if I had a list of choices displayed as a pie chart? Each slice of the pie is a focusable object that, when you click on it, allows you to take an action on that pie slice. Surely you'd agree that rendering a pie chart is a natural use-case for the canvas element. I know it's technically possible in css, but it's quite tricky - whereas it's simple and natural in canvas. And there are plenty of shapes that are basically impossible in pure CSS. But how should the list of pie slices behave if you were interacting with the pie chart using the keyboard? Why not a list box? Conceptually you just have a list of elements, one of which can be selected at a time. Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Just because people do it doesn't mean we need to design our APIs around it, or otherwise endorse it. For example, people use table elements for layout purposes, but this is expressively against the table conformance requirements. People use blockquote for indenting, but instead of providing a blockquote indent-depth attribute, we improve CSS to support indenting. And so on. Even though you're not supposed to use table for layout, is there any part of the HTML spec that forbids placing a certain element inside a table cell because the only legitimate reason to do so would be if it was a layout table? I'm not aware of one. Similarly, I think it'd be simplest to just allow any element to be the target of a hit region. We can still discourage it, but fail gracefully if authors decide to abuse it. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. Yes, and people are building replacements for select using web components now, like polymer-ui-menu: http://www.polymer-project.org/components/polymer-ui-menu/smoke.html It should be easy to make something like polymer-ui-menu accessible using role=listbox and role=option under the hood. The question is, why shouldn't it be possible to implement a polymer-ui-canvas-menu that works the same way but uses a canvas to render? So this is why I ask for the precise use cases. We can only evaluate if the technologies are actually addressing needs by going through and seeing how they do with precise use cases. If the use cases are very vague, we can at best guess, and we might guess poorly. What if I do want a select, but I just want a canvas to render it visually? Are Web Components and CSS unable to get the effects you need? Maybe we should be improving those rather than canvas. It's hard to tell without knowing precisely what you want to do. Is my pie chart example
Re: [whatwg] input type=number for year input
On 20/02/2014 01:34, TAMURA, Kent wrote: Hi, The current WebKit/Blink behavior is: - Accept both of the ASCII digits and localized digits - Accept both of the standard decimal point '.' and a localized decimal point That sounds similar to what I've implemented, but users can't mix digits, decimal or grouping separators from different locales. The entire input must be consistent. Specifically, input typed in by the user is first processed using the locale of the element (as defined by the 'lang'/'xml:lang' attributes, if any). If that fails we retry with the locale of the document (Content-Language header). If that fails we retry with the locale of the browser. If that fails then we pass the string off to HTMLInputElement's internals to be set as its value without de-localizing it, where it will be parsed using the HTML 5 rules for valid floating-point number (essentially allowing ASCII digits and decimal point as the final fallback). (We start with the element and work out looking for locale information in order to give priority to the locale of the context in which the input exists.) For what it's worth I just tried the following in Chrome, and if I type in 12,34 then increment using the spinner it resets to zero, seeming to indicate that the , was rejected. Is that expected? data:text/html,input type=number step=0.01 lang=fr - Not accept grouping separators and don't show grouping separators We showed grouping separators in the past. But we stopped it because grouping separators disturb some use cases. So I've discovered. ;) We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. So essentially you assume any separator that is a decimal separator in any locale is a decimal separator all cases? Even that approach would seem to have the potential for unexpected results for users; for example, a user types in 1,234 meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand? Jonathan
[whatwg] Proposal: requestBackgroundProcessing()
We're building a browser-based P2P multiplayer engine on top of WebRTC DataChannels. You can try out our work-in-progress here: http://www.scirra.com/labs/multiplayer/test1/ The first player in to a room is assigned the host, and all other subsequently joining peers connect to the host with WebRTC DataChannels and start exchanging game data. Like all responsible HTML5 games, it runs based on a requestAnimationFrame loop. When switching tab, the requestAnimationFrame loop stops, and most browsers also limit timers to 1 Hz in background tabs. This is a sensible strategy to avoid wasting resources and draining battery from inactive tabs. However in the use case of a WebRTC-based multiplayer game, the host is effectively acting as the game server, and this basically hangs the server. If there were 20 peers connected to the host, the game hangs for all 20 players. Users regularly switch tabs and probably don't expect that this hangs the game for everyone. To prevent multiplayer games commonly hanging, perhaps there could be a new API to request that a page can keep running at full capacity even in the background, such as window.requestBackgroundProcessing(). This could show a permission prompt like 'Do you want to allow this page to run in the background? Allow / Deny' to help protect against abuse. The formal definition could be: if background processing is approved, all timer and requestAnimationFrame callbacks run with the same frequency they would in visible state even when in hidden state (using the terms from the Page Visibility API). Alternatively browsers could automatically perform this if any WebRTC DataChannel has been created by the page. However there are probably cases where it doesn't matter if the DataChannel hangs or reduces to 1 Hz response, and so it would still be good to save resources. Also, there may be other use cases not involving WebRTC where it would be useful to run a page in the background. If this specific proposal does not seem appropriate, please consider suggesting any other possible solutions to avoid multiplayer games hanging when put in to a background tab - we've already run in to this with testing, so it seems likely to affect real-world games too. Ashley Gullen Scirra.com
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote: We're building a browser-based P2P multiplayer engine on top of WebRTC DataChannels. You can try out our work-in-progress here: http://www.scirra.com/labs/multiplayer/test1/ The first player in to a room is assigned the host, and all other subsequently joining peers connect to the host with WebRTC DataChannels and start exchanging game data. Like all responsible HTML5 games, it runs based on a requestAnimationFrame loop. I think this is your problem. rAF isn't a replacement for setTimeout, it's a variant designed to better solve the timer problem *when you want to be synced to the screen*. If you're doing network-management work, that has nothing to do with the screen refresh rate, and shouldn't be associated with it. Just run a normal setTimeout loop instead. (If people used rAF for what it was *intended* for, we could probably have stopped firing it *entirely* when the window isn't visible. Instead, we had to compromise with the 1s refresh rate instead.) ~TJ
Re: [whatwg] Proposal: requestBackgroundProcessing()
Isn't setTimeout also clamped to 1s in the background? This alone would add so much latency as to effectively hang the game anyway. On 20 February 2014 16:18, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote: We're building a browser-based P2P multiplayer engine on top of WebRTC DataChannels. You can try out our work-in-progress here: http://www.scirra.com/labs/multiplayer/test1/ The first player in to a room is assigned the host, and all other subsequently joining peers connect to the host with WebRTC DataChannels and start exchanging game data. Like all responsible HTML5 games, it runs based on a requestAnimationFrame loop. I think this is your problem. rAF isn't a replacement for setTimeout, it's a variant designed to better solve the timer problem *when you want to be synced to the screen*. If you're doing network-management work, that has nothing to do with the screen refresh rate, and shouldn't be associated with it. Just run a normal setTimeout loop instead. (If people used rAF for what it was *intended* for, we could probably have stopped firing it *entirely* when the window isn't visible. Instead, we had to compromise with the 1s refresh rate instead.) ~TJ
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 8:23 AM, Ashley Gullen ash...@scirra.com wrote: Isn't setTimeout also clamped to 1s in the background? This alone would add so much latency as to effectively hang the game anyway. Ah, I wasn't sure if anyone actually did that; I just tested in Chrome, though, and it definitely does. All right, proceed with your request. ^_^ ~TJ
Re: [whatwg] Proposal: requestBackgroundProcessing()
On 2/20/14 11:18 AM, Tab Atkins Jr. wrote: (If people used rAF for what it was *intended* for, we could probably have stopped firing it *entirely* when the window isn't visible. We do. At least Chrome and Firefox do. Instead, we had to compromise with the 1s refresh rate instead.) That's what Chrome and Firefox do for setTimeout/setInterval. -Boris
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: CE or BE or ROC do not specify units (successor elements), but points of reference (neutral elements). In my examples, the unit for a time offset is always the duration of a solar year. Yes, sorry, by 'essentially' I meant that they /act/ like and can be treated as such, as a simplification. Looks like a type error to me – similar to the following cases: - octets can be treated as characters, as a simplification - UTF-16 can be treated as UCS-2, as a simplification - REST can be treated as CRUD, as a simplification - HTML can be parsed with regular expr…ZA̡͊͠͝LGΌ The first operand is the name for a duration of time (conveying a start point and an end point), while the second operand is an offset. Suppose the result was displayed using html, like time2014/time: I agree so far, sure, but note also that the year name is itself comprised of an offset and a description of a zero point; 2014 CE is the year starting at the moment when 2,014 years have elapsed from the start of 1 BC. It is itself a number of years, rendered a certain way by convention. - A user agent could localize the result to 2557 BE or ROC 103 or YOLD 3180 without introducing errors into the calculation - similar to an conversion between binary, decimal and hex. Why should it be unable to localize the input (which is done with time zones all the time, btw) ? Sure, you can change the number that corresponds to a given abstract year by changing the zero, and this would depend on knowing the original zero such that it's clear that, for example, '2014' means 2014 CE rather than BE or even BCE (presumably by specification). I think the HTML specification follows ISO 8601 – so yes, 2014 CE. The question is, is it a big enough deal that it demands a new input type, rather than, say, a number and a dropdown with typical eras, provided by the author? That solution leads to the following prerequisites for localization: 1. authors are aware of localization issues 2. authors care about localization issues 3. authors know about user locale 4. authors implement localization 5. authors are competent working with localized data The input type=year solution instead only requires that the web server is able to process ISO 8601 dates. It would place a small one-time burden on implementors, instead of a continuous burden on authors. Or, for that matter, a CSS property telling the browser to display the number following its conventions for year numbers, which could include choice of zero just as much as grouping, as long as the document's choice can be determined. I do not think that localization should be an author's burden. I also do think that localization should not depend on sender, but on receiver. - A user agent could not localize the offset, unless a separate input type=timedelta (or similar) would be introduced. One can use an input type=number for a time offset quite nicely, also see below. Yes, of course. Although I'm not sure what localising an elapsed time would even mean (beyond the obvious choice of characters), except possibly converting it into some non-year unit. See example: 900 seconds or 15 minutes, what would you rather read? I hereby - only half-jokingly - propose a @unit-type attribute for both input type=number and input type=range, which conveys what the given number represents. Thee @unit-type attribute can have the values K, s, m, kg, cd, A and mol to enable hints for the seven SI base units. A microsyntax using the tokens (, ), +, -, *, / and ^ could be used to specify derived units. User agents would be encouraged to localized the displayed data. Example for input element on a cooking form: labeltemperature input type=number unit-type=K value=453.15/label labelcooking time input type=number unit-type=s value=900/label labelbeep frequency input type=range unit-type=1/s value=1/label A user agent could display this - localized - as follows: temperature [ 180 °C ][+|-] cooking time[ 15 min ][+|-] beep frequency [ each second ][+|-] The @unit-type attribute could also provide useful when allowed on the data, var, output and meter elements. Mark my words. When I first read this, I considered it unnecessary complexity. On reflection, though, I find that I kind of like it. Perhaps it should be allowed for data as well? Of course, I'm not sure that anyone would really use it in practice. Public transport schedule query forms commonly ask how much time you want to have for changing trains at each stop and/or how far the stop is allowed to be from the actual target and how fast you can walk. This common use case already covers time (s), distance (m) and speed (m/s). Those forms use select and option nowadays, see example:
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote: The host is effectively acting as the game server, and this basically hangs the server. If there were 20 peers connected to the host, the game hangs for all 20 players. That's a bug in your application design. If one web page is performing operations necessary for things orthogonal to that page's visual display, those operations should not be tied to a requestAnimationFrame loop. If the host is responding to network updates from other clients, for instance, then it could perform that work in response to the network events coming in. The page may also be performing the normal game updates for that one client in a rAF loop concurrently. - James
Re: [whatwg] Proposal: requestBackgroundProcessing()
The host needs to keep simulating the world even when no network events are occurring. That can't happen if rAF isn't firing and timers only run at 1 Hz. On 20 February 2014 17:56, James Robinson jam...@google.com wrote: On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote: The host is effectively acting as the game server, and this basically hangs the server. If there were 20 peers connected to the host, the game hangs for all 20 players. That's a bug in your application design. If one web page is performing operations necessary for things orthogonal to that page's visual display, those operations should not be tied to a requestAnimationFrame loop. If the host is responding to network updates from other clients, for instance, then it could perform that work in response to the network events coming in. The page may also be performing the normal game updates for that one client in a rAF loop concurrently. - James
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 10:32 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Feb 20, 2014 at 12:02 PM, Ashley Gullen ash...@scirra.com wrote: The host needs to keep simulating the world even when no network events are occurring. That can't happen if rAF isn't firing and timers only run at 1 Hz. This sounds like work that should be done in a worker. Worker timers aren't throttled when in the background, and this is exactly something workers are for. Is WebRTC available in a worker?
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, 20 Feb 2014, Dominic Mazzoni wrote: I'm happy to keep chasing after legitimate use-cases instead of contrived ones, but just because we can't think of one, doesn't mean it doesn't exist. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. Maybe the vast majority of web apps that use canvas for a grid, or a slider, or a list box would be better off using standard html5 objects. But what if there's one app that can't, for some reason we haven't anticipated? If we wait until that app appears to allow that control to have a hit region, then it will be months or years before that app can be accessible. The problem is that without knowing what the unanticipated app is, we can't possibly design for it. Trying to design APIs blindly results in poor APIs. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. But it _does_ mean we can't possibly design for it. I'll try, though: what if I had a list of choices displayed as a pie chart? Each slice of the pie is a focusable object that, when you click on it, allows you to take an action on that pie slice. Isn't that handled by just a series of buttons corresponding to each slice? I don't really understand why you'd need a list box here. But how should the list of pie slices behave if you were interacting with the pie chart using the keyboard? Why not a list box? Conceptually you just have a list of elements, one of which can be selected at a time. I think conceptually you have a series of buttons. It would be more like a list box if instead of each slice being activatable, the slices were selectable, maybe multiple slices being selectable such that you can then operate on them as a group. That does seem like a reasonable use case. It would argue for allowing select size=n where n1, and for select multiple. It's a bit weird to require that we explicitly give the size for a fallback select, so maybe we should instead just say that any select size=1 that's in canvas fallback is automatically assumed to have a non-1 size? Would that be reasonable to implement? Even though you're not supposed to use table for layout, is there any part of the HTML spec that forbids placing a certain element inside a table cell because the only legitimate reason to do so would be if it was a layout table? We've made lots of elements non-conforming, e.g. font. Looking at tables specifically, there's no element that was previously only allowed in tables that has since been disallowed (all the elements we've disallowed from table were also allowed elsewhere before and are disallowed everywhere now), but there's lots of _attributes_ on table, td, etc, that we've made non-conforming for the same reason: table bgcolor table border table bordercolor table cellpadding table cellspacing table width td align td bgcolor ...etc. Plus of course we don't allow any elements that aren't currently in HTML. Similarly, I think it'd be simplest to just allow any element to be the target of a hit region. We can still discourage it, but fail gracefully if authors decide to abuse it. I'm all for allowing things which have reasonable use cases. But there's plenty of things which make zero sense as fallback content. input type=color, for example, simply cannot be sanely implemented in canvas, because we don't provide the right hooks. Similarly for select size=1, in its normal form (i.e. assuming we don't special-case it to turn it into a listbox rather than a drop-down widget). Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. Yes, and people are building replacements for select using web components now, like polymer-ui-menu: http://www.polymer-project.org/components/polymer-ui-menu/smoke.html (Loading that page shows why it's terrible to design new widgets from scratch instead of building them on existing fallback elements, by the way. It's a completely unusable page with near zero semantics. Completely inaccessible, even to non-AT users, all because the scripts can't load.) It should be easy to make something like polymer-ui-menu accessible using role=listbox and role=option under the hood. The question is, why shouldn't it be possible to implement a polymer-ui-canvas-menu that works the same way but uses a canvas to render? I think it's a fine use case that we should enable. We just need to work out what to do regarding select size=1, as discussed above. I'd suggest a different analogy: suppose your company makes foam pipe insulation and you discover people are buying your product and using it as a
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier caban...@gmail.com wrote: This sounds like work that should be done in a worker. Worker timers aren't throttled when in the background, and this is exactly something workers are for. Is WebRTC available in a worker? I don't know, but if not, fixing that is probably closer to the right direction than letting people run fast timers in minimized UI threads. If this is just messaging of game state, he could probably do just relay that through the UI thread, so the game simulation still takes place in a worker. -- Glenn Maynard
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Feb 20, 2014, at 9:01 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/20/14 11:18 AM, Tab Atkins Jr. wrote: (If people used rAF for what it was *intended* for, we could probably have stopped firing it *entirely* when the window isn't visible. We do. At least Chrome and Firefox do. Safari too. Instead, we had to compromise with the 1s refresh rate instead.) That's what Chrome and Firefox do for setTimeout/setInterval. We actually clamp timers even more for background tabs if the page has not done anything externally observable (e.g. Send or receive network data) in a while. Cheers, Maciej
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson i...@hixie.ch wrote: So far, it seems like to support grids in canvas, we need: - enable table-related elements (table, td, tfoot, etc) to be hit region controls. (exclude col and colgroup) - fire an event on an element when the user agent (possibly because of a request from the AT, but not necessarily) wants to scroll to an element; default action is to actually scroll. - when this event is fired on a canvas, include the region information. ...and to support list boxes, we need: - enable select multiple elements to be hit region controls. - enable select size=N eements where N1 to be hit region controls. - enable option to be hit region controls. - optionally, if implementors are on board: - make select size=1 in canvas act like size=N where N1. - enable select size=1 elements to be hit region controls. This all sounds great. Are there any other use cases we should address? Possibly, but this is a great start for now. I'll post more use cases as I uncover them or think of them. What's your take on the select thing; should we have a special case in browsers for size=1, or should we require size1? I can't think of a way to make size=1 work, so requiring size1 may be the only option. It seems ugly, though. - Dominic -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] MetaExtensions for HTML5 vs. custom tagging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Christine Smith chris...@us.ibm.com, 2014-01-16 10:21 -0500: Over the years, my company has developed custom IBM.xxx meta tags for our internal and external web pages that are used by various internal tools. My question has two parts: 1) Is there an allowance for custom taxonomy definition The HTML specification and meta@name registration mechanism and conformance checkers are all agnostic toward whatever taxonomy you want to use for meta@name values you register. Each of the registered values is effectively seen just as a opaque string with no relationship at all to any of the other registered values. that is not a proposal for general acceptance? The majority of the meta@name values that are currently registered are not for general acceptance -- if by general acceptance you mean values that have some shared utility in multiple tools or services on the Web. The majority of the registered values are semi-private values that have utility to only one tool or service somewhere. For example, if we manage our own company-specific meta data schema and linked our pages two it, would it pass validation? Each individual meta@name value you register will pass validation. Whatever schema you might have that defines some relationship among your meta@name values, it's irrelevant to validation. You can't, say, register a set of IBM.* meta@name values by referencing a schema. Instead you just have to list and register each individual value as a separate string. If so, is there a spec that shows how to create our own schema? You don't need to provide a schema. You just to need to provide each meta@name value with a link for each to some document that defines what that one value means. Of course if you want, that document can be something that defines a schema that specifies how those values are related to one another. But it's not necessary for the values to be related to each other in any way, and not necessary to explain how they are related to each other if there is some relationship. 2) The Registered Extensions table at http://wiki.whatwg.org/wiki/MetaExtensions still show status of proposal for all tags. Does that imply that they are not fully accepted as extensions? For example, -- I would like to know that Dublin Core is accepted, so that I can rely on its continued support. Anything that's listed in the first table on that page is accepted for the purposes of validation. Whatever purposes there might be other than validation are basically just hypothetical. -- However, there are also redundant examples in that table (e.g. web_author and designer) Those are only redundant if you expect it's required for the values to actually mean something standard, or to mean what they look like they should probably mean. You could register the string this_means_old if you wanted to, and then define it as meaning new, as long as you provided a link to some document that gave it that definition. and tool-specific proposals that could be made more generic for broader use (e.g. Web Trends wt.xxx could become analytics.xxx). As far as I know, nobody's planning to do that. I think the organizations who've registered values that only work with their tool or service are probably happy with what they have and don't show any signs of being interested in spending time on trying to get agreement about values with standard meanings that might accomplish the same thing. Is there a timeline to update the status to accepted for those that will be supported in the future? There's no such timeline I'm aware of -- and as far as I can see, nothing at all would change in practice if and when any particular value were to move to accepted. --Mike - -- Michael[tm] Smith http://people.w3.org/mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTBlaXAAoJEIfRdHe8OkuVauUP/1SNvmSNNP/a+TKnBfxlnAN2 n+gOAf7evb3GNRoM4QJmih8lTwC1Lvj6wknpz5pVC4QLTE8mHtHC179i9HvLTNT3 NnAYZbqH5UwhvPZpnRe0BUrJ3cec20BXJ90DMlSqRPwgc5DFZ6evjNvY3GuRCusV hw5gaJUGdOxzUDeBTvfX8c7Wm6qDnx6ZA2iUi65EsawfoF45ldKvXLPeQ4DoYi9B 2B+KMvwH8TK680+bM3xTSHU9XVByfLxc9wjabHK/g/TtHTQV0sHnWYOxJMzB7awL 43SyGpO0aBwrvuqgwfRf8njL6UfC/1G6MfkgjevGY8/889o7aTBTULoQJ258dWI8 mzCxU2rzquN8pk9DzbxlOY17bLwzXZX5bgOj/mV0vAqRiHyuuuv93K4xk55i2alU TEFyorQwGUXyDpKC31VLg8RqIkHJt1lseekUHBuAiql42+qNR6qZSXbzRc5Ho3Sf FRtn+ygjz+PCd1S4b/FsVY9tv/I7gTOiEOBGRuIxtZq1UynmVD4Su5FqWwM0O07C fsxEGHNWvIdeMbVusaBHOtxWJvoEloPpLmcDY06h6vivxhrg+L42PBbWwhBp04s/ ObKgHogoknOyl1SUw/mclvUIiLkgdYWVPziW02hUhfhdh/ry+peRqCbuvrGdUErB qFJhn8OPsLRy44Pye3nq =4ZDF -END PGP SIGNATURE-
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, 20 Feb 2014, Dominic Mazzoni wrote: On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson i...@hixie.ch wrote: So far, it seems like to support grids in canvas, we need: - enable table-related elements (table, td, tfoot, etc) to be hit region controls. (exclude col and colgroup) Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24750 - fire an event on an element when the user agent (possibly because of a request from the AT, but not necessarily) wants to scroll to an element; default action is to actually scroll. - when this event is fired on a canvas, include the region information. Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24748 ...and to support list boxes, we need: - enable select multiple elements to be hit region controls. - enable select size=N eements where N1 to be hit region controls. - enable option to be hit region controls. - optionally, if implementors are on board: - make select size=1 in canvas act like size=N where N1. - enable select size=1 elements to be hit region controls. Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24749 What's your take on the select thing; should we have a special case in browsers for size=1, or should we require size1? I can't think of a way to make size=1 work, so requiring size1 may be the only option. It seems ugly, though. The way we could make it work would be to change the logic in the select so that when it's in a canvas, it's a list box and not a drop-down. But that might be more confusing than requiring that people set size=2? I guess I'll just punt on this for now and we'll see whether authors get confused or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: requestBackgroundProcessing()
There's a lot of worker features that aren't widely supported yet, like rendering to canvas with WebGL and 2D, Web Audio support, inputs, various APIs like speech and fullscreen, so I don't think that's practical right now. I guess that's not a reason to standardise a new feature, but is there not at least a workaround for the mean time? Are workers able to wake the UI with postMessage()? On 20 February 2014 18:50, Glenn Maynard gl...@zewt.org wrote: On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier caban...@gmail.com wrote: This sounds like work that should be done in a worker. Worker timers aren't throttled when in the background, and this is exactly something workers are for. Is WebRTC available in a worker? I don't know, but if not, fixing that is probably closer to the right direction than letting people run fast timers in minimized UI threads. If this is just messaging of game state, he could probably do just relay that through the UI thread, so the game simulation still takes place in a worker. -- Glenn Maynard
Re: [whatwg] hit regions: limited set of elements for fallback content
Dominic Mazzoni dmazz...@google.com writes: First a high-level thought. I'm happy to keep chasing after legitimate use-cases instead of contrived ones, but just because we can't think of one, doesn't mean it doesn't exist. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. Maybe the vast majority of web apps that use canvas for a grid, or a slider, or a list box would be better off using standard html5 objects. But what if there's one app that can't, for some reason we haven't anticipated? If we wait until that app appears to allow that control to have a hit region, then it will be months or years before that app can be accessible. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Well for example, is the use case one of the controls on Bugzilla's advanced search page?: https://www.w3.org/Bugs/Public/query.cgi?format=advanced If so, I feel comfortable saying that we don't need to make canvas support that, since that use case is already handled very well by the select element. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. Absence of evidence is at least weak evidence of absence. Quote http://rationalwiki.org/wiki/Absence_of_evidence: You hear some rustling noises in your backyard, and you want to figure out if the noises were caused by your neighbor's dog or by some other intruder. Fortunately, you know what your neighbor's dog is like - he's rambunctious and he barks constantly. So you listen closely, and after 20 minutes you don't hear any barking. What should you conclude? I'll try, though: what if I had a list of choices displayed as a pie chart? Each slice of the pie is a focusable object that, when you click on it, allows you to take an action on that pie slice. What if I look at that page in a textual user agent? Surely you'd agree that rendering a pie chart is a natural use-case for the canvas element. Nope. If it is just decoration, you should use CSS. Look at source code: http://daten.dieweltistgarnichtso.net/src/css-pie-chart-form.html (For pages like these, I have a hotkey for “disable CSS”.) I know it's technically possible in css, but it's quite tricky - whereas it's simple and natural in canvas. And there are plenty of shapes that are basically impossible in pure CSS. I might consider that a good thing. May I ask if you have designed human-computer interfaces. If so, may you provide examples? What if I do want a select, but I just want a canvas to render it visually? Are Web Components and CSS unable to get the effects you need? Maybe we should be improving those rather than canvas. It's hard to tell without knowing precisely what you want to do. This requests reminds me of customers wanting “page intro in flash.”. If a region has a car theft problem, you don't solve it by giving all the thieves the car keys. You solve it by improving the economy so that thieves have better things to do (like get an interesting job), and you solve the remainder by improving law enforcement. The same applies here. We solve it by providing better tools for custom text editing controls (e.g. better contenteditable APIs), and by making it non-conforming to abuse canvas for this purpose. I'd suggest a different analogy: suppose your company makes foam pipe insulation and you discover people are buying your product and using it as a swimming pool flotation device. Do you try to stop them from using your product and try to get them to purchase other pool toys, or do you start selling your pipe insulation directly to the sporting goods stores? You might check if the pipe insulation is toxic, first. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 03:25:56PM +, Ashley Gullen wrote: Users regularly switch tabs and probably don't expect that this hangs the game for everyone. To prevent multiplayer games commonly hanging, perhaps there could be a new API to request that a page can keep running at full capacity even in the background, such as window.requestBackgroundProcessing(). This could show a permission prompt like 'Do you want to allow this page to run in the background? Allow / Deny' to help protect against abuse. Hi Ashley, I have some concerns about this as a user of browsers. I strongly prefer that when a tab is not displayed, it's not running down my battery, causing a cooling fan to spin, making my computer sluggish, or otherwise making a nuisance of itself. I also dislike being forced into any dialog, such as Allow/Deny, with the system. I also strongly prefer not to be a part of the browser's or operating system's CPU/RAM/power/bandwidth-arbitration loop, however, I will accept granting or adjusting a share of some resource to some tab if the trade-offs are fairly clear. For example, I'm happy to let a tab draw down the battery a little faster or to run the CPU a little hotter in order for it to have more up-to-date information (most current weather report, for example) when I revisit it: more energy in exchange for lower average latency in the display. If I grant a program a share of a resource, I would like to be able to claw that share back at a later time. I think that if I was going to make engineering suggestions, they would be for the browser makers, not for you, Ashley. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 3:29 PM, Ashley Gullen ash...@scirra.com wrote: There's a lot of worker features that aren't widely supported yet, like rendering to canvas with WebGL and 2D, Web Audio support, inputs, various APIs like speech and fullscreen, so I don't think that's practical right now. I guess that's not a reason to standardise a new feature, but is there not at least a workaround for the mean time? Are workers able to wake the UI with postMessage()? You were talking about running the server of a multiplayer game. Other than communicating with other clients, it doesn't need any of that, right? Those are all client-side behaviors. You can send a message to the UI thread. I didn't suggest that, since it feels like an arms race of trying to sidestep browser behavior. It may not matter, since the common things they're trying to stop are probably things like never-ending animation timers running when you can't even see it (who have no reason to drive their timers from a worker to bypass the timer throttling), but I'd recommend trying to move your actual server logic into a worker. -- Glenn Maynard
Re: [whatwg] Proposal: requestBackgroundProcessing()
Since it's a peer-to-peer engine, the user acting as the server is also a participant in the game. This means the server is also running the full game experience with rendering and audio. The game logic is tied to rAF, since we intend to step the world once per screen draw, including for the player acting as a server. It looks like the server is caught between running in the UI thread and hanging when in the background, or running in the worker and not having a straightforward way to provide the rendering and audio game experience for the host player. One solution is to make web workers able to access many of the same APIs the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then it might be practical to move a full game engine in to a worker. If that is planned, I guess there is no need for a new feature. Ashley On 20 February 2014 21:55, Glenn Maynard gl...@zewt.org wrote: On Thu, Feb 20, 2014 at 3:29 PM, Ashley Gullen ash...@scirra.com wrote: There's a lot of worker features that aren't widely supported yet, like rendering to canvas with WebGL and 2D, Web Audio support, inputs, various APIs like speech and fullscreen, so I don't think that's practical right now. I guess that's not a reason to standardise a new feature, but is there not at least a workaround for the mean time? Are workers able to wake the UI with postMessage()? You were talking about running the server of a multiplayer game. Other than communicating with other clients, it doesn't need any of that, right? Those are all client-side behaviors. You can send a message to the UI thread. I didn't suggest that, since it feels like an arms race of trying to sidestep browser behavior. It may not matter, since the common things they're trying to stop are probably things like never-ending animation timers running when you can't even see it (who have no reason to drive their timers from a worker to bypass the timer throttling), but I'd recommend trying to move your actual server logic into a worker. -- Glenn Maynard
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, Feb 20, 2014 at 4:32 PM, Ashley Gullen ash...@scirra.com wrote: Since it's a peer-to-peer engine, the user acting as the server is also a participant in the game. This means the server is also running the full game experience with rendering and audio. The user is a client, and also a server for all clients (including itself). There should be no need for the client to run in the same environment as the server. The user's client is just another client to the server (that happens to be running in a worker in the same browser). The game logic is tied to rAF, since we intend to step the world once per screen draw, including for the player acting as a server. That doesn't make sense. requestAnimationFrame is bound to the refresh rate of the user's monitor, and each user can have a monitor with a different refresh rate. (You can even have different monitors on the same system with different refresh rates, though I don't know if that happens in practice today.) Even if everyone's monitor happens to have the same refresh rate, the monitors won't all be refreshing in sync. You also wouldn't want gameplay behavior to change in subtle ways depending on whether some user's display was at 50Hz or 60Hz or 120Hz. It looks like the server is caught between running in the UI thread and hanging when in the background, or running in the worker and not having a straightforward way to provide the rendering and audio game experience for the host player. The host player just connects to the server, like any other client does. (The actual connection layer is likely to be different, of course, since you can just post messages across and not establish any network connection.) One solution is to make web workers able to access many of the same APIs the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then it might be practical to move a full game engine in to a worker. If that is planned, I guess there is no need for a new feature. Not a full game engine, just the server logic where gameplay state, physics and so on are handled and communicated to clients. -- Glenn Maynard
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Fri, Feb 21, 2014 at 11:32 AM, Ashley Gullen ash...@scirra.com wrote: One solution is to make web workers able to access many of the same APIs the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then it might be practical to move a full game engine in to a worker. If that is planned, I guess there is no need for a new feature. Having (some form of) all these APIs available in a Worker is a long-term goal, but as Glenn just pointed out, it sounds like you could just run the server in a Worker and the rest of the engine on the main thread. Having said that, your server would want WebRTC DataChannels on the worker, and we don't have that yet. You can work around it by proxying messages to the main thread; postMessage from a Worker to the main thread is usually not throttled. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
