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

[Darin Adler]

On Aug 12, 2005, at 3:35 PM, Duncan Wilcox wrote:

>> Since this is the first time we've done a patch that introduces  
>> new public WebKit API there is at least one thing to consider. New  
>> API needs to be staged so it can go through the Apple API review  
>> process. This means that at first we'd put the new API into a  
>> "planned to be public API" place that's not in a public header,  
>> and then move it to the public header after the API review is  
>> complete. That's just because the Safari team might need to  
>> "submit" this to an OS X build, and we can't change public API  
>> there until it's approved.
>
> Would probing a delegate via respondsToSelector: for a not-yet- 
> public delegate method be a problem or does it have to be disabled  
> until the review is done?

We can probably get away with that, but adding something to a header  
would be a no-no.

> Does the Apple API review have to be done on an actually integrated  
> patch?

Sorry, I don't understand the question.

API review has to happen before a copy of Mac OS X can go out with  
the new API in it. We don't want any API changes checked into the  
tree in a public way that are not yet approved because it would  
prevent us from submitting the TOT into a Mac OS X build. But we can  
put them in "staging" places to get ready. The approval doesn't take  
long.

>> Another thought, maybe only single caret selections need the  
>> concept of affinity and only range selections need direction, so  
>> there may be something we can do to take advantage of that.
>
> You mean merging NSSelectionAffinity and WebSelectionDirection in  
> some way?

Maybe. My thinking on this isn't very clear.

> khtml::Selection doesn't implement but does have affinity for start/ 
> end/base/extent, so perhaps affinity is meaningful also for ranges?

Good point. I don't know.

     -- Darin