Re: [whatwg] Proposal: requestBackgroundProcessing()

[Robert O'Callahan]

On Fri, Feb 21, 2014 at 11:32 AM, Ashley Gullen  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.r"t 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

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Glenn Maynard]

On Thu, Feb 20, 2014 at 4:32 PM, Ashley Gullen  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()

[Ashley Gullen]

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  wrote:

> On Thu, Feb 20, 2014 at 3:29 PM, Ashley Gullen  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()

[Glenn Maynard]

On Thu, Feb 20, 2014 at 3:29 PM, Ashley Gullen  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()

[David Young]

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] hit regions: limited set of elements for fallback content

[Nils Dagsson Moskopp]

Dominic Mazzoni  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  wrote:
>
>> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
>> > On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 
>> support that, since that use case is already handled very well by the
>>  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 :

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:


(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 , 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 . 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  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

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Ashley Gullen]

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  wrote:

> On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier  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

[Ian Hickson]

On Thu, 20 Feb 2014, Dominic Mazzoni wrote:
> On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson  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  elements to be hit region controls.
> >  - enable  eements where N>1 to be hit region controls.
> >  - enable  to be hit region controls.
> >  - optionally, if implementors are on board:
> > - make  in  act like size=N where N>1.
> > - enable  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  thing; should we have a special case 
> > in browsers for size=1, or should we require size>1?
> 
> I can't think of a way to make size=1 work, so requiring size>1 may be 
> the only option. It seems ugly, though.

The way we could make it work would be to change the logic in the  
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] MetaExtensions for HTML5 vs. custom tagging

[Michael[tm] Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Christine Smith , 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

[Dominic Mazzoni]

On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson  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  elements to be hit region controls.
>  - enable  eements where N>1 to be hit region controls.
>  - enable  to be hit region controls.
>  - optionally, if implementors are on board:
> - make  in  act like size=N where N>1.
> - enable  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  thing; should we have a special case in
> browsers for size=1, or should we require size>1?
>

I can't think of a way to make size=1 work, so requiring size>1 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] Proposal: requestBackgroundProcessing()

[Maciej Stachowiak]

> On Feb 20, 2014, at 9:01 AM, Boris Zbarsky  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] Proposal: requestBackgroundProcessing()

[Glenn Maynard]

On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier  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

[Ian Hickson]

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  where n>1, and for . It's a bit weird to require that we explicitly give the size 
for a fallback , so maybe we should instead just say that any 
 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  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. . 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  were also allowed elsewhere before and are disallowed 
everywhere now), but there's lots of _attributes_ on , , etc, 
that we've made non-conforming for the same reason:

  
  
  
  
  
  
  
  

...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. , for example, simply cannot be sanely implemented in canvas, 
because we don't provide the right hooks. Similarly for , 
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 
> >  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  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 , 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 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 d

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Rik Cabanier]

On Thu, Feb 20, 2014 at 10:32 AM, Glenn Maynard  wrote:

> On Thu, Feb 20, 2014 at 12:02 PM, Ashley Gullen  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] Proposal: requestBackgroundProcessing()

[Glenn Maynard]

On Thu, Feb 20, 2014 at 12:02 PM, Ashley Gullen  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.

-- 
Glenn Maynard

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Ashley Gullen]

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  wrote:

> On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen  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()

[James Robinson]

On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen  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] for year input

[Nils Dagsson Moskopp]

Qebui Nehebkau  writes:

> On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp
>  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 2014:
>
> 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  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 >   type=timedelta> (or similar) would be introduced. One can use an
>>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
>>  and , 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  element on a cooking form:
>>
>> temperature 
>> cooking time 
>> beep frequency 
>>
>> 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
>> , ,  and  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  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  and  nowadays, see example:


Weather sites commonly display temperature. I'd probably use temperature
and time myself (more likely if @unit-type could also contain '°C',
'min' and 'h').

-- 
Nils Dagsson Moskopp 

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Boris Zbarsky]

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] Proposal: requestBackgroundProcessing()

[Tab Atkins Jr.]

On Thu, Feb 20, 2014 at 8:23 AM, Ashley Gullen  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()

[Ashley Gullen]

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.  wrote:

> On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen  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()

[Tab Atkins Jr.]

On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen  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

[whatwg] Proposal: requestBackgroundProcessing()

[Ashley Gullen]

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] for year input

[Jonathan Watt]

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,


  - 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

Re: [whatwg] hit regions: limited set of elements for fallback content

[Dominic Mazzoni]

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  wrote:

> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> > On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 
> support that, since that use case is already handled very well by the
>  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  elements for
> layout purposes, but this is expressively against the  conformance
> requirements. People use  for indenting, but instead of
> providing a  attribute, we improve CSS to support
> indenting. And so on.
>

Even though you're not supposed to use  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  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  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 , 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 . It's hard to tell without
> knowing precisely what you want to do.
>

Is my pie chart example good? We can keep brains