- From: <bugzilla@jessica.w3.org>
- Date: Mon, 24 Mar 2014 03:24:08 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24860 --- Comment #13 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> --- (In reply to Jon Piesing (HbbTV) from comment #12) > I think the specification would benefit from a link from the language on > "honor user preferences for automatic text track selection" to the text > mentioned in comment 9 from Opera. These are two completely different and orthogonal topics. "honor user preferences for automatic text track selection" is generally applicable, independent of there being a @controls attribute or not, just like almost everything else that relates to a media element. > Note: User agents may provide controls to enable users to affect playback of > text tracks at times other than when the user agent is required to honor > user preferences for automatic text track selection. See > http://www.w3.org/TR/html51/embedded-content-0.html#user-interface That note makes no sense. The UA is always required to honor user preferences for automatic text track selection. "honor user preferences for automatic text track selection" is merely an algorithm that is called either after a media element has been created, or when a text track has been added - that's what the "required" in that paragraph refers to. The user agent is able to provide controls at any time, but is particularly encouraged to do so when scripting is disabled or when @controls is present. I believe you have a misunderstanding of what the word "controls" in this context means. The "controls" that we're talking about here are the visually represented playback and navigation controls - the actual buttons and sliders. In contrast, a remote control is not such a "control". From the browser's viewpoint, a remote control is merely an input device that provides events that the browser reacts to. If you have the keyboard focus on the video element and you interact with the video element via a remote control, the browser will receive the keypresses as keyboard events with keyCodes for the pressed buttons. See e.g. http://dev.opera.com/articles/view/functional-key-handling-in-opera-tv-store-applications/ , http://samsungdforum.com/Guide/art00046/index.html , http://stackoverflow.com/questions/12421379/samsung-smart-tv-app-brightcove-sample-app-remote-control-issue/. I think, we might be able to make two changes that I hope will address your issues: 1. We could explicitly mention something about captions in the paragraph that Simon cited, e.g.: "Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, caption track activation/deactivation and volume controls), but such features... 2. We could explicitly mention the possible use of remote controls as input devices in the "User interface" section, e.g. in the same paragraph: "..should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu or via a TV remote control." Would that be satisfactory? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 24 March 2014 03:24:12 UTC