[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

Aryeh Gregor Simetrical+w3c at gmail.com
Tue Jul 26 14:26:32 PDT 2011

Since February, I've been working on writing a detailed specification
for browser editing, primarily the document.execCommand() and
document.queryCommand*() methods.  These were created by Microsoft in
the 1990s and were subsequently adopted in some form by all other
browsers, and today browsers have to implement them to be compatible
with web content, but no detailed specification ever existed.
Interoperability is practically nonexistent as a result, which has
driven all major content editing frameworks away from using
execCommand().  Hopefully we can start to fix that and make these APIs
a part of the web platform that just works.

The current version of the specification is at
<http://aryeh.name/spec/editing/editing.html>.  It's about fifty pages
printed, and supersedes the Editing APIs section of HTML
(which is more like two pages).  In the style of modern web specs, it
is phrased in terms of algorithms that attempt to cover all corner
cases unambiguously and leave no behavior undefined, and it tries to
match the behavior of existing browsers to the greatest extent
possible.  At this point, it's stable and complete enough that I
believe it's ready for serious review by implementers, and I would
like as much detailed feedback as possible.

There is a basically complete JavaScript implementation, which is used
to produce expected results for a largely undocumented and entirely ad
hoc test suite:
<http://aryeh.name/spec/editing/autoimplementation.html>.  I used the
tests as an aid to writing the spec, and they probably aren't well
suited to aid implementers in implementing it.  I will probably get
around to porting them to something like testharness.js at some point.
 I haven't tried testing my implementation on real-world sites, only
on artificial input, so I don't know at this point how implementable
it really is, but the JS implementation means that it at least has
large parts that make sense.

Anyone reviewing the spec should be advised that I put extensive
rationale in HTML comments.  If you want to know why the spec says
what it does, check the HTML source.  I plan to change this to use
<details> or such in the near future.  There are lots of minor known
issues still left, but none that I thought was important enough that
it needs to delay review.  Feedback can be sent to the whatwg list,
CCing me, with [editing] in the subject.  (I'm also fine receiving
feedback on public-html or public-webapps, but I don't know if the
chairs would be okay with that, since it's off-topic.)  I should be
available to respond to all feedback promptly at least through the end
of August.  After that, I can't make specific guarantees about my
availability, but I do plan to continue maintaining the spec in the
long term.

I've CCd or BCCd everyone who's commented on or contributed to this
spec at some point.

More information about the whatwg mailing list