Re: existing contenteditable spec

On Wed, May 27, 2015 at 2:56 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> I noticed that. That should go into the contentEditableTrue spec. But also that may be deprecated. The new "contentEditableTyping" spec just records user intentions (user tried to add a line break), but the default action is None, meaning that it has to be entirely handled by Javascript. Even caret movement will be turned into mere "intentions".

Hmm -- I can see why full-fledged editors would prefer that, yes.  The
question is whether there's significant demand for
contentEditableTrue.  Maybe there's not so much.  On the other hand,
interoperability is not so bad and browsers could probably converge
here.

Note that with the EditingBeforeInputEvent that I specced (and I don't
think anyone ever implemented), things like hitting enter are events
that can be captured and cancelled if a script wants to cause its own
effects.  Likewise there are events for keypress and so forth that can
be intercepted.  I think the standard way to implement this
contentEditableTyping thing in terms of web technologies would be to
use contentEditableTrue, but fire cancelable events for all user
actions.  These can be abstract actions that express user intents, on
a higher level than keystrokes.  But there's probably been a lot of
discussion on this already that I've missed.

One important question to ask is: do editing libraries not want to use
contentEditableTrue because it doesn't serve their needs at all?  Or
because it's not presently interoperable?  If it's mainly the latter,
then the best way forward is probably to work on interop of
contentEditableTrue and allow scripts to hook into it.  Only if the
libraries really want to rewrite everything that all keystrokes do
does it make sense to have a whole separate system (and maybe not even
then).

>  Ok, understood. Yes so it may be that the specification gets a big sticker "deprecated" on the top and that it then doesn't evolve much further from there. It may be that it gets the sticker, and that it still evolves. Or it may be that it gets no sticker and just evolves.
>
> There seem to be different ideas about how to proceed with either execCommand or ContentEditableTrue.

execCommand is basically useless for editing libraries, because
interop is too bad, and it's far too complicated and rigid.  In real
life the way forward is libraries.  Browsers might still want to
converge on execCommand behavior to better support existing sites, but
I'm not sure if that's what this task force is focused on.

I'm not sure at all that it's a good idea to deprecate
contentEditableTrue.  I think getting browsers to converge and adding
suitable hooks is probably better, unless there's something I'm
missing.  That way, if a library happens to be okay with the way
browsers handle some things, they don't have to bother overriding
them.  If they're not, they can just override everything and nothing
is lost.  I'm not sure what an entirely separate feature adds.

> We were told by some browser people that it may be dangerous to touch the existing execCommand & co due to sites depending on the various bugs it has. And that the way forward may be to create new versions that function properly.

I don't think there's demand for new versions, so if browsers don't
want to touch their implementations, there's no use in a spec.  My
experience here a few years ago was that browsers might have been
theoretically interested, but certainly were not willing to devote
resources to improving.  Which is why I stopped working on the spec.

> All the test scripts have been properly transferred and copied. It's just that neither one of you bothered to check the github repositories. :)

Guilty as charged!  :)

On Wed, May 27, 2015 at 3:35 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> Could we put these into Note blocks or something like that? The respec
> system doesn't seem to play well with other javascript.

They're in class=comments, so you can do whatever you like with them
via CSS or JS.  I think making them collapsed by default is a good
idea, because they're not really interesting if you're reading the
main content of the spec, and some are very long.

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

Agreed.  It's only useful to support legacy pages.

Received on Thursday, 28 May 2015 11:23:50 UTC