[cssom-view][css-overflow] Missing terminology

[frivoal]

In https://wicg.github.io/spatial-navigation, I've found myself wanting to refer to a scroll-able thing that isn't already scrolled to the maximum. (and in my case, I only cared about manually scrollable things, not things that can be scolled only by script, like overflow:hidden)

For now, I've rolled my own definition (see below), but this should be in a css spec somewhere. Maybe this is CSSOM-View. Maybe there should be a new CSS spec that deals with the general processing model for scrolling, to which various bits of CSSOM-View and CSS-scrollsnap could refer to (and/or be moved to).

An element e can be manually scrolled in a given direction d if:

• The principal box established by e is a scroll container, and
• if d is up or down, the computed value of the 'overflow-y' property is not ''overflow/hidden'', and
• if d is left or right, the computed value of the 'overflow-x' property is not ''overflow/hidden'', and
• e is not at the scroll boundary in the direction d
• e is not snapped to the last ''mandatory'' snap point in direction d

[anawhj]

It seems to describe the state whether an element e can be scrolled or not. I wonder what terminology we could define to catch the state of an element in the CSS context. Using JS, we could simply get the state of an element to check that the element can be scrolled or not through some manual operation. If we can define the state in CSS, which use cases we could use the information for?

[css-meeting-bot]

The Working Group just discussed Status Update on work in WICG & Demo.

The full IRC log of that discussion

<dael> Topic: Status Update on work in WICG & Demo
<dael> Demo link: https://wicg.github.io/spatial-navigation/demo/blog/
<dael> Spec Link: https://wicg.github.io/spatial-navigation/
<dael> jihye: spacial navigation is ability to nav between focusable elements.
<dael> jihye: florian and I introduced this last year. Most browsers have not histocially offered these features. Some browsers have allowed it using arrow keys. No browser now provides it by default. Some web apps provide using JS libraries.
<dael> jihye: We thought to spec basic behavior and provide some overriding APIs of the default behavior.
<dael> jihye: [shows spec]
<dael> jihye: florian and I wrote the ED. It includes processing model which is basic browser behavior. We're writing overriding APIs and the CSS property.
<dael> jihye: I also made a polyfill based on the spec. It's not complete, but supports main behavior
<dael> florian: This is mostly not a CSS spec right now. From a CSS sense it's as if everything was auto. We need to say what happens when a user tries to do things when everything is auto and then we have some JS for chaning auto.
<dael> florian: We started with CSS properties but with limited data on what authors and users want we thought it was better to get the basic APIs and then add additional CSS properties based on what people do with JS. This works without JS, but the JS overrides. The questions we have later is things the depend on layouts.
<dael> jihye: [shows demo]
<dael> jihye: In the page there are several focusable elements and you can nav using arrow keys. You can do with tab, but you have to press more times. Web apps using inline layout spacial nav is very useful.
<dael> jihye: [shows a page with many examples of layout]
<dael> jihye: There's many corner cases, including hover cases.
<dael> florian: One of this thing we're interested in seeing is the long standing questions about re-ordered sequential navigation and we think they want spacial navigation. We're interested to see if people still want the re-ordered sequential after we've done this.
<dael> tantek: There's always been an a11y desire to make sequential work without a spacial view.
<dael> florian: This is a side note.
<dael> Rossen: We've been impl and shipping spacial nav on Xbox with Edge for a few releases. WE've precieved it as a general UI nav and for that reason we're allowing a generic UI for a11y and anything, including XBox controller or input based on connect motion or verbal commands is just working. WE don't have to deal with all modes of input and user input, that's tempered by a11y interface.
<dael> Rossen: Also, from what tantek said, I've been in the APA WG and that's been their top gripe aboutflexbox and grid and everything else. I'm very interested in anything we'll do to help those efforts. If we're not solving this for a11y as well I think we're missing out.
<tantek> agreed with Rossen
<dael> florian: We have an open issue saying if you have use cases not solved by spacial nav for reordered sequential please tell us. We haven't heard, but maybe don't have the right eyes. I don't think there's anything incompat, but I've heard conflicting requests for the seqential and some of them may be solved.
<dael> tantek: It's better to look through minutes for a11y meeting
<dael> florian: There's multiple people saying conflicting things.
<fantasai> s/There/I did. There/
<dael> florian: But that's not what we wanted to talk about today.
<tantek> s/a11y meeting/joint CSS WG and a11y meeting at TPAC 2017
<dael> florian: For issues, one thing that became apperent is stat nav isn't easy. If the first focused button is several pages down you want to scroll until you get to it. When we tried to spec in relation to scroll we found it difficult to define in terms of CSS. There's some in overflow, some in scroll snap points, some in CSSOM view which defines API. These bits are not well integrated. The more proceedural approach in CSSOM view doesn't talk about snap points.
<jihye> https://github.com//issues/2322
<fantasai> s/conflicting things/conflicting things. I suspect that some of these conflicts would go away once we have spatnav/
<dael> florian: We have two issue son the agenda. #2322 and #2323
<jihye> https://github.com//issues/2323
<myles> A+
<dael> florian: IT's the desire for a scrolling spec to exist. #2322 we found a need to refer to a thing that can be scrolled.
<myles> q+
<dael> github: https://github.com//issues/2322
<dael> fantasai: Do you want something that can be scrolled by the user
<Rossen> q?
<dael> florian: Yes and that can be manually scrolled. It's not already scrolled all the way in. If it's all the way down it cannot. If it's the last mandatory scroll point you cannot. If a use wants to scroll in this direction, could they? We found a need to try and talk to that. You can describe this, but there's no single term.
<dael> fantasai: What do you want the WG to do?
<dael> florian: These two issues call for a scrolling spec that folds all the things in so that we don't have to talk about proerties from many specs when talking about scrolling. What's the WG stategy to make scrolling easy to refer to.
<dael> fantasai: Termonology in Overfow makes sense if it's general. If it's API-based it should be in there.
<dael> florian: This is anchoring termonology.
<dael> fantasai: CSS Overflow
<dael> florian: We needed a thing that can be manually scrolled in another direction and the other is scroll directionally by a UA defined amount taking into account all the other properties.
<dael> fremy: Scroll a single user?
<dael> florian: If you pressed the down arrow, find an anchoring term
<dael> fantasai: Scroll in intended direction.
<fantasai> https://www.w3.org/TR/css-scroll-snap-1/#scroll-types
<dael> florian: There's the classification of things in Scroll Snap.
<dael> fantasai: We can move that section to Overflow.
<dael> Rossen: I think what fantasai said is CSS Overflow is where termonology should be. If it's not there point it out. In terms of additional features that live on those termonologies, we shouldn't have base definitions in snap points
<dael> florian: So propose terms to Overflow with notes to spec how they effect that term
<dael> majidvp: Overscroll introduces scroll boundary and that's something you alluded that you needed so it makes sense to refactor.
<dael> florian: I'll propose the relevent edits.
<dael> Rossen: For issue #2322 do you need anything for the group?
<dael> florian: No, I need to propose.
<Rossen> q?
<Rossen> ack myles
<dael> myles: I wanted to ask for clarifcation on the xbox. Were you talking about logicial vs visual ordering or talking about making the API work for a11y
<dael> Rossen: Mine was about that we've been asked many times to help a11y WG by defining how the flexbox reordering, or grid, plays nicely with a11y. a11y for all the providors today is still tree based and based on content order. If you reorder using flex order or you target visually different grid cells you are disconnecting visual order from content order.
<dael> Rossen: This has been the #1 issue the a11y WG has been asking us to help them solve.
<dael> Rossen: They have also been asking in addition for help with generla spacial nav. Put aside flexbox and grid, if they have a canvas with a bunch of little thing sin side how do the spacially navigate. Like with a map. Then going back to HTML/CSS how do you nav over a document.
<dael> Rossen: I sympathize with the effort. I hoped florian and jihye work would help with both things. I hoped that they wouldn't reinevent the wheel with how it currently works. If this is something that can aid this.
<dael> florian: Clarification. We're trying not to reinvent. Our model is closer to the one that exists in Chrome. It doesn't exist by default, but you can get it in a console command and it's similar to presto. I don't know the type of stat nav.
<dael> iank_: It's similar to presto when it was in opera.
<dael> Rossen: myles does that answer?
<dael> myles: Yes.
<Rossen> q?