- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Thu, 29 Aug 2013 17:29:17 +0200
- To: Gary Kacmarcik (Кошмарчик) <garykac@chromium.org>
- Cc: "Vickers, Mark" <Mark_Vickers@cable.comcast.com>, Arunprasad Rajkumar <ararunprasad@gmail.com>, public-web-and-tv <public-web-and-tv@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
On Wed, Aug 28, 2013 at 4:04 PM, Gary Kacmarcik (Кошмарчик) <garykac@chromium.org> wrote: > The current bug tracking the location values is: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22834 > > In summary, we're not sure that DOM_KEY_LOCATION_MOBILE has value (and it's > certainly not well-defined what devices would count as "mobile"). > And I would agree with it > > > On Wed, Aug 28, 2013 at 2:50 AM, Giuseppe Pascale <giuseppep@opera.com> > wrote: >> >> adding a proper tag >> >> On Wed, Aug 28, 2013 at 11:41 AM, Giuseppe Pascale <giuseppep@opera.com> >> wrote: >> > ** adding the www-dom list ** >> > >> > On Wed, Aug 28, 2013 at 12:08 AM, Vickers, Mark >> > <Mark_Vickers@cable.comcast.com> wrote: >> >> I think a good argument could be made to use DOM_KEY_LOCATION_MOBILE >> >> for keys from remote controls. For one thing, a traditional remote control >> >> device fits the definition: >> >> >> >>> DOM_KEY_LOCATION_MOBILE >> >>> The key activation originated on a mobile device, either on a physical >> >>> keypad or a virtual keyboard. >> >> >> > >> > Personally I wouldn't think about a remote control when reading this >> > text. To me this is clearly intended to indicate smartphones and >> > tablets, where the input may be virtual or physical but on the same >> > screen/device as the browser >> > >> > Maybe people on www-dom can help us clarify this? >> > >> >> Second, in current widespread practice, remote control functionality >> >> comes from both traditional dedicated remote control devices as well as apps >> >> running on phones and tablets. Since they are performing the same function, >> >> treating them the same makes sense. >> >> >> > >> > I'm not convinced. I think there some variations that need to be >> > considered here: if I'm using a mobile phone to control my TV, but the >> > mobile phone is emulating a full keyboard, should location be used as >> > if I was using a physical keyboard? Same for those remote controls >> > that have a full keyboard in the back. >> > >> > All in all, it seems to me that this "location" attribute should be >> > used to indicate the "layout" (keyboard, mobile, RC, Joystick) of the >> > input device rather than if it is a physical device or emulated >> > >> > /g >> > >> > >> >> Thanks, >> >> mav >> >> >> >> On Aug 27, 2013, at 2:43 PM, Giuseppe Pascale <giuseppep@opera.com> >> >> wrote: >> >> >> >>> Hi, >> >>> I don't think there is any TV/STB out there using DOM3 events model, >> >>> although there may be in future. (depends also at what kind of >> >>> enviroment you are looking at, web technologies are used in many >> >>> different ways inside TVs and STBs) >> >>> >> >>> About TV specific extensions or in general the value that keylocation >> >>> will take in case of TV implementations I think this is a good point. >> >>> It could be raised with the DOM group but is also a question for >> >>> implementers and also for TV groups (like DLNA or HbbTV) that could >> >>> influence that by mandating a special value in some cases. >> >>> >> >>> I would guess that missing a dedicated value and a reason for doing it >> >>> most implementers will just use "DOM_KEY_LOCATION_STANDARD" >> >>> >> >>> >> >>> >> >>> On Wed, Aug 21, 2013 at 6:59 AM, Arunprasad Rajkumar >> >>> <ararunprasad@gmail.com> wrote: >> >>>> Hello Folks, >> >>>> >> >>>> Is there any way to use KeyboardEvent.keylocation in TV/STB world to >> >>>> differentiate keys originating from Remote Control & Front Panel? >> >>>> >> >>>> Stable DOM 3 Event specification doesn't have any DOM_KEY_LOCATION >> >>>> constants >> >>>> for TV/STB. Is there any plan for adding more constants(relevant to >> >>>> TV) in >> >>>> upcoming specs(may be DOM 4 Events) ? >> >>>> >> >>>> Regards, >> >>>> Arun >> >>> >> >> >> >
Received on Thursday, 29 August 2013 15:30:05 UTC