- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Jul 2019 18:50:03 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Spatial Navigation
------------------
- RESOLVED: Add spatial-navigation-function to the spec (Issue #3964)
- There was a proposal to separate focus from "interest" in special
navigation. Proposal text:
https://github.com/bokand/bokand.github.io/blob/master/spatnav/spat-nav-on-the-web.md
An example of the difference is if a user is in a search box
their interest would be in suggested results but the focus would
still be on the input.
- Some concern was expressed that these should be separate concepts,
not all grouped together.
- This was built referencing the accessibility tree and does have
useful accessibility functionality, but if this isn't used
widely it's likely that authors won't include it in their page
design.
- There was concern expressed about this working off the main thread
CSSOM View
----------
- Issue #4011 is a proposal to add an event for when overscroll
occurs and potentially to cap the scroll value to 0 and prevent
negative values.
- There is also discussion in a WICG topic over overscroll events:
https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481/16
- Generally there was support for the overscroll event and interest
in checking on web compat for changes to scroll value.
- Discussion will continue on the WICG topic since currently CSSOM
View doesn't cover overscroll at all so it seems premature to
add this proposal
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: heycam
Spatial Navigation
==================
Predefined algorithm for spatial navigation
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3964
jihye: In general, the focus moves to the closest element from the
currently focused element
jihye: and in the spec the algorithm for how to find the closest
element, there is a description about that
jihye: but some authors this kind of algorithm it's not suitable for
them
jihye: depending on their own layouts
jihye: So there is some spatial nav API to help authors customize
this algorithm
jihye: but it's difficult to do this, since they have to interrupt
the processing model of spatial nav
jihye: The processing model means finding the best target
jihye: starting from when the user inputs some information, finding
the best target -- all that process is called "processing
model"
jihye: It's hard to interrupt that in the middle
jihye: so it would be nice to have a new CSS property to provide
another algorithm for spatial navigation
jihye: This will increase flexibility of spatial navigation, and
will help authors to implement it more easily
jihye: I want to propose spatial-navigation-function CSS property,
with two values
jihye: normal, where focus will move to the closest one
jihye: and grid, this will go to the most aligned element from the
currently focused element
jihye: The focus will go to a more obvious spatial navigation
direction
jihye: You can select normal or grid, and see how it works
differently
demo: https://raw.githack.com/WICG/spatial-navigation/develop/demo/calendar/index.html
florian: bikeshedding aside, I'm supportive of having a property to
switch how we calculate the distance, how to pick
florian: I'm wondering if we have the right values in that list
florian: If we think we do, and implementors want to experiment with
this, sure
florian: but there are a number of variants we can think of
florian: The ones proposed seem reasonable, but are they actually a
good match?
florian: The alternative to normal, is that what authors really
want? We're lacking experience
florian: It's difficult to say "70% of people who have trouble with
normal want this grid behavior"
jihye: With grid, I'm communicating with framework team in LG. This
is their main request from them
jihye: Their main implementation is something like TV schedule web
page, or TV content
jihye: Normally those kinds of pages, elements are grouped
horizontally and vertically, so in that case moving the focus
just horizontally or vertically is more important than moving
to the closest one
florian: For that reason, intuitively the grid behavior makes sense
to me
florian: If you have anecdotal evidence that authors want this, this
is an improvement
florian: Not quite as good as stats over many users but it's a start
heycam: Is that sufficient evidence to add it to the spec?
florian: We have some evidence it's wanted, and on the face of it is
reasonable, so sure
bkardell: I would like to reserve comments until after the next
topic, since they're related
Rossen: Any objections to adding this to the spec?
RESOLVED: Add spatial-navigation-function to the spec
Introducing spatial navigation with “interest”
----------------------------------------------
documents: https://docs.google.com/document/d/1-ASYIuPpBm2cFxy_KUagakLGPc1mdF--rC9-EliqYRU
https://github.com/bokand/bokand.github.io/blob/master/spatnav/spat-nav-on-the-web.md
bokan: The main problem this is trying to solve is that today
spatial navigation just moves focus around on a page
bokan: and focus is a preexisting property of pages
bokan: Very often used for very different reasons
bokan: It's not uncommon that pages will completely break when you
do this
bokan: e.g. youtube embeds, as soon as you move focus into them,
they steal keys, now you're scrubbing through the video
bokan: The proposal here was instead of moving focus around the
page, we have another concept I call "interest"
bokan: That's invisible until you enter into an element, then it
will focus it
bokan: This gets to a larger issue -- spatial nav is moving page
level concepts around, and we're often fighting with the page
bokan: So I think the more general point here is that I'd like to
see spatial nav be a higher level concept, and not so tied to
the page
bokan: I think there are 2 problems
bokan: First is general navigation on the web with spatial nav, this
would be e.g. a TV browser or game console browser, browsing
the web
bokan: 2nd issue is when you're trying to build apps for these
devices without mice/keyboards
bokan: For me the spec and API are solving the second issue more
bokan: In the 1st issue you want a non customizable, predictable
spatial nav method
bokan: but in the 2nd you want rich customizable experiences
bokan: Would like to get thoughts on treating these separately
florian: You had two topics
florian: starting with the first one, the interest
florian: Indeed the web as is today both when it comes to native
controls, and author created things, consume key events
florian: if you naively send key arrow events to the page sometimes
they'll get consumed
florian: Today, the spec doesn't say that arrow keys trigger spatial
nav
florian: so you probably can't do that
florian: The spec doesn't advocate for any particular UI to trigger
spatial nav
florian: but I agree that most likely, to be compat with the web,
you need to have something that isn't sending key events to
the page be the thing that controls spatial nav
florian: If you want to do it with arrow keys, you need a mode where
it moves the spatial nav it around, and not in the page it
sends the event to the page
florian: What is not clear to me is when you're in that mode, the
thing that you move around needs to not be the focus
florian: I'm not dismissing it out of hand, but I don't know why it
needs to be a separate thing
florian: The distinction of concepts effectively means that what
you're doing with focus later on is not spatial nav
florian: From the point of view of the focus, the focus would just
be jumping around
florian: the decision of where to move is at another layer
florian: All the pseudos that style the focus ring then wouldn't
apply
bokan: Key events are one example
bokan: focus rings are the next thing
bokan: On a mobile page, chances are it's set to :focus
{outline: none}
bokan: If you're using spatial nav you need to force a focus outline
on
florian: If you're using a Tab key on a device with a mouse that you
can't use, it's the same problem
florian: If the user is using the key based navigation, I'll
override the author styles to put a ring anyway, I think
it's reasonable
bokan: Problem is deeper. The outlines are often overlaid by other
thing. By having the indicator be part of the page, it needs
to be designed knowing that that's how the user will nav
through the page
bokan: overflow:clip on an element e.g. will cause the outline not
to be visible
bokan: I think we're spending a lot of time fighting with pages to
find heuristics that work, but it's whack a mole
florian: I agree it's a problem. Don't know why it's different for
spatial nav to tab nav
bokan: I think it's a problem in both, and we can solve it for both
florian: So the interest movement will also apply for tab nav?
bokan: Ideally this would be outside the rendering engine, outside
the page
bokan: I chatted with Rossen a few months ago, the idea was to use
the accessibility tree and effectively use AT to do this
bokan: If I'm not mistaken, the spec about outline gives a lot of
flexibility, including that you can draw it on top of
everything, for precisely that reason
bokan: May be difficult for other reasons, but there's allowance for
that
bokan: There are ways to fix these individual problems, but it seems
like a long tail of things
bokan: e.g. pages can move focus around programmatically, that could
interfere with nav
florian: But if authors have decided to style the focus outline, and
you're going to have a thing that is not controllable by
things in the page. You're effectively saying we should
never have allowed the authors to customize focus outline
florian: That sounds like what you're proposing to do
AmeliaBR: As an a11y override
florian: If you use that override every time you navigate...
AmeliaBR: I generally like the idea of being able to talk about
moving around the page in a spatial way separate from
focus
AmeliaBR: One thing in the current spec I find confusing is the way,
if you're in a scroll container and you're navigating in a
direction, jumping between focusable items
AmeliaBR: but you have to deal with if you run out of focusable items
AmeliaBR: Now you switch to scrolling instead of focusing, but why
were you jumping before?
AmeliaBR: It gets messy that you're not giving users the option to
just scroll things smoothly with the spatial nav keys
AmeliaBR: and that's one thing that would work if we're talking
about just navigable content in general
AmeliaBR: But there are lots of details and what florian brought up
about recognizing where your focus outlines are is part of
it
AmeliaBR: but if you're not just jumping to focusable items there
are lots of things you might be interested in! Arrowing
through every item on the page might be unusable
AmeliaBR: One other way of thinking of it is that essentially it
becomes like moving a a cursor around the page
AmeliaBR: until you switch into a different mode
AmeliaBR: Whatever's in my current focus interest rectangle,
regional cursor, you can tab into it
AmeliaBR: There are ways to think about different modes of
navigation, agree with florian that we should make
explicit modes so we're not overloading key behaviors
AmeliaBR: but once we have those different modes that don't
necessarily have to be mutually exclusive
<tantek> No this is a misunderstanding about how focusable
navigation and scrolling navigation are integrated in
practice. WebTV literally solved this nearly two decades ago
<tantek> It's not useful to theoretically reason about mixing
focusable navigation and scrolling navigation about what's
possible / pitfalls without referring to existing
implementation experience which has (had) largely solved
this
bkardell: I think the short version is that I'm hugely supportive of
this idea
bkardell: When the topic first came up, I made a comment that I had
concerns in this area
bkardell: We met a number of times in WICG to talk about them, and
how do we move forward without being able to address some
of the problematic things
bkardell: They're not spat nav problems, they're platform focus
problems-
bkardell: currently focus is a mess
bkardell: There's a bug in WHATWG to work through a whole bunch of
those
bkardell: There's something missing. It's not even really just in
spat nav, there are concepts we use focus for that make it
considerably more complex than what florian is presenting
bkardell: Things are not just focusable or not, they may be keyboard
focusable or not
bkardell: It's convoluted already before adding spat nav
bkardell: before we add controlling how focus moves through the page
in CSS
bkardell: This is not the only place we have a want for this in CSS,
I'm hesitant to add more
bkardell: I like this proposal for attempting to tackle some of
this, and it makes a lot of sense, so yes I'm supportive
<tantek> +1 bkardell, focus has many more complexities just on its
own about specific elements, and yes they are platform
focus challenges, a layer below spat nav challenges
jihye: I think we need to make some conditions precise between
switching interest and focus mode
jihye: In your suggestion you said using Esc key e.g., pressing Esc
will blur the focus
jihye: there will be no focus ring in the page then
jihye: If there is an interest element, and if it has an indicator
for that, what will happen if you press Esc?
jihye: I think nothing will happen at that moment
jihye: so that kind of behavior can confuse users
jihye: so I think maybe there will be some different style of
indicator for focus and interest
bokan: There would only be one ring on the page at any time
bokan: If you blur focus, it doesn't necessarily remove the
indicator. It would still be on an input field, but you would
now be free to move around the page
bokan: Not sure if I understand the situation
jihye: For users, an indicator for both focus and interest maybe
would be the same
bokan: There shouldn't even be 2 different indicators, that would be
confusing
bokan: today we implemented our experiment by only drawing [...]
Rossen: There are patterns that are supposed to have a distinction
between focus and interest
Rossen: especially for a11y, consider the address bar
Rossen: When you start typing, there will be search suggestions
Rossen: As a user of a11y, you should be able to start reading the
suggestions, it doesn't mean you're changing your typing
focus
Rossen: Again, the pattern there is that you have a control where
you're typing, and you have an interest where you're reading
Rossen: so I'm very sympathetic to the idea proposed here, it allows
you to create such complex behavior and experience where you
don't constantly have to fight with the focus in the page
Rossen: That's why IMO the interest for dis-joining spatial nav from
focus, and moving things forward, allowing a lot more
freedom to avoid the current existing problems on the web
with focus
Rossen: sounds great
jihye: Focusable elements should be the interest element?
bokan: If you are focused you are interested. Interest doesn't imply
focus
bokan: Today to avoid confusion we blur when the interest moves.
Don't have a strong opinion on that
bokan: I could imagine there could be confusion if you move and
scroll away and now you're typing into something off screen
bokan: I'm willing to change my opinion on that
myles: Trying to understand some pieces
mlyes: Would there be some visual indicator of the interest?
bokan: Yes
myles: And it wouldn't interact with the rendering engine?
bokan: Ideally yes
bokan: not the case in our impl today
bokan: Would have this be rendered outside the rendering engine
myles: Any browser can implement any feature they want outside the
engine
myles: Presumably talking about it in this group because CSS can
tweak the behavior
bokan: I'm a bit concerned about the spec here being applied to the
case of trying to spatially nav around pages that aren't
designed for that
bokan: So I guess my point is that I would like to see that not be a
part of the platform
bokan: Where the spec is useful is if you're designing specifically
for spatial nav, so I would like to separate those two
bokan: I think the reason I brought this up here is that having a
spec with deep hooks into spatial nav here puts a lot of
constraints on what we can do with a general purpose nav tool
bokan: One example is that this would tie us closely to the main
thread
bokan: it would prohibit for example having a spatial nav mode that
is independent of the main thread
bokan: A long running JS task would break the experience
bokan: Ideally you would be able to move around off main thread
bokan: but if implement this spec for all cases it would prohibit
that
AmeliaBR: So something that would run on the scrolling compositing
level?
bokan: Potentially, or another thread
bkardell: Is it what ChromeVox and VoiceOver do?
bokan: That would be my preference
hober: Right
florian: I think we have been slightly talking over each other with
interest
florian: IIUC in your experiment it's a pre-focus thing
florian: Not a general a11y feature
florian: it's restricted to focusable elements
bokan: Yes
bokan: To clarify, the interest would move in the same way as
spatial nav does
bokan: The spec of how navigation moves, the nav steps in the spec,
we want to spec and follow that
bokan: I think the interest as implemented today is a half step
bokan: The greater aspiration would be to continue towards something
like ChromeVoc, where it's outside the platform
Rossen: With the difference that the content layer will be aware of
where the interest is
florian: I think this is where the tension is
florian: If interest is largely pre-focus, and largely the
difference is the page can't control it, this kind of
conflicts with the reasons that we added all these focus
controls to start with
florian: If they're damaging the platform, we should remove them,
but if we're not removing them because they're useful...
florian: That's a weird tension
florian: Rossen just said it would be a different layer
florian: but if the page started controlling it we're back in the
original problems
florian: So this only works if the page can't control it. But then
why do we have the original focus methods?
bokan: Spatial nav is used by a small proportion of people on the
web
bokan: All these APIs, they're useful if enough pages do something
with them
bokan: If a tiny percentage of users want to use them, authors won't
test their pages with them
florian: You could say the same for Tab key navigation
bokan: I haven't thought deeply about that
florian: Another thing, working off the main thread. That I'm
sensitive to
florian: I think there are tweaks to the existing design to make
that easier
florian: Most of the existing processing model currently doesn't
require main thread
florian: One thing that does sync it back to the main thread is that
the way we offer the author the ability to hijack is
through events
florian: and these events tie back to the page's main thread
florian: Would could give an ability to run that off the main thread
bkardell: One clarification, I think that nobody is saying "here is
a fully cooked idea, just accept it"
bkardell: Simultaneously, some of us are saying that focus is
currently sufficiently weird and there are other cases
where we already overload focus and is convoluted
bkardell: We have conflicting advice around focus
bkardell: so there are a number of things to unwind that, and for
spatial nav, I think this is the one we need
bkardell: There are things to improve here
bkardell: but I don't think the answer to remove focus
florian: Not saying this is not a good idea, just that it's a hard
problem
florian: interest bundles in many aspects
florian: we should explore the various aspects of this
florian: and maybe take some but not all
CSSOM View
==========
Overscroll observability
------------------------
github: https://github.com/w3c/csswg-drafts/issues/4011
smfr: The issue here is whether web content should be able to
observe when the user is rubber-banding
smfr: when you reach the scroll extent of the scroll bar, and you
pull down some more
smfr: On Apple platforms we have rubber banding. On Android you get
some overscroll affordance
smfr: On Apple platforms we continue to send scroll events, and
those have negative offsets if you're at the top/left
smfr: or great than max offsets at bottom/right
smfr: We found that this is not very web compatible, a bit of web
content doesn't expect negative offsets
smfr: listening to scroll events, taking those scroll positions as
input to some math
smfr: CodeMirror does this, the line numbers will jiggle around in
weird ways
smfr: So I'm considering making the rubber banding scroll offsets
clamp to 0
smfr: that then implies authors cannot detect when that is happening
smfr: Should there be a different event that gets fired during
overscrolling?
smfr: I saw jonjon linked to a proposal
smfr: I'd like to get feedback from other browser vendors
smfr: Common desire for authors would be to have a pull to refresh
smfr: It's possible I might break that when clamping to 0
<smfr> https://github.com/w3c/csswg-drafts/issues/3801
bokan: We at Chrome are very supportive of this
bokan: an overscroll event?
smfr: We're supportive of that. We've seen this as well, implement
pull to refresh is difficult
smfr: Pages want to know when you're reaching the end of the scroll,
maybe adding a transform to start bringing in another view
AmeliaBR: So this would mean, having a separate event -- the scroll
event would never give you overscroll results, never give
you negative offsets or larger than max
AmeliaBR: and then this custom overscroll event would start firing
instead?
AmeliaBR: Also means author could listen to overscroll without
listening to scroll
AmeliaBR: so they could handle pull to refresh even if they don't
care about regular scrolling
AmeliaBR: So smfr your only concern is that web apps might be
currently listening to negative scroll offsets, when what
they really want is overscroll events?
smfr: Yes
smfr: There is one somewhat tricky thing here which is if the user
built up enough momentum when scrolling, and the scroller hits
the end, it will rubber band
smfr: So the overscroll events probably need to contain enough info
to know the user has the finger down
myles: An additional benefit, a website might not care where you are
in the content, but do care about overscroll
myles: distinguishing the types lets you do that
heycam: Especially since scroll events are bad for performance?
mstange: Scroll events themselves are fine because they fire async
mstange: Wheel events are bad for perf, but that's only on desktop
smfr: Wheel events and touch events are input to scrolling, scroll
events are reactive to scroll
mstange: I support the addition of scroll events, having a
distinction is good
<bkardell> +1
smfr: The CSSOM View spec is the one that talks about scroll events
smfr: would it fit into that spec?
emilio: Probably, but do you want to edit that spec? There's no
editor
smfr: Not particularly
Rossen: You might have to
smfr: I'd be willing to write text for this specific thing
<bradk> If the negative offsets are going away, can they have a
deprecation warning in the console for a while first? So,
some overlap of having both that and the new overscroll
events for a while?
<AmeliaBR> The repo for Overscroll & Scrollend events:
https://github.com/NavidZ/overscroll-scrollend-events
heycam: Do these just send negative positions or ...?
smfr: On some platforms there is not concept of a real negative
positions values here
heycam: I am kind of wondering if we should not be asking authors to
do the math to figure out these things based on positions -
like when does it 'indicate'
heycam: Maybe we should just have events when that happens
smfr: The simpler thing is that we just do that, the more complex is
that we give them discrete values
bokan: I think the pull to refresh is just one case
bokan: You have a carousel article, horizontally scrolling and when
you reach the end you do an animated transition
bokan: Having a predefined animation would be more limiting
smfr: I think I agree
majidvp: I just want to point out that this matches nicely with
overscroll-behavior property
majidvp: The author will use that property to prevent chaining, or
the overscroll action triggering the native overscroll
behavior
majidvp: and declaratively you prevent the default action
majidvp: Then you use overscroll events to customize, create the
animation that responds to user input without having to add
any sort of blocking events, I think that allows you to do
this without being main thread bound
smfr: That sounds good
mstange: Do we already have a spec with overscroll events with delta
fields?
<smfr> https://navidz.github.io/overscroll-scrollend-events/
majidvp: This is in incubation. Proposed in WICG
majidvp: They are looking for feedback
majidvp: whether you need the deltas, or maybe just the sum of the
deltas, they'd like feedback on that
<NavidZ> It is not yet in incubation. I would love more support to
move the repo under WICG. So please comment on the
discourse.
majidvp: There's also scrollend event
<NavidZ> There has been some concerns for example regarding the
reversal of scroll in UAs but I think we can iterate on
those and add more css attributes to control those as well
mstange: Is there also a way to tell -- let's say fingers down, get
into overscroll, then release
majidvp: and you're still in the overscroll state for a while after
lifting the finger
bokan: Not sure if it's part of the same proposal, but there was an
event called scrollend when the scroll gesture finishes
bokan: that would be for this case
mstange: So scroll event wouldn't be separation of scroll and
overscroll
bokan: It could come between either, but all at the end
bokan: It's when the finger is lifted
bokan: if you're rubber banding, the proposal here would be "you're
no longer scrolling"
smfr: There's a period where the scroll view is animating back from
negative position to 0
smfr: When do you fire scrollend, and do you fire overscroll events
for that automatic animation
bokan: smfr you said you found negative scroll was not web compat?
smfr: But if you turn those into overscroll events for that settling
period, that's fine
smfr: but I think we may need to add data to the overscroll event to
say if the finger is down
bokan: I don't think we're set on one shape of the API, but it is
important to know when the user has lifted their finger
mstange: There are a bunch of different questions here, don't know
which we need to discuss now
mstange: One more question. The idea is scrollTop will reflect out
of range values?
smfr: Having scrollTop reflect negative values is one of the big
parts that's not web compat
smfr: so it would need to be clamped to zero
mstange: In the overscroll events we'd carry the correct
information, maybe the relative update since the last event
and the current absolute position?
mstange: You need the absolute position e.g. to update your parallax
background
mstange: I've seen cases maybe in the Apple Maps app, if you open a
panel on the point of interest, you can scroll in the
panel, and it does something parallaxy in the header image
mstange: It wants to know the scrollTop
smfr: I think that's probably necessary
smfr: We should start opening issues on the overscroll spec
smfr: and go from there
mstange: Sounds good
bokan: There's a WICG thread about this, please chime in
<bokan> WICG thread:
https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481/16
AmeliaBR: smfr did you want a resolution on your original issue
about the scroll events and negative offsets? or are you
going to wait on resolve that until overscroll events are
more clearly defined
smfr: The CSSOM View spec currently doesn't say anything about
overscroll
smfr: better to leave it that way until we have the rest of the
stuff in a well defined state
Rossen: That's a good way
Rossen: plus when we have the WICG repo we can filing more issues
there
mstange: If we start clamping scrollTop, do we clamp other things
like
mstange: like getBoundingClientRect in the middle of overscroll state
mstange: We can discuss those in that other location
-- lunch time --
Received on Thursday, 11 July 2019 22:51:05 UTC