[whatwg] Control over selection direction

(This thread started talking about the text field selection API, but 
several posts discussed changes to the range API instead, apparently due 
to some miscommunication. I have ignored the posts that referred to the 
range API. I recommend following up with the editor(s) of the DOM Range 
spec if changes are desired to that spec.)

On Wed, 12 Jan 2011, Marijn Haverbeke wrote:
> 
> 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.)

On Wed, 12 Jan 2011, Tim Down wrote:
> 
> 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.

On Thu, 13 Jan 2011, Marijn Haverbeke wrote:
> 
> That seems to introduce the problem of having this integer match up with 
> one of the ends. It's not a big problem, you could just ignore values 
> that don't correspond to an end, but it seems to add unnecessary 
> conceptual noise, since this is simply a two-valued piece of state.

On Thu, 13 Jan 2011, Tim Down wrote:
> 
> Fair enough, I think you may be right. Given that this is a binary 
> property of the selection state, how about a a Boolean 
> `selectionBackwards` property?

On Thu, 13 Jan 2011, Ryosuke Niwa wrote:
> 
> FWIW, WebKit's implementation has a boolean isBaseFirst member function 
> which checks the value of a boolean m_baseIsFirst member variable 
> although they aren't exposed to scripts.

On Wed, 12 Jan 2011, Aryeh Gregor wrote:
> 
> I used the term "forwards" and "backwards" for the DOM Range spec [...].

On Thu, 13 Jan 2011, Marijn Haverbeke wrote:
> 
> Coincidentally, that was exactly what I was going to propose at first, 
> but then I found the "top"/"bottom" thing made the concepts slightly 
> easier to explain ("where is the anchor" vs "if it goes in this 
> direction, that means the anchor is ..."). Anyway, I'm fine with your 
> proposed terminology too.

On Thu, 13 Jan 2011, Ryosuke Niwa wrote:
>
> I don't like "top"/"bottom" because it seems to imply certain visual 
> orientation. (e.g. I think RTL text in vertical writing mode flows 
> bottom up).  To make terms agnostic of text direction and writing mode, 
> I'd prefer "forwards" / "backwards".

On Fri, 14 Jan 2011, Marijn Haverbeke wrote:
>
> Another relevant precedent is window.getSelection().modify (Webkit and
> Gecko-2 specific), which uses the strings "forward" and "backward" to
> specify the direction in which to alter the selection. [...]

I've added selectionDirection = 'forward'/'backward'/'none'. ('none' is 
the default selection direction on Mac OS.)


On Fri, 14 Jan 2011, Ryosuke Niwa wrote:
> 
> Maybe we can spec this so that regular selection primitives work 
> properly for textarea/input.  e.g. you can expect that when 
> startContainer/endContainer is textarea/input, selection is set inside 
> textarea/input.

On Fri, 14 Jan 2011, Marijn Haverbeke wrote:
> 
> That would work for me, however, it'd be backwards-incompatible -- not 
> in a critical way, but probably enough to break a few pieces of code. 
> Also, I assume there is a reason that textarea/textinput content is not 
> 'officially' part of the DOM, and that separate selection-management 
> functionality has been implemented for it.

On Sun, 16 Jan 2011, Ryosuke Niwa wrote:
> 
> Does it make sense to add selectionBase and selectionExtent instead of 
> exposing direction?  That seems to match better with DOM selection for 
> which we have baseNode, baseOffset, extentNode, and extentOffset.

On Sun, 16 Jan 2011, Aryeh Gregor wrote:
> 
> Yes, but it's more redundant.  The exposed properties would no longer be 
> orthogonal -- changing one would have to change the others, and it's not 
> intuitively obvious in some cases how they should change. E.g., suppose 
> selectionAnchor == 5, selectionFocus == 8, so the selection is forward.  
> Now I set selectionStart = 4.  Does this give me selectionAnchor == 4 
> and selectionFocus == 8 (so it's the same as changing selectionAnchor), 
> or does it give selectionAnchor == 8 and selectionFocus == 4 (changing 
> direction to backwards because I extended backwards), or maybe 
> selectionAnchor == 5 and selectionFocus == 4 (behaving like extend())?
>
> If we just have a boolean, it's unambiguous: the properties are all 
> logically separate.  We don't want to emulate the DOM selection API, IMO 
> -- it's ridiculously complex for minimal functionality gain, even 
> accounting for the fact that it has to deal with nodes as well as 
> offsets.  Save authors the pain, if they only have to deal with text 
> fields.

These proposals seem more complicated than necessary.


On Thu, 13 Jan 2011, Kornel Lesi?~Dski wrote:
> 
> Would you use [the direction] in cases other than restoring previous 
> selection?
> 
> If not, maybe methods to save/restore selection or modify content 
> without removing selection would be better? (this would allow browsers 
> to support multiple selected ranges, block selection in multiline 
> inputs, etc.)
> 
> var previousSelection = input.currentSelection; // opaque object describing properties of selection
> input.value = 'foo';
> input.currentSelection = previousSelection;

On Thu, 13 Jan 2011, Marijn Haverbeke wrote:
> 
> My typical use case is that I mess with the content of the input, and 
> then restore the selection. For example, after adding three characters 
> to the front, I then restore selectionStart and selectionEnd by adding 
> three to their original values. It seems that simply saving and 
> restoring a selection does not address this case.

Having an API that directly addresses the use case seems better, but it's 
unclear how to do it in this case, since the direction has to "move" to 
take into account changes to the text. So I haven't gone this route.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 3 May 2011 16:49:59 UTC