- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Wed, 2 Jul 2014 07:56:33 +0000
- To: Daniel Davis <ddavis@w3.org>
- CC: "mark a. foltz" <mfoltz@google.com>, Mark Watson <watsonm@netflix.com>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Mark Scott <markdavidscott@google.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, Bob Lund <B.Lund@cablelabs.com>, "Philipp Hoschka" <ph@w3.org>
On 02 Jul 2014, at 10:26, Daniel Davis <ddavis@w3.org> wrote: > There are arguments for showing the icon permanently to avoid confusion, > similar to a wifi icon which remains visible but may change state/colour > when no networks are available. Agreed. That said, how the UI will look like and behave is an implementation detail, and we must be careful to not try to enforce a specific UI design in the API spec. Rather, we must enable different UIs with the API, so that UA implementers and web developers can innovate on the UIs. For example, I think we all agree the API must be async and non-blocking, instead of something like window.prompt() which would greatly limit the UI options. In some cases the UA may want to show an availability icon (similarly to how the OS handles the WiFi icon), while also the web content may want to change its appearance in response to the availability hint. Both have good use cases and benefit from further exploration, experimental implementations, to figure out what works the best. Thanks, -Anssi
Received on Wednesday, 2 July 2014 07:57:07 UTC