[whatwg] Control over selection direction

[Ryosuke Niwa]

On Fri, Jan 14, 2011 at 3:09 PM, Marijn Haverbeke <marijnh at gmail.com> wrote:

> > If you accept that other selection APIs can't be used in textarea /
> input,
> > then why would you expect your property/method to specify direction can
> be?
>
> Because I proposed it as *only* working for input fields.
>

Ah, I misunderstood your intention.

>  Specifically that this direction property/method works for textarea /
> input
> > and other properties/method doesn't is very inconsistent,
>
> This is exactly the situation we have now with the selectionStart and
> selectionEnd properties. I'm merely working in the spirit of the
> existing situation.
>

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, Jan 16, 2011 at 12:21 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> Currently there are two totally different selection APIs.  There's one
> for selections in the DOM, which is accessed using
> window.getSelection():
> <
> http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface
> >.
>  But this doesn't work for text in inputs/textareas, since that's not
> in the DOM, so they have their own API:
> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection
> >
>  The two APIs are already unrelated and inconsistent, which is bad,
> but that's the situation.  The proposal here is to extend the latter
> API slightly.  So I'm not sure what you mean.
>

Adding selectionBase and selectionExtent seem to serve better in terms of
aligning DOM selection API and input/textarea selection API.

- Ryosuke