17:01:10 RRSAgent has joined #editing 17:01:10 logging to https://www.w3.org/2022/01/14-editing-irc 17:01:20 zakim, this is the Editing WG meeting 17:01:21 got it, Travis 17:01:33 present+ Travis_Leithead 17:02:14 present+ 17:02:22 Anne has joined #editing 17:02:23 present+ 17:02:41 present+ 17:02:49 present+ 17:02:52 ScribeNick: Travis 17:02:55 Scribe: Travis 17:03:12 Meeting: January 14, 2022 Editing WG meeting 17:03:59 Topic: ClipboardItem is sensitive in .write/.writeText() 17:04:08 github: https://github.com/w3c/clipboard-apis/issues/154 17:04:26 BoCupp: This is an option that allows one to specify whether clipboard items roam and/or are included in history 17:04:26 present+ 17:04:33 .. a common feature of various platforms. 17:04:55 tilgovi: https://meet.google.com/pdx-dnmm-cen 17:05:27 BoCupp: This is something that we [Microsoft] could take up and write an explainer for? 17:05:47 Anne: My main concern is about the default values (which ones should be correct)? 17:06:00 BoCupp: Defaults should be what the user has configured on the platform. 17:06:18 .. [cites how Windows-clipboard prompts on first-use...] 17:06:37 .. There may be exceptions for privacy modes, or copying from a password field (context specific) 17:06:47 Anne: Is it OK for websites to override defaults? 17:06:50 BoCupp: I think so. 17:07:16 .. specifying per-format allows imposing limits. (e.g., large bitmap roaming) 17:07:29 Anne: How will a website make the right decision? Do expose the user preference? 17:07:31 q+ 17:07:34 alexk has joined #editing 17:07:43 q- 17:07:57 BoCupp: I don't think we would expose the user preference--the implementation would configure this as desired. 17:08:28 .. We might add additional restrictions 17:08:33 q+ 17:09:01 q- 17:09:08 BoCupp: We can continue discussion in the issue... when we're ready to draft a PR we'll revisit. 17:10:37 https://github.com/w3c/clipboard-apis/pull/162 17:11:03 Topic: Add Custom Clipboard format 17:11:11 github: https://github.com/w3c/clipboard-apis/pull/162 17:12:14 BoCupp: Context: Folks weren't interested in unsanitized option (that would require a sanitization library). 17:12:48 .. 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. 17:13:46 .. 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.) 17:14:04 .. If we look at Anupam's PR, we see it will be a big maintenance headache ;( 17:14:17 .. Therefore, I would like us to reconsider. 17:14:29 .. I believe AnneVK chimed in showing their interest in this feature? 17:15:01 .. Finally, why would we not add language in the primary spec? Might create pressure on Apple ("not spec compliant"). 17:15:15 .. I think we'd still have web.dev posts (and other blog posts when it launches). 17:15:32 .. So... the absense of this (in the spec) may not justify not adding it to the spec. 17:15:43 .. So, will listen to others' reactions? 17:15:56 Anne: I'm not sure about unsantizied either. 17:16:05 .. mainly was expressing support for custom formats (in the spec). 17:16:16 .. I think that is something worth having in the spec (incl. Apple) 17:16:39 .. Want to preserve that we would have a specification for custom formats. 17:16:53 .. Separately, we need to consider the unsanitized option. I'm *less* favorable on that one. 17:17:10 .. It's weird that the legacy API and new API do different things...I think we should try to unify them. 17:18:07 whsieh_ has joined #editing 17:18:48 BoCupp: For custom formats, I think we agree that there isn't a sanitization algorithm that we'd apply to custom formats (unknown structure) 17:19:11 .. Wanted to be sure that together with unsanitized keyword, that the format would be listed. 17:19:22 .. Do you think it's useful in that context? 17:19:30 Anne: Interesting. I might be ammenable to that. 17:19:53 BoCupp: To be fair, we doubled-up the purpose here... we wanted to provide this to the HTML format. 17:20:04 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 17:20:33 .. (details for legacy API vs new API) 17:20:51 .. Don't really want to touch the legacy API behavior. 17:21:33 BoCupp: Yes, that matches what I recall. 17:21:34 I think there are ways to ensure backwards compatibility even without the sanitize option 17:21:41 .. I think that's Apple's position. 17:22:05 .. I think Chromium's position is different... want to focus on the mechanics (assuming we won't come to an agreement). 17:22:16 .. And what's the most appropriate way to document it. 17:22:17 right, but this is about whether or not we should build the concept of 'sanitize' into the spec right? 17:22:24 (the sanitize option, that is) 17:23:28 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). 17:23:53 .. per Domenic, we should just call algorithms that have undefined (up to the UA) behavior. 17:24:02 .. We should be sure it's specified and deterministic. 17:24:07 .. This is now blocking the PR. 17:24:20 whsieh has joined #editing 17:24:28 Anne: Historically, I would see failure of standardization process if we can't get agreement. 17:24:44 .. We don't have many API in this sort of deadlock... 17:24:53 BoCupp: Why I think it may be OK in this circumstance. 17:25:22 .. The clipboard shape is unknown--someone could have written santizied content to the clipboard originally--how would one know? 17:25:39 .. Today, you can get a loss of fidelity when clipboard transfer occurs. 17:26:03 we're okay with offering platform API to support unsanitized transport of information from native apps to the web 17:26:04 .. I think it's OK if a UA wants to be more cautious (or not) in sanitizing at their discretion. 17:26:21 .. So that web devs don't have to write unique code. 17:26:32 q? 17:26:41 johanneswilm: Devs do have to write different code if they get sanitized from one browser and unsanitized from another. 17:26:58 .. might have provide an upload mechanism to help understand the data. 17:27:03 .. (as an alternative) 17:27:21 snianu: Most websites that parse HTML string.. they use getData/setData. 17:27:33 .. in Firefox and all Chromium browser we get unsanitized content. 17:27:38 we only sanitize cross-origin 17:27:47 .. this is not so for Safari (not sure if there's special code paths for Safari) 17:28:16 Anne: Why even have a sanitize (if most are not sanitizing today)? 17:28:35 snianu: I believe whsieh mentioned they only wanted to provide unsanitized content between same origin... 17:29:01 right. the only reason is compat 17:29:08 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? 17:29:13 (but there are ways to fix compatibility issues without baking it into the spec) 17:29:54 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. 17:30:06 .. There's a way for authors to do this too. 17:30:50 would it be useful to provide API to sanitize markup in the style of the clipboard? 17:30:57 .. 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). 17:31:16 johanneswilm: On "is it a failure of the standardization process" is there another way we can move forward? 17:32:26 q? 17:32:27 .. 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. 17:33:16 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). 17:33:24 .. (assuming can't get to an agreement) 17:33:36 .. but would like to have something like this (either or option) in the spec. 17:33:37 https://github.com/w3c/editing/pull/383 17:33:52 👆 the forked PR 17:34:32 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. 17:34:48 .. (can this be another instance of that?) 17:34:56 Anne: Specific to Safari for Apple platforms! 17:36:20 whsieh: but does it need to be in the spec? 17:36:49 Anne: only argument that's persuasive to me is Ctrl+V, and I'm not sure its that specific... 17:37:11 BoCupp: Hmm, there are some potentially risky unsanitized content on the pickled formats. 17:37:24 Anne: potentially different accessor for pickled formats versus built-in formats? 17:37:53 .. Wouldn't say "unsanitized"... might have "unsafe" prefix or something similar. (Have used 'unsafe' in other APIs in the past. 17:38:06 .. Could work for HTML and/or image formats? 17:38:40 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? 17:38:47 .. (thinking on the lfy here...) 17:39:16 Anne: Could access some format through a pickled format and also not (through separate APIs) 17:39:31 .. In that case security is up to website/native apps. 17:40:06 whsieh: If the website writes pickled formats... we wouldn't want to expose that raw content to native app (they' need an opt-in) 17:40:17 Anne: The native app would need to opt-in also, correct? 17:40:44 .. native app can get to normal html/png directly, but if you wrote pickled html/png, they wouldn't get it. 17:41:00 whsieh: and if they asked for regular html they'd get the sanitized version... 17:41:28 .. could lead to issues if the website authors use pickled versions for the clipboard. 17:41:47 .. today the browser writes a safe AND unsafe version to the clipboard... 17:42:09 .. so that Apps can decide which to use. (If they don't opt-in they get sanitized version.) 17:42:26 .. Important point: we should push websites to write both versions (or ensure the browser has a way to do that). 17:42:43 BoCupp: Taking a moment to point out our implementation status... 17:43:04 .. Don't think we'll get agreement on how all our implementations will align. 17:43:19 .. Happy to change chromium implementation if we can get agreement. 17:43:29 .. But assuming (based on history) that we won't. 17:43:56 .. In Edge, we have shipped something to allow native apps to exchange content... 17:44:14 .. In the chromium process, the hold-up is where we are going to write the behavior down. 17:44:39 .. There are many options here. Looking for what the right approach is that minimized disruption/impact on the WG? 17:44:49 Anne: felt like we were pretty close to an agreement! 17:44:58 whsieh: We agree that the behaviors can be different. 17:45:22 .. We don't agree that writing the unsanitized option into the spec is OK. 17:45:42 .. last time, we talked about ways of configuring this (that are different from the unsanitized flag) 17:45:56 .. mentioned a tag for this purpose... 17:46:07 .. could solve the compat issue. 17:46:34 BoCupp: Wouldn't be my preference... 17:47:01 johanneswilm: Wondering if we could move this out... or have another meeting? 17:47:23 .. moving to the time-zones meeting? 17:48:10 BoCupp: To conclude... I'll try to setup a meeting over email. By default, Anne, whsieh, me... smaug, johanneswilm.... 17:48:14 .. +megan 17:48:34 .. I will follow-up on the public-editing-tf list. 17:48:48 Topic: New meeting time 17:49:13 github: https://github.com/w3c/editing/issues/359 17:50:03 BoCupp: At a minimum, I would like to meet a little earlier PST for those in central europe time. 17:50:27 .. if we started at 7 pst, this is a little better for UTC 17:50:51 .. The midnight time (ASIA) eats into the weekend. We should move to Thursday. 17:51:47 Megan: 7 is quite early... how about 8? 17:52:08 .. very "pro" Thursday! 17:52:09 7am PT is quite early, but I can manage it. 8 is great. 17:52:52 johanneswilm: So, 2nd Thursday of the month (that shall be the new rule)? 17:52:55 BoCupp: Feb 10th? 17:53:10 johanneswilm: 5pm Central Europe 17:53:52 .. 8am Pacific (fix it to that for DST changes) 17:54:01 .. can we also move to Jitsi? 17:54:10 .. Right now I have to admit folks... 17:54:49 BoCupp: Not sure. 17:55:02 .. Also I wanted to include masyuki 17:55:28 .. but don't want to have everyone adopt a japan-optimized time if he won't be attending. 17:56:13 .. wondering if folks are willing to attend in the "off times" (in a rotating schedule) 17:56:25 .. Will poll to gauge interest 17:56:42 .. otherwise will stick to Thursdays and the -1 hour 17:57:26 Topic aside: Anne suggests Jan 27 (two weeks) 17:57:48 BoCupp: Willing to start at 7... 17:58:01 whsieh: 7 is a bit early, how about a compromise 7:30 AM? 17:58:42 Travis: I note Megan, snianu +1 that 7:30 time. 17:58:53 Anne: I can also handle Zoom meetings. 17:59:27 BoCupp: For default we'll go with same tech for meeting/IRS 17:59:40 ha ha... IRC, not IRS 17:59:58 snianu: Shall we have a separate meeting for EditContext? 18:00:08 BoCupp: I think we could just discuss in the main meeting. 18:00:25 Topic: Input events 18:00:55 github: https://github.com/w3c/input-events/pull/122 18:01:09 johanneswilm: Is there agreement on what to do next? 18:01:19 .. please follow up BoCupp ! 18:01:35 Topic: end 18:02:00 RRSAgent, please make logs public 18:02:30 zakim, please end the meeting 18:02:30 As of this point the attendees have been Travis_Leithead, comandeer, BoCupp, johanneswilm, snianu, tilgovi 18:02:32 RRSAgent, please draft minutes v2 18:02:32 I have made the request to generate https://www.w3.org/2022/01/14-editing-minutes.html Zakim 18:02:35 I am happy to have been of service, Travis; please remember to excuse RRSAgent. Goodbye 18:02:39 Zakim has left #editing