- From: Bo Cupp <notifications@github.com>
- Date: Wed, 16 Mar 2022 23:00:00 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/393/1070354913@github.com>
Yes, you could restore all of them assuming we have platform support for adding custom formats to history and that there's no limit more restrictive than the 100 simultaneous formats that we already impose. The browser could be in control of what is marked to be included in history and we could choose to not provide the author any control. If we do allow the author to opt out of storing some formats in history though, we'll need to mark the formats they allow for history and our "Web Custom Format Map" as the set of custom formats to be included in a clipboard history entry. The "Web Custom Format Map" will have a complete list of the mappings from mime-types to all "Web Custom Format0..N" slots, but since the author chose to not add some of those to history, some mime-types will be dangling (the slot they refer to won't be restored to the clipboard when the user chooses to paste a clipboard history item). So the exception I was talking about is that apps which process the "Web Custom Format Map" must not assume that just because a slot is named in the map that it is also present on the clipboard. I think that's reasonable defensive code for any app to write even if we weren't talking about the clipboard history scenario, so I don't see it as a problem - dangling "Web Custom Format Map" mime-types should be ignored by apps reading the clipboard. I was just calling it out for completeness since we're thinking about potential problems when this model interacts with clipboard history. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/393#issuecomment-1070354913 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/393/1070354913@github.com>
Received on Thursday, 17 March 2022 06:00:12 UTC