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

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

From: Markus Ernst <derernst@gmx.ch>
Date: Fri, 04 Mar 2011 19:17:22 +0100
Message-ID: <4D712CB2.2030308@gmx.ch>
Am 01.03.2011 19:36 schrieb Aryeh Gregor:
> Two or three weeks ago I began writing a specification for
> execCommand() and related functions.  I don't have anything
> implementable yet -- it's very incomplete and there are known issues
> with the existing stuff.  But I thought I'd post it for any early
> review comments on the direction I'm taking, particularly from
> implementers but also from anyone else familiar with the APIs (e.g.,
> someone who's used them in practice):
> http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD
> The plan is that this should be merged into the main HTML spec, with a
> full test suite, by the end of August.  Feedback appreciated.

I am very interested in your work because I work with content management 
systems a lot. Some months ago I started to write a simple rich text 
editor trying to use DOM methods instead of execCommand(), because I 
don't like the the code some UAs produce, and wanted a slim and easily 
configurable editor. If execCommand() gets standardized and enhanced, I 
might be happy to abandon the project. Here are a few comments from my 
point of view:

- I assume that the list of commands is not complete, as some commands 
given in the HTML spec are missing, such as "formatBlock" or 
"insertHTML" - or is it your intention to drop these commands? For 
better understanding, it might be worth to clarify this.

- Please consider adding a generic "formatInline" command for applying 
all kinds of inline elements. A sophisticated RTE might e.g. want to 
provide separate "bold" and "strong" options for authors caring about 
this distinction.

- I'd like a "className" command to be added. Corporate websites usually 
use a restricted set of formattings; in a CMS for such a website it 
should be possible to provide a select box with the respective CSS 
classes rather than font and color menus.

- In the opposite case, where everything is allowed, users might want to 
apply CSS properties not covered by the command list, such as borders, 
or future fancy stuff such as shadows. For these cases, an "applyCSS" 
command could be helpful.

- Some CMS systems use different doctypes than the pages where the 
edited text is finally published. Content edited in an HTML5 page might 
be published in an XHTML page. While it is not too complicated to solve 
this in practice with server-side string editing - would it be possible 
to specify the desired HTML style for the output? (Which could result in 
different HTML styles in a contenteditable area and the surrounding 

These are just some thoughts out of my everyday work, of course I have 
no idea about implementation cost and whatever issues. Generally, I 
think that a future-proof execCommand() specification should rather 
provide generic commands for inline and CSS formatting, and support 
specific commands such as "bold" or "backColor" only for backwards 
compatibility reasons. (This would also make a discussion on the 
preference of element or CSS formatting obsolete, as RTE authors would 
have the choice to use either.)
Received on Friday, 4 March 2011 10:17:22 UTC

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