Intent to Implement and Ship: CSS3 nav-up/down/left/right properties

[Anton Obzhirov]

This intent is based on the intent submitted by Krzysztof Olczyk (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/u2lKAP3EiU4)

 

Contact emails

a.obz...@samsung.com, kol...@opera.com

Spec

CSS3 UI

(http://dev.w3.org/csswg/css-ui/#nav-dir)

Summary

Implementation of CSS3 nav-up/down/left/right properties from CSS3 UI .

User agents for devices with directional navigation keys respond by navigating the focus according to four respective nav-* directional navigation properties (nav-up, nav-right, nav-down, nav-left)

 

Motivation

Regarding implementations / use:

- these properties have been supported in Presto core (Previous Opera layout engine) for quite some time

- these properties are widely used by the TV industry (both devices and apps) as it's an easy way to define D-Pad navigation.

- WebKit-based TV browsers from major TV manufacturers support it

Interoperability and Compatibility Risk

Although these properties are marked as "at risk" in the specification, there are no known issues with their definition, so the "at risk" was only due to lack of known implementations and tests.

Opera has agreed to submit tests to the CSS-WG and the WG has agreed to keep these properties in if tests are submitted .

There are already implementations of these feature in products already in market:

- WebKit-based TV browsers from major TV manufacturers support it

- These properties have been supported in Presto core for quite some time

The similar patch was filed to WebKit  - https://bugs.webkit.org/show_bug.cgi?id=66027

The www-style discussion on the feature: http://lists.w3.org/Archives/Public/www-style/2013Jun/0332.html

 

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=614003

Link to entry on the feature dashboard

No entry created (will create one if it is deemed necessary).

Requesting approval to ship?

Yes

 

BR,

Anton Obzhirov

 

[Ian Kilpatrick]

Hi Anton,

Firstly a few questions:

1) You mention that WebKit based TV browsers support these properties. This isn't implemented in WebKit trunk, specifically which Webkit-TV browsers support these?

2) Without these CSS properties, how do TV-apps currently support these features?

3) What are other vendors opinions on this feature currently? Specifically other vendors in the past said that they may formally object. (I.e. there may be high interop risk) [1]

4) Is there any data on how widely used this feature is currently?

I'm a non-owner, but I'd be against shipping this feature (but would like to know what others think). It seems like this is easily implementable with javascript today (via DOM attributes).

With custom properties and values [2], they could be easily polyfilled using CSS properties as well. [3]

Thanks,

Ian 

[1] https://lists.w3.org/Archives/Public/www-style/2013May/0076.html

[2] https://drafts.css-houdini.org/css-properties-values-api/

[2] https://gist.github.com/bfgeek/dbec129142c926c17dda6742c644302f

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Anton Obzhirov]

Hi Ian,

 

To answer your questions:

1)      Yes, it is not implemented in WebKit trunk however originally a patch (https://bugs.webkit.org/show_bug.cgi?id=66027) was submitted upstream and then applied downstream to various versions of WebKit.

HbbTV specification which is fully supported by Samsung, Sony, Panasonic, Philips, LG and Vestel (and other manufacturers) requires this feature.

 

2)      TV apps can still use spatial navigation or their own version of navigation system designed in JS however most of TV and setup boxes do support CSS3 navigation.

 

3)      I am not aware of any objections from other vendors (especially because they need to support the feature to comply the HbbTV specification). The objections described in [1] centre on nav-index and nav-context, which we do not intend to implement.   

 

4)      Since it is part of HbbTV specification all devices that undergo certification are required to support it. At present HbbTV is deployed in at least 15 countries [2] but many other countries are actively seeking to introduce services.

 

In terms of implementation - there is already CL for this feature

https://codereview.chromium.org/1919813002/.

It is based on rebased patch submitted by Opera few years ago and it is already implemented  with the tests added.

 

BR, Anton

 

[1] https://lists.w3.org/Archives/Public/www-style/2013May/0076.html

[2] https://www.hbbtv.org/overview/#hbbtv-overview

--

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ian Kilpatrick]

Hi Anton,

Thanks for taking the time to reply, it always helps having more insight.

Other vendors - It would be helpful reaching out to other vendors explicitly and asking their opinion on this feature, without this there is no way of judging the interop risk.

Usage data - It would be helpful to have actual usage metrics of this feature on real world devices.

That being said (again as a non-owner) I don't believe we should implement this feature, and it should be kept on vendor specific branches.

I don't believe we add features to blink which we don't intend on shipping to the wider web platform.

1) This feature is at the wrong level of the platform. CSS currently doesn't have any other mechanism for controlling focus, or user navigation. This should have been specified as a html attribute at the very least (but probably as a wider a11y effort).

2) The feature is currently ambiguous, and unclear how it interacts with other web APIs; for example the it allows focus on elements which are "not otherwise focusable". As a result of this, is a focus event fired? Does the tabindex attribute of the element change?

I understand that this was implemented by tv-browsers and required as part of a certification body, however it doesn't seem like we should ship this to the wider web platform.

Thanks,

Ian

--

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

The use case here (enabling customization of spatial navigation behavior) does seem valuable to me, though I share others concerns about the specific API as currently defined.  Eg. even nav-left/right/up/down have some of the composition issues James Craig mentioned in his thread.  For example, how is an element of one reusable UI widget (eg. a web component) supposed to describe how focus should shift from it to other such widgets on the page?  It seems like you need global knowledge of the page structure to describe the navigation relationships using this API.

I did a quick httparchive search (essentially a CSS grep of top 500k websites) to try to gauge usage.  I had to refine my query as most of my hits were for elements with ID's like 'nav-left', or were for general initialization rules that explicitly set the properties to 'auto'.  Ultimately this regex seemed pretty good: "[ ;\t]nav-(up|down|left|right)\s*:\s*[^a]".  This came up with 11 hits.  I.e. basically these CSS properties don't seem to be used much at all in the top sites when serving to a normal Chrome browser (although they could be added by JS, or otherwise delivered dynamically based on the UserAgent).  Absent more compelling data, this suggests to me that it's more important to get the API right than to ship what's already been specified.

Anton, any idea if there is appetite for evolving the API to address the concerns?  Eg. this use case seems like a great candidate to be incubated via a lightweight process in the WICG in conjunction with an experimental implementation.

--

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Takayoshi Kochi]

Hi Anton,

This is a question in general about the spec itself, not for your intent to implement,

but the feature seems to be in the area of DOM (or maybe accessibility), not CSS.

(in the past, "ime-mode" was defined in CSS UI but was dropped due to low

implementation interest (although IE implemented) and (non-)fitness in CSS,

among various reasons)

--

Takayoshi Kochi

[Anton Obzhirov]

Hi Rick,

 

Thanks for the search – but I guess your search didn’t include TV broadcast applications which far more likely to use these properties.

I had a chat internally – we would need some time to understand what we can do from our side

but in principle yes, we would like to work on improving the API further if needed.

 

Just a side note:

There was another discussion after the one I mentioned before:

http://lists.w3.org/Archives/Public/www-style/2013Jul/0090.html

in which it was decided to leave directional nav-* properties at risk in level 3.

 

The CSS UI tests have been submitted (by Opera) and partially approved:

http://test.csswg.org/shepherd/search/spec/css-ui-3/name/nav/load/t83/#t16

[Rick Byers]

A few of us chatted about this at BlinkOn.  If I recall the general conclusions were:

1) The TV broadcast platform is a fork of the web, and it is explicitly a non-goal of the blink/chromium projects to support platforms which are web-like but not actually the web (of which there are many).  Any code landed in blink for non-web platforms is likely to suffer from poor understanding, maintenance, etc.  So web forks wishing to leverage blink should do so via a fork of blink, not by landing code in blink upstream.

2) That said, we're happy to talk about how forks can be best maintained and whether/how our code architecture can be improved to help reduce the cost of maintaining a fork for some features.  In this case we wonder if it might be possible to leverage some of the C++ hooks for custom properties (or other Houdini / layering work) to build this feature in a way that minimizes the intrusiveness into blink core.  ikilpatrick@ is probably the Houdini expert to talk to.

3) This use case of reliably supporting directional navigation does seem worth solving for the web, but the existing nav-up/down/left/right properties have some issues that should be hammered out before talk of shipping, eg:

• Why CSS properties instead of HTML attributes (like tabindex)?  What would it mean to set "nav-left" on a div or class?
• How does the feature interact with the existing definition of focus and what is or isn't focusable
• How can the feature be made to be composable.  Eg. in a world of custom elements and frameworks like polymer, how can you reason about spatial navigation without having global knowledge of the whole page?  Eg. could we instead make the properties define local spatial navigation (eg. between components) while allowing components to define navigation behavior inside of themselves?

Since there's virtually no usage of these APIs on "the Web" today, we should be willing to overhaul the design however necessary to resolve concerns.  One good way to get started would be to create a GitHub repo with a simple explainer describing the problem and what a solution might look like (similar to what we did for IntersectionObserver and EventListenerOptions).  Then we can loop the right people from various browser vendors in on specific GitHub issues to discuss the details and try to converge on a prototype design, in parallel with landing an experimental implementation in blink.  We should also try to engage the TV broadcast folks to get their feedback on the design to ensure it also meets their needs (hopefully eventually eliminating the need to fork the platform for this feature at least).  

I hope this helps!

   Rick