Re: existing contenteditable spec

On Tue, May 26, 2015 at 8:49 AM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On 26 May 2015, at 14:09, Arthur Barstow <art.barstow@gmail.com> wrote:
> >
> > On 5/22/15 1:31 PM, Johannes Wilm wrote:
> >> I personally don't have any license preference. But it would be
> preferable if it could all be under the same license so the terms are
> clear. Also, it should be whatever is the standard for the w3c.
> >
> > I presume work on the four documents Ben started (inputEvents.html and
> the 3 contentEditable*.html specs) will be continued so I just changed
> those documents to use the ED template and that automagically gives them
> the `standard` w3c copyright.
>
> This is the right URL to be looking at these, right:
> https://w3c.github.io/editing-explainer/input-events.html
> https://w3c.github.io/editing-explainer/contentEditable.html
> https://w3c.github.io/editing-explainer/contentEditableTrue.html
> https://w3c.github.io/editing-explainer/contentEditableTyping.html
>
> If so, refspec seems to be failing to load for some reason, as I'm getting
> completely unstyled documents.
>
> > I did not change execCommand.html, primarily because it appears this
> group might not progress that document "as is". However, if the group does
> agree to work on it, then yes, we seek advice on how to handle that
> document's copyright.
>
> As far as I can tell:
>   https://w3c.github.io/editing-explainer/historic-editing-apis.html
> and
>   https://w3c.github.io/editing-explainer/execCommand.html
> are the same, except for the presence of one extra section (Selections) in
> the first one, and they are copies of:
> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
>

The contents are currently very similar, yes, but I spent about 2 hours
going through them to convert the file format (adding sections, etc.) and
make them work with respec. Also, the start is different, making clear that
one is a draft spec and the other one isn't.

Whether we need both, one or none depends a bit how we go on. Some have
suggested we properly spec execCommand. So I assume that that document will
develop in one direction mainly with contributions by all those who want to
see execCommand live.

At the same time, I thought a lot of good information was collected in the
old document about how browsers currently work or used to work, so I turned
it into a "non-spec" historical info doc. This sort of research may
continue as well, but somewhat independent of the execCommand spec. Also
because one solution may be to create a "new execCommand" (execCommand with
a different name) that behaves according to spec, while the old execCommand
lives on to support legacy apps.

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