Re: Updated Presentation API WebIDL - call for review

Hi Louay, Mark, Dominik, All,

On 21 Mar 2014, at 18:24, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de> wrote:

> The File picker dialog on iPads will be displayed in the place where you touch the screen (inside the input element boundaries) --> See screenshots.

Thanks for the screenshots. I don’t have an iPad at hand so I wasn’t aware of this. Personally I think what iPad does makes sense from the usability point of view.

AFAIK, implementations should be able to display the screen picker dialog in the context of the element (not just HTMLInputElement) that triggered the requestSession() operation without any extra information if they wish.

Dominik - perhaps you could elaborate a bit on how that could be implemented? Or correct me if I’m wrong here.

> In my point of view, I don't think it is a good idea to touch the HTML stuff otherwise we need to speak with HTML Group and then we will lost the focus on our original work.

Agreed about the focus. In my opinion, We should not try to avoid liaise with other groups if that would be the right thing to do from the technical point of view. Often we can also cleanly extend or reuse the HTML without added inertia. That is true if we make use of the explicit extension points and do not (monkey)patch the base spec. For example, we’ve defined some extensions specifically to the HTMLInputElement [1] in the past without much extra effort (spec now at CR, implemented in Blink/Chromium and WebKit, shipping in e.g. Chrome for Android).

> One possible option from my side (if we agree that the location of the screen piker dialog is important for better user experience)  is to add optional input parameter for  requestSession indicating the preferred position of the dialog. Browsers may ignore this parameter. 

We could also use the existing platform primitives for the task. Specifically, each HTML element [2] can have an associated context menu [3] represented by an HTMLMenuElement from which we could trigger the requestSession() operation. I think it could address the requirement discussed herein without the need to specify any new extensions to the HTML. The context menu feature is not widely implemented yet [4], but we could motivate more implementers to add support for the feature if we show more interesting use cases for it. That said, it would be a complement to what we currently have in terms of the API.

MarkW - could you confirm whether the context menu addresses your requirements? See the examples at [3]. On a touch-driven device, the user may use e.g. a long-tap gesture instead of right-click, or whatever is the platform’s convention.

Thanks,

-Anssi

[1] http://www.w3.org/TR/html-media-capture/
[2] http://www.w3.org/html/wg/drafts/html/master/dom.html#elements-in-the-dom
[3] http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#dom-contextmenu
[4] http://caniuse.com/menu

Received on Monday, 24 March 2014 09:23:48 UTC