MiniApps for TV

[QingAn]

For MiniApps running on mobile phone, user interaction depends on the touch screen. But for MiniApps running on TV, user interaction switches to TV remote panel keyboard + TV screen focus. This brings new standardized API requirements for TV MiniApps.

1. The current keyboard APIs and events are specific for PC keyboard, not for TV remote panel keyboard. We need to consider how to define TV remote panel keyboard event.
2. For TV screen focus, in order to obtain the focus, do we need to define a new label like <tv-view>? or to extend the existing <view>'s attributes?
3. Spatial navigation (Note: W3C has some discussion previously, but seems no further progress, https://github.com/WICG/spatial-navigation/wiki/Meeting-minutes)

[xfq]

Just FYI:

• UI Events KeyboardEvent key Values and UI Events KeyboardEvent code Values include TV-related keyboard events.
• Spatial navigation is in CSS now (see spec and issues)

We should probably listen to what MEIG think of our use cases & requirements.

[xfq]

Related work:

• WoT use case (related to #157)
• TV Control API (discontinued)

Related discussions:

• https://www.w3.org/2021/02/25-miniapp-minutes.html#t02
• https://www.w3.org/2021/03/25-miniapp-minutes.html#t03
• https://www.w3.org/2021/11/02-me-minutes.html

[QingAn]

MiniApps for TV, there is a standardization requirement to define a label to track the focus on TV, maybe like <focusable-view>.

For the event key values and code values related to the such label, it makes sense to reuse the existing W3C specs:

• UI Events KeyboardEvent key Values and UI Events KeyboardEvent code Values include TV-related keyboard events.

For the spatial navigation for MiniApps for TV, we think the current W3C spec cannot simply apply here.

• Spatial navigation is in CSS now (see spec and issues)

The current spec adds three new attributes for TV focus, but it is a one-dimension focus track, which is based on the tab / tab+shift on PC keyboard. But for TV case, there is no tab button on TV remote, instead the left/right/up/down button on remote is used to control focus on TV, which is a two-dimension focus track. Therefore, we need to consider extend the current W3C spec to support the requirements.

Look forward to further comment.

[hax]

What is <focusable-view> semantic? Normally only interactive controls could have focus.

[hax]

The current spec adds three new attributes for TV focus, but it is a one-dimension focus track

As i understand, current CSS-nav draft already support two-dimension (up/down/left/right) nav.

[zhuyingda]

The current spec adds three new attributes for TV focus, but it is a one-dimension focus track

As i understand, current CSS-nav draft already support two-dimension (up/down/left/right) nav.

Hi, where is this "current CSS-nav" you have mentioned? Could you give me a url link?

[zhuyingda]

The current spec adds three new attributes for TV focus, but it is a one-dimension focus track

As i understand, current CSS-nav draft already support two-dimension (up/down/left/right) nav.

As far as I know, current CSS-nav draft is one-dimension (tab / shift+tab) nav, not (up/down/left/right).

[xfq]

The current spec adds three new attributes for TV focus, but it is a one-dimension focus track

As i understand, current CSS-nav draft already support two-dimension (up/down/left/right) nav.

As far as I know, current CSS-nav draft is one-dimension (tab / shift+tab) nav, not (up/down/left/right).

I don't think so. According to my understanding, css-nav is designed to do be used in non linear layouts (e.g., a grid), because sequential navigation (Tab) doesn’t work well there (the user needs to press Tab many times to reach the desired element).

When spatial navigation is active, pressing an arrow key will either move the focus from its current location to a new focusable item in the direction requested, or scroll if there is no appropriate item.

[zhuyingda]

The current spec adds three new attributes for TV focus, but it is a one-dimension focus track

As i understand, current CSS-nav draft already support two-dimension (up/down/left/right) nav.

As far as I know, current CSS-nav draft is one-dimension (tab / shift+tab) nav, not (up/down/left/right).

I don't think so. According to my understanding, css-nav is designed to do be used in non linear layouts (e.g., a grid), because sequential navigation (Tab) doesn’t work well there (the user needs to press Tab many times to reach the desired element).

When spatial navigation is active, pressing an arrow key will either move the focus from its current location to a new focusable item in the direction requested, or scroll if there is no appropriate item.

Hi, thanks for your reply :) css-nav does match the requirements of us (spatial navigation, pressing an arrow key to move the focus, etc.), but there is 2 reason we think we should add <FocusableView> to our MiniApp DSL features:

1. css-nav draft does not give us a way to decide whether a DOM node should be treated as a focusable element or not in MiniApp environment but not a traditional web browser, we have to define a new MiniApp tag to told MiniApp runtime this;
2. If I want to change the behavior of a spatial-navigation-moving ( for example: move the focus to another target or just stop this direction moving), according to css-nav I have to write javascript code with navbeforefocus event. This is a bad runtime performance in many IoT devices, because of the long render pipeline (ui-thread to js-thread). <focusable-view> is a better choice because it give us xml-attribute-api to do this with a shorter render pipeline, that is more friendly to render engine implementation.

[hax]

css-nav draft does not give us a way to decide whether a DOM node should be treated as a focusable element

I think this is a undecided issue in css-nav (see https://github.com/w3c/csswg-drafts/issues/3377).

Currently there are two workarounds:

1. using HTML tabindex attribute. Obviously it's not perfect, but in many aspect, <FocusableView> may have the similar issues.
2. using some vendor css property, like https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-user-focus , maybe we could temporarily invent -miniapp-user-focus.

[zhuyingda]

using HTML tabindex attribute. Obviously it's not perfect, but in many aspect, <FocusableView> may have the similar issues

In semantical, <focusable-view> is just a new tag for non-linear focus, but tabindex is for traditional linear focus(tab / shift + tab). We did not find any feature except tabindex to do this, so we created it... Maybe there is a better way to do this, it is also a reason which we want to talk about <focusable-view> here but not just implement it in our DSL. What do you think of the issues about <focusable-view> similar with tabindex?

using some vendor css property, like https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-user-focus

This is not standard css feature. In MiniApp DSL, we just accept standard css feature without any private feature in some specific browser.

Also, how do you think of this?

If I want to change the behavior of a spatial-navigation-moving ( for example: move the focus to another target or just stop this direction moving), according to css-nav I have to write javascript code with navbeforefocus event. This is a bad runtime performance in many IoT devices, because of the long render pipeline (ui-thread to js-thread). is a better choice because it give us xml-attribute-api to do this with a shorter render pipeline, that is more friendly to render engine implementation.

[hax]

@zhuyingda Maybe I'm misguided by the name "focusable-view", could u give me a link of doc for <focusable-view> so I can figure out the precise usage of it?

[anawhj]

Good to see the interesting discussion here. I and my colleague have proposed css-nav a few years ago, and I assume that <focusable-view> requirement could be supported by the proposed APIs in css-nav. Could someone elaborate the details on <focusable-view> requirement?

[zhuyingda]

@zhuyingda Maybe I'm misguided by the name "focusable-view", could u give me a link of doc for <focusable-view> so I can figure out the precise usage of it?

@hax Hi, sorry for late reply, we are still talk about the precise description docs inside our team. We will share our docs here as soon as we can, thanks.

[zhuyingda]

Good to see the interesting discussion here. I and my colleague have proposed css-nav a few years ago, and I assume that <focusable-view> requirement could be supported by the proposed APIs in css-nav. Could someone elaborate the details on <focusable-view> requirement?

Hi, thanks for your sharing proposal, this draft url I have ever seen before in this issue discussion above :)

[chrisn]

Thank you @QingAn for introducing MiniApps to the Media & Entertainment Interest group (minutes). We have a tracking issue at https://github.com/w3c/media-and-entertainment/issues/75.

As @anawhj mentioned during the meeting, if possible it would be good to align with the proposed CSS Spatial Navigation spec. We could hold another call sometime to follow up on the details.