[whatwg] Control over selection direction

I completely agree, and have been lobbying for similar functionality
for the main document selection object, resulting in the current
ongoing discussion in this bug:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624.

Rather than a single string property, how about integer
selectionAnchor and selectionFocus properties? This is then analogous
to Selection's anchorNode, anchorOffset, focusNode and focusOffset
properties and avoids an awkward string property.

Tim

On 12 January 2011 19:35, Marijn Haverbeke <marijnh at gmail.com> wrote:
> Hi,
>
> I'd like to propose a minor addition to 4.10.20 APIs for the text
> field selections. When programmatically setting the selection of a
> text input, it is currently impossible to create a range with the
> 'anchor' at the bottom and the 'base' at the top. Concretely, this
> means that, after a selection has been set by a program, if the user
> presses shift and moves the cursor, it is always the bottom of the
> selection that is moved. When doing heavy scripting on such input
> element, it is often necessary to restore a previous selection exactly
> as the user made it. This is currently not possible, and I'd say the
> HTML5 standard is our only hope of finally getting something like this
> widely implemented.
>
> The most obvious way to handle this would be to allow selectionStart
> to be greater than selectionEnd. This is, however, unacceptable for
> various reasons -- it's not easily feature-detectable, it breaks older
> code that reads these properties and expects start to never be greater
> than end, and it makes the names more confusing than they have to be.
>
> So I propose a selectionAnchor property, which holds either "top" or
> "bottom", and can be set to one of these strings to modify the
> direction. "top" would mean the anchor lies after the base of the
> selection, so further shift-movement modifies the bottom, whereas
> "botton" means the inverse, with movement modifying the top. (I think
> the "top"/"bottom" terminology shouldn't break with any languages that
> order characters differently. Does anyone write bottom to top? If
> someone sees a problem, we could choose other terms, but these are the
> most obvious I could come up with.)
>
> So, in standard-ese:
>
> -----
>
> element.selectionAnchor [= value]
>
> Returns either "top" or "bottom", indicating the side of the selection
> that is anchored.
>
> Can be set to change the side of the selection that counts as the anchor.
>
> [...]
>
> The selectionAnchor attribute must, on getting, return one of the
> strings "top" or "bottom". "bottom" is returned when the anchor, the
> fixed end, of the selection lies before the base, the movable end.
> "top" is returned in all other cases.
>
> When set to "top" when its current value is "bottom", or set to
> "bottom" when its current value is "top", is must flip the roles of
> the ends of the selection, so that what used to be the anchor now
> becomes the base. When set to any other value, this is ignored.
>
> ------
>
> Let me know what you think.
>
> Best,
> Marijn Haverbeke
>

Received on Wednesday, 12 January 2011 15:24:31 UTC