Re: Updated Presentation API WebIDL - call for review

I have some concerns about giving the site control over the positioning of
the screen selection dialog.  Allowing content to manipulate dialogs
managed by the UA leads to a number of unfortunate corner cases and
consequences:

- The user begin to expect that the dialog will appear within the page
viewport, which then gives the page an opportunity to spoof it.  Not the
greatest concern (as a spoofed screen selection dialog would not be able to
do much) but I prefer not training users to confuse UA dialogs with page
elements when more is at stake (permission requests, security warnings).

- The <button type="screens"> element could be hidden, located offscreen,
or near a screen border, the UA would have to handle all these cases.

- Constraints for mobile (small screen, touch friendly) mean that placement
and UX for the dialog is highly constrained and the position of the <button
type"screens"> element would likely be ignored.  Consistent treatment of
the dialog (always handled by the UA) for desktop and mobile would make
behavior predicable for developers and users.

Regarding the context menu proposal, I have some concerns from a
discoverability point of view - how would a user know which elements
supported the requestSession context menu item?

Also context menus (as they are typically implemented on desktop) are not
the most touch- or mobile-friendly.  Perhaps there are some additional
mocks in the HTML 5.1 draft that show a touch friendly version.

m.


On Mon, Mar 24, 2014 at 2:22 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

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



-- 
http://wiki/Main/OnlyCheckEmailTwiceADay