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 9:51 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
> ...

> > 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.
>

Possibly, yes. But given that it is such a nightmare to work with, and just
about everyone needs to either use one of the editor projects (such as
CKeditor, Aloha Editor, 1.0, TinyMCE, etc.) OR have a large programming
staff for maintenance (such as Gmail), and all of these will likely switch
once an alternative is viable, I think this is the smallest problem. The
problem is more with sites that have an old version of TinyMCE merged into
their custom built code that they refuse to update to a newer version of
TinyMCE... That will possibly work for a long time, until newer browsers
break some other parts that custom solution is based on, at which stage the
page will need reprogramming anyway.

But all that is just speculation. Let's see how it goes. Clear wording that
W3C should make sure not to make their specs depend on execCommand is the
most important thing here.


>
> 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.
>

I am too new to this to have followed those religious wars, so thanks for
pointing out what they mean for some people. Using the terms "obsolete" and
"non-conforming" is fine for me.

And I think all of us realize that even though this is what the situation
looks like right now, things can always change in the future. So there is
the possibility that execCommand will experience a second spring, in which
case we simply will remove the warning again.


> 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.


My experience with the bugs I have filed with browsers is that they don't
care about it. But of course that may change one day.



> 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 think this is a good solution. All of the text of your specs is preserved
so far, and we won't change that. The text of the warnings at the top of
the specs will be adjusted to use wording that isn't considered offensive
to anyone.

Also, I don't think anyone would mind for people to continue to work on
those drafts, as long as the prominent warnings aren't removed.


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org