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

I have updated the notice at the top of the two specs with this text, which
is a combination of the one Aryeh used and the one we had, taking into
consideration the criticism here on this list:

*"This spec is incomplete and it is not expected that it will advance
beyond draft status. Authors should not use most of these features
directly, but instead use JavaScript editing libraries. The features
described in this document are not implemented consistently or fully by
user agents, and it is not expected that this will change in the
foreseeable future. There is currently no alternative to some execCommand
actions related to clipboard content and contentEditable=true is often used
to draw the caret and move the caret in the block direction as well as a
few minor subpoints. This spec is to mean to help implementations in
standardizing these existing features. It is predicted that in the future
both specs will be replaced by Content Editable Events and Input Events."*


I left out the part about old websites, because in the cases were old
websites use execCommand, they will also depend on the existing broken and
inconsistent behavior, so doing any change at all to implementations will
likely break those sites rather than fix them.

If this is good enough for the time being, then I will leave it at that.

On Thu, Aug 6, 2015 at 5:01 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

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



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