Selection & CSS Regions

[Manuel Rego Casasnovas]

Hi,

we've been working for a while in selection and CSS Regions.

Current implementation is working fine from the DOM tree point of view,
the retrieved content when you do a selection is right (fulfilling the
editing spec [1]).

However, in several use cases with CSS Regions, highlighted content in
the view does not match with the retrieved one, which is wrong.

We've been thinking in different 2 different approaches to fix this
problem. They're explained in detail in the following wiki page:
https://github.com/Igalia/css-regions-selection/wiki/Selection-&-CSS-Regions

Sorry for the cross posting, but we'd like to know the opinion, doubts
and concerns of editing/selection experts in both projects (WebKit and
Blink) before going further with the implementation.

What do you think? Could any of these approaches be eventually
integrated upstream?

Thank you very much,
Rego

[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

[Yoshifumi Inoue]

I would like to take Render Tree based approach, but I don't want to make Render Object to have state of selection. Actually, Render object have selected state for rendering but these states should be implementation detail of rendering and not expose to editing module.

Selection for Shadow DOM tree is similar to CSS Region. Shadow DOM tree also randomizes rendering order against (shadow/non-shadow) DOM tree order.

Using render tree information for selection also allows us to handle position:absolute elements, e.g. advertised elements displayed displayed at page bottom.

We have a plan to make TextIterator to traverse Render Tree rather than DOM tree for ease and robust support of Shadow DOM tree.

Thanks.

-yosi

[Manuel Rego Casasnovas]

Hi Yosi,

On 19/12/13 02:17, Yoshifumi Inoue wrote:
> Selection for Shadow DOM tree is similar to CSS Region. Shadow DOM tree
> also randomizes rendering order against (shadow/non-shadow) DOM tree order.
>
> Using render tree information for selection also allows us to handle
> position:absolute elements, e.g. advertised elements displayed displayed
> at page bottom.
>
> We have a plan to make TextIterator to traverse Render Tree rather than
> DOM tree for ease and robust support of Shadow DOM tree.

Let me check if I understand your mail properly.

You're talking about fixing the selection from the user point of view
forgetting about selection being always DOM based (like in editing
spec).

For example in the following page with absolute positions, the idea
would be that when you select from content-1 to content-2, absolute-1
text is not selected:
http://people.igalia.com/mrego/css/absolute/example.html

I agree that this would be the best solution from the user point of
view.

So, if I'm not wrong, the plan is to make TextIterator traverse the
render tree, so things like shadow DOM, absolute positions or CSS
Regions could be properly traversed.

I'm wondering if the next step would be that selection's algorithms
use TextIterator to traverse the render tree too or not. If not I
guess that similar changes should be needed in rendering code.

As a side note, in CSS Regions it might be needed to jump from a
RenderRegion to its content in the RenderFlowThread and the other way
around. That could be done in TextIterator as we'll have all render
tree information. Directly traverse of the render tree won't fix the
issue in CSS Regions.

Thanks for your feedback,
Rego

PS: I've been testing different layout models (shadow DOM, absolute
positions, flexbox and regions) checking selection's behavior, you can
find a summary at:
https://github.com/Igalia/css-regions-selection/wiki/Selection-&-Other-layout-models

[Yoshifumi Inoue]

I would like to provide render tree iterator base rendered position from Render Tree for TextIterator, Selection, and others. TextIterator is the first client of its. 

I'm not clear about traversing doesn't solve CSS region selection. Does it come from current implementation? Or, is traversing wrong idea?

BTW, changing selection will be after TextIterator, because  exposing selected node to JavaScript needs new API, e.g. Selection.getNodeSet(scope). So, it will come later.

Thanks!

-yosi

[Manuel Rego Casasnovas]

Hi Yosi,

On 20/12/13 02:37, Yoshifumi Inoue wrote:> I would like to provide

render tree iterator base rendered position from
> Render Tree for TextIterator, Selection, and others. TextIterator is the
> first client of its.

Ok, I guess that it could be something similar to the RenderIterator
that has been recently introduced in WebKit:
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderIterator.h

> I'm not clear about traversing doesn't solve CSS region selection. Does
> it come from current implementation? Or, is traversing wrong idea?

What I mean is that regular traverse of the render tree won't fix
selection issues in CSS Regoins (neither in absolute positions for
example).

Let me explain with a simple example:
http://people.igalia.com/mrego/css/regions/example.html

The Render tree is something like:
RenderView
RenderHTML
RenderBody
RenderBlock content-1
RenderRegion region-1
RenderBlock content-2
RenderFlowThread
RenderBlock source-1

However visually you get something like:
content-1
region-1
source-1
content-2

If you select from "content-1" to "content-2" and you traverse render
tree, you won't process "source-1".

So, we'd need some special conditions for CSS Regions in the
RenderIterator, to jump to the RenderFlowThread subtree (and the other
way around) when needed. I guess this is ok, as it's an implementation
detail.

> BTW, changing selection will be after TextIterator, because exposing
> selected node to JavaScript needs new API, e.g.
> Selection.getNodeSet(scope). So, it will come later.

I agree that this will be after TextIterator, just trying to understand
the whole picture.

About changing the selection I'm thinking in RenderView::setSelection()
method. This method should also use the RenderIterator instead of
regular render tree traversing to fix the problem.

BTW, where can I find information about that new API
"Selection.getNodeSet(scope)"? It is not in the editing spec [1].

Thanks,
Rego

[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selection