[whatwg] Control over selection direction

[Ojan Vafai]

Looks good to me. Using a string instead of a boolean is more
future-extensible should we need to add a new type and is more consistent
with other attributes.

Just to be clear, when you say before/after, you mean in document order
right? So, it's unaffected by rtl, right?

On Fri, Feb 4, 2011 at 11:00 PM, Tim Down <timdown at gmail.com> wrote:

> On 4 February 2011 11:07, Marijn Haverbeke <marijnh at gmail.com> wrote:
> > See below for a revised proposal, based on the discussion here. To
> > move this forward, I understand I must get some people to implement
> > it. I'll probably eventually get to submitting a Firefox patch. If
> > anyone reading this list knows the people who'd be able to make this
> > happen on other browsers, please point them at it.
> >
> > -----
> >
> > element.selectionDirection [= value]
> >
> > Returns either "forward" or "backward", indicating which side of the
> > selection is anchored. For "forward" it is the top, for "backward" the
> > bottom.
> >
> > Can be set to one of these strings to change the side of the selection
> > that counts as the anchor.
> >
> > [...]
> >
> > The selectionDirection attribute must, on getting, return one of the
> > strings "forward" or "backward". "backward" is returned when the anchor,
> the
> > fixed end, of the selection lies after the base, the movable end.
> > "forward" is returned in all other cases.
> >
> > When set to "forward" when its current value is "backward", or set to
> > "backward" when its current value is "forward", it 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.
> >
>
> I still prefer a Boolean (and therefore a change of name to
> selectionBackwards or similar). I see no gain from using a string.
> Otherwise, this seems like the best solution.
>
> Tim
>