Re: existing contenteditable spec

On Fri, May 29, 2015 at 8:08 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

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


To Frederico's defense: This is what the browser people told as their plan
initially. Fixing contentEditable=True was "unfixable", and this was the
way forward. Up until now we have only been discussing
contentEditable=typing and the other parts have not been touched.

In a certain sense I think it's good that we have focused on the one and
most important part so far, because efforts to fix contentEditable have
been derailed so often in the past, as we all know, so it's really
important that we keep this one going.

But once we have a clear wording of cE=typing, I would be in favor of
looking at these other parts. However, I also think they could likely
(initially) be implemented via JavaScript. Following the principles set out
in the Extensible Web Manifesto, we start out by having defined the
primitives needed to make this happen in JavaScript libraries. The
construction of JavaScript libraries for this purpose and writing of specs
would then happen in parallel.

Once the JavaScript libraries and the specs stabilize sufficiently, and if
there is an interest from browser makers, these specs can then be
implemented by browsers. Alternatively they simply stay W3C specs
implemented in Javascript.



> 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 wonder if we need to invent a new attribute name to make sure we don't
accidentally end up with contentEditable=true by acccident. To me it would
seem that would be the cleanest.


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


Yes, I noticed that, and I think we need to transfer this to the
cotnentEditableTrue specification.

>
>
> This specifies behavior for Enter, Shift-Enter, backspace, forward
> delete, and typing text, by means of defining them as equivalent to
> certain execCommand()s.


Yes, that's why I found it difficult to extract only the parts related to
contenteditable without also copying execCommand. But I think with a little
more time and some careful assessment of what is where, this should be
adoable.


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

There is a selection APi that is actively being worked on.
http://www.w3.org/TR/selection-api/  . I don't think caret movement is part
of it.

For contenteditable=typing I have defined some basic steps, but they are
not that developed, also because I was thinking that most advanced editing
libraries likely will ignore them anyway. I recently removed them when it
seemed that we would only do caret movement intentions and handle the rest
in Javascript, but from the lastest feedback from browser makers it seems
like we want this text anyway.

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


Yes, let's try to do this using the already converted documents [1][2] and
not the one from the mercurial repository. Right now the text is still
quite similar, but the structure of the HTML is already somewhat different
(to comply with respec) .


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

I don't see that this is necessary. The logic should be so general so it
also works for:

<p>foobar</p><p class="somecustomclass">bazquz</p>



[1] http://w3c.github.io/editing/contentEditableTrue.html
[2] http://w3c.github.io/editing/execCommand.html

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