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 <o...@chromium.org> wrote: > On Tue, Apr 13, 2010 at 11:13 AM, Eric Seidel <e...@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 implementing it! 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... ;) Cheers, - Roland
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev