- From: Daniel Clark <daniec@microsoft.com>
- Date: Thu, 12 Oct 2023 17:30:03 +0000
- To: "public-editing-tf@w3.org" <public-editing-tf@w3.org>
- Message-ID: <SN6PR00MB034952F1DB0D94519CF197EBC5D3A@SN6PR00MB0349.namprd00.prod.outlook.com>
8:09 AM <dandclark> scribe: dandclark
8:09 AM <dandclark> github: https://github.com/w3c/clipboard-apis/issues/193
8:09 AM — github-bot I can't set a github URL because you haven't started a topic.
8:10 AM <dandclark> topic: Start and End fragment tags in text/html format on Windows
8:10 AM <dandclark> github: https://github.com/w3c/clipboard-apis/issues/193
8:10 AM — github-bot OK, I'll post this discussion to https://github.com/w3c/clipboard-apis/issues/193 (Start and End fragment tags in text/html format on Windows).
8:10 AM <dandclark> snianu: On windows, there are start fragment and end fragment markers that need to be inserted into markup before it can be added to clipboard. Not clear why they have this guidance.
8:11 AM <dandclark> ...: Mainly because when we copy, need to parse selection range and create fragment out of it, indicating what exactly was copied out of the HTML doc.
8:11 AM <dandclark> ...: App can use fragments to get selection
8:12 AM <dandclark> ...: Doesn't make sense in this context because the whole document is inserted
8:12 AM <dandclark> ...: Note, this is Windows-specific.
8:12 AM <dandclark> ...: Not generally an issue if we insert the markers surrounding the document. We've validated this with partners. Can standardize it because dataTransfer APIs also use it.
8:13 AM <dandclark> ...: In CHromium, if use dataTransfer APIs, we wrap the markup that was provided around the HTML headers
8:13 AM <dandclark> ...: If they write a full doc, the headers will surround the full doc. Native apps know they can't rely on these markers.
8:13 AM <whsieh> present+
8:13 AM <whsieh> q+
8:13 AM <dandclark> ...: They have a way to get the data from the HTML markup, don't rely on the fragment offsets
8:13 AM <johanneswilm> q+
8:14 AM <dandclark> ...: proposal is to insert the start & end fragment marker as part of the HTML header to surround the web author content
8:14 AM <johanneswilm> present+
8:14 AM <dandclark> ...: even if full doc, markers are inserted as placeholder.
8:14 AM <edgar> present+
8:14 AM <dandclark> present+
8:14 AM <sanketj_> present+
8:14 AM <snianu> present+
8:14 AM → GameMaker joined (~textual@7e4e2622.public.cloak<mailto:~textual@7e4e2622.public.cloak>)
8:14 AM <comandeer> present+
8:14 AM <GameMaker> present+
8:14 AM <dandclark> whsieh: These are just comments, not rendered content. So safe to insert anywhere.
8:15 AM <dandclark> ...: If you write full HTML doc but only have tags around a subset of the DOM, is expectation that on paste you only paste what's indicated in that range?
8:15 AM <dandclark> snianu: No. Parse the entire fragment. Don't know where payload is coming from so assume markers could be anywhere. Ignore start/end fragment offset and parse like regular HTML
8:15 AM <dandclark> whsieh: So proposal is UAs may include start/end comments in a document
8:16 AM <dandclark> snianu: In Windows, docs say we have to insert markers. From example, scenario is regular copy paste, fragment markers surround the selected range. But doesn't make sense in other scenarios where we have the full document. But we still have to include the fragments.
8:17 AM <dandclark> whsieh: Makes sense
8:18 AM <dandclark> johanneswilm: I thought markers were there b/c sometimes when you copy part of the page, can make new page including only the part user selected. Make everything else go away. Selection of the page corresepds to contents of <body > of HTML page you have on clipboard. But other times it's not possible, e.g. user copied only parts of table. Need to still have entire structure of table in clipboard, ane mark where selection begins/ends.
8:18 AM <dandclark> snianu: That's how it works with regular copy paste. But this is specific to APIs where authors specify what to insert to clipboard.
8:19 AM <dandclark> snianu: For regular copy paste we still insert the markers, and there are sanitation steps
8:19 AM <dandclark> sanketj_: Point is that we'll do whatever the authors specify, ti's on the authors to specify the right thing
8:20 AM <dandclark> s/ti's/it's
8:20 AM <dandclark> snianu: Proposal is when the author writes the HTML markup, we surround the whole thing with the start/end fragment tags.
8:21 AM <dandclark> johanneswilm: So if I select half a table, then w/ regular clipboard you do get the offsets. In async clipboard, it grabs the entire table.
8:21 AM <dandclark> snianu: Only if the author specifies the entire table. Authors may not want to preserve the structure of the table.
8:21 AM <dandclark> johanneswilm: So if you select cell 1-5, then what?
8:22 AM <dandclark> snianu: regular copy/paste?
8:22 AM <dandclark> snianu: Regular copy/paste we still do the old thing, but for async the authors can choose to insert the markers or not
8:23 AM <dandclark> snianu: Conclusion is let web authors decide what to do with the tags. When they fetch marker from clipboard, don't do any operation on the markup to figure out where the fragment tags are
8:23 AM <dandclark> snianu: Proposal is specific to async clipboard, not changing other APIs
8:23 AM <dandclark> johanneswilm: Need resolution?
8:24 AM <dandclark> snianu: Yes. that you agree with proposal.
8:24 AM <dandclark> RESOLVED: Group agrees with proposal as stated by snianu
8:24 AM <dandclark> topic: Read Blob data for the supported formats on-demand during getType.
8:24 AM — github-bot Successfully commented on https://github.com/w3c/clipboard-apis/issues/193 UNABLE TO REMOVE LABEL Agenda+ on https://github.com/w3c/clipboard-apis/issues/193 due to error: Fault { code: 403, error: ClientError { message: "Must have admin rights to Repository.", errors: None, documentation_url: Some(https://docs.github.com/rest/issues/labels#remove-a-label-from-an-issue) } }
8:25 AM <dandclark> github: https://github.com/w3c/clipboard-apis/issues/191
8:25 AM — github-bot OK, I'll post this discussion to https://github.com/w3c/clipboard-apis/issues/191 (Read Blob data for the supported formats on-demand during getType.).
8:25 AM ⇐ GameMaker quit (~textual@7e4e2622.public.cloak<mailto:~textual@7e4e2622.public.cloak>) "My MacBook has gone to sleep. ZZZzzz…"
8:25 AM <dandclark> snianu: When we read (in Chromium) async clipboard, we read all supported formats. When authors specify getType, we return the blob
8:25 AM <dandclark> snianu: Has perf issues, web authors maybe only want plaintext or HTML.
8:25 AM <dandclark> ...: Don't need to read all formats
8:26 AM <dandclark> ...: Proposal is to make decision in getType, not in read
8:26 AM <dandclark> ...: When authors call read() we return formats supported in clipboard. But don't read actual data.
8:26 AM <dandclark> ...: Only read the data when authors call getType()
8:27 AM <dandclark> ...: In dataTransfer, already have this perf optimization. In Windows, check the sequence number, do something similar in MacOS. When clipboard changes, seq number incremented
8:27 AM <dandclark> ...: Can query the number to see if clipboard has changed since you read the formats
8:27 AM <whsieh> q+
8:27 AM <dandclark> ...: If doesn't match, returns empty string. Proposal here is to reject the promise.
8:28 AM <dandclark> whsieh: Proposal is so you read the data lazily. So this is what we do right now in webkit, with the same policy. If change count changes we'll reject the promise.
8:28 AM <edgar> q+
8:28 AM <dandclark> snianu: This matches dataTransfer, so this will make everything interoperable
8:29 AM <dandclark> edgar: What if the web author calls getType multiple times. Between the calls, the data was changed. What happens?
8:30 AM <dandclark> snianu: For dataTransfer it will be empty string every time. For this API, we reject promise.
8:30 AM <dandclark> snianu: In this scenario if clipboard changes between getType calls, e.g. because you switched focus and copied something, then yes we reject promise.
8:33 AM <dandclark> snianu: Proposal here is to reject promise for getType if clipboard has been invalidated. Use sequenceNumber on Windows, the corresponding approach on MacOS. Reject if doesn't match, resolve the promise with the data if matches.
8:33 AM <dandclark> RESOLVED: Change API to behave as specified by Anupam above
8:34 AM <sanketj_> https://github.com/w3c/clipboard-apis/pull/192
8:34 AM — github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
8:35 AM <sanketj_> scribe:dandclark
8:35 AM <sanketj_> github: https://github.com/w3c/edit-context/issues/69
8:35 AM — github-bot OK, I'll post this discussion to https://github.com/w3c/edit-context/issues/69 (Does the composition range need to be exposed on EditContext/TextUpdate?) instead of https://github.com/w3c/clipboard-apis/issues/191 like you said before.
8:36 AM <sanketj_> dandclark: Should compositionRangeStart/End be exposed on EditContext?
8:36 AM <sanketj_> dandclark: Chromium implementation does not, but spec mentions them.
8:36 AM <sanketj_> dandclark: OTs do not suggest these are needed.
8:37 AM <sanketj_> dandclark: Proposal is to remove compositionRangeStart and compositionRangeEnd from the EditContext IDL.
8:37 AM <sanketj_> johanneswilm: Seems reasonable.
8:37 AM <sanketj_> Resolution: Accept resolution.
8:37 AM <sanketj_> Resolution: Accept proposal.
8:38 AM <sanketj_> github: https://github.com/w3c/edit-context/issues/68
8:38 AM — github-bot OK, I'll post this discussion to https://github.com/w3c/edit-context/issues/68 (`editContext` is on HTMLElement but `attachedElements()` returns Element.) instead of https://github.com/w3c/edit-context/issues/69 like you said before.
8:39 AM <sanketj_> dandclark: editContext property is on HTMLElement, but editContext property list returns Element.
8:39 AM <sanketj_> dandclark: Proposal is to make them consistent and have editContext property list return HTMLElement.
8:39 AM <sanketj_> Resolution: Accept proposal.
8:39 AM <sanketj_> github: https://github.com/w3c/edit-context/issues/26
8:39 AM — github-bot OK, I'll post this discussion to https://github.com/w3c/edit-context/issues/26 (Should the methods of EditContext throw an exception if they abort due to not activated?) instead of https://github.com/w3c/edit-context/issues/68 like you said before.
8:40 AM <sanketj_> dandclark: Spec mentions that updateText and similar method all should abort early if EditContext is not active.
8:41 AM <sanketj_> dandclark: Chromium does not implement that way, does not abort if EditContext is not active.
8:41 AM <sanketj_> dandclark: Seems unnecessary to abort, and maybe not desirable.
8:41 AM <johanneswilm> q+
8:42 AM <sanketj_> johanneswilm: Agree not desirable. Requiring focus seems not as convenient.
8:43 AM <sanketj_> Resolution: Accept proposal.
8:43 AM <dandclark> topic: Add supports API for async clipboard.
8:43 AM — github-bot Successfully commented on https://github.com/w3c/edit-context/issues/26 UNABLE TO REMOVE LABEL Agenda+ on https://github.com/w3c/edit-context/issues/26 due to error: Fault { code: 403, error: ClientError { message: "Must have admin rights to Repository.", errors: None, documentation_url: Some(https://docs.github.com/rest/issues/labels#remove-a-label-from-an-issue) } }
8:43 AM <dandclark> github: https://github.com/w3c/clipboard-apis/pull/192
8:43 AM — github-bot OK, I'll post this discussion to https://github.com/w3c/clipboard-apis/pull/192 (Add supports API for async clipboard.).
8:44 AM <dandclark> snianu: Supports API that was proposed some years ago, was proposed to feature detect in async clipboard API. So can determine if format is supported or not.
8:44 AM <dandclark> snianu: We had consensus in the WG that it's a good addition. Had stated need from web devs too. Need to know if given format is supported. Custom formats can be expensive to produce.
8:45 AM <dandclark> snianu: Leads to unnecessary work otherwise, to generate unsupported formts.
8:45 AM <dandclark> snianu: In this issue, proposal is for web custom formats, instead of just providing web prefix the author has to provide entire MIME type, web prefix and suffix.
8:46 AM <dandclark> snianu: If it's a valid format with 'web ' prefix, return true, else false.
8:46 AM <dandclark> snianu: Was some confusion with web custom formats we require the 'web ' prefix. Without the space it's invalid MIME type.
8:47 AM <dandclark> snianu: We strip out the 'web ' prefix and parse the MIME type to see if it's valid MIME type. Proposal is to let authors provide the entire format with the 'web ' prefix
8:48 AM <dandclark> snianu: 'web' and 'web ' (witth space) might be convenient to authors, but if they provide invalid MIME that it fails. So is better to require entire name, as 'web MIMEtype'. Ensures that format is valid and write will succeed.
8:49 AM <dandclark> johanneswilm: No comments from other implementers, what's this mean?
8:49 AM <dandclark> whsieh: Seems fine to me
8:49 AM <dandclark> johanneswilm: Can we resolve or is this controversial?
8:50 AM <dandclark> snianu: It's straightforward. We will make the change that authors have to provide the full custom format with 'web ' (with space) prefix, and MIME type suffix.
8:50 AM <dandclark> RESOLVED: make the change that authors have to provide the full custom format with 'web ' (with space) prefix, and MIME type suffix.
8:51 AM <dandclark> topic: Change meeting link?
8:51 AM — github-bot Successfully commented on https://github.com/w3c/clipboard-apis/pull/192 UNABLE TO REMOVE LABEL Agenda+ on https://github.com/w3c/clipboard-apis/pull/192 due to error: Fault { code: 403, error: ClientError { message: "Must have admin rights to Repository.", errors: None, documentation_url: Some(https://docs.github.com/rest/issues/labels#remove-a-label-from-an-issue) } }
8:52 AM <dandclark> johanneswilm: Let's try to get a different link from W3c for this meeting given audio problems
8:52 AM <dandclark> sanketj_: SGTM
Received on Thursday, 12 October 2023 17:30:17 UTC