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