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

On Wed, Aug 5, 2015 at 2:10 PM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Wed, Aug 5, 2015 at 12:06 AM, Hallvord Reiar Michaelsen Steen
> <hsteen@mozilla.com> wrote:
> > (I'm still worried you're simply moving the complexity of implementing
> > editing well from the UA implementors to the JS authors. Probably a
> natural
> > impulse since the UAs have done a poor job.)
>
> I think that's exactly the right thing to do under the circumstances.
> This is what JS is meant for -- there's absolutely no reason for 95%
> of editing code to be built into the browsers.  Browsers should work
> on exposing primitives that are difficult for JS writers to do as
> well, not things that JS writers can do just as well.  Browser
> features are vastly more expensive than JS, because of the need for
> standardization, multiple implementations, inconsistencies between
> implementations, users not upgrading their browsers, etc.  If there's
> a problem with a JS library, it can be fixed by the site author in an
> hour if he has the right tools.  Browsers -- good luck.
>

Well, Aryeh - I guess you and me have been working different parts of the
browser-website tech circuit. I have been doing outreach to websites on
behalf of Opera and later Mozilla for many, many years - trying to get
sites to fix clearly broken and wrong code. During those years, spec
editors, browser vendors and QA people have taken us through absolutely
*magic* transformations: HTML5 happened, new HTML parsing algorithm
happened, test suites were written and regression test frameworks
automated, JS and CSS likewise went through significant updates and
rewrites. So my experience and perspective becomes the exact opposite of
yours: it takes only a few people (say, one spec author, one C++ coder and
one QA person) a few weeks or months to improve a browser, but if you've
found a bug in TinyMCE or one of the other libs and need to get a million
sites to update it -- good luck!

(This is a philosophical discussion which we should probably not burden the
editing-tf mailing list with, so I'll try to make this my final response..)


>
> Nevertheless, having some kind of spec is a good idea in principle,
> because implementers still do maintain their implementations to some
> degree, like fixing bugs.  I don't know if my spec is actually useful
> from that perspective to anyone other than me, because it's very
> complicated and I don't know if it's comprehensible to anyone else
> without a lot of study that they aren't going to put in.  I think it's
> probably best to keep it around somewhere, but prominently indicate
> that the feature is obsolete and non-conforming.
>
> Is everyone happy with that?
>

I'm certainly happy with that, and I would also like the very minor change
that will say execCommand with copy/cut/paste argument should trigger the
corresponding actions in the clipboard API spec - to describe the current
state of affairs and help implementors who want to be compatible with
legacy code out there. For atonement I promise to follow up suggestions for
a new API for writing to the clipboard - one that will not use
execCommand() ;).
-Hallvord