W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Ongoing work on an editing commands (execCommand()) specification

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Thu, 17 Mar 2011 18:31:15 -0400
Message-ID: <AANLkTikQxFefqQ6Lyfcmk-c07V-Pzrx1H1iXmwqwOi1i@mail.gmail.com>
I just rewrote the spec, and it's now both shorter and produces better
results.  For a quick view of the results, as compared to the browser
you're currently using, you can look here:


That link isn't stable, and will change and possibly break as I edit
it, but it will probably work fine.  Each table row gives the input
(with the selection marked by brackets), the output of the spec's
algorithm as implemented on top of the browser (which might not be
quite correct due to browser bugs), and the output of the browser's
native execCommand(), all for running the command "bold".  Everything
is given in both rendered and source form.

I've looked over all the results of that table in both Chrome and
Firefox, and every nontrivial difference I've found between the spec
and browsers boils down to one of

* The browser's results are visibly wrong (text is bold when it
shouldn't be or isn't when it should be)
* The browser's markup is more verbose
* The browser mangles the markup's semantics (like breaking apart an
element with an id, so that things that were previously contained in
that id no longer are)
* In one case, WebKit normalizes markup more aggressively than the
spec does, so it winds up being shorter and still correct, but only
because the spec ignored ancestors beyond what it had to modify; I'm
ambivalent about this one
* In one case, the spec adds <b> around a single space, while WebKit
doesn't; I'm inclined to say this is a WebKit bug (which also occurs
in my spec implementation as viewed in WebKit, but not Firefox, since
WebKit mangles ranges when you add them to a selection; I plan to
change my implementation to work around that)

I hope this addresses many of Ryosuke's objections to my previous algorithm.

The stable link to the spec is (still) here:


If you don't want to read the spec in detail, a high-level explanation
of my goals and of how the new styling algorithm works can be found in
the Introduction section, and in the long note at the beginning of
"Styling a node":


The algorithm was only really designed to support bold so far,
although that means it should support italics fine too.  Soon I'll
work on adding support for foreColor, and trickier things like
underline and hiliteColor, but the basic framework should work for
those too.  I haven't started on entirely different sorts of commands
yet, like formatBlock or delete.
Received on Thursday, 17 March 2011 15:31:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC