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

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.

On Wed, Aug 5, 2015 at 9:51 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 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.

That's just the reality of it, though.  This e-mail is encoded in
ASCII with hardcoded line breaks at 80 columns because that's the way
terminals worked a few decades ago.  And if I want anything different
. . . I have to encode it as ASCII in base64 with hardcoded line
breaks at 80 columns.  Packet sizes on the Internet are 1500 bytes
because that was was Ethernet switches could take back in the day, so
routers need to route millions of tiny packets a second instead of
thousands of reasonable-sized ones.  The keyboard I'm using is
formatted based on what made sense for typewriters.  There are tons of
other classic examples from all over computing (and outside
computing).  Once something is entrenched, it's very often stuck for a
very very long time, because you can't coordinate everyone to remove
it at once.

> Also, I do not think that people in 200 years time will keep execCommand
> around because someone wrote a webpage in 2007 using it and refuses to
> change it now.

No, but since browsers in 2015 still have to support it, some people
writing new pages will decide they want to use it in their new pages.
This may be true indefinitely.  So yes, it's *possible* that the
feature will be removable at some point in the far distant future.
But realistically, the track record for removing this sort of thing is
not good.

Anyway, I personally don't really care what you call it.  But be aware
that the word "deprecated" will elicit negative reactions from a lot
of people in web standards-land, because it evokes the ideological
battles that surrounded XHTML 2 and the creation of the WHATWG, which
to some degree are still ongoing today.  I think what would make
everyone happy is to call it "obsolete", and declare it not to be
conforming HTML, but acknowledge that it is still practically part of
the web platform for the foreseeable future.  That's what Hixie has
done for features like this in the HTML spec.  Marking it clearly as
an obsolete and non-conforming feature should ensure that spec writers
don't build on it, and scare away some authors from using it.

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?

Received on Wednesday, 5 August 2015 12:11:03 UTC