Re: [components] Apple's consolidated feedback on Web Components

[Dimitri Glazkov]

Thank you for writing this up, Maciej. Looking forward to the F2F.

:DG<

On Wed, Apr 22, 2015 at 11:19 PM, Maciej Stachowiak  wrote:

>
> > On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak  wrote:
> >
> >
> > Hi everyone,
> >
> > In preparation for Fridays’ face-to-face, a number of us at Apple
> (including me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor
>
> I forgot to mention that Gavin Barraclough also contributed to this
> discussion. We also incorporated past feedback from others on the team.
>
>  - Maciej
>

Re: Exposing structured clone as an API?

[Boris Zbarsky]

On 4/23/15 9:31 PM, Kyle Huey wrote:

Today it's not demanding, it's not even possible.  e.g. how do you
duplicate a FileList object?


Ah, there we go.  I figured there was something that would fail the 
"ways of cloning them all" test in the platform today... ;)


We should make it possible to manually clone FileList of course, but the 
larger point is that this is likely to continue being a problem.


-Boris

Re: Exposing structured clone as an API?

[Kyle Huey]

On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky  wrote:
> On 4/23/15 6:34 PM, Elliott Sprehn wrote:
>>
>> Have you benchmarked this? I think you're better off just writing your
>> own clone library.
>
>
> That requires having a list of all objects browsers consider clonable and
> having ways of cloning them all, right?  Maintaining such a library is
> likely to be a somewhat demanding undertaking as new clonable objects are
> added...
>
> -Boris
>

Today it's not demanding, it's not even possible.  e.g. how do you
duplicate a FileList object?

- Kyle

Re: Exposing structured clone as an API?

[Boris Zbarsky]

On 4/23/15 6:34 PM, Elliott Sprehn wrote:

Have you benchmarked this? I think you're better off just writing your
own clone library.


That requires having a list of all objects browsers consider clonable 
and having ways of cloning them all, right?  Maintaining such a library 
is likely to be a somewhat demanding undertaking as new clonable objects 
are added...


-Boris

Re: Directory Upload Proposal

[Anne van Kesteren]

On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas  wrote:
> If there is sufficient interest, I would like to work on this within the 
> scope of the WebApps working group.

It seems somewhat better to just file a bug against the HTML Standard
since this also affects the processing model of e.g. .files.
Which I think was the original proposal for how to address this...
Just expose all the files in .files and expose the relative
paths, but I guess that might be a bit too synchronous...

(Also, you want to use sequence<> not [] for listContents().)


-- 
https://annevankesteren.nl/

Re: Exposing structured clone as an API?

[Anne van Kesteren]

On Thu, Apr 23, 2015 at 3:02 PM, Ted Mielczarek  wrote:
> Has anyone ever proposed exposing the structured clone algorithm directly as
> an API?

There has been some talk about moving structured cloning into
ECMAScript proper and exposing the primitives. But TC39 does not seem
particularly receptive unless it comes with a way for someone to
participate in the structured cloning algorithm with custom objects.

But yeah, I think this should definitely be an API of sorts eventually.


-- 
https://annevankesteren.nl/

[Bug 28353] [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. /

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353

Koji Ishii  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||kojii...@gmail.com
 Resolution|WORKSFORME  |---

--- Comment #2 from Koji Ishii  ---
Can tpu clarify what you meant? I just didn't understand.

Should the example be valud, pr not? I prefer not, but it was controversial.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Exposing structured clone as an API?

[Martin Thomson]

On 23 April 2015 at 15:34, Elliott Sprehn  wrote:
> Have you benchmarked this? I think you're better off just writing your own
> clone library.


Not really the point of my mail.  Of course you would be better
writing a real clone.

It could probably even be synchronous, though it removes this (or a
less bad version, see Maceij's comments) as a polyfill option.

Re: Exposing structured clone as an API?

[Maciej Stachowiak]

> On Apr 23, 2015, at 3:27 PM, Martin Thomson  wrote:
> 
> On 23 April 2015 at 15:02, Ted Mielczarek  wrote:
>> Has anyone ever proposed exposing the structured clone algorithm directly as 
>> an API?
> 
> If you didn't just do so, I will :)
> 
>> 1. https://twitter.com/TedMielczarek/status/591315580277391360
> 
> Looking at your jsfiddle, here's a way to turn that into something useful.
> 
> +Object.prototype.clone = Object.prototype.clone || function() {
> - function clone(x) {
>return new Promise(function (resolve, reject) {
>window.addEventListener('message', function(e) {
>resolve(e.data);
>});
> +window.postMessage(this, "*");
> -window.postMessage(x, "*");
>});
> }
> 
> But are we are in the wrong place to have that discussion?

Code nitpick: it probably should remove the event listener from within the 
handler, or calling this function repeatedly will leak memory. Also it will get 
slower every time.

Actually, now that I think about it, this isn’t usable at all if you are using 
postMessage for anything else, since you could accidentally capture 
non-cloning-related messages.

I guess these are potentially arguments to expose cloning directly.

Regards,
Maciej

Re: Exposing structured clone as an API?

[Elliott Sprehn]

The way many browsers implement this isn't going to be particularly fast.
It serializes the objects to a byte sequence so it can be transferred to
another thread or process and then inflates the objects on the other side.

Have you benchmarked this? I think you're better off just writing your own
clone library.
On Apr 23, 2015 12:30 PM, "Martin Thomson"  wrote:

> On 23 April 2015 at 15:02, Ted Mielczarek  wrote:
> > Has anyone ever proposed exposing the structured clone algorithm
> directly as an API?
>
> If you didn't just do so, I will :)
>
> > 1. https://twitter.com/TedMielczarek/status/591315580277391360
>
> Looking at your jsfiddle, here's a way to turn that into something useful.
>
> +Object.prototype.clone = Object.prototype.clone || function() {
> - function clone(x) {
> return new Promise(function (resolve, reject) {
> window.addEventListener('message', function(e) {
> resolve(e.data);
> });
> +window.postMessage(this, "*");
> -window.postMessage(x, "*");
> });
> }
>
> But are we are in the wrong place to have that discussion?
>
>

Re: Exposing structured clone as an API?

[Martin Thomson]

On 23 April 2015 at 15:02, Ted Mielczarek  wrote:
> Has anyone ever proposed exposing the structured clone algorithm directly as 
> an API?

If you didn't just do so, I will :)

> 1. https://twitter.com/TedMielczarek/status/591315580277391360

Looking at your jsfiddle, here's a way to turn that into something useful.

+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, "*");
-window.postMessage(x, "*");
});
}

But are we are in the wrong place to have that discussion?

Exposing structured clone as an API?

[Ted Mielczarek]

Has anyone ever proposed exposing the structured clone algorithm directly
as an API? Katelyn Gadd was musing about fast deep copy in JS on Twitter,
and I proposed a hack to use postMessage to do so[1], which works but it's
a little roundabout. Since structured clone is a primitive that the web
platform is built on it seems like a primitive that ought to be exposed. I
know this exists in other languages (Python has copy.deepcopy[2]) and
there's an npm "deepcopy" module[3] with lots of downloads so this is
clearly something people use.

-Ted

1. https://twitter.com/TedMielczarek/status/591315580277391360
2. https://docs.python.org/2/library/copy.html#copy.deepcopy
3. https://www.npmjs.com/package/deepcopy

[Bug 27325] [Shadow]: Figure out how session history should work for s in shadow DOM

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325
Bug 27325 depends on bug 20144, which changed state.

Bug 20144 Summary: [Shadow]: Add "closed" flag to createShadowRoot
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 28552] [Shadow]: Shadow DOM v1

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552
Bug 28552 depends on bug 20144, which changed state.

Bug 20144 Summary: [Shadow]: Add "closed" flag to createShadowRoot
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks

[Ted Mielczarek]

On Thu, Apr 23, 2015 at 4:13 AM, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
> running into some tricky questions I'd like to discuss here.
>
> Basically, on Windows IE and other apps that write HTML to the clipboard
> use the CF_HTML format. This format is simply described as
>

There's some related discussion in bug 137450[1], I wrote a patch for that
quite a few years ago (that never landed). In the comments someone pointed
out that Microsoft has documented CF_HTML[2] since then, which is nice.

-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=137450#c33
2. https://msdn.microsoft.com/en-us/library/aa767917%28v=vs.85%29.aspx

[Bug 28491] [Shadow]: [Meta] Unblock Mozilla's shipping of Shadow DOM

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28491

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Anne  ---
These are now moved to v1 blockers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 28353] [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. /

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@annevk.nl
 Resolution|--- |WORKSFORME

--- Comment #1 from Anne  ---
This falls out of defining CSS in terms of the composed tree.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Directory Upload Proposal

[Ali Alabbas]

Hello WebApps Group,

For the past few years sites have been enabling directory uploads by using the 
old FileSystem API [1] in Chrome and Opera. In the April 2014 face to face 
WebApps group meeting [2], there was a CfC to move the old specs into a WG Note 
and to continue working on the new FileSystem API [3] instead, effectively 
discontinuing work on the old FileSystem API.

The new FileSystem API tries to satisfy a large number of use cases with an 
approach that is better than the old API. However, its broad scope and its 
dependencies on future capabilities (e.g. Observables) has slowed down the pace 
at which it is moving forward. Due to this, there is currently no interoperable 
way to enable directory uploads on the web. We have received lots of feedback 
from developers - including some working on Microsoft services such as OneDrive 
- that supporting directory upload is a high priority for them. 

To enable developers to build future interoperable solutions, we've drafted a 
proposal [4], with the helpful feedback of Mozilla and Google, that focuses 
strictly on providing the mechanisms necessary to enable directory uploads. The 
proposal uses a subset of the new FileSystem API so that it can be expanded in 
the future to enable more scenarios when the new FileSystem API is further 
along. To help understand the proposal (especially the APIs involved) I have 
written a polyfill [5] and demo page [6] that is built on top of Chrome's old 
FileSystem API.

If there is sufficient interest, I would like to work on this within the scope 
of the WebApps working group.

Thank you,
Ali

[1] Old FileSystem API: http://www.w3.org/TR/file-system-api/
[2] WebApps April '14 Meeting: 
http://www.w3.org/2014/04/10-webapps-minutes.html#item02
[3] New FileSystem API: http://w3c.github.io/filesystem-api/
[4] Proposal: http://internetexplorer.github.io/directory-upload/proposal.html
[5] Polyfill: 
https://github.com/InternetExplorer/directory-upload/blob/gh-pages/polyfill.js
[6] Demo: http://internetexplorer.github.io/directory-upload/index.html

[Bug 28440] [Shadow]: Layout Containment and Shadow Trees

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28440

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Anne  ---
This can be done in CSS and doesn't impact us much. But it's very cool!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 24861] [Shadow]: Add a way to detect when the list of nodes distributed to an insertion point mutates

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24861

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@annevk.nl
 Resolution|--- |DUPLICATE

--- Comment #5 from Anne  ---


*** This bug has been marked as a duplicate of bug 21149 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 28539] [Shadow]: Typos Spefifies and Speficies

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28539

Dimitri Glazkov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dglaz...@chromium.org
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[components] Isolated Imports and Foreign Custom Elements

[Maciej Stachowiak]

Hi everyone,

I wrote up a proposal (with input and advice from Ryosuke Niwa) on a possible 
way to extend Web Components to support fully isolated components:

https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal 


I welcome comments on whether this approach makes sense.


I’d also like to discuss this during the proposals section of tomorrow’s F2F. I 
know it’s supposed to be focused on Shadow DOM, but I think this proposal is 
relevant context.

I think this proposal, even if it is itself a post-v1 project, helps explain 
why closed mode is important and relevant. While closed mode doesn’t provide 
strong security isolation by default, its a building block that can be used to 
build full isolation, whereas open mode can’t be used that way.

If we agree to have a closed mode eventually, then it’s probably sensible to 
add it for v1. We’d also want to decide sooner rather than later whether closed 
or open is the default (or whether there is no default and we require authors 
to choose one explicitly).

Regards,
Maciej

Re: [clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks

[Daniel Cheng]

On Thu, Apr 23, 2015 at 1:16 AM Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
> running into some tricky questions I'd like to discuss here.
>
> Basically, on Windows IE and other apps that write HTML to the clipboard
> use the CF_HTML format. This format is simply described as
>
> > headers (name:value meta data)
> >
> > 
> > 
> > HTML
> > 
> > 
>
> where the StartFragment / EndFragment comment tags are inserted by
> implementations writing HTML to the clipboard to show where the actually
> selected content starts and ends. Several very common implementations
> (including I believe Microsoft Word's) will add tags like STYLE outside of
> the StartFragment/EndFragment tags and add rules that may be significant
> for rendering the content of the fragment correctly. Also noteworthy is
> that the meta data may include a SourceURL property showing the URL of the
> page you copied from.
>
> So, because of the significance of the STYLE information and other stuff
> outside Start/EndFragment, certain browsers return the full document
> including the Start/EndFragment comment tags when a script does
> getData('text/html'). This is obviously very useful when there's important
> stuff outside these tags. It still means scripts have to do extra work to
> find those comments and extract the content inside them to know what data a
> user actually intended to paste. This also adds a risk that scripts will be
> tested only on Windows and authored to require those comments and fail if
> they aren't there on other platforms.
>
>
Chrome's behavior is to return the literal HTML data, but without the
metadata header when a page calls getData('text/html'). However, if Chrome
is executing the default action of paste, we attempt to parse out the
fragment and only paste the fragment (however, we incorrectly don't include
styles).


> Should we, then, standardise returning the full document including
> Start/EndFragment comments (basically requiring or encouraging other
> platform implementations to start using those comments when serializing
> HTML for the OS clipboard) - or should getData() return only what's inside
> the Start/EndFragment tags? Are any other important platforms already using
> CF_HTML conventions, or would their developers balk at being encouraged to
> do so?
>

CF_HTML is not a format that any other app on any other platform would be
expecting, so you wouldn't be able to just start writing it to the
clipboard on Mac/Linux in place of the original HTML. So there's a bit of a
chicken and egg problem here.

I also can't say I love the CF_HTML format: the markup is a lot easier to
work with when the styles are inlined, etc. Plus pasting 

[Bug 28246] [Shadow]: Disable event capturing through a ShadowRoot

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28246

Dimitri Glazkov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dglaz...@chromium.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Dimitri Glazkov  ---


*** This bug has been marked as a duplicate of bug 26892 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 28552] New: [Shadow]: Shadow DOM v1

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552

Bug ID: 28552
   Summary: [Shadow]: Shadow DOM v1
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: dglaz...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 11350] [IndexedDB] ObjectStores should have a way to hint that they're "evictable"

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=11350

Joshua Bell  changed:

   What|Removed |Added

 CC||jsb...@google.com
 Resolution|LATER   |WONTFIX

--- Comment #3 from Joshua Bell  ---
LATER -> WONTFIX

In discussions with implementers, this seems to be the wrong direction. See
https://wiki.whatwg.org/wiki/Storage for some more recent thoughts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 16595] Ability to get non-sequential records from various operations

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595

Joshua Bell  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jsb...@google.com
 Resolution|LATER   |---

--- Comment #2 from Joshua Bell  ---
We're thinking of tackling this with a combination of two new entry points:

IDBObjectStore/IDBIndex#getAll(keys [, count]) - implemented in FF, WIP in
Chrome

IDBKeySet - a set (*gasp*!) of keys.

getAll() and existing methods that take a key-or-range would be extended to
take key-or-range-or-set.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 17681] [IndexedDB] Operations that raise multiple exceptions types should define order

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17681

Joshua Bell  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |---

--- Comment #15 from Joshua Bell  ---
I do want to attempt to fix this for the V2 of the spec.

I'll attempt to survey the existing implementations first, and basically spec
the consensus where possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 20257] IDBCursor should walk on secondary ordering of index value

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20257

Joshua Bell  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |---

--- Comment #13 from Joshua Bell  ---
IDBCursor#continuePrimaryKey() is implemented in Chrome (behind and
experimental flag). We haven't touched the openCursor/openKeyCursor methods
yet, though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 23332] Support Binary Keys

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332

Joshua Bell  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ann...@annevk.nl,
   ||bent.mozi...@gmail.com
 Resolution|LATER   |---

--- Comment #11 from Joshua Bell  ---
cc: bent, annevk

I was chatting with bent and annevk yesterday and they indicated a preference
for the approach of BufferSource (input)/ArrayBuffer (output), and no
preserving of view type when comparing or retrieving values.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 22370] Inform script of corruption-induced data loss

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22370

Joshua Bell  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jsb...@google.com
 Resolution|LATER   |---

--- Comment #3 from Joshua Bell  ---
As dgrogan@ noted, we shipped IDBVersionChangeEvent#dataLoss and
IDBVersionChangeEvent#dataLossMessage in Chrome, and it's seeing use. Since
they're not widely publicized entry points we're open to alternate suggestions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 19955] [IndexedDB] Add IDBObjectStore.openKeyCursor

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19955

Joshua Bell  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Joshua Bell  ---
Specified in
https://github.com/w3c/IndexedDB/commit/0f168cc96e38441b9131124786992589fbdb0388

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 19955] [IndexedDB] Add IDBObjectStore.openKeyCursor

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19955

Joshua Bell  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |---

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 28549] New: [Shadow]: Add [TreatNullAs=EmptyString] to ShadowRoot.innerHTML

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28549

Bug ID: 28549
   Summary: [Shadow]: Add [TreatNullAs=EmptyString] to
ShadowRoot.innerHTML
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
   URL: https://w3c.github.io/webcomponents/spec/shadow/#the-s
hadowroot-interface
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: phil...@opera.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

This is how it's implemented in Blink, and it's consistent with
Element.innerHTML:
https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html#extensions-to-the-element-interface

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks

[Hallvord Reiar Michaelsen Steen]

We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
running into some tricky questions I'd like to discuss here.

Basically, on Windows IE and other apps that write HTML to the clipboard
use the CF_HTML format. This format is simply described as

> headers (name:value meta data)
>
> 
> 
> HTML
> 
> 

where the StartFragment / EndFragment comment tags are inserted by
implementations writing HTML to the clipboard to show where the actually
selected content starts and ends. Several very common implementations
(including I believe Microsoft Word's) will add tags like STYLE outside of
the StartFragment/EndFragment tags and add rules that may be significant
for rendering the content of the fragment correctly. Also noteworthy is
that the meta data may include a SourceURL property showing the URL of the
page you copied from.

So, because of the significance of the STYLE information and other stuff
outside Start/EndFragment, certain browsers return the full document
including the Start/EndFragment comment tags when a script does
getData('text/html'). This is obviously very useful when there's important
stuff outside these tags. It still means scripts have to do extra work to
find those comments and extract the content inside them to know what data a
user actually intended to paste. This also adds a risk that scripts will be
tested only on Windows and authored to require those comments and fail if
they aren't there on other platforms.

Should we, then, standardise returning the full document including
Start/EndFragment comments (basically requiring or encouraging other
platform implementations to start using those comments when serializing
HTML for the OS clipboard) - or should getData() return only what's inside
the Start/EndFragment tags? Are any other important platforms already using
CF_HTML conventions, or would their developers balk at being encouraged to
do so?

On a related topic, I see SourceURL as useful (could be used to properly
attribute citations automatically and such) - it would be nice to
standardise DataTransfer.sourceURL or something like that, to be set when
available.
-Hallvord
(editor of https://w3c.github.io/clipboard-apis/ )
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=586587

=[xhr]

[Charles Perry]

This is causing grepolis to lag significantly. Please fix it

 

Charles T Perry