Re: existing contenteditable spec

On Wed, May 27, 2015 at 6:54 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Mon, May 25, 2015 at 1:36 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
...

>
>
> > With "historical behavior" I meant the behavior browsers currently show,
> and
> > your document seems to list a lot about how Opera X and Chrome 11, etc.
> > behave in this and this situation.
>
> These comments are hidden in normal reading, if the stylesheets and
> scripts are working correctly.  Those aren't part of the spec themselves --
> they're just background to explain why I specced it the way I did, in case
> anyone thinks it should be done differently.  (I originally made them HTML
> comments.)
>

Could we put these into Note blocks or something like that? The respec
system doesn't seem to play well with other javascript.


> Specs of existing features need to always match preexisting
> implementations as much as possible, because sites depend on how existing
> implementations work, and changing existing implementations is always
> risky.  It could break sites, which makes users angry, so implementers are
> unwilling to do it unless strictly necessary.  A spec that deviates too
> much from existing behavior is very unlikely to get implemented in
> practice.  So any spec of contenteditable needs to be closely based on how
> current browsers behave, or else it will probably not wind up getting used.
>

Yes, that's one of the reasons we were given for why
contentEditableTrue/execCommand could be entirely unspec'able and that
instead we should invent something entirely new that will depend on a
Javascript editor implementation and cannot be used alone.

Others would want execCommand to be spec'ed (under it's current name or
another one). There is also a suggestion to spec execCommand fully, but to
not make it depend on an editing host the way it currently does. Then there
is Florian's suggestion to only spec part of execCommand and throw the rest
under the bus.



*From talking to those creating complex editing libraries as well as my own
experience, it seems to me that execCommand is not used for its intended
purposes by semi-advanced editors. Sometimes it's invoked, but that's just
to get around bugs in contentEditableTrue itself.*


So personally I do not care too much which of the options we end up
choosing. The important part for me is that:

1. JS editor makers should not have to depend on execCommand for anything.

2. Whatever path we choose, we do not say "we won't deprecate
contentEditableTrue/execCommand, but we are not going to spec it either".


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