[w3c/selection-api] Flat Tree or Composed Tree (Issue #336)

This surfaced from the conversation at TPAC 2024 about whether we should use a Flat Tree Traversal (https://github.com/w3c/selection-api/issues/169) for comparing Selection positions that cross shadow trees.

## Composed Tree
With the Composed Tree, we do the normal DOM tree traversal, but consider the owner document to be the common ancestor.
Why this is good:
- Currently, most Selection API uses the Composed Tree, including setStart/setEnd/setBaseAndExtent/isPointInRange. There might be many compat risks to change these APIs.
- Doesn’t require updating Style and Layout. Easier to implement.

## Flat Tree
With the Flat Tree, we traverse a flattened tree where the shadow trees are flattened to all be contained within one tree.
Why this is good:
- This is what the user sees when the selection is painted.
- Would take care of re-ordered slotted contents.
- Would make IsPointInRange() and toString() more useful to web users, as what the user sees is what’s selected in the flat tree.
- It avoids the problem of multiple range objects to manage, but looks visually contiguous to the user

## Open questions
1. Should we change existing Selection APIs to use flat trees? This information can be stored internally and only be accessed by getComposedRanges(), keeping the rest of the behaviors unchanged.
2. Else, should we have new APIs which definitely do use Flat Tree?
3. Should we support discontiguous ranges?

## Examples:
Selection where start and end are in the same tree, but slotted to be in reverse order.
Selection start from the sibling of shadow host, end inside the slotted content.
https://github.com/mfreed7/shadow-dom-selection?tab=readme-ov-file#3-slotted-content

## Some use cases
Bidi, tables, flex/grid layout maybe.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/336
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/issues/336@github.com>