Move script-created events out of "fire a clipboard event" about clipboard-apis HOT 49 CLOSED

@foolip the intention here is to both handle events that fire due to a script calling dispatchEvent() and events that fire due to a script calling document.execCommand('copy'). (I guess that should be clarified). The execCommand() call will trigger a copy action (as defined by the spec), which will run the 'fire a clipboard event' algorithm. So I think this still needs to take into account whether it was triggered from JS (i.e. execCommand()) - unless you can suggest a different way to structure it..

from clipboard-apis.

Why do you need to say anything about a script calling dispatchEvent() @hallvors? Doesn't DOM already define everything there?

from clipboard-apis.

To really handle both you would have to monkey patch dispatchEvent(), as written there is no way for a scripts to reach this algorithm, although it's not entirely clear what would invoke the "copy action".

To make document.execCommand('copy') work properly my hunch is that https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html would have to be fixed I think. Now it just says "This specification does not define exactly how the selection is to be copied to the clipboard, but the Clipboard API and events specification might be useful."

from clipboard-apis.

I don't need to redefine dispatchEvent(), this is really about the execCommand() actions.

The idea (thanks to @annevk 's advice earlier) is that my spec defines "actions" which the editing spec should be updated to reference.

from clipboard-apis.

So I guess I could change text like "if the event was triggered by a script" to "if the event was triggered by an execCommand action"?

from clipboard-apis.

Well, maybe, but then the execCommand spec doesn't ever actually create and fire clipboard events, so strictly speaking everything that followed would be dead code.

I think that either the execCommand spec needs to explicitly integrate with the Clipboard API spec, or add extension points for other specs to do their own thing, which could be used by the Clipboard API spec.

from clipboard-apis.

The plan (if there is one) is the former - rather than the "clipboard API spec might be useful" text, that spec should just say that the copy/cut/paste commands trigger the corresponding actions as defined in the Clipboard API spec.

from clipboard-apis.

That sounds good. Last I checked @ayg did not have any plans of working on the spec, so I'm sure if you want to do it the honor will be yours :)

from clipboard-apis.

Still, I assume there's some difference between calling execCommand('paste') and the user pressing Ctrl+V? If there isn't, then a site could read the clipboard at any time.

from clipboard-apis.

@foolip see steps in the definition of the paste action https://w3c.github.io/clipboard-apis/#the-paste-action

from clipboard-apis.

..although the steps in https://w3c.github.io/clipboard-apis/#integration-with-rich-text-editing-apis should probably be moved into those actions, because it's confusing to have it in two places..

from clipboard-apis.

..that's now #18 and here's a bug on saying something we want somewhere in Editing land: w3c/editing#61

(Should I also submit a PR to @ayg ' s editing spec? I'm not really paying attention to those spec efforts, my bad..)

from clipboard-apis.

I wasn't aware of http://w3c.github.io/editing/execCommand.html until now, looks like that's the new place for the spec, excellent!

from clipboard-apis.

@foolip see steps in the definition of the paste action https://w3c.github.io/clipboard-apis/#the-paste-action

OK, I see. I agree that if execCommand() comes with some permission requirements, then doing those in the execCommand seems better.

from clipboard-apis.

(That seems like a minor question of spec editor workload distribution, but FWIW I think it makes sense to let various specs define "actions" or "commands" execCommand can just invoke, and that those actions/commands can have their own security requirements. Otherwise you have to edit the Editing / execCommand() spec every time you add a new command with different security requirements, no?)

from clipboard-apis.

(BTW - the "editing community group" has put Aryeh's text in their repo but they don't seem to plan to actually update it - all their work is about making something new and shiny to replace the contentEditable=true / execCommand() approach.)

from clipboard-apis.

@hallvors : Indeed, that seems to be the current state of affairs, although it is a taskforce and not a community group. The main point of the taskforce is to make editing in the browser usable and taking on all the editing spec works and figuring out which ones are to survive and which ones aren't. The feedback we have received from browser makers so far has been that they have no interest at all in implementing a contentEditable=true or execCommand specification and that they would also like to see both deprecated. Additionally, we have discussed whether we should deprecate these features but still write the specs for them, and the feedback has been that there is no interest in implementing such specs if these features are deprecated anyway.

Also, we have not been able to found anyone willing to spend time on working on these specs and noone has suggested spending any time at the F2F to work collectively on these specs.

With that in mind, it seems fairly plausible that the F2F meeting either decides to remove all text of the spec drafts and replace it with a text discouraging the use of execCommand and contentEditable and deprecating these, or that it will postpone this decision to a later date but to not allocate any further time to work on these.

Of course you guys can change it all. The F2F meeting in Paris 23-24 August will also be accessible through IRC, etc. so if you have a good argument why these should continue to be developed and someone has the time required to work on these, I don't think anyone will be against doing that.

from clipboard-apis.

@foolip @hallvors Sorry for the confusion. I have added notices to both specs that they will likely be deprecated in the near future.

from clipboard-apis.

@johanneswilm that doesn't mean anything if browsers can't remove those features. How many XHTML 2.0-like efforts does it take before enough of the standards population realizes this?

from clipboard-apis.

The feedback we have received from browser makers so far has been that they have no interest at all in implementing a contentEditable=true or execCommand specification and that they would also like to see both deprecated.

@johanneswilm, this is very surprising to me. To lack the interest or resources to maintain execCommand() is one thing, but to hold out hope that it could eventually be removed (why else deprecate?) seems unwarranted.

If the W3C Editing TF doesn't continue work on execCommand() then someone else will have to, at least to minimally maintain it so that integration jobs of the kind discussed in this spec can be performed.

from clipboard-apis.

@foolip Others can of course join the editing taskforce, and argue to not deprecate execCommand. The point is precisely to coordinate the efforts in the area of editing in this taskforce. It's not a lack of interest in execCommand that makes people want to deprecate it. It is more an active wish to make it go away that seems to drive this pending decision.

@annevk Of course, it will take a while before execCommand can be removed entirely from browsers due to the legacy code that is out there that depends on it. That is likely also why they preferred to replace cE=True with something entirely new.

But I suggest for all of you guys to join the mailing list and argue your point.

But even if contenteditable=true/execCommand is to be revived, none of this will influence the new specs in which execCommand will not work.

from clipboard-apis.

@johanneswilm of course it does since you need to figure out how they work together. There's no mode switch.

from clipboard-apis.

@annevk: Not sure what you are referring to. CE=intentions (or whatever it will be called in the end) is specifically meant to not work with execCommand. There has been a long discussion about that some months ago.
We really only need one, or possibly two new functions then: one to initiate copying, and possibly one to initiate paste with some checks that they are user initiated. Whatever checks you use for the equivalent legacy execCommand functions should work here as well. Cutting should not need to be something apart from copying as all changes to the DOM will be handled directly by JS code.

from clipboard-apis.

@johanneswilm, the important question isn't whether we deem execCommand() to be deprecated and hope for its eventual removal, but whether it can in fact ever be removed from browsers.

My assumption is that execCommand() cannot ever be removed, and thus that deprecation is meaningless. If it would help inform the discussion, I'd be happy to add telemetry to Blink to measure just how high usage of execCommand() is. In the best of worlds, I'll be surprised and it really can be removed, but I wouldn't bet on it. If I'm right and usage is high, I would strongly advise against trying to design something new that doesn't define how it works together with execCommand().

from clipboard-apis.

I think you guys should just forget about execCommand. Just do the exact same thing you guys were planning to change in execCommand by inventing a new fubction name. I realize that what you guys are doing is important, but most of execCommand is just unusable clutter that is not used in today's editors anyway.

from clipboard-apis.

@johanneswilm you cannot just forget about execCommand. It's there and it'll be invoked. What's the interaction of this new contenteditable value with designMode?

from clipboard-apis.

And please don't use "you guys", some find it exclusive. Try "you folks" instead.

from clipboard-apis.

It turns out there is a use counter for Document.designMode already, usage is far above what's normally considered for deprecation or removal in Blink:
https://www.chromestatus.com/metrics/feature/timeline/popularity/742

Not sure if Document.execCommand() usage would be higher or lower, but if anyone really hopes for its removal I could measure to attenuate those hopes.

from clipboard-apis.

@annevk: my apologies. I am not a native English speaker. I could also "y'all" if that makes it better.

No, execCommand will likely not be directly removed from browsers in tge near future. However, in order to lower its usage over time it will most likely be marked as deprecated and the spec not developed further. That's why new features, such as what you are workibg on, should not be added to execCommand.

Of course y'all can change the course of history by reopening the debate. I don't think I would do that though, because there are quite good reasons to get rid of the rest of execCommand and you adding new features exclusively to execCommand with no alternative will only prolong the process.

from clipboard-apis.

@johanneswilm, if the Editing TF is not interested in maintaining the execCommand spec, then please just remove http://w3c.github.io/editing/execCommand.html instead of calling it "deprecated".

When someone comes along to pick up the slack, they'll presumably find another venue to work on execCommand.

from clipboard-apis.

This is not a new feature though. This is mostly about describing an existing feature that a ton of sites rely upon, including GitHub these days. I don't think we need copy/paste primitives really.

from clipboard-apis.

Just to pitch in in support of Johannes -- it's true execCommand etc. will probably never be removable, but the cost-benefit ratio of making it interoperable is extremely unfavorable. The status quo is all browsers have some sort of implementation that makes the web work, and implementations are extremely complex and fragile and regression-prone. Breaking existing sites is very easy, and existing sites are happy enough with the current complete lack of interop, and few new sites want to use it (they mostly prefer JS libraries). So I don't think browsers are likely to bother converging in the foreseeable future, and there's no need for a spec. Which is why I dropped the spec -- no one wanted to implement it.

That said, I don't think "deprecated" is the right word to use, because it suggests it will eventually be removed, which is optimistic. I would rather say that the feature is not standardized and there are no plans to standardize it, and authors are encouraged to use libraries based on standardized features instead.

from clipboard-apis.

I don't see how that helps new implementations, e.g., Servo. It doesn't seem responsible. And as mentioned it does not cover just editing, but also related operations that are supported in the same way across browsers, and do not need new API surface.

from clipboard-apis.

I am fine with using another word, although I do think that once TinyMCE, CKeditor and a handful of other editors out there concert to alternatives, usage will drop quite a bit, as it's rather impossible to use execCommand directly, without a JS based editor.
I didn't add anything extra to the spec as I wanted to wait for theF2F meeting to decide how to proceed. Now that I noticed that y'all had not followed the discussion in the taskforce and were busy working more on top of execCommand, I thought it was in its place to add a warning that this is not something to build more on top of.

I am sure the F2F can come up with a more precise wording.

from clipboard-apis.

It doesn't help new implementations. But don't blame us, complain to the implementers. AFAIK, none has any interest in rewriting their implementations to converge. Therefore writing a spec is pointless.

from clipboard-apis.

I think that even if nobody is actively trying to converge with the spec as a project in itself, it would be valuable to have a spec that can be changed when specific problems come up and a browser wants to make some change, as has happened for me twice even though I have no specific interest in execCommand:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27533
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27552

If there were a goal statement for such a spec, it would be to reduce execCommand to the minimum set of commands required for web compat.

@ayg, would you mind if you old spec were published at https://editing.spec.whatwg.org/, or do you think that the mere impression of "this is maintained" is a net negative?

from clipboard-apis.

In practice the spec is occasionally useful to me, but it's probably useless to anyone else, in real life -- you'd have to spend a bunch of time to understand it, and I don't think anyone else has or will. So if no one wants to take over maintaining it, leaving it where it is is fine (basically just somewhere where I can access it). If someone wants to take over maintaining it, great, although I think they're wasting their time.

Incidentally, the one thing that's really useful IMO is the spec's conformance tests. They take a long time to run, but at least for Gecko, they're absolutely invaluable as regression tests when making any sort of changes to the editor. (Assuming you pass enough to start with for them to be useful, I guess.)

from clipboard-apis.

It looks like those tests aren't part of web-platform-tests, right?

from clipboard-apis.

Yes, please lets deal with this in the editing taskforce and join the taskforce if you want to work on this. None of us are religious about any of this, but on the JS side of things we have now experienced about a decade with little progress in terms of getting cE to work consistently and predictably and the taskforce seems to finally be a step forward.

from clipboard-apis.

I'm afraid I don't have the bandwidth to get involved with any more groups. I would just like for there to be a spec for execCommand, and if the Editing TF isn't taking that on, fine, hopefully someone else will. In that case please just leave it orphaned instead of saying that it's deprecated, at least until there's a credible plan for removing execCommand. (Otherwise anyone who takes up work will have to compete with your unmaintained copy for search engine rankings, a common problem in the land of specs.)

from clipboard-apis.

@ayg the problem is that currently it is published nowhere and that even somewhat trivial changes cannot be integrated. I would be happy to work on both getting it published and doing trivial changes. And perhaps at some point figure out if it's good enough for Servo to implement from.

from clipboard-apis.

@foolip Correct. They're here:

https://dvcs.w3.org/hg/editing/file/07d356bde327/conformancetest
https://dvcs.w3.org/hg/editing/file/07d356bde327/selecttest

conformancetest/runtest.html is the most interesting one. Note, it takes a long time to run. I've been meaning in theory for a long time to split it up into multiple files. Getting it into web-platform-tests would be a worthwhile project, if people don't mind how long it takes to run (and that there's no real spec for it).

@annevk Please feel free.

from clipboard-apis.

@annevk You are welcome to join the editing taskforce. If you fulfill the W3C requirements for spec editors (whatever they are), I don't think anyone will stop you from becoming a spec editor. But of course the taskforce/involved working groups can overrule your draft decisions, such as saying whether it is deprecated or not.

@foolip As previously described, the editing task force has taken these on. It's just that the task force's conclusion seems to be at this stage to want editing to not depend on execCommand and for implementations to prioritize other things than execCommand. So noone else should be working on these drafts. Also you are likely very welcome as an editor, under the same conditions as @annevk.

That being said, I don't think anyone would mind for y'all to be working more on those drafts, as long as you leave in warnings at the top of specs communictaing to others to please do not make anything else depend on those specs and instead focus on these newer specs.

@ayg and @annevk Also the tests were transferred correctly and can now be found here: https://github.com/w3c/editing/tree/gh-pages/tests/historic

from clipboard-apis.

@ayg @annevk The editing tests dirs lacked index files, which means that github pages didn't show their contents. I have now fixed that by adding those manually. All the links to tests in https://w3c.github.io/editing/historic-editing-apis.html#tests should therefore work now.

Please be aware that although very similar to Aryeh's last draft, this is not entirely the same. Among other things, quite a few large commits were necessary to make it work with ReSpec. In order not to confuse the matter even more, please refer to the newest drafts and not the older ones.

from clipboard-apis.

@johanneswilm If the Editing TF isn't planning on maintaining the draft or tests, I think it would be best if you didn't keep a fork. Could you just delete your copies and let my existing ones be the only ones? I'm happy to update it with a warning not to use it. In particular, I actually want to reformat the editing tests and get them into web-platform-tests.

from clipboard-apis.

Warning added at top of spec: https://dvcs.w3.org/hg/editing/raw-file/bc0c4afad8a2/editing.html

I didn't claim that the features are non-conforming, because I think that should be decided in the HTML spec, and make its way to the HTML validator.

from clipboard-apis.

@ayg that note seems incorrect at least for execCommand(), which is the only way sites can implement copy functionality without Flash today. GitHub recently switched away from Flash due to Firefox adding support for that. I wouldn't want to encourage developers to move back to Flash. Seems bad.

from clipboard-apis.

@annevk Patches welcome. (Or just suggested wording, if you prefer.)

from clipboard-apis.

Feel free to continue this discussion elsewhere, I think with the recent edits to both the spec about execCommand and the clipboard API spec the issue here is sorted out.

from clipboard-apis.