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

[Tim Down]

Is a column full of

"Exception: [Exception... "Not enough arguments" nsresult: "0x80570001
(NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame ::
http://aryeh.name/spec/editcommands/implementation.js :: getState ::
line 1046" data: no]"

the expected result in Firefox 3.6.15?

I'm interested in this stuff and am very grateful for your work. I've
been writing a document.execCommand() replacement for my Rangy library
(http://code.google.com/p/rangy/), so this is all extremely relevant
for me.

Tim

On 17 March 2011 22:31, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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:
>
> http://aryeh.name/spec/editcommands/autoimplementation.html
>
> 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:
>
> http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD
>
> 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":
>
> http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD#introduction
> http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD#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.
>