[webkit-dev] DOMRange and khtml::Selection direction

[Darin Adler]

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  
affinity too.

>> You don't mention how the selection direction would be passed to  
>> the delegate method, but I assume you'd suggest n additional  
>> parameter.
>
> 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  
> webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelectin 
> 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.

     -- Darin