css-meeting-bot
commented
8 months ago 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
The full IRC log of that discussion
<dandclark> topic: Start and End fragment tags in text/html format on Windows<dandclark> github: https://github.com/w3c/clipboard-apis/issues/193
<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.
<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.
<dandclark> ...: App can use fragments to get selection
<dandclark> ...: Doesn't make sense in this context because the whole document is inserted
<dandclark> ...: Note, this is Windows-specific.
<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.
<dandclark> ...: In CHromium, if use dataTransfer APIs, we wrap the markup that was provided around the HTML headers
<dandclark> ...: If they write a full doc, the headers will surround the full doc. Native apps know they can't rely on these markers.
<whsieh> q+
<dandclark> ...: They have a way to get the data from the HTML markup, don't rely on the fragment offsets
<johanneswilm> q+
<dandclark> ...: proposal is to insert the start & end fragment marker as part of the HTML header to surround the web author content
<dandclark> ...: even if full doc, markers are inserted as placeholder.
<dandclark> whsieh: These are just comments, not rendered content. So safe to insert anywhere.
<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?
<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
<dandclark> whsieh: So proposal is UAs may include start/end comments in a document
<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.
<dandclark> whsieh: Makes sense
<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.
<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.
<dandclark> snianu: For regular copy paste we still insert the markers, and there are sanitation steps
<dandclark> sanketj_: Point is that we'll do whatever the authors specify, ti's on the authors to specify the right thing
<dandclark> s/ti's/it's
<dandclark> snianu: Proposal is when the author writes the HTML markup, we surround the whole thing with the start/end fragment tags.
<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.
<dandclark> snianu: Only if the author specifies the entire table. Authors may not want to preserve the structure of the table.
<dandclark> johanneswilm: So if you select cell 1-5, then what?
<dandclark> snianu: regular copy/paste?
<dandclark> snianu: Regular copy/paste we still do the old thing, but for async the authors can choose to insert the markers or not
<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
<dandclark> snianu: Proposal is specific to async clipboard, not changing other APIs
<dandclark> johanneswilm: Need resolution?
<dandclark> snianu: Yes. that you agree with proposal.
<dandclark> RESOLVED: Group agrees with proposal as stated by snianu
On Windows, according to the mdn doc, native apps need to write
<!--StartFragment -->and<!--EndFragment -->tags to indicate the fragment start and end in the HTML markup. This information is also present in the HTML headers that get written to the clipboard. However, it's not exactly clear where we should insert these fragment tags into the markup when web authors read/write the HTML data from/to the clipboard via async clipboard read()/write() method and DataTransfer API getData/setData methods.We think that it's better to let the web authors decide what to do with the tags, so it's simpler to just return the start and end fragment tags as-is without any changes to the existing HTML markup. This also makes async read() method interoperable with DataTransfer APIs getData method. Note that even though the below example is specific to Chromium, Firefox also behaves the same way when it comes to DataTransfer APIs set/getData methods.
e.g. In Chromium browsers, when
<p>Hello World</p>is inserted via setData method during copy event, we see the below content forHTML formaton the system clipboard:getData method returns the following string during paste event:
In Async clipboard API, write() method produces the below markup:
read() method strips out the fragment tags and returns
<p>Hello World</p>:@evanstade @annevk @sanketj @inexorabletash @smaug---- @EdgarChen