[webkit-dev] Editing Meeting
rolandsteiner at google.com
Tue Apr 13 21:02:46 PDT 2010
I have to say I agree with Ryosuke that this requires more consideration
(see inline comments).
On Wed, Apr 14, 2010 at 6:35 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Tue, Apr 13, 2010 at 11:13 AM, Eric Seidel <eric at webkit.org> wrote:
>> - There is an issue where application does not behave as expected:
>> <a>....</a> depending on the position of the caret into the tag, the
>> behaviour is not the same.
> The more general point here is that web apps need control over where
> editing commands go (e.g. where text gets inserted or where Range.insertNode
> inserts the node). The common case is anchor tags, but there are apps with
> custom widgets (e.g. comments in Google Docs) that need different behavior.
> The way they do this in Firefox is to control where the selection is (e.g.
> set it to be inside/outside the anchor). This doesn't work in WebKit because
> we normalize to a VisiblePosition.
Up to now, we've been assuming that the solution is to add the same support
> as Firefox. The suggestion at this meeting was to instead approach this from
> a policy perspective since we don't want web apps to have to capture
> key/mouse events to make this work. That way, we keep the invariant that
> there is one VisiblePosition to each cursor position. So, instead, we'll
> propose adding CSS rules that control this.
> -webkit-selection-affinity-start: inside/outside
> -webkit-selection-affinity-end: inside/outside
There are 2 main issues I see with this approach:
- User style sheets can be crafted to inadvertently or deliberately break
web apps that rely on a specific setting
- It creates rather many ambiguous cases, and some cases are impossible,
e.g. with nested elements of the same type: ... <span class="a"><span
class="a"> ... </span></span> ... --> how can I "wrap" the inner span, but
not the outer (e.g., to delete it)?
In general I'm not sure this is a good invariant to keep (even though I can
understand the desire for it). E.g., on the boundaries of, say, bold and
non-bold text I find it most intuitive that I continue typing bold if the
cursor came from the bold side (i.e., is still within the <b> element), and
type non-bold if the cursor came from the non-bold side (i.e., is outside
the <b> element). Implementing such doesn't seem possible with this scheme.
As mentioned in another post to webkit-dev, I'd rather prefer having the
ability to specify arbitrary (non-normalized!) ranges that are affected by
editing operations. E.g., adding a 4th optional parameter to execCommand:
execCommand(command, showUI, value, range): if the 4th parameter is
present it specifies the range the command operates on. Otherwise the
default is the current selection.
This would be straightforward (IMHO), non-ambiguous and also remove the
current necessity of futzing around with the selection state. Also,
technically this isn't mutually exclusive with the CSS-based proposal (and
adding such attributes may still be worthwhile to guide user-made
selections), but it obviates the need to rely on it.
Now this would probably require more up-front standardization discussions
compared to a vendor-specific CSS attribute, but being more generally useful
(IMHO) I'd expect it to be less controversial in the end (may well be wrong
here, of course).
- We talked about creating performance tests for the various DOM operations.
> The specific idea was that we care more about order of magnitude runtime
> than we do raw numbers. So we can do something much simpler than proper perf
> tests that require a reference build. Instead, we can have tests for
> specific actions with different values of n to make sure that an O(n) case
> doesn't become O(n^2).
Yes, that's a great idea!
- We talked about deprecating "position" class, and getting rid of
>> node, node offset pairs in the DOM.
> We'd like to remove node/offset pairs entirely from
> VisiblePosition/Position. Instead we'll have beforeNode, afterNode,
> beginningOfNode, endOfNode. The only exception is that we'll still need
> offsets for offsets into text nodes.
This is quite similar to my refactoring proposal I sent to the mailing list,
so I'd very much like to see this change and would be glad to implement/help
Just for clarification how this is meant:
1. does this also remove the current "virtual" positions such as [<img>,
1], i.e., beginningOfNode(node) == beforeNode(node.firstChild),
endOfNode(node) == afterNode(node.lastChild) if a child exists, and
beginningOfNode(node) == endOfNode(node) if the node is empty and there is
no beforeNode/afterNode in such a case, OR
2. this retains the current "virtual" positions, and beforeNode/afterNode
are for such positions (e.g., [<img>, 0] and [<img>, 1]) and
beginningOfNode/endOfNode are for "regular" positions (or vice versa)
I'd very much hope for 1.) here... ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev