[webkit-dev] DOMRange and khtml::Selection direction
darin at apple.com
Fri Aug 12 09:50:31 PDT 2005
On Aug 12, 2005, at 12:38 AM, Duncan Wilcox wrote:
>> We will need to do something like this to solve the problem. A
>> completely separate method would be inconvenient. I think I'd
>> prefer a new class that includes both a range and a selection
>> direction, or something along those lines.
> Would it be possible to extend DOMRange with selection direction?
Probably not. DOMRange is from the DOM standard, and I don't think
it's a good idea to put additional state in it.
But we can create a new class that we can use instead of DOMRange
that can include a DOMRange plus more; we'd probably integrate the
>> You don't mention how the selection direction would be passed to
>> the delegate method, but I assume you'd suggest n additional
> I had thought that perhaps selection direction is not needed very
> often, and that the delegate might expressely call [WebView
> selectionDirection] to get it, but on second thought it creates
> trouble with the mouse selection, so I guess the correct way is
> either an additional parameter in the
> g: delegate method and in [WebView setSelectedDOMRange:affinity:],
> or an extension to DOMRange so that the parameter is implicitly
> carried along.
Right, we'll need to either add an extra parameter or change the
class of the existing parameters.
More information about the webkit-dev