Re: on execCommand() and script-triggered copy/cut/paste

On Thu, Aug 6, 2015 at 4:46 PM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Thu, Aug 6, 2015 at 5:27 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
> > Well, we are making some updates to it, and the warning corresponds as
> far
> > as I can tell to the wording Aryeh preferred. We were doing some minor
> > things already before yesterday, so this spec is the one things happen in
> > and not the one from beginning of 2014. That entire discussion was some
> > months ago when maintainership was transferred. Aryeh and you are also
> > welcome to rejoin the drafts as part of the editor team if you want to
> add
> > something more to it yourselves.
>
> Okay, if you're actively maintaining it at all, or even think you
> might sort of be, then I'd prefer to delete my copy.  I'm not planning
> to work on the spec at all, and if I do want to make a change or two
> I'll submit a pull request.  What are the documents that replace my
> old editing.html, and are there links to readable HTML copies
> available (not just source code)?


Yes, we have been instructed to use github pages for this, which means that
github serves HTML readable pages directly based on the sourcefiles in the
gh-pages branch fo a github repository. So you can find all the files from
the github repository in a HTML viewable version here:

https://w3c.github.io/editing/


> I'll update my old spec with links.
>

I think the forwarding should be in place already. Is it not?

I have split it into three parts:

Historic:
https://w3c.github.io/editing/historic-editing-apis.html

execCommand:
https://w3c.github.io/editing/execCommand.html
https://w3c.github.io/editing/contentEditableTrue.html

The historic document I created thinking that we may end up deleting a
large part of the execCommand document and then it would be good to keep a
file with the research of current implementations. If we were to decide to
do a sort of "general relaunch of execCommand" then we may want to delete a
lot of functions or add a lot of functions, and then that would just be in
the execCommand doc.

So far the historic document and the execCommand contain almost the same
information (with the exception of clipboard actions), but one is a spec
and the other one just a document.

The contentEditableTrue doc does not contain a lot of information. Part of
the execCommand doc should eventually be moved there (about paragraph
splitting, etc.), but I have had a hard time figuring out how much should
go into the other document, as the execCommand doc will still need to link
to a lot of this.


I'd like to know what's happening with the tests, though.  If the spec
> is actually being updated, the tests will be out of sync, and as
> things stand the expected results can't actually be updated based on
> algorithm changes, because they need to be regenerated in a way that
> cannot be done right now.  If substantive changes are being made to
> the spec, it might be a good idea to ensure that there's a way to
> regenerate the tests, and that the spec editors do that whenever they
> make changes.  Otherwise, I guess the tests will just fall out of
> sync.
>

The tests I have left in the historic document, which should still be the
same information it had previously, so the tests should also correspond to
that. I just added index files so that the contents of the test file dirs
show up.

I just saw there were a lot fo files in there that I figured I would need
some longer time to figure out how relate to the tests (filenames such as:
MANIFEST, diff, dir, etc.).


> I just reformatted the tests to be more usable (many small files
> instead of one giant one) and made a couple of other tweaks based on
> changes made to Mozilla's local copy.  I think web-platform-tests is
> where these things are supposed to go these days -- if that's correct,
> the tests should live there, and other copies should be deleted.
>


Ok, you did this after we transferred the files to github (in May or
June?)? I also did quite a lot of changes to the files to make them work
with ReSpec back then. Did your changes only touch the test files? Would
you like to commit your changes yourself, or should I try to investigate
what has changed and then merge manually?


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