Meeting minutes
ClipboardItem is sensitive in .write/.writeText()
github: https://
BoCupp: This is an option that allows one to specify whether clipboard items roam and/or are included in history
… a common feature of various platforms.
tilgovi: https://
BoCupp: This is something that we [Microsoft] could take up and write an explainer for?
Anne: My main concern is about the default values (which ones should be correct)?
BoCupp: Defaults should be what the user has configured on the platform.
… [cites how Windows-clipboard prompts on first-use...]
… There may be exceptions for privacy modes, or copying from a password field (context specific)
Anne: Is it OK for websites to override defaults?
BoCupp: I think so.
… specifying per-format allows imposing limits. (e.g., large bitmap roaming)
Anne: How will a website make the right decision? Do expose the user preference?
BoCupp: I don't think we would expose the user preference--the implementation would configure this as desired.
… We might add additional restrictions
BoCupp: We can continue discussion in the issue... when we're ready to draft a PR we'll revisit.
Add Custom Clipboard format
github: https://
BoCupp: Context: Folks weren't interested in unsanitized option (that would require a sanitization library).
… Chromium-based browsers still wanted to move forward... one proposal was that a "browser may do X or Y". To specify whether they want unsanitized content or not.
… another options was not to add anything to the spec; but to fork the spec into another CG or separate doc. (The latter was what we did.)
… If we look at Anupam's PR, we see it will be a big maintenance headache ;(
… Therefore, I would like us to reconsider.
… I believe AnneVK chimed in showing their interest in this feature?
… Finally, why would we not add language in the primary spec? Might create pressure on Apple ("not spec compliant").
… I think we'd still have web.dev posts (and other blog posts when it launches).
… So... the absense of this (in the spec) may not justify not adding it to the spec.
… So, will listen to others' reactions?
Anne: I'm not sure about unsantizied either.
… mainly was expressing support for custom formats (in the spec).
… I think that is something worth having in the spec (incl. Apple)
… Want to preserve that we would have a specification for custom formats.
… Separately, we need to consider the unsanitized option. I'm *less* favorable on that one.
… It's weird that the legacy API and new API do different things...I think we should try to unify them.
BoCupp: For custom formats, I think we agree that there isn't a sanitization algorithm that we'd apply to custom formats (unknown structure)
… Wanted to be sure that together with unsanitized keyword, that the format would be listed.
… Do you think it's useful in that context?
Anne: Interesting. I might be ammenable to that.
BoCupp: To be fair, we doubled-up the purpose here... we wanted to provide this to the HTML format.
<whsieh_> sorry, not sure why my mic isn't working :( what I recall agreeing on last was that sanitization should be a feature of the browser, not something that sites should be able to opt out of. so blink would always unsanitize, and WebKit can continue sanitizing
BoCupp: (details for legacy API vs new API)
… Don't really want to touch the legacy API behavior.
BoCupp: Yes, that matches what I recall.
<whsieh_> I think there are ways to ensure backwards compatibility even without the sanitize option
BoCupp: I think that's Apple's position.
… I think Chromium's position is different... want to focus on the mechanics (assuming we won't come to an agreement).
… And what's the most appropriate way to document it.
<whsieh_> right, but this is about whether or not we should build the concept of 'sanitize' into the spec right?
<whsieh_> (the sanitize option, that is)
snianu: Domenic's last comment on my PR was that we don't have to define all the details, but add ref to the sanitizer API (and how its configured).
… per Domenic, we should just call algorithms that have undefined (up to the UA) behavior.
… We should be sure it's specified and deterministic.
… This is now blocking the PR.
Anne: Historically, I would see failure of standardization process if we can't get agreement.
… We don't have many API in this sort of deadlock...
BoCupp: Why I think it may be OK in this circumstance.
… The clipboard shape is unknown--someone could have written santizied content to the clipboard originally--how would one know?
… Today, you can get a loss of fidelity when clipboard transfer occurs.
<whsieh> we're okay with offering platform API to support unsanitized transport of information from native apps to the web
BoCupp: I think it's OK if a UA wants to be more cautious (or not) in sanitizing at their discretion.
… So that web devs don't have to write unique code.
johanneswilm: Devs do have to write different code if they get sanitized from one browser and unsanitized from another.
… might have provide an upload mechanism to help understand the data.
… (as an alternative)
snianu: Most websites that parse HTML string.. they use getData/setData.
… in Firefox and all Chromium browser we get unsanitized content.
<whsieh> we only sanitize cross-origin
snianu: this is not so for Safari (not sure if there's special code paths for Safari)
Anne: Why even have a sanitize (if most are not sanitizing today)?
snianu: I believe whsieh mentioned they only wanted to provide unsanitized content between same origin...
<whsieh> right. the only reason is compat
Anne: I don't think we need the sanitized option then... if this is already something that is there? Why provide it? Wondering if there's a compat thing?
<whsieh> (but there are ways to fix compatibility issues without baking it into the spec)
BoCupp: If you Ctrl+V and don't prevent the default, the browser needs it's own santiized logic (style adjustment, JS stripping, etc.) prep logic for "merge ready" HTML.
… There's a way for authors to do this too.
<whsieh> would it be useful to provide API to sanitize markup in the style of the clipboard?
BoCupp: It would be more ergonomic to allow authors to leverage this "merge-ready" logic... thought having an option to choose would be good (for well-known formats).
johanneswilm: On "is it a failure of the standardization process" is there another way we can move forward?
… On Bo's last comment: this can be problematic for editor creators--if they rely on the browser sanitization, it can lead to incompatible paste content in their editor--so they have to sanitize anyway.
BoCupp: For moving forward, I'd like to see language that is a delta to the existing spec (rather than an entire clone of the spec).
… (assuming can't get to an agreement)
… but would like to have something like this (either or option) in the spec.
<snianu> https://
👆 the forked PR
snianu: The presentation style attribute is not supported in Chrome/Firefox. Also multiple clipboard formats are only supported on Apple platforms. So there is some precident already that is Safari-specific.
… (can this be another instance of that?)
Anne: Specific to Safari for Apple platforms!
whsieh: but does it need to be in the spec?
Anne: only argument that's persuasive to me is Ctrl+V, and I'm not sure its that specific...
BoCupp: Hmm, there are some potentially risky unsanitized content on the pickled formats.
Anne: potentially different accessor for pickled formats versus built-in formats?
… Wouldn't say "unsanitized"... might have "unsafe" prefix or something similar. (Have used 'unsafe' in other APIs in the past.
… Could work for HTML and/or image formats?
BoCupp: If we look at separate accessors... it's possible that an unknown format (today) could become a built-in format (future). Would it migrate?
… (thinking on the lfy here...)
Anne: Could access some format through a pickled format and also not (through separate APIs)
… In that case security is up to website/native apps.
whsieh: If the website writes pickled formats... we wouldn't want to expose that raw content to native app (they' need an opt-in)
Anne: The native app would need to opt-in also, correct?
… native app can get to normal html/png directly, but if you wrote pickled html/png, they wouldn't get it.
whsieh: and if they asked for regular html they'd get the sanitized version...
… could lead to issues if the website authors use pickled versions for the clipboard.
… today the browser writes a safe AND unsafe version to the clipboard...
… so that Apps can decide which to use. (If they don't opt-in they get sanitized version.)
… Important point: we should push websites to write both versions (or ensure the browser has a way to do that).
BoCupp: Taking a moment to point out our implementation status...
… Don't think we'll get agreement on how all our implementations will align.
… Happy to change chromium implementation if we can get agreement.
… But assuming (based on history) that we won't.
… In Edge, we have shipped something to allow native apps to exchange content...
… In the chromium process, the hold-up is where we are going to write the behavior down.
… There are many options here. Looking for what the right approach is that minimized disruption/impact on the WG?
Anne: felt like we were pretty close to an agreement!
whsieh: We agree that the behaviors can be different.
… We don't agree that writing the unsanitized option into the spec is OK.
… last time, we talked about ways of configuring this (that are different from the unsanitized flag)
… mentioned a <meta> tag for this purpose...
… could solve the compat issue.
BoCupp: Wouldn't be my preference...
johanneswilm: Wondering if we could move this out... or have another meeting?
… moving to the time-zones meeting?
BoCupp: To conclude... I'll try to setup a meeting over email. By default, Anne, whsieh, me... smaug, johanneswilm....
… +megan
… I will follow-up on the public-editing-tf list.
New meeting time
github: https://
BoCupp: At a minimum, I would like to meet a little earlier PST for those in central europe time.
… if we started at 7 pst, this is a little better for UTC
… The midnight time (ASIA) eats into the weekend. We should move to Thursday.
Megan: 7 is quite early... how about 8?
… very "pro" Thursday!
<tilgovi> 7am PT is quite early, but I can manage it. 8 is great.
johanneswilm: So, 2nd Thursday of the month (that shall be the new rule)?
BoCupp: Feb 10th?
johanneswilm: 5pm Central Europe
… 8am Pacific (fix it to that for DST changes)
… can we also move to Jitsi?
… Right now I have to admit folks...
BoCupp: Not sure.
… Also I wanted to include masyuki
… but don't want to have everyone adopt a japan-optimized time if he won't be attending.
… wondering if folks are willing to attend in the "off times" (in a rotating schedule)
… Will poll to gauge interest
… otherwise will stick to Thursdays and the -1 hour
Topic aside: Anne suggests Jan 27 (two weeks)
BoCupp: Willing to start at 7...
whsieh: 7 is a bit early, how about a compromise 7:30 AM?
Travis: I note Megan, snianu +1 that 7:30 time.
Anne: I can also handle Zoom meetings.
BoCupp: For default we'll go with same tech for meeting/IRS
ha ha... IRC, not IRS
snianu: Shall we have a separate meeting for EditContext?
BoCupp: I think we could just discuss in the main meeting.
Input events
github: https://
johanneswilm: Is there agreement on what to do next?
… please follow up BoCupp !