Re: [w3c/clipboard-apis] Start and End fragment tags in text/html format on Windows (Issue #193)

The Web Editing Working Group just discussed `Start and End fragment tags in text/html format on Windows`, and agreed to the following:

* `RESOLVED: Group agrees with proposal as stated by snianu`

<details><summary>The full IRC log of that discussion</summary>
&lt;dandclark> topic: Start and End fragment tags in text/html format on Windows<br>
&lt;dandclark> github: https://github.com/w3c/clipboard-apis/issues/193<br>
&lt;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.<br>
&lt;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.<br>
&lt;dandclark> ...: App can use fragments to get selection<br>
&lt;dandclark> ...: Doesn't make sense in this context because the whole document is inserted<br>
&lt;dandclark> ...: Note, this is Windows-specific.<br>
&lt;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.<br>
&lt;dandclark> ...: In CHromium, if use dataTransfer APIs, we wrap the markup that was provided around the HTML headers<br>
&lt;dandclark> ...: If they write a full doc, the headers will surround the full doc. Native apps know they can't rely on these markers.<br>
&lt;whsieh> q+<br>
&lt;dandclark> ...: They have a way to get the data from the HTML markup, don't rely on the fragment offsets<br>
&lt;johanneswilm> q+<br>
&lt;dandclark> ...: proposal is to insert the start &amp; end fragment marker as part of the HTML header to surround the web author content<br>
&lt;dandclark> ...: even if full doc, markers are inserted as placeholder.<br>
&lt;dandclark> whsieh: These are just comments, not rendered content. So safe to insert anywhere.<br>
&lt;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?<br>
&lt;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<br>
&lt;dandclark> whsieh:  So proposal is UAs may include start/end comments in a document<br>
&lt;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.<br>
&lt;dandclark> whsieh: Makes sense<br>
&lt;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 &lt;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.<br>
&lt;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.<br>
&lt;dandclark> snianu: For regular copy paste we still insert the markers, and there are sanitation steps<br>
&lt;dandclark> sanketj_: Point is that we'll do whatever the authors specify, ti's on the authors to specify the right thing<br>
&lt;dandclark> s/ti's/it's<br>
&lt;dandclark> snianu: Proposal is when the author writes the HTML markup, we surround the whole thing with the start/end fragment tags.<br>
&lt;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.<br>
&lt;dandclark> snianu: Only if the author specifies the entire table. Authors may not want to preserve the structure of the table.<br>
&lt;dandclark> johanneswilm: So if you select cell 1-5, then what?<br>
&lt;dandclark> snianu: regular copy/paste?<br>
&lt;dandclark> snianu: Regular copy/paste we still do the old thing, but for async the authors can choose to insert the markers or not<br>
&lt;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<br>
&lt;dandclark> snianu: Proposal is specific to async clipboard, not changing other APIs<br>
&lt;dandclark> johanneswilm: Need resolution?<br>
&lt;dandclark> snianu: Yes. that you agree with proposal.<br>
&lt;dandclark> RESOLVED: Group agrees with proposal as stated by snianu<br>
</details>


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/193#issuecomment-1759835348
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/193/1759835348@github.com>