Re: on execCommand() and script-triggered copy/cut/paste

On Wed, Aug 5, 2015 at 11:39 AM, Hallvord Reiar Michaelsen Steen <> wrote:

> On Wed, Aug 5, 2015 at 8:51 AM, Johannes Wilm <>
> wrote:
>> On Tue, Aug 4, 2015 at 11:06 PM, Hallvord Reiar Michaelsen Steen <
>>> wrote:
>>> I think "deprecated" is the right word for the goal you're describing,
>>> I'm just saying the goal itself is unrealistic and therefore pointless.
>>> If I may quote Aryeh Gregor himself (I hope he doesn't mind..)
>>> "it's true execCommand etc. will probably never be removable"  - from
>> That sounds like a defeatist attitude. In that case I think the word
>> "deprecated" is correct. Not everything that is marked as "deprecated"
>> disappears quite as fast as those deprecating it had hoped for. Sometimes
>> things are even "un-deprecated". But to give up before one even begins
>> doesn't sound like a healthy attitude.
> Maybe not :) It's simply our experience with spec'ing stuff for the web
> that
> * Making a "clean break" with the past to do things "the right way" has
> historically not worked (see efforts standardising XHTML and XHTML2 instead
> of HTML etc)
> * Removing features from the web platform is very, very hard
> * Complexity usually exists for a reason. I'm not saying simplifying
> editing is impossible, nor that a "simplified editing element" like
> cE=intents is useless - but given that it's very, very hard to make a fully
> fledged editor, you need a lot of "primitives" and a lot of logic handling
> corner cases will simply be cloned in JS although the UA already has it
> built-in.
> I said "our" experience because I think many browser developers and spec
> editors will agree with all three points.

The idea to start with something entirely new came from browser makers and
not us JS developers. I think most of us started out with a hope to fix
cE=true. The message from browser makers was very clear: Such efforts will
not go anywhere; we need a clean break. Aryeh received the same response.

> I suggest you develop your new things and see if browser developers
> implement them while not claiming ownership over or power to "deprecate"
> those old things.

Well, this is a taskforce to address editing in general. We are looking at
all the different ways to do editing in browsers. We asked Aryeh and had a
discussion with him here on possibly taking over his spec draft, which he
agreed to. Subsequently we had a discussion about how to go on with this.
The state of this discussion so far is that it likely makes no sense to
drive this spec to completion AND to ask people to please not write more
things on top of them.

> Now and then, a developer will want to fix something in
> contentEditable=true land, and simply having Aryeh's spec around will
> inform that work and improve compatibility and quality - over time, even
> though noone might have the manpower to do massive cE rewrite efforts right
> now.

We JS developers have been filing bugs for several years, and even written
scientific articles about the bugs, and they are largely ignored by the
browser makers based on the argument that there is no official spec. At the
same time they are not interested in a spec because it would break too much
legacy code.

Should this situation change, and browser makers be more interested in
making cE more interoperable by following a future version of the current
specs, then the right place to continue the development of those specs
would also be this taskforce (if it is still in operation).

In the meantime I think it is very important to have a big disclaimer in
those drafts to make sure that other spec writers do not add more features
to execCommand.

> As for the clipboard stuff, I hear what you're saying about the benefits
> of a new API so I'm also asking for feedback on possibly doing that.


> -Hallvord

Johannes Wilm
Fidus Writer

Received on Wednesday, 5 August 2015 10:52:31 UTC