On Tue, Oct 5, 2021 at 4:02 AM Anupam Snigdha <sni...@microsoft.com> wrote:
> Here is a WIP PR to address the spec issue: > https://github.com/w3c/clipboard-apis/pull/158. > Can you address feedback from Anne on the PR? > > > *From:* Anupam Snigdha > *Sent:* Monday, October 4, 2021 10:45 AM > *To:* 'Yoav Weiss' <yoavwe...@chromium.org>; Anne van Kesteren < > ann...@annevk.nl> > *Cc:* blink-dev <blink-dev@chromium.org>; Marijn Kruisselbrink < > m...@chromium.org>; Bo Cupp <pc...@microsoft.com> > *Subject:* RE: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: > Add support for Promise to Blobs in clipboard item > > > > For #1: I don’t think we would want to diverge from the spec. There is a > reason why we have promises to Blobs and not just Blobs in the > ClipboardItem because, well, not having promises defeats the purpose of > having an async API. Also waiting for the Blob data synchronously without > triggering the clipboard write operation leads to problems like this > <https://bugs.chromium.org/p/chromium/issues/detail?id=1014310#c15> and > performance issues in sites like Excel Online where the copy payload is in > MBs. > That makes sense. > > > For #2: This might sound more of a rant so apologies in advance. > > > > I agree with Anne that the spec is not really clear at all on the > specifics of the async clipboard API and some of the terminologies used in > the algorithms. > > However, making changes to the spec or even clarifying the language after > an API has been shipped, is really hard, as we need to get consensus from > all browser vendors. > > I tried to clarify what “sanitization” means just for the HTML format > <https://github.com/w3c/clipboard-apis/issues/150#issuecomment-909405090> > and Apple opposed to this change > <https://github.com/w3c/clipboard-apis/issues/150#issuecomment-922211803>. > > That's unfortunate :/ > Perhaps I can add a non-normative note which would at least give some > clarity on the sanitization process, but that would probably require UA > specific non normative notes which defeats the purpose of standardization. > > I also tried to make changes to address Mozilla’s concern about mandatory > data types supported by async clipboard APIs: > https://github.com/w3c/clipboard-apis/pull/155, but this PR has been > sitting for almost a month now and I’m not able to make any progress. > FWIW, it seemed to have made some progress initially and then stalled. Pinging it may make sense. > > > In order to make progress on spec changes, we decided to have a discussion > with the Editing WG members and submit changes to the spec if no one > objects to it. Currently the Editing WG has representatives from Apple and > MS who regularly attend the monthly status meetings. So my question is, if > we get an approval from the WG, then does that meet the minimum bar to make > spec changes? > That's for the Editing WG to decide. Looking at its charter <https://www.w3.org/2021/06/web-editing-wg-charter.html>, it seems the chairs may be able to help move things along (e.g. by bringing decisions to a vote, if no consensus is reached). > > Anyways, I’m working on updating the spec to at least define the Clipboard > interface IDL, but since Apple and Chromium browsers have already shipped > this API, I don’t think it’s possible to make any significant changes to > the APIs without breaking at least one of the browsers. > > This change addresses the discrepancy between the ClipboardItem IDL as > defined in the spec(also implemented by Apple) and what is implemented in > Chromium. This is not a breaking change so I think the risk is minimal here. > > > > *From:* Yoav Weiss <yoavwe...@chromium.org> > *Sent:* Friday, October 1, 2021 4:15 AM > *To:* Anne van Kesteren <ann...@annevk.nl> > *Cc:* Anupam Snigdha <sni...@microsoft.com>; blink-dev < > blink-dev@chromium.org>; Marijn Kruisselbrink <m...@chromium.org>; Bo Cupp > <pc...@microsoft.com> > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: > Add support for Promise to Blobs in clipboard item > > > > > > > > On Fri, Oct 1, 2021 at 12:46 PM Anne van Kesteren <ann...@annevk.nl> > wrote: > > On Fri, Oct 1, 2021 at 12:35 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > > Thanks Anne and Thomas for the cross-browser context. > > > > Anupam - looking at the issue Anne posted, it seems Firefox explicitly > did not implement this. > > I think it'd be interesting to get their opinions as to why, and whether > we should align with the current WebKit behavior or the current Chromium > one. > > > > Anne - do y'all want to chime in here, or would a standards position > issue be the best venue? > > There is an existing issue: > https://github.com/mozilla/standards-positions/issues/89 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F89&data=04%7C01%7Csnianu%40microsoft.com%7C4d9c1e5cbc7e43cee5a308d984ccc46f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686837296796022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0uOT1hsreAkS2O16h4lXCb2qm1W4U5tKyuPCuJfQoaE%3D&reserved=0>. > The problem > we are having in evaluating all this is that there isn't really any > specification to speak of, as I tried to point out. One can take > guesses as to what the expected behavior is likely to be, but that is > very far from ideal and normally not even close to acceptable, right? > > > > That's fair. > > > > From my perspective, the ideal outcome here would be: > > 1) Getting agreement on this specific issue that's currently causing > developer pain, and moving forward in that direction. > > 2) Properly specifying the correct behavior for the rest of the broader > API, in ways that would enable interoperable implementations (and reduce > developer pain in the future). > > > > It seems like (2) requires Someone™ to take on the work of gathering the > different unspecified behaviors, opening an issue to discuss each one, > reaching agreement on them and pushing to align existing implementations. > > > > Maybe we can decouple (1) and (2), but I'd like to see we have a concrete > plan for (2) before we do that. > > > > Anupam - who would be best positioned to take on that work? > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWvkMxEKksoVzCjgm0jtw242%3De6tmTKTNy18NCvbD8Vvg%40mail.gmail.com.
