On 06/07/2015 03:22 , Mike Connor wrote:
Does it need to be an API, or would dispatching an event be sufficient?
Something like "busy" and "idle" events would be easy to send from JS, and
UAs would be free to honour or ignore based on context.
On the face of it it's certainly useful: writing your own busy indicator
is one of the first things you get to do when producing a Web
application. If we can get this built-in, it's a win.
I'm slightly worried about the possibility of actually getting it right,
though. It's not uncommon for Web app above a certain level of
complexity to be doing more than one thing at once. If I'm conducting
two operations, and have therefore dispatched two "busy" events (or
whatever API equivalent) I would probably expect there to have to be two
"idle" events before the UI state returns to idle (i.e. there's a busy
counter).
This could possibly seem acceptable, but what happens when the app
transitions to a different internal page? Today wiping the DOM is enough
to remove the spinners, so no one bothers maintaining state for this,
but with the API you'd have to. History.pushState() could wipe the busy
flag, but that might be the wrong thing to do if a busy part of your UI
stays there.
Also: what does the busy indicator do in fullscreen?
I'm not trying to shoot this down, just pointing at potential pitfalls
to avoid adding a feature that will just largely get ignored except
perhaps in the simplest cases.
--
Robin Berjon - http://berjon.com/ - @robinberjon
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
