Meeting minutes
scribe Travis
BoCupp: rniwa was clear about not standardizing at this time. Is this a unified Apple position?
whsieh: yes...
… we are not interested in pursuing the spec as written (using domparser and sanitization)
BoCupp: is there some other sanitization you'd like to see?
whsieh: ideally we leave that open-ended for the user agent.
BoCupp: perhaps we don't have to spend the WG time speccing that... I suppose we can do as we see fit?
… anyone have other thoughts?
whsieh: yes, regarding sanitization
… other things we could possibly align on... do we include HMTL/BODY tags?
… those are some of the details we could pursue for standards.
… however the fine details of "how to sanitize web content"; we'd like to keep that as UA-defined.
BoCupp: e.g., read api returns a fragment vs a document?
whsieh: seems nice to clarify.
BoCupp: just that one point would be better than nothing?
… we have some preferences, wondering what the group would think about that?
Action: BoCupp to assert some of the points Microsoft would like to have in the Chromium version of the API; then check for agreement.
a?
https://github.com/w3c/clipboard-apis/issues/150
a?
https://github.com/w3c/editing/issues/334
BoCupp: Microsoft motivation is to have native apps write to the clipboard so that many sites can consume.
… heard from whsieh that a single origin could be specified to access the content...
… wondering if we could open this up to specify some core syntax?
whsieh: discussed internally; we would like to limit to single origins.
… 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.
… if they opt-in, we would then allow the data (unsanitized) to be read by any site.
… (the native API would be opting in)
… with CORS-like scheme, in the end-game everyone would just specify "*" (no downside)
… if we do something like that, we should put this on app authors.
BoCupp: you'd like to limit to single origin--and you have an idea on multiple origins?
whsieh: I don't feel this would require standardization...
… a native app API that provides the ability to send to any site (doesn't require standardization)
BoCupp: wondering if what is provided in the clipboard would have some special characteristics (standardized)?
… assuming adopting pickling w/sanitization... or is this free-for-all (don't pursue pickling)?
… if we build something like snianu made... details the shape of the format on the clipboard...
… having the presence of the format allows them to be shared...
BoCupp: what would you put on the clipboard to indicate that it should be associated with a particular origin (related to pickling)?
whsieh: I'm not proposing a format.
… today app would use NSPasteboard APIs to set data. In the new world, they'd use "WriteUnsanitizedContentForWeb"
… something explicit. Apple would take care of the format in the pasteboard.
BoCupp: hmm. When Edge ships something, our approach isn't to create a new Apple API (we can't).
… what we will advertise is: here the format to put on the clipboard, and the JSON structure to make content available to web apps.
… 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.
whsieh: there would be reading/writing separate parts.
… apps writing unsanitized data would use new API.
… other browser would use a corresponding app read API.
… this also gives us the ability to copy data between browsers because they're on the same platform, and it would just work.
BoCupp: so, if safari has it's own formats for interchange different from Chromium they'd have to agree..?
whsieh: not quite. Any app could use the unsanitizedNativePlatformAPI and you'd achieve interop.
… because the details are abstracted.
BoCupp: We're still interested in standarizing something that works cross-platform... we have a proposed content shape..
… with a mime-type it might be translated differently on different platforms. We might use different syntax...
… (thinking0
… I guess we go into each platform domain (Linux, Windows) and specify how pickled content would look.
whsieh: given the JSON map, would the types be different per-platform?
BoCupp: the map just takes author-specified mime types and mapping to a format that can be read.
whsieh: that native format time is going to be platform specific.
BoCupp: Guess there would be guidelines for apps per platform.
whsieh: main drawback then is that the app APIs were talking about don't exist yet.
… 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.
BoCupp: we are incentivized to do it that way to minimize differences across platforms.
… to wrap up
… long term, Apple is in support of multiple origins being able to read from a native app?
whsieh: Yes, as long as the native app has made the choice to opt-in. It must be a os platform API.
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)?
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.
… like a write untrusted content on the pasteboard.
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).
… we do want to add details into the spec to allow for pickled formats on the async API.
… no objection to put a PR for that? And omit the details of how to write that?
whsieh: yes, and the details can be described once the native apis are defined.
BoCupp: so, we can advance the spec to have additional pickling capabilities, while staying away from the format.
whsieh: We don't require any additional web-facing API for pickling, right?
BoCupp: we might?
… follow-up with an unsanitized option, where on write we produce both formats (efficiently)...
… as part of pickling, if you specify unsanitized html on read, we would expect a website to be able to access it on read.
whsieh: I understand that if a website is able to read unsanitized, they should be able to.
BoCupp: they should be able to do so.
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.
BoCupp: the new format was an attempt to cause the web app to opt-in.
BoCupp: pickling (for writing) is to protect native apps (from web-sourced attacks)
… we were putting formats on the clipboard to isolate native apps from reading.
johanneswilm: would it be an option to have bo/whsieh have a virtual coffee?
… to get a condensed version of the discussion?
Action: have BoCupp, whsieh, snianu get together separately to work on details of pickling in special one-off meeting.
https://github.com/w3c/input-events/issues/117
johanneswilm: we agree last time on having this be a non-normative note.
… question was raised: should it be normative instead?
BoCupp: we were advising on how to obtain an image (for a sticker) into content. We said, use an existing event.
… seems to be advice to authors (since there's no new feature specified).
… we said use a paste event.
johanneswilm: now looking at PR 123: https://
BoCupp: hmm, see that this looks like ordering of events.
johanneswilm: separate things: first, what do we use for an image? We all agreed on 'insertFromPaste'. was merged into the spec.
… then asked if paste should be fired. We agreed to the same.
… should it be normative?
Travis: I think it should be normative so that it will get implemented.
johanneswilm: also I agree.
BoCupp: where were you observing the order of paste events?
johanneswilm: in webkit, I believe.
… other folks want to check?
… couldn't find in Edge.
BoCupp: that doesn't relate to what you have written.
… what was written didn't quite match what I was thinking...
johanneswilm: for the order, I just checked what WebKit was doing.
… can we resolve to remove the non-normative note from the note?
BoCupp: could you check other implementations on the event order?
johanneswilm: if I find no difference on regulare paste, and beforeinput and regular paste, are you OK?
Travis: is a Note (by itself) non-normative?
… whatever way of making it non-normative is good with me.
<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.
travis: suggesting to test event order of paste and insertFromPaste. If implementations agree, then we remove the non-normative disclaimer on the note.
johanneswilm: agree to make it normative.
… so should drop the "note" container.
Action: johanneswilm convert the note to a regular conformance statement assuming implementations all agree on the event order of paste and insertFromPaste.
https://github.com/w3c/input-events/pull/122
johanneswilm: we have l1 and l2 because chromium couldn't implement all parts of the spec.
… later on, chromium could do it!
… chromium now has a larger amount of l2! Let's go back to having just one level...
… chromium can't do every detail of l2.
… so, can we mark the parts that chromium can't do as optional?
… webkit will have implemented the optional parts, and chromium would not.
… or as BoCupp suggests, we drop the parts only implemented in WebKit.
BoCupp: I agree that these are the last gap.
… we also don't have the same event ordering.
<whsieh> to be clear, the gap is about IME?
BoCupp: insertFromComp, deleteCompText... these cause unnecessary churn in the DOM.
… you get a range and for each update the range gets replaced.
… you want to be able to isolate the churn from the DOM to another element, etc.
… you want the composition to be unaffected by the selection change.
… you want to preserve enough state to be able to do that.
… I see that almost working in Safari, but not quite.
… have some extra data I can share.
… I assert that the scenario is not fully accomplished and causes unnecessary churn in the DOM.
… as long as the author knows the range, the author can remove it themselves. I wrote a test to prove this out.
… You want to be updating the view as the user is typing.
johanneswilm: might need another deep dive.
… those events are at the beginning and end (not in between).
… without event listeners, you can even skip them?
… long discussion we had several years ago? Perhaps we can discuss again?
BoCupp: sounds good (having a separate meeting) to outline the discussion, provide a demo. Understand the purpose of the events.
whsieh: the only preventable events are the beginning and the end?
… the relocating is happening at the beginning and end?
BoCupp: why are you preventing?
… to cancel?
whsieh: thought the context is trying to mirror what is happening?
travis: ultimately we are thinking that the outcome of the deep dive is to see about potentially dropping them?
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.
<johanneswilm> editing group promotion video: https://
Action: BoCupp in two weeks, present overview of the nuances of composition input event scenarios.
BoCupp: thanks johanneswilm!
<whsieh> this is great!