Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

selectstart event handler needs to be exposed on Text #159

Open
dontcallmedom opened this issue Jul 27, 2022 · 7 comments
Open

selectstart event handler needs to be exposed on Text #159

dontcallmedom opened this issue Jul 27, 2022 · 7 comments

Comments

@dontcallmedom
Copy link
Member

I believe selectstart can be emitted on a Text node, but there isn't a matching event handler on the Text interface (GlobalEventHandlers only take care of exposing it on elements and their bubbling parents).

(based on discussion with @tidoust and @foolip in w3c/webref#630 (comment) )

@rniwa
Copy link
Contributor

rniwa commented Jul 29, 2022

We don't expose other event handlers on Text. Why is this event specially useful / needed? Author can always use addEventListener as well.

@foolip
Copy link
Member

foolip commented Jul 29, 2022

What are the other events that can fire on Text nodes?

I think the practical use in any specific situation is minimal, especially for a long-existing event, but the argument is one of consistency:
https://w3ctag.github.io/design-principles/#always-add-event-handlers

@rniwa
Copy link
Contributor

rniwa commented Jul 29, 2022

Hm... I thought we fired mousedown, etc... on a Text node but apparently we don't. That raises a question as to whether we should be firing selectstart on a Text node in the first place or not. That seems rather inconsistent with all other events.

@tidoust
Copy link
Member

tidoust commented Oct 13, 2022

What are the other events that can fire on Text nodes?

Looking at webref data, on top of mutation events, the other events that fire on Text node are:

They don't have corresponding IDL attributes either.

@annevk
Copy link
Member

annevk commented Oct 13, 2022

Thoughts:

  1. It makes sense to investigate why we fire events on Text to begin with, especially with it being such a small subset. Maybe @smaug---- or @petervanderbeken have insights? (I could imagine something dragging a Text node, but you might also be dragging a subset of the text or more than one node so...)
  2. If they are interoperable and tested, we should probably add event handlers for consistency.
  3. We should probably define the attributes in HTML as part of the overall event handler infrastructure.

@tidoust
Copy link
Member

tidoust commented Oct 13, 2022

Regarding "interoperable", I noticed that Chrome does not fire pointercancel on Text nodes (unlike Firefox) and reported that in a Chromium bug. Chrome and Firefox both fire drag events on Text nodes as far as I can tell. I haven't tried to test selectstart.

@smaug----
Copy link

Per HTML spec pointercancel may fire on Text:
"If it is a selection that is being dragged, then the source node is the Text node that the user started the drag on"
...
"Fire a pointer event at the source node named pointercancel"

And firing drag event on a text node is also specified:
"Fire a DND event named drag at the source node."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants