Re: [Editing] Splitting Selection API Into a Separate Specification

On Mon, Mar 17, 2014 at 1:59 PM, Robin Berjon <robin@w3.org> wrote:
> My understanding from talking to various people is that at least part of the
> problem comes from the type of code that is currently deployed in the wild.
> An awful lot of it works around browser inconsistencies not through feature
> testing but through user agent switching. This means that when a given
> browser fixes a bug in order to become more in line with others (and
> presumably the spec), it actually breaks deployed code (some of which is
> deployed an awful lot).

I don't think this is the primary issue.  Most of the users of
execCommand I've seen don't depend very much on specific behaviors,
and only browser-switch on a few things, and this is a problem whenever
browsers converge on common behavior.  Generally browsers work around
this by someone taking the hit and changing their behavior and dealing
with a bit of interop fallout by evangelism, or in IE's case
mode-switching.

The major issue is that the feature is extremely complex, so it would
require tons of resources invested by all the browsers to get
interoperable, and this would introduce zillions of clear-cut bugs
that would have to be fixed at the cost of even more resources.  There
just aren't enough consumers to be worth it.  Sites that make
non-trivial use of editing features mostly have given up and use JS
libraries anyway.

> One suggestion has been to make at least the selection API interoperable,
> which seems achievable. So I'm very glad to see Ryosuke propose it here, I
> was about to suggest the same.

Yes, this should mostly not be difficult, with a couple of exceptions
(.modify and stringification come to mind).

> Another that I've been mulling over is to have something like
> contenteditable=minimal (bikeshed syntax at will). This would give you a
> caret with attendant keyboard motion and selection, but no ability to
> actually edit the content. Editing would happen by having a script listen to
> key events and act directly on the content itself. The hope is that not only
> is this a saner architecture for an editor, but it can also bypass most
> (possibly all, if the selection API is improved somewhat) browser bugs to do
> with editing.

This would be possible using the beforeinput/input events that are
already specced.  Per spec, various standard actions like "delete next
character" could be intercepted at a high level -- watch the
beforeinput event, and if you see .command == "delete" cancel it and
do your own thing.  I don't think browsers actually implement the
necessary bits for this, though.  Also, it's not so hard to do this
yourself with key handlers, although it might require a bit of work to
get it to not be error-prone.

On Mon, Mar 17, 2014 at 10:58 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> I'm very pessimistic about the prospect of fixing execCommand.  I think we
> have a much better chance of coming up with some lower-level API that JS
> libraries could use to build editors.

Yes, especially the bits that are very hard to get right -- like "wrap
this list of consecutive nodes in tag X"
<https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#wrapping-a-list-of-nodes>
and such.  I've tried to spec some such algorithms separately in the
spec (without speccing APIs for authors), but they're likely to still
be buggy.  Browsers mess this sort of basic operation up a lot, which
is a good reason to expect authors won't get it right!

We still should have execCommand specced well enough that a new
browser could theoretically write a web-compatible implementation
based only on the spec, but it's probably not worth the effort
relative to other things.

> The biggest piece we're missing on the web platform today is mapping of key
> events to intended editing actions. e.g. how do you know that Shift+Enter
> should insert line break as opposed to start a new paragraph, or that
> Shift+Control+Left should extend selection to the beginning of the line.

Relative to the difficulty of writing a full editing implementation, a
JS editor implementation should be able to do this pretty easily,
shouldn't it?

Received on Tuesday, 18 March 2014 12:14:56 UTC