beforematch: Target element definition is ambiguous.

[emilio]

It says:

the element that contains the text which was matched by find-in-page or scroll-to-text navigation.

What happens when the text to be found spans multiple elements, like:

<span>foo</span> <span>bar</span>

What if the match happens across shadow tree boundaries?

[josepharhar]

I agree this is ambiguous, I need to update the explainer.

The event is fired on the block-level element containing the text which will be scrolled to. In the case of <div id=parent> <span>foo</span> <span>bar</span> </div>, beforematch will be fired on parent in the scroll-to-text and find-in-page cases.

As for shadow boundaries, the beforematch event is fired on the first block-level element containing the matching text in the flat tree. I just tested it out and it appears to basically ignore shadow boundaries, the event is fired on whatever the first block-level containing element is, whether its in shadow or not. If the shadow boundary is inline and the matching text goes across it, it just goes to the first block-level containing element which in this case would be outside of the shadow dom.

[josepharhar]

@emilio I updated the explainer to elaborate some more. Has the ambiguity been resolved?

[emilio]

What does "block-level ancestor element" mean in this case? An inline-block is a block inside, but not outside, for example. Also probably should reference "block level boxes".

The new definition is a bit concerning, consider you have an inline element with a shadow root, with a bunch of text in it. The closest block ancestor is outside the shadow root, but it doesn't know it has any text on it. Seems like this breaks shadow boundary encapsulation by dispatching events outside of a shadow tree for stuff that happens inside of the shadow tree.

[josepharhar]

Thanks for the feedback!

What does "block-level ancestor element" mean in this case? An inline-block is a block inside, but not outside, for example. Also probably should reference "block level boxes".

I tested this out with this HTML:

<div id=one style="display: block">
  one 
  <div id=two style="display: inline-block">
    two 
    <div id=three style="display: inline">
      three
    </div>
  </div>
</div>

I found that whatever text is searched for, <div id=one> is always selected to fire beforematch on. Is this the case you are talking about, or is it something else? Is <div id=two> a block level box?

The new definition is a bit concerning, consider you have an inline element with a shadow root, with a bunch of text in it. The closest block ancestor is outside the shadow root, but it doesn't know it has any text on it. Seems like this breaks shadow boundary encapsulation by dispatching events outside of a shadow tree for stuff that happens inside of the shadow tree.

I see how this breaks shadow encapsulation. Which element do you think would be best to fire the event on in this case? Should we fire it at all? What about when the match crosses a shadow boundary? @vmpstr

[emilio]

I found that whatever text is searched for, <div id=one> is always selected to fire beforematch on. Is this the case you are talking about, or is it something else? Is <div id=two> a block level box?

Well, sure, in Chrome, which is the only implementation of this draft :)

Yeah, I guess <div id=one> is a block-level box per https://drafts.csswg.org/css2/visuren.html#block-boxes, and <div id=two> is a block container, but not a block level box. So I guess that's fine as a definition, but you should link to that probably.

...

Which element do you think would be best to fire the event on in this case?

We could probably fire the event on the text node, and let it bubble. That behaves sanely with Shadow DOM I think.

About what happens when it crosses a shadow boundary, or where it matches multiple text-nodes... that's unclear.