search

w3c / selection-api

Selection API
http://w3c.github.io/selection-api/
Other
46 stars 28 forks source link

Selection.direction spec issue, what should happen on multiple click? #177

Open mozesstumpf opened 3 months ago

mozesstumpf commented 3 months ago

Based on the documentation, it only specifies the Selection.direction based on the position of the boundary-points.

Selection.direction

(...) first indicated boundary point is after the second, then the corresponding selection must initially be backwards. If the first indicated boundary point is before the second, then the corresponding selection must initially be forwards. Otherwise, it must be directionless.

The spec does not mention what should happen in case of double or triple click, when a whole word/line is selected.

The Mozilla's position is that the direction should be "none" in case of double-click, since it does not involve any direction. Bugzilla: Selection.direction's value is incorrect

My opinion is that the direction would be useful if its value were calculated based on the positions of the boundary points, because I don't see any advantage of knowing whether the selection was made by mouse dragging or multiple-click.

annevk commented 3 months ago

WebKit also returns none. I'd be rather worried this would be a breaking change.

mozesstumpf commented 3 months ago

WebKit also returns none. I'd be rather worried this would be a breaking change.

Yes, it would be a breaking change, but since it does not work properly in Gecko (bug report), nor Webkit (bug report) and it hasn't shipped to chromium yet, I don't think that it would currently break any website.

My concern is, that I do believe that the only use case where the direction property would be useful is to determine whether the anchor is before, after, or equal with the focus boundary-point.

I've been actively working on a contenteditable for a while and as the direction currently works, I don't see any advantage of it and I can't think to a case where I could use it as it's implemented right now.

zcorpan commented 3 months ago

If I understand from the WebKit bug, to match macOS conventions, the selection should be directionless in more cases than what the spec currently requires. I think it makes sense to match platform conventions, which suggests changing the spec to allow more flexibility.

annevk commented 2 months ago

Given Simon's comment this should prolly remain open.

sefeng211 commented 2 months ago

Generally which nodes are selected with double/tripple clicks are implementation specific, so if we use the selected nodes to determine the direction, then it would be non-interoperable. So likely the only interoperable solution would be returning "none" here?