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

[mozesstumpf]

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]

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

[mozesstumpf]

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]

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]

Given Simon's comment this should prolly remain open.

[sefeng211]

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?