Wording around default actions needs updating

[foolip]

The model, as discussed in [https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230](bug 12230), is:

if (target.dispatchEvent(event))
  doSomethingByDefault();

In other words, instead of saying "the default action of the beforecopy event is to ..." and (in one place) "If the event's default action is not prevented", the spec should consistently look like the cut action, where it's "fire a clipboard event named cut" followed by "if the event was not cancelled".

Also s/cancelled/canceled/ everywhere :)

[hallvors]

Is it OK to use the "default action" phrase in a sentence like

In a non-<a>editable context</a>, or if there is no selection, the cut event's default action is to do nothing.

?

[hallvors]

(I rephrased that anyway, it's clearer to talk about the "cut action" than the "cut event's default action". The "default action" concept still appears in three places or so, and I wasn't quite sure how to rewrite those.)

[annevk]

The way you want to fix this is effectively rewriting the declarative prose into an algorithm from which you dispatch events and update UI. The way the document is written now will never result in this getting fixed I think. I believe we have discussed this, but I'm happy to help over IRC (or elsewhere as you prefer) if there's something still unclear.

[hallvors]

Yes, we've discussed it and I believe most of the document now follows your recommendations. I'll ping your on IRC anyway in case there are things I've forgotten about :)

The part that doesn't is the onbefore* stuff, which is where Philip pointed out the main remaining cases of "default action"-type descriptions.

I think writing the spec more like an algorithm (AKA "processing model") was a great exercise that made me spot several inconsistent parts and corner cases. However, I also think that algorithm-style specs are harder to read. The onbefore* stuff seems very simple, so I don't think it really needs an algorithm-style section. @foolip , what do you think?

[hallvors]

(I forgot that it has an algorithm-type section already, in addition to the prose - but Anne is pointing out that there are some issues left to define - #15 has details)

[foolip]

Which is the remaining bit around before* events that needs fixing, one of these sections?
https://w3c.github.io/clipboard-apis/#processing-model-for-before-events
https://w3c.github.io/clipboard-apis/#otherevents

I guess this issue should still be open.

[hallvors]

There are currently three instances of "default action", but neither of them are in the before* sections.

There's one note just reminding readers that script-generated events don't have default actions (which I guess is OK to leave as-is), and two cases in "other events" in text that is just trying to clarify how to prevent a copy action from key events:

If the clipboard operation is triggered by keyboard input, the implementation must fire the corresponding event as the default action of the keydown event that initiates the clipboard operation. For example, if the user presses Ctrl-C to copy, dispatching a copy event must be the default action of the C key's keydown event.

Not sure how to rewrite that.

[foolip]

Oh, I see. What is the expected order of keydown, keyup, keypress, beforecopy and copy events when pressing Ctrl-C? I'm thinking that https://w3c.github.io/uievents/ has to be changed to say that there are certain UA-defined combinations of keys and modifiers that trigger clipboard events, and to define precisely at which step a ClipboardEvent should be created and fired.

[hallvors]

That would be nice. If it were handled in uievents we could just drop this text from the clipboard spec. My main concern was leaving it underdefined where you'd expect preventDefault() from stopping the copy action & event from happening.

[foolip]

I guess that canceling the before* events is supposed to prevent the copy/paste/cut? If so I'm thinking that some specs says the equivalent of:

  var event = new ClipboardEvent('beforecopy');
  // event.isTrusted is true
  if (target.dispatchEvent(event)) {
    platformLevelCopy();
  }

[hallvors]

@foolip cancelling before* event does not prevent copy/cut/paste events. Cancelling certain key events does, if the copy/cut/paste action is triggered from the keyboard.

I don't think it is an important use case to be able to prevent those events from happening in the first place, so this text was just trying to clarify something that might cause implementation differences and compat problems down the road.

[foolip]

I see, so the spec that binds a user-defined key combination to copy/paste actions also needs to only invoke the copy/paste actions if those key events are not canceled.

[hallvors]

I have killed the before(cut|copy|paste) events. I think we can get away with inventing something better because even the existing legacy implementations were so poor I don't think anyone can actually use this, and the events themselves were rather confusing (some evidence of that is earlier in this very discussion..)

Now, @foolip and @annevk - not sure what, if anything, still needs to be reworded to fix this issue. The UIEvents spec should certainly say when (relative to other events) keypresses trigger the copy|cut|paste actions from the Clipboard Events spec. There's some stuff in my spec about the order of events, perhaps it should be removed if we get similar stuff into UIEvents.. But what exactly is this issue about?

[annevk]

The specification still mentions "default action" as if it is a thing. Since there's no "default action" those paragraphs should probably be reworded.