[webkit-dev] DOMRange and khtml::Selection direction
darin at apple.com
Fri Aug 12 16:02:50 PDT 2005
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
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
>> 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.
More information about the webkit-dev