-
Notifications
You must be signed in to change notification settings - Fork 747
Description
Hi,
The current css-view-transitions-1 draft at point 4.2. View Transition Painting Order, says:
When a Document’s active view transition’s phase is "animating", the boxes generated by any element in that Document with captured in a view transition and its element contents, except transition root pseudo-element’s inclusive descendants, are not painted (as if they had
visibility: hidden
) and do not respond to hit-testing (as if they hadpointer-events: none
).
Note: Elements participating in a transition need to skip painting in their DOM location because their image is painted in the corresponding
::view-transition-new()
pseudo-element instead. Similarly, hit-testing is skipped because the element’s DOM location does not correspond to where its contents are rendered. However, there is no change in how these elements are accessed by assistive technologies or the accessibility tree.
The issue is that the use of visibility: hidden
in the following sentence:
are not painted (as if they had
visibility: hidden
) and do not respond to hit-testing (as if they hadpointer-events: none
).
can't coexist with this sentence:
there is no change in how these elements are accessed by assistive technologies or the accessibility tree.
because visibility: hidden
don't just make the element invisible and not-interactive, it also remove it from the accessibility tree.
Also, visibility: hidden
doesn’t reflect how Chrome and Firefox currently preserve element focusability and interactivity, while opacity: 0
combined with pointer-events: none
matches their behavior.
Related issue:
- [css-view-transitions-1] Add a11y text to specify how VT works with it #9365
- [css-view-transitions-2] Figure out a way to make hit-testing work on live (new) elements during a view transition #10930
Testing links: