Failure in /css/css-scroll-snap/snap-after-relayout/multiple-aligned-targets/prefer-focused-nested-containers.html
Categories
(Core :: Layout: Scrolling and Overflow, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox152 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
Honestly I don't quite understand what the test wants to check.
// This test verifies that a snap container (outer) which contains another
// snap container (inner) snaps with awareness of focus on children of the
// inner container, i.e. outer should prefer to select the snap area whose
// child has focus even if there is an intermediate snap container between
// the child and outer.
This is opposed to the model of scroll snap that I do understand. From the spec;
Snap positions only affect the nearest ancestor scroll container on the element’s containing block chain.
Comment 1•6 months ago
|
||
I don't think there is a conflict between this test and quoted line of the spec.
The quoted line of the spec is saying that an element E can be a candidate snap target of a scroll container S only if S is the nearest ancestor scroll container of E. So, in this test, for S=outercontainer, leftcontainer and rightcontainer can be candidate snap targets, but e.g. lefttarget1 cannot.
But this line of the spec is not placing any constraints on the rules to tie-break between leftcontainer and rightcontainer. So e.g. a rule could be "leftcontainer is preferred if any descendant of it is focused", and this is what the test seems to be checking.
Comment 2•6 months ago
|
||
(In reply to Botond Ballo [:botond] from comment #1)
So e.g. a rule could be "
leftcontaineris preferred if any descendant of it is focused"
That said, while I don't think such a rule would conflict with anything in the scroll snap model, I think it's also true that the current Selecting between multiple aligned snap areas section does not seem to spell out such a rule.
What the section says about focused content is:
If list contains the focused box, remove all other boxes from list.
If the intent is to prefer boxes if any descendant of them is focused, I think it should rather say:
If list contains a box which is focused or has a focused descendant, remove all other boxes from list.
So I think this also needs a spec issue filed to clarify the spec text.
| Assignee | ||
Comment 3•5 months ago
|
||
Filed a spec issue; https://github.com/w3c/csswg-drafts/issues/13673
Thank you Botond!
| Assignee | ||
Comment 4•4 months ago
|
||
Add a new WPT (prefer-element-having-focused-element.html) since no
existing test covered this case. It verifies that a snap target
containing a focused non-snap element takes priority over other
aligned snap targets.
Updated•4 months ago
|
| Assignee | ||
Comment 5•4 months ago
|
||
Per spec, snap positions only affect the nearest ancestor scroll
container, so re-snapping is normally only triggered on that container.
However, if a snap target contains the focused element, ancestor scroll
containers of that snap target may also need to re-snap.
| Assignee | ||
Comment 6•4 months ago
|
||
Though the spec issue hasn't yet been resolved, I've uploaded two patches to make prefer-focused-nested-containers.html pass.
Comment 7•4 months ago
|
||
The patches in this bug have a code dependency on bug 1880436; adding a bug dependency to reflect it.
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/59881 for changes under testing/web-platform/tests
Comment 10•4 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/148a8757aad1
https://hg.mozilla.org/mozilla-central/rev/06751e224307
Upstream PR merged by moz-wptsync-bot
Updated•3 months ago
|
Description
•