[webkit-dev] DOMRange and khtml::Selection direction
duncan at mclink.it
Fri Aug 12 15:35:36 PDT 2005
> 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
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
> 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
khtml::Selection doesn't implement but does have affinity for start/
end/base/extent, so perhaps affinity is meaningful also for ranges?
More information about the webkit-dev