Re: existing contenteditable spec

On Thu, May 28, 2015 at 2:46 PM, Frederico Knabben
<f.knabben@cksource.com> wrote:
> One of the ideas that made cE=typing was that cE should be “modular”. It
> means that “typing” was one of the modules but we could have others. In this
> way one could have contenteditable=“typing newline delete etc”, enabling a
> series of editing modules. Each module could be spec’ed independently.
> Finally, cE=true could be simply spec’ed as a shortcut to have all modules
> enabled.

What advantages does this have over keeping contenteditable
all-or-nothing and firing cancelable events that allow libraries to
override behavior selectively?  Note also that the syntax you suggest
(contenteditable="typing newline delete etc") will be interpreted by
existing browsers as the same as contenteditable="true", which I'm not
sure is the desired fallback behavior.


I forgot to mention, by the way -- my spec includes a partial
contenteditable=true specification, by way of this section:

https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements

This specifies behavior for Enter, Shift-Enter, backspace, forward
delete, and typing text, by means of defining them as equivalent to
certain execCommand()s.  It does not specify behavior for anything to
do with cursor movements -- that should be the same as
Selection.modify(), which at one point I looked at speccing but then I
ran away very quickly.  :)

If contenteditable=true is to be specced separately from execCommand,
these commands could be split out into the new spec.  I didn't look at
how practical it is to do that without dragging a lot of the existing
spec along.  Off the top of my head, the "restore the values"
algorithm requires implementing the entire algorithm used for inline
formatting commands, at which point it might make sense to just leave
execCommand() in the spec.  Also, their behavior depends on what
execCommand("defaultParagraphSeparator") was set to.  (These are
issues that any contenteditable=true spec will have to deal with, not
just one based on my spec.)


Thinking about it a bit more -- the fact is, to implement the user
deleting text (for instance), you really have to implement
execCommand("bold") and so forth anyway.  Because if you have this:

  <p>foobar</p><p style="font-weight: bold">bazquz</p>

and the user deletes the text "barbaz", you want to end up with something like

  <p>foo<span style="font-weight: bold">quz</span></p>
or
  <p>foo<b>quz</b></p>

and the method of detecting that "quz" was originally bold but no
longer is, and then making it bold, is logically equivalent to running
queryCommandState("bold") on the text and then execCommand("bold") to
change it.  So while deprecating execCommand() is sensible, I think we
still effectively need to spec a lot of the command logic if we want
to spec UA behavior for things like delete.  At that point we may as
well just spec execCommand() itself.

Received on Friday, 29 May 2015 12:09:39 UTC