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

[Duncan Wilcox]

> 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?

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

> I wonder if there's anything else that this selection object might  
> need to include.

Can't think of anything myself...

> 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?

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

Duncan