Re: [clipboard] document.execCommand and clipboard actions

On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
> <hsteen@mozilla.com> wrote:
> > so I hit a bit of an issue: I've written some parts of the clipboard spec
> > with the assumption that it will be invoked from a
> > document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
> > require some extra permission work which no UA but IE has attempted so
> far).
>
> So you're saying most of this is deployed and used by content?
>

Any editor which has "copy", "cut" or "paste" buttons in its UI have
exactly two ways to implement those commands, document.execCommand() or
Flash. I haven't seen any editor use Flash for this, but they may exist.
The editors I have tested have a sort of "fallback mode" where they check
if the command is enabled, and if not tell the user to press Ctrl-C/X/V
instead - in the "paste" case they tend to pop up a specific dialog with a
rich text element for the user to paste into.

So yes, this is deployed and used by content but with a poor cross-browser
compat story that typically requires workarounds.


>
> > Meanwhile, the editing task force has gathered feedback on developing
> editor
> > features from implementors and drawn the conclusion that the current
> "stuff"
> > including contentEditable=true and document.execCommand() is
> unsalvageable.
>
> It seems that's wrong at least as far as copy/paste is concerned,
> given our recent successes in getting Flash replaced by execCommand()
> calls.
>

I haven't been following discussions in that group, so I don't know how
many developers they consulted. I'm sure we all understand the frustration
with the contentEditable implementations out there - ensuring this feature
generates sane code has not exactly been a high priority for browser
vendors. Certain editors (with Google Docs being a very high profile case)
have been through a phase of using contentEditable and have simply moved on
to do various hacks where they fake selections and cursors by modifying the
DOM directly to avoid dealing with the serious inconsistencies of
cross-browser contentEditable implementations.


>
> > Would implementors want to support [a new API]?
>
> I think we should first solve the hard problems around security and
> format interoperability. We can always add new APIs once the
> underlying primitives are well understood. Doing that before seems
> rather dangerous. And as you point, without respect for historical
> precedent showing it's a bad idea.
>

Makes sense to me.
-Hallvord