- From: <bugzilla@jessica.w3.org>
- Date: Mon, 10 Mar 2014 06:52:22 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24860 --- Comment #7 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> --- (In reply to Jon Piesing (HbbTV) from comment #6) > >> If it's a reference to the controls attribute then that has numerous issues > >> in a TV environment. TV apps generally do not include the controls attribute > >> to avoid those issues and the subtitle key would need to work when that > >> attribute is not present. > > >To avoid what issues? > > TV app developers (almost?) always provide their own controls for several > reasons; > a) they get to control the visual appearance (if any) so it fits with the > rest of their UI So you overrule the adaptation that Web developers have already made to make sure that their controls fit visually with the rest of the Web page? Are we talking about Web pages or native TV applications here? > b) they can ensure that the app has control over the VCR-style features, > pause/resume, fast-forwards/fast-reverse, jump forwards/backwards. This is > particularly critical for broadcasters funded by advertising. All UA provided controls provide thee features. > >I don't understand. How can you have UA provided controls when you > > disallow the @controls attribute? > > That depends on what functionality provided by the UA would be disabled when > the controls attribute is absent. None. The @controls attribute does not disable or enable any features. It only exposes some features visually with buttons and sliders to the user that otherwise are only available to script. > >Also, if you disallow the browser from creating controls, but then provide > >your own on top, then it's up to you to expose such a user interface and > > take care of the providing the features that the @controls attribute > > would provide. > > I agree 100% but an app has to make assumptions about what features the > @controls attribute would provide in order to take care of providing those > features. What I don't understand is what an "app developer" is in this environment. To me, an "app developer" is the person who wrote the Web page and the layout and the graphical design in HTML, CSS and Javascript and has made sure that all the functionality is there that is required to interact with the Web page. If they decide to use @control, then the UA gets to render the controls. If they decide to do it themselves, the don't use @control. Is that the same "app developer" you are talking about? > TV apps would normally handle the remote control keys for > pause/resume/ff/frew/jump (etc) themselves. > > They may do this without rendering any visible UI though. That's perfectly fine. A remote control is just a different input device to a keyboard. It will still create key events: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#constructor-keyboardevent There is a whole section on media keys in that spec: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#key-media -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 10 March 2014 06:52:23 UTC