Comments (14)
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.
?
from clipboard-apis.
(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.)
from clipboard-apis.
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.
from clipboard-apis.
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?
from clipboard-apis.
(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)
from clipboard-apis.
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.
from clipboard-apis.
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.
from clipboard-apis.
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.
from clipboard-apis.
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.
from clipboard-apis.
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();
}
from clipboard-apis.
@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.
from clipboard-apis.
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.
from clipboard-apis.
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?
from clipboard-apis.
The specification still mentions "default action" as if it is a thing. Since there's no "default action" those paragraphs should probably be reworded.
from clipboard-apis.
Related Issues (20)
- Should clipboard-write permission be removed too? HOT 3
- Arbitrary clipboard types HOT 32
- What should `clipboard.readText()` return when the clipboard contains multiple clipboard items? HOT 7
- Clipboard Pickling: should the unsanitized option support a way to ask for all representations to be unsanitized? HOT 4
- Should `clipboard.writeText()` replace `\n` characters with `\r\n` on Windows? HOT 3
- `ClipboardItem` constructor should throw when `items` are empty HOT 4
- Feature detection for supported clipboard formats HOT 12
- Replacing no-break spaces when converting HTML to plain text upon clipboard export HOT 4
- ā¸āšā¸˛ā¸
- What are the mandatory data types for Asynchronous Clipboard API? HOT 2
- The MIME type checking should ignore the "web " prefix HOT 2
- Should reading the clipboard throw DataError or empty clipboard items? HOT 6
- Async clipboard read and race conditions. HOT 6
- Interoperability issue: `navigator.clipboard.write()` and `navigator.clipboard.writeText()` user gesture requirement HOT 18
- Shared clipboard across devices
- Cross-device Shared clipboard
- Undefined behaviour when handling data promise resolved value HOT 2
- Why does the Clipboard interface extends EventTarget?
- Broken references in Clipboard API and events
- Web Platform tests using "clipboard-read" HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
đ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. đđđ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google â¤ī¸ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clipboard-apis.