IRC log of editing on 2021-09-24
Timestamps are in UTC.
- 15:59:53 [RRSAgent]
- RRSAgent has joined #editing
- 15:59:53 [RRSAgent]
- logging to https://www.w3.org/2021/09/24-editing-irc
- 16:00:59 [Travis]
- Travis has changed the topic to: 9/24/2021 Editing WG meeting
- 16:01:07 [Travis]
- present+ Travis Leithead
- 16:01:14 [whsieh]
- whsieh has joined #editing
- 16:01:23 [BoCupp]
- present+
- 16:01:28 [comandeer]
- present+ Tomasz Jakut
- 16:01:42 [GameMaker]
- GameMaker has joined #editing
- 16:01:47 [GameMaker]
- present+
- 16:02:05 [whsieh]
- present+
- 16:02:07 [snianu]
- snianu has joined #editing
- 16:02:47 [alexk]
- alexk has joined #editing
- 16:03:28 [Travis]
- agenda+ https://github.com/w3c/clipboard-apis/issues/150
- 16:04:14 [Travis]
- scribe Travis
- 16:04:27 [Travis]
- agenda-
- 16:05:02 [Travis]
- BoCupp: rniwa was clear about not standardizing at this time. Is this a unified Apple position?
- 16:05:10 [Travis]
- whsieh: yes...
- 16:05:33 [Travis]
- .. we are not interested in pursuing the spec as written (using domparser and sanitization)
- 16:05:41 [Travis]
- BoCupp: is there some other sanitization you'd like to see?
- 16:05:53 [Travis]
- whsieh: ideally we leave that open-ended for the user agent.
- 16:06:24 [Travis]
- BoCupp: perhaps we don't have to spend the WG time speccing that... I suppose we can do as we see fit?
- 16:06:31 [Travis]
- .. anyone have other thoughts?
- 16:06:39 [Travis]
- whsieh: yes, regarding sanitization
- 16:06:52 [Travis]
- .. other things we could possibly align on... do we include HMTL/BODY tags?
- 16:07:07 [Travis]
- .. those are some of the details we could pursue for standards.
- 16:07:26 [Travis]
- .. however the fine details of "how to sanitize web content"; we'd like to keep that as UA-defined.
- 16:07:47 [Travis]
- BoCupp: e.g., read api returns a fragment vs a document?
- 16:07:55 [Travis]
- whsieh: seems nice to clarify.
- 16:08:05 [Travis]
- BoCupp: just that one point would be better than nothing?
- 16:08:22 [Travis]
- .. we have some preferences, wondering what the group would think about that?
- 16:08:49 [Travis]
- action: BoCupp to assert some of the points Microsoft would like to have in the Chromium version of the API; then check for agreement.
- 16:09:00 [Travis]
- a?
- 16:09:03 [Travis]
- agenda?
- 16:09:18 [Travis]
- agenda-
- 16:09:30 [Travis]
- Zakim, take up agenda 1
- 16:09:30 [Zakim]
- agendum 1 -- https://github.com/w3c/clipboard-apis/issues/150 -- taken up [from Travis]
- 16:09:34 [Travis]
- a?
- 16:09:37 [Travis]
- agenda?
- 16:09:45 [Travis]
- zakim, drop agenda 1
- 16:09:45 [Zakim]
- agendum 1, https://github.com/w3c/clipboard-apis/issues/150, dropped
- 16:10:20 [Travis]
- agenda+ https://github.com/w3c/editing/issues/334
- 16:10:27 [Travis]
- zakim, take up agenda 2
- 16:10:27 [Zakim]
- agendum 2 -- https://github.com/w3c/editing/issues/334 -- taken up [from Travis]
- 16:10:50 [Travis]
- BoCupp: Microsoft motivation is to have native apps write to the clipboard so that many sites can consume.
- 16:11:10 [Travis]
- .. heard from whsieh that a single origin could be specified to access the content...
- 16:11:21 [Travis]
- .. wondering if we could open this up to specify some core syntax?
- 16:11:36 [Travis]
- whsieh: discussed internally; we would like to limit to single origins.
- 16:12:27 [Travis]
- .. if we had to expose this, it would likely be a native api (os). Such an API would be very clear that the posted content could be read by un-trusted sites.
- 16:12:41 [Travis]
- .. if they opt-in, we would then allow the data (unsanitized) to be read by any site.
- 16:12:50 [Travis]
- .. (the native API would be opting in)
- 16:13:15 [Travis]
- .. with CORS-like scheme, in the end-game everyone would just specify "*" (no downside)
- 16:13:36 [Travis]
- .. if we do something like that, we should put this on app authors.
- 16:14:04 [Travis]
- BoCupp: you'd like to limit to single origin--and you have an idea on multiple origins?
- 16:14:16 [Travis]
- whsieh: I don't feel this would require standardization...
- 16:14:45 [Travis]
- .. a native app API that provides the ability to send to any site (doesn't require standardization)
- 16:15:10 [Travis]
- BoCupp: wondering if what is provided in the clipboard would have some special characteristics (standardized)?
- 16:15:40 [Travis]
- .. assuming adopting pickling w/sanitization... or is this free-for-all (don't pursue pickling)?
- 16:16:03 [Travis]
- .. if we build something like snianu made... details the shape of the format on the clipboard...
- 16:16:14 [Travis]
- .. having the presence of the format allows them to be shared...
- 16:17:37 [Travis]
- BoCupp: what would you put on the clipboard to indicate that it should be associated with a particular origin (related to pickling)?
- 16:18:03 [Travis]
- whsieh: I'm not proposing a format.
- 16:18:40 [Travis]
- .. today app would use NSPasteboard APIs to set data. In the new world, they'd use "WriteUnsanitizedContentForWeb"
- 16:18:56 [Travis]
- .. something explicit. Apple would take care of the format in the pasteboard.
- 16:19:21 [Travis]
- BoCupp: hmm. When Edge ships something, our approach isn't to create a new Apple API (we can't).
- 16:19:51 [Travis]
- .. what we will advertise is: here the format to put on the clipboard, and the JSON structure to make content available to web apps.
- 16:20:16 [Travis]
- .. When Apple comes up with a platform api that writes with a different shape? For apps, they need to bifurcate and write to different platform conventions.
- 16:20:27 [Travis]
- whsieh: there would be reading/writing separate parts.
- 16:20:46 [Travis]
- .. apps writing unsanitized data would use new API.
- 16:21:04 [Travis]
- .. other browser would use a corresponding app read API.
- 16:21:23 [Travis]
- .. this also gives us the ability to copy data between browsers because they're on the same platform, and it would just work.
- 16:22:21 [Travis]
- BoCupp: so, if safari has it's own formats for interchange different from Chromium they'd have to agree..?
- 16:23:02 [Travis]
- whsieh: not quite. Any app could use the unsanitizedNativePlatformAPI and you'd achieve interop.
- 16:23:11 [Travis]
- .. because the details are abstracted.
- 16:23:35 [Travis]
- BoCupp: We're still interested in standarizing something that works cross-platform... we have a proposed content shape..
- 16:24:00 [Travis]
- .. with a mime-type it might be translated differently on different platforms. We might use different syntax...
- 16:24:06 [Travis]
- .. (thinking0
- 16:25:05 [Travis]
- .. I guess we go into each platform domain (Linux, Windows) and specify how pickled content would look.
- 16:25:37 [Travis]
- whsieh: given the JSON map, would the types be different per-platform?
- 16:25:54 [Travis]
- BoCupp: the map just takes author-specified mime types and mapping to a format that can be read.
- 16:26:02 [Travis]
- whsieh: that native format time is going to be platform specific.
- 16:26:48 [Travis]
- BoCupp: Guess there would be guidelines for apps per platform.
- 16:27:08 [Travis]
- whsieh: main drawback then is that the app APIs were talking about don't exist yet.
- 16:27:38 [Travis]
- .. so an advantage of standardizing the JSON, is that we don't have to wait for platforms to create the APIs, we can just specify the format.
- 16:27:58 [Travis]
- BoCupp: we are incentivized to do it that way to minimize differences across platforms.
- 16:28:02 [Travis]
- .. to wrap up
- 16:28:20 [Travis]
- .. long term, Apple is in support of multiple origins being able to read from a native app?
- 16:28:39 [Travis]
- whsieh: Yes, as long as the native app has made the choice to opt-in. It must be a os platform API.
- 16:30:12 [Travis]
- BoCupp: does the API have to be provided by the native platform? Or could it be a standardized (the shape and name to be written)?
- 16:30:59 [Travis]
- whsieh: if there was a special type that could be the same across platforms, then that might work... we would expose it natively on the platform.
- 16:31:34 [Travis]
- .. like a write untrusted content on the pasteboard.
- 16:32:02 [Travis]
- BoCupp: so, no one opposed to putting in the spec (or omitting) "pickled payload must be limited to the origin that wrote it" (we don't want that).
- 16:32:20 [Travis]
- .. we do want to add details into the spec to allow for pickled formats on the async API.
- 16:32:45 [Travis]
- .. no objection to put a PR for that? And omit the details of how to write that?
- 16:33:00 [Travis]
- whsieh: yes, and the details can be described once the native apis are defined.
- 16:33:21 [Travis]
- BoCupp: so, we can advance the spec to have additional pickling capabilities, while staying away from the format.
- 16:33:43 [Travis]
- whsieh: We don't require any additional web-facing API for pickling, right?
- 16:33:46 [Travis]
- BoCupp: we might?
- 16:34:55 [Travis]
- .. follow-up with an unsanitized option, where on write we produce both formats (efficiently)...
- 16:35:40 [Travis]
- .. as part of pickling, if you specify unsanitized html on read, we would expect a website to be able to access it on read.
- 16:36:25 [Travis]
- whsieh: I understand that if a website is able to read unsanitized, they should be able to.
- 16:36:41 [Travis]
- BoCupp: they should be able to do so.
- 16:37:17 [Travis]
- whsieh: the native api mitigates some of the privacy/security risks because it's explicit that the content is intended to be read (unsanitized) by web content.
- 16:37:45 [Travis]
- BoCupp: the new format was an attempt to cause the web app to opt-in.
- 16:39:22 [Travis]
- BoCupp: pickling (for writing) is to protect native apps (from web-sourced attacks)
- 16:39:44 [Travis]
- .. we were putting formats on the clipboard to isolate native apps from reading.
- 16:40:20 [Travis]
- johanneswilm: would it be an option to have bo/whsieh have a virtual coffee?
- 16:40:32 [Travis]
- .. to get a condensed version of the discussion?
- 16:41:36 [Travis]
- action: have BoCupp, whsieh, snianu get together separately to work on details of pickling in special one-off meeting.
- 16:42:41 [Travis]
- agenda+ https://github.com/w3c/input-events/issues/117
- 16:42:47 [Travis]
- zakim, take up agenda 3
- 16:42:47 [Zakim]
- agendum 3 -- https://github.com/w3c/input-events/issues/117 -- taken up [from Travis]
- 16:43:04 [Travis]
- johanneswilm: we agree last time on having this be a non-normative note.
- 16:43:15 [Travis]
- .. question was raised: should it be normative instead?
- 16:43:38 [Travis]
- BoCupp: we were advising on how to obtain an image (for a sticker) into content. We said, use an existing event.
- 16:43:55 [Travis]
- .. seems to be advice to authors (since there's no new feature specified).
- 16:44:11 [Travis]
- .. we said use a paste event.
- 16:45:41 [Travis]
- johanneswilm: now looking at PR 123: https://github.com/w3c/input-events/pull/123
- 16:45:54 [Travis]
- BoCupp: hmm, see that this looks like ordering of events.
- 16:46:22 [Travis]
- johanneswilm: separate things: first, what do we use for an image? We all agreed on 'insertFromPaste'. was merged into the spec.
- 16:46:40 [Travis]
- .. then asked if paste should be fired. We agreed to the same.
- 16:47:09 [Travis]
- .. should it be normative?
- 16:47:23 [Travis]
- Travis: I think it should be normative so that it will get implemented.
- 16:47:32 [Travis]
- johanneswilm: also I agree.
- 16:47:43 [Travis]
- BoCupp: where were you observing the order of paste events?
- 16:47:52 [Travis]
- johanneswilm: in webkit, I believe.
- 16:48:00 [Travis]
- .. other folks want to check?
- 16:48:09 [Travis]
- .. couldn't find in Edge.
- 16:48:29 [Travis]
- BoCupp: that doesn't relate to what you have written.
- 16:49:03 [Travis]
- .. what was written didn't quite match what I was thinking...
- 16:49:26 [Travis]
- johanneswilm: for the order, I just checked what WebKit was doing.
- 16:49:57 [Travis]
- .. can we resolve to remove the non-normative note from the note?
- 16:50:13 [Travis]
- BoCupp: could you check other implementations on the event order?
- 16:50:38 [Travis]
- johanneswilm: if I find no difference on regulare paste, and beforeinput and regular paste, are you OK?
- 16:51:25 [Travis]
- Travis: is a Note (by itself) non-normative?
- 16:51:42 [Travis]
- .. whatever way of making it non-normative is good with me.
- 16:52:30 [BoCupp]
- From conformance language in spec: As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
- 16:53:15 [Travis]
- travis: suggesting to test event order of paste and insertFromPaste. If implementations agree, then we remove the non-normative disclaimer on the note.
- 16:53:28 [Travis]
- johanneswilm: agree to make it normative.
- 16:53:39 [Travis]
- .. so should drop the "note" container.
- 16:54:28 [Travis]
- action: johanneswilm convert the note to a regular conformance statement assuming implementations all agree on the event order of paste and insertFromPaste.
- 16:55:13 [Travis]
- agenda+ https://github.com/w3c/input-events/pull/122
- 16:55:24 [Travis]
- zakim, take up agenda 4
- 16:55:24 [Zakim]
- agendum 4 -- https://github.com/w3c/input-events/pull/122 -- taken up [from Travis]
- 16:55:39 [Travis]
- johanneswilm: we have l1 and l2 because chromium couldn't implement all parts of the spec.
- 16:55:46 [Travis]
- .. later on, chromium could do it!
- 16:56:07 [Travis]
- .. chromium now has a larger amount of l2! Let's go back to having just one level...
- 16:56:16 [Travis]
- .. chromium can't do every detail of l2.
- 16:56:32 [Travis]
- .. so, can we mark the parts that chromium can't do as optional?
- 16:56:51 [Travis]
- .. webkit will have implemented the optional parts, and chromium would not.
- 16:57:04 [Travis]
- .. or as BoCupp suggests, we drop the parts only implemented in WebKit.
- 16:57:31 [Travis]
- BoCupp: I agree that these are the last gap.
- 16:57:37 [Travis]
- .. we also don't have the same event ordering.
- 16:57:40 [whsieh]
- to be clear, the gap is about IME?
- 16:58:38 [Travis]
- .. insertFromComp, deleteCompText... these cause unnecessary churn in the DOM.
- 16:58:56 [Travis]
- .. you get a range and for each update the range gets replaced.
- 16:59:19 [Travis]
- .. you want to be able to isolate the churn from the DOM to another element, etc.
- 16:59:30 [Travis]
- .. you want the composition to be unaffected by the selection change.
- 16:59:49 [Travis]
- .. you want to preserve enough state to be able to do that.
- 17:00:02 [Travis]
- .. I see that almost working in Safari, but not quite.
- 17:00:08 [Travis]
- .. have some extra data I can share.
- 17:00:25 [Travis]
- .. I assert that the scenario is not fully accomplished and causes unnecessary churn in the DOM.
- 17:00:47 [Travis]
- .. as long as the author knows the range, the author can remove it themselves. I wrote a test to prove this out.
- 17:01:08 [Travis]
- .. You want to be updating the view as the user is typing.
- 17:01:22 [Travis]
- johanneswilm: might need another deep dive.
- 17:01:37 [Travis]
- .. those events are at the beginning and end (not in between).
- 17:01:51 [Travis]
- .. without event listeners, you can even skip them?
- 17:02:03 [Travis]
- .. long discussion we had several years ago? Perhaps we can discuss again?
- 17:02:53 [Travis]
- BoCupp: sounds good (having a separate meeting) to outline the discussion, provide a demo. Understand the purpose of the events.
- 17:03:21 [Travis]
- whsieh: the only preventable events are the beginning and the end?
- 17:03:38 [Travis]
- .. the relocating is happening at the beginning and end?
- 17:03:45 [Travis]
- BoCupp: why are you preventing?
- 17:03:48 [Travis]
- .. to cancel?
- 17:04:07 [Travis]
- whsieh: thought the context is trying to mirror what is happening?
- 17:06:15 [Travis]
- travis: ultimately we are thinking that the outcome of the deep dive is to see about potentially dropping them?
- 17:07:03 [Travis]
- whsieh: webkit has been shipping them for many years. Folks could be dependent on them (Mac/Native Apps could be relying on this behavior). Could be difficult to extricate from the engine.
- 17:09:58 [johanneswilm]
- editing group promotion video: https://drive.google.com/file/d/1CcN0qqSZ_CspZOyk4yMQSRHwCl_HoU-V/view?usp=drive_web
- 17:10:08 [Travis]
- action: BoCupp in two weeks, present overview of the nuances of composition input event scenarios.
- 17:10:55 [Travis]
- BoCupp: thanks johanneswilm!
- 17:11:13 [whsieh]
- this is great!
- 17:30:05 [Travis]
- RRSAgent, make logs public
- 17:30:15 [Travis]
- RRSAgent, please generate the minutes
- 17:30:15 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/09/24-editing-minutes.html Travis
- 17:43:27 [Travis]
- Meeting: Special 2nd September W3C Web Editing WG meeting
- 17:44:08 [Travis]
- RRSAgent, please generate the minutes
- 17:44:08 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/09/24-editing-minutes.html Travis
- 17:44:39 [Travis]
- agenda?
- 17:44:58 [Travis]
- zakim, drop all agendum
- 17:44:58 [Zakim]
- I don't understand 'drop all agendum', Travis
- 17:45:08 [Travis]
- zakim, drop agenda 2, 3, 4
- 17:45:08 [Zakim]
- I don't understand 'drop agenda 2, 3, 4', Travis
- 17:45:16 [Travis]
- zakim, drop agenda 2 3 4
- 17:45:16 [Zakim]
- I don't understand 'drop agenda 2 3 4', Travis
- 17:45:24 [Travis]
- zakim, drop agenda 2 and 3
- 17:45:24 [Zakim]
- I don't understand 'drop agenda 2 and 3', Travis
- 17:45:28 [Travis]
- zakim, drop agenda 2
- 17:45:28 [Zakim]
- agendum 2, https://github.com/w3c/editing/issues/334, dropped
- 17:46:36 [Travis]
- agenda- 3
- 17:46:39 [Travis]
- agenda- 4
- 17:46:44 [Travis]
- agenda?
- 19:35:10 [GameMaker]
- GameMaker has joined #editing
- 19:59:14 [Zakim]
- Zakim has left #editing
- 23:02:26 [GameMaker]
- GameMaker has joined #editing
- 23:51:15 [GameMaker]
- GameMaker has joined #editing