[css-ui] Be more precise about event dispatching of pointer events on the ellipsis

[frivoal]

In the section about text-overflow, CSS-UI states that

Ellipsing only affects rendering and must not affect [...] dispatching of pointer events

This phrasing isn't super clear, and makes me (and @fantasai) wonder if the behavior is fully defined.

If there is only a block element with textual content, then there is no ambiguity and events should go to that element.

However, if there are <span>s or other inline elements in the block element, and that the elided content belonged to them, then it does not seem clear whether the pointer events should be dispatched the (inline) element whose content was elided, or to the block element to which the ellipsis is attached.

My initial reading of the spec made me think it may have intended the events to be dispatched to the element whose content was elided, but the wording does look somewhat ambiguous to me, and current implementations differ: only Firefox dispatches the events to the elided inline element, while Chrome, Safari, and Edge dispatch the events to the block element to which the ellipsis is attached.

My suggestion is to:

• leave the ambiguous phrasing in level 3, only test that events get dispatched (without checking if they go to the to the inline with elided content first and bubble up to the block or if they get dispatched to the block directly), and accept both the Firefox and the Chrome/Edge/Safari behaviors as conformant for now.
• decide one way or the other in level 4, clarify, add tests accordingly, and file bugs on the relevant browsers.

[FremyCompany]

There is more to it than just whether the "..." generated content has pointer-events:none set to it or not.

Edge's current behavior is explained as we simply do not render anything so when you click the ... or beyond the ... there is no element to meet your click, which is not interoperable. We might want to rethink this. If we do, I prefer Firefox's behavior and I think it matches the spec more closely. In Chrome, spans that are displayed after the ... (in the padding) are able to get :hover so the "..." eating the click is more likely an oversight than an actual design choice.

https://wptest.center/#/ysx1l1

[FremyCompany]

Oh well, I have more thoughts...

https://wptest.center/#/lhhbr2

[frivoal]

@FremyCompany Thanks, these are interesting ways to poke at the problem, and can probably be a good basis for test cases.

So you favor the Firefox behavior. I think I agree. Do you think the level 3 spec already requires it? Do you think we should fix level 3 to require it? Do you think we can keep level 3 ambiguous and narrow it down in level 4?

[FremyCompany]

I think the spec hints the Firefox behavior pretty well, but I wouldn't quite argue it does require it either. I think it is reasonable to file a bug on both Chrome and Edge about the current behavior even without making change to the level 3 spec; we can then obviously narrow the spec text in level 4.

[css-meeting-bot]

The CSS Working Group just discussed Be more precise about event dispatching of pointer events on the ellipsis, and agreed to the following resolutions:

• RESOLVED: Clarify in level 3 that the UA should dispatch the event to the elided element.

The full IRC log of that discussion

<eae> Topic: Be more precise about event dispatching of pointer events on the ellipsis
<eae> github: https://github.com//issues/1637
<eae> Florian: We have a statement in the spec, text-overflow ellipsis should not affect dispatching of pointer events.
<tantek> q+ re: https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/ I would be strongly concerned with any test that fails in blink, edge, gecko, *and* webkit - per CR impl experience the spec&tests should likely change for those (postpone or whatever is appropriate per feature)
<eae> Florian: When you click the ellipsis the block that hosts it gets the event. Not clear to me that the statement normatively requires how the event is dispatches. Should it be dispatched directly yo the element hosting it or the one ellided.
<tantek> tries to remember what he was thinking with this text
<eae> Florian: Leave level 3 somewhat ambiguous about how events are eing fired (but not that they *are* being fired) and be more specific in level-4.
<eae> tantek: It is better than before
<eae> Florian: Block with nested block, event to block vs in0between spans. Not iterop.
<eae> tantek: Are there any strong preferences about how it should work?
<eae> Florian: Firefox seems better.
<eae> fremy: Agree, edge should match Firefox.
<eae> eae: Chrome thinks it is resonable to./
<eae> tantek: Can we add a SHOULD here to capture the consensus?
<eae> Florian: Haven't worked out the implications.
<eae> tantek: It is already in issue description.
<eae> tantek: Resolve on that same phrase, without being overly precise
<eae> tantek: Sounds like we have rough consensus
<eae> tantek: "dispatches the event to the ellided inline element"
<eae> tantek: That is all it takes, add it as a should. Capture consensus and keep moving.
<eae> tantek: We have one impl and verbal agreement from other vendors.
<eae> Florian: Normative change.
<eae> tantek: Not all normative changes need to go to CR
<eae> Florian: If we can do this without process changes that's fine.
<eae> tantek: We need to document ever change in the PR to CR process.
<eae> Rossen: No problem with that.
<eae> PROPOSED RESOLUTION: Clarify in level 3 that the UA should dispatch the event to the elided element.
<eae> RESOLVED: Clarify in level 3 that the UA should dispatch the event to the elided element.

[fantasai]

So the resolution was that events are dispatched as if 'text-ellipsis' was 'none'.