[whatwg] Generalized execCommand() alternatives, or standardized selection and range handling

On Tue, May 31, 2011 at 4:15 AM, Markus Ernst <derernst at gmx.ch> wrote:
> While following the discussions about Aryeh Gregor's great work on
> execCommand(), I get the impression that this method is very limited to some
> basic formatting actions. It provides shortcuts for a limited set of DOM
> actions, but is not really extendable or generalizable.
>
> Some of the discussions were about adding support for new elements, such as
> <header> and <section>, or for distinctive <i> and <em> resp. <b> and
> <strong> elements. I doubt that extending execCommand() with specific new
> commands for more elements would be the direction to go.
>
> With the focus on HTML editing rather than WYSIWYG editing, some kind of
> generalized wrapping/unwrapping mechanism would be helpful. This could be
> handled with a new method that offers shortcuts for wrapping/unwrapping
> selections; some kind of addWrapper(elementName) and
> removeWrapper(elementName).

I do have a wrapping algorithm in the current spec:

http://aryeh.name/spec/editcommands/editcommands.html#wrap

There are a whole bunch of others you can find in the spec too, some
of which Tim Down mentions.  Once everything looks stable and the
kinks are worked out, I'm definitely going to think about exposing
some of the primitives my spec relies on to authors as new methods
someplace.  However, I'd prefer to wait until we have actual
implementations that confirm that these primitives are the right way
to do things for execCommand().  I don't want to say we should expose
an algorithm when it turns out that the algorithm doesn't make sense
and needs to be split in pieces or something.

> Anyway, everything we need is actually available in the DOM, except a
> standardized and simple handling of selections and ranges. (Well, I might be
> wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference,
> they show very different approaches to the range and selection objects, and
> the code of TinyMCE shows lots of browser sniffing.)

That's because browsers' implementations don't follow the specs, or in
some cases because there weren't specs until the last few months, not
because there's anything wrong with the spec.  I've implemented all my
algorithms in pure JavaScript, and there are almost no places where I
have to work around browser bugs -- given that I only target the
latest versions of IE/Firefox/Chrome/Opera.  implementation.js is over
4000 lines, and I estimate I've needed maybe ten browser-specific
workarounds, certainly under twenty.  (If you want to support IE<9, of
course, have fun . . .)

The only major thing that can't be done in JS is change how ranges
behave when you mutate the DOM.  Effectively, I work around it by
using a single Range object to represent the user's selection, and I
only care how that changes.  This might actually be the way I'll end
up speccing it too, although it'd be nice if we could preserve ranges
outside the selection too.

Received on Tuesday, 31 May 2011 10:39:23 UTC