Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, 06 Sep 2011 00:51:01 +0200, Glenn Maynard gl...@zewt.org wrote: I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs If we spec'ed that, what would the point of firing the events be? How would you solve the use cases we're trying to solve? Your concerns are valid but need UI-work, preferences and other stuff that is generally considered UA features and outside of a technical API spec. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Re: CfC: new WD of Clipboard API and Events; deadline April 5
We've seen people who abused hidden style to smuggle evil shell commands into seemingly innocuous shell instructions. When pasting text into a word processor, one generally gets a functional preview of the results. When pasting into a shell, things are typically executed immediately sans preview. Now, there are solutions, kinda. Instead of copying directly to the clipboard, you can provide a number of flavors on the clipboard, with the default being WYSIWYG and another being what the tool offered. Office apps and web browsers could let users select the alternate flavor. Simple apps should get the WYSIWYG flavor. We only recently fixed the css hidden clipboard bugs. On 9/5/11, Glenn Maynard gl...@zewt.org wrote: On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht p...@hoplahup.net wrote: Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash advertisement 100% cpu) and I am confident they will not that some pages mingle with their copy ability or actually provide a service to do so. Sorry, I'm having trouble parsing this. My experience so far is that people are aggravated by pages that insert ads into copied text, but not quite enough to stop them from using a page. They grumble and delete the ad. That's the most annoying category of abuse, in my opinion: not bad enough to strongly discourage its use, causing it to spread, but bad enough to continuously annoy users. I'd love to hear your feedback but that's how I feel things and I think we just have to accept it: new technology, new risks, positive and negative. It's acceptable for new technologies to have negatives, of course; the positives need to balance the negatives. To be clear, I don't mean that this abuse is newly exposed by this API. It's an abuse that's been spreading lately, using hacks with existing APIs. I meant that it shows that people will broadly abuse anything that lets them fiddle with the clipboard; in other words, this isn't a theoretical problem. I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs, but this API makes that approach useless; it officially blesses the entire category of messing-with-what-the-user-copies, so it'd never be fixable. That's frustrating. (As an aside, it would still be possible to do this sort of clipboard hijacking even if that was done, by fiddling with the selection when the selection change happens instead of waiting for the copy. From my experiments, though, that approach is much more brittle, which is a deterrent in and of itself.) We can't stop pages from being annoying, but we should definitely keep in mind the annoying things that are actually being done in the wild today, and be aware of the things a new API might exacerbate. -- Glenn Maynard -- Sent from my mobile device
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Wed, 07 Sep 2011 02:08:04 +0200, Glenn Maynard gl...@zewt.org wrote: use a browser that doesn't support these events, or a browser that lets you disable them (perhaps on a per-site basis), or a browser that supports extensions that let you disable them. These aren't solutions that help average users. What helps average users is IMO mostly a UI question ;-) I'd predict that this will be handled much like popup windows. They became a nuisance for users, so UAs evolved to develop popup blocking, various types of UI for opt-in enabling et cetera. If clipboard event abuse becomes a severe enough problem, UAs will respond. Also, nothing stops UAs from giving the user opt-in measures before enabling this functionality in the first place, and some UAs already have opt-in mechanisms when scripts want to use the OS clipboard that could or should be extended to also enable/disable clipboard events. Doing this in a user-friendly way is a fair playing field for UAs to compete on, and not something we should figure out now and put in the spec. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: CfC: new WD of Clipboard API and Events; deadline April 5
Le 7 sept. 2011 à 09:43, Hallvord R. M. Steen a écrit : What helps average users is IMO mostly a UI question ;-) I'd predict that this will be handled much like popup windows. They became a nuisance for users, so UAs evolved to develop popup blocking, various types of UI for opt-in enabling et cetera. If clipboard event abuse becomes a severe enough problem, UAs will respond. Also, nothing stops UAs from giving the user opt-in measures before enabling this functionality in the first place, and some UAs already have opt-in mechanisms when scripts want to use the OS clipboard that could or should be extended to also enable/disable clipboard events. Doing this in a user-friendly way is a fair playing field for UAs to compete on, and not something we should figure out now and put in the spec. I'd like to agree but we have to be a bit more nuanced. I think we should avoid the historical errors of MSIE. Though I may have a biassed view of history, here's how I see that. The MSIE API for clipboard has been there since IE 6, long long long ago. But it was very quickly pointed to as a very evil feature (allowing web-pages to read clipboard without asking) and became limited to trusted sites; it was not really made useful. By now, we know how to avoid the aforementioned problem but there are suspicions of other problems. If we do not convince someone like Glenn, we run the risk of the same failure, so we have an interest to do so. Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit : To be clear, I don't mean that this abuse is newly exposed by this API. It's an abuse that's been spreading lately, using hacks with existing APIs. I meant that it shows that people will broadly abuse anything that lets them fiddle with the clipboard; in other words, this isn't a theoretical problem. I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs, but this API makes that approach useless; it officially blesses the entire category of messing-with-what-the-user-copies, so it'd never be fixable. That's frustrating. As said earlier, the fiddle is expected to be useful... we can't remove it. To the risk of an annoying clipboard service of the web page, I would propose the solution of Jonas Sicking: a copy text command (CTRL-SHIFT-C maybe?) that would ignore the scripts. I note that it's not the spec's job to specify such. It's the job of informal material around the spec, such as this list, to suggest workarounds to recognized risks. paul
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
It'd be great if that were the case, but in my experience this is the level of annoyance that will irritate users, but not enough to make many of them stop using a site. This same discussion always pops up when a new feature might have implications beyond the browser window, like dd, file api, web gl, clipboard api, etc. Features are demanded and the specs need to be written in a way that supports most, if not all, of the valid use cases. If there are possibilities of those same APIs being used to hinder user experience, then the user agent must provide options for the user to control what the sites do, so it becomes an UI issue. And, such websites are few, slim, and have little users. Now, we can move forward :) Thank you.
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, 05 Sep 2011 16:50:15 +0200, Glenn Maynard gl...@zewt.org wrote: Pretty much everything in this spec can be abused to cause nuisance. Personally, I'm less than thrilled to see an API giving sites more ability to mangle what I copy. With greater powers comes, as they say, greater responsibility. If you personally don't like the possibilities for nuisance this API enables, you have multiple options - use a browser that doesn't support these events, or a browser that lets you disable them (perhaps on a per-site basis), or a browser that supports extensions that let you disable them. I also think that a site that behaves in user-unfriendly ways will end up loosing users. If a site is arrogant enough to mess with what I copy unless to improve it, it deserves to loose users. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, Sep 6, 2011 at 7:25 AM, Hallvord R. M. Steen hallv...@opera.comwrote: With greater powers comes, as they say, greater responsibility. If you personally don't like the possibilities for nuisance this API enables, you have multiple options - use a browser that doesn't support these events, or a browser that lets you disable them (perhaps on a per-site basis), or a browser that supports extensions that let you disable them. These aren't solutions that help average users. I also think that a site that behaves in user-unfriendly ways will end up loosing users. If a site is arrogant enough to mess with what I copy unless to improve it, it deserves to loose users. It'd be great if that were the case, but in my experience this is the level of annoyance that will irritate users, but not enough to make many of them stop using a site. -- Glenn Maynard
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, 04 Sep 2011 23:47:08 +0200, Hallvord R. M. Steen hallv...@opera.com wrote: Also, scripts shouldn't be able to call clearData() during copy/cut events, correct? Why not? Is it useful in any other context? It can be abused to prevent copy and paste from a site. But maybe there are other ways for that too. For 10. Cross-origin copy/paste of source code, we might also want to consider stripping elements that can refer to external URLs such as link, meta, base, etc... Those will typically be in the HEAD and not usually part of a pasted fragment. We certainly don't want to remove A tags or their HREFs, so I'm not sure why we'd want to remove e.g. LINK. Depending on the type of link it can fetch its resource automatically. -- Anne van Kesteren http://annevankesteren.nl/
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, 05 Sep 2011 10:44:13 +0200, Anne van Kesteren ann...@opera.com wrote: On Sun, 04 Sep 2011 23:47:08 +0200, Hallvord R. M. Steen hallv...@opera.com wrote: Also, scripts shouldn't be able to call clearData() during copy/cut events, correct? Why not? Is it useful in any other context? It can be abused to prevent copy and paste from a site. But maybe there are other ways for that too. Pretty much everything in this spec can be abused to cause nuisance. For 10. Cross-origin copy/paste of source code, we might also want to consider stripping elements that can refer to external URLs such as link, meta, base, etc... Those will typically be in the HEAD and not usually part of a pasted fragment. We certainly don't want to remove A tags or their HREFs, so I'm not sure why we'd want to remove e.g. LINK. Depending on the type of link it can fetch its resource automatically. As in LINK rel=prefetch and LINK rel=stylesheet? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, 05 Sep 2011 12:13:35 +0200, Hallvord R. M. Steen hallv...@opera.com wrote: As in LINK rel=prefetch and LINK rel=stylesheet? Yes. But this would apply to img too of course; maybe they can become a blob URL or some such? -- Anne van Kesteren http://annevankesteren.nl/
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, 05 Sep 2011 12:14:27 +0200, Anne van Kesteren ann...@opera.com wrote: On Mon, 05 Sep 2011 12:13:35 +0200, Hallvord R. M. Steen hallv...@opera.com wrote: As in LINK rel=prefetch and LINK rel=stylesheet? Yes. But this would apply to img too of course; maybe they can become a blob URL or some such? Well, giving JS access to the clipboard's HTML will be next to useless if we remove just about everything :-p For the record, I think the spec as-is is too paranoid and that we probably should allow form elements (except input type=hidden). Coherent, usable, safe - pick any one and a half.. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, Sep 5, 2011 at 6:13 AM, Hallvord R. M. Steen hallv...@opera.comwrote: Pretty much everything in this spec can be abused to cause nuisance. Personally, I'm less than thrilled to see an API giving sites more ability to mangle what I copy. Clipboard hijacking scripts that add read more at... spam to copied text make it painfully clear that sites will actively abuse a clipboard API; I'd sooner see sites have less control, to prevent this gross abuse, not more. Browsers should copy only what I tell them to copy. -- Glenn Maynard
Re: CfC: new WD of Clipboard API and Events; deadline April 5
Le 5 sept. 2011 à 16:50, Glenn Maynard a écrit : On Mon, Sep 5, 2011 at 6:13 AM, Hallvord R. M. Steen hallv...@opera.com wrote: Pretty much everything in this spec can be abused to cause nuisance. Personally, I'm less than thrilled to see an API giving sites more ability to mangle what I copy. Clipboard hijacking scripts that add read more at... spam to copied text make it painfully clear that sites will actively abuse a clipboard API; I'd sooner see sites have less control, to prevent this gross abuse, not more. Browsers should copy only what I tell them to copy. Glenn, there was a long thread about that at the TAG mailing list. http://www.w3.org/mid/affab130-b693-4ac9-91e6-b6834e57b...@w3.org Unfortunately, there is no way to discriminate a page that tries to be useful and a page that tries to lower your actions (as the other one I just sent the webapp mailing list which, btw, uses no clipboard API). Such a lack of discrimination was also there for JavaScript which could create DoS attacks easily. You can disable javascript but then, who does? It did not become so fashionable anymore... same for applets, flash, ... Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash advertisement 100% cpu) and I am confident they will not that some pages mingle with their copy ability or actually provide a service to do so. I'd love to hear your feedback but that's how I feel things and I think we just have to accept it: new technology, new risks, positive and negative. paul
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht p...@hoplahup.net wrote: Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash advertisement 100% cpu) and I am confident they will not that some pages mingle with their copy ability or actually provide a service to do so. Sorry, I'm having trouble parsing this. My experience so far is that people are aggravated by pages that insert ads into copied text, but not quite enough to stop them from using a page. They grumble and delete the ad. That's the most annoying category of abuse, in my opinion: not bad enough to strongly discourage its use, causing it to spread, but bad enough to continuously annoy users. I'd love to hear your feedback but that's how I feel things and I think we just have to accept it: new technology, new risks, positive and negative. It's acceptable for new technologies to have negatives, of course; the positives need to balance the negatives. To be clear, I don't mean that this abuse is newly exposed by this API. It's an abuse that's been spreading lately, using hacks with existing APIs. I meant that it shows that people will broadly abuse anything that lets them fiddle with the clipboard; in other words, this isn't a theoretical problem. I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs, but this API makes that approach useless; it officially blesses the entire category of messing-with-what-the-user-copies, so it'd never be fixable. That's frustrating. (As an aside, it would still be possible to do this sort of clipboard hijacking even if that was done, by fiddling with the selection when the selection change happens instead of waiting for the copy. From my experiments, though, that approach is much more brittle, which is a deterrent in and of itself.) We can't stop pages from being annoying, but we should definitely keep in mind the annoying things that are actually being done in the wild today, and be aware of the things a new API might exacerbate. -- Glenn Maynard
Re: riks of the new clipboard operations API (was: Re: CfC: new WD of Clipboard API and Events; deadline April 5)
Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit : On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht p...@hoplahup.net wrote: Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash advertisement 100% cpu) and I am confident they will not that some pages mingle with their copy ability or actually provide a service to do so. Sorry, I'm having trouble parsing this. My experience so far is that people are aggravated by pages that insert ads into copied text, but not quite enough to stop them from using a page. They grumble and delete the ad. That's the most annoying category of abuse, in my opinion: not bad enough to strongly discourage its use, causing it to spread, but bad enough to continuously annoy users. They will provide feedback and/or prefer sites that do not do that. The offer is diverse enough for this. That's what the paragraph above says. I agree that the API indeed brings in new possibilities of abuse and new utilities, they cannot be discerned except by an end user. You are are right we need to be aware of the risks. The tracker injection is, to my taste, relatively mild. Hidden anchors would be considerably worse. paul I'd love to hear your feedback but that's how I feel things and I think we just have to accept it: new technology, new risks, positive and negative. It's acceptable for new technologies to have negatives, of course; the positives need to balance the negatives. To be clear, I don't mean that this abuse is newly exposed by this API. It's an abuse that's been spreading lately, using hacks with existing APIs. I meant that it shows that people will broadly abuse anything that lets them fiddle with the clipboard; in other words, this isn't a theoretical problem. I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs, but this API makes that approach useless; it officially blesses the entire category of messing-with-what-the-user-copies, so it'd never be fixable. That's frustrating. (As an aside, it would still be possible to do this sort of clipboard hijacking even if that was done, by fiddling with the selection when the selection change happens instead of waiting for the copy. From my experiments, though, that approach is much more brittle, which is a deterrent in and of itself.) We can't stop pages from being annoying, but we should definitely keep in mind the annoying things that are actually being done in the wild today, and be aware of the things a new API might exacerbate. -- Glenn Maynard
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
Hi Ryosuke Niwa, responding to this on list: I think I have raised my concern before but what should happen if script calls getData() within a copy/cut event handler? With the current version of the spec, no data from the actual OS clipboard will be visible in copy/cut event processing. I have however not added any specific limitations on calling getData() during copy/cut events, so if the script already used setData() it will return any added data of the requested format. Does that sound OK to you? Also, scripts shouldn't be able to call clearData() during copy/cut events, correct? Why not? Is it useful in any other context? For 10. Cross-origin copy/paste of source code, we might also want to consider stripping elements that can refer to external URLs such as link, meta, base, etc... Those will typically be in the HEAD and not usually part of a pasted fragment. We certainly don't want to remove A tags or their HREFs, so I'm not sure why we'd want to remove e.g. LINK. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote:
http://dev.w3.org/2006/webapi/clipops/clipops.html
Also, the XML source could be placed in the clipboard with the
appropriate transformation occurring when pasting.
The XML source can also ...
Fixed.
I find when pasting problematic. At paste time might be better, or
some indication of which side is doing the transformation.
Not sure which is better but accepted your suggestion.
---
interface ClipboardEvent : Event {
void initClipboardEvent (in DOMString eventType, in boolean
canBubble, in boolean cancelable, in DOMString dataType, in DOMString
data);
doesn't seem to allow for multiple flavors.
It doesn't. I don't think the use case for a script sending multiple
flavours of data to itself through a synthetic event is all that
interesting. I guess we could do something like
evt.initClipboardEvent('paste', true, true, {'text/plain':'Hello world',
'text/html':'bHello world/b'} );
but I don't think we need the added complexity..
The associated drag data store is a live but filtered view of the
system clipboard, exposing all data types the implementation knows the
script can safely access.
safely seems underspecified, you probably should clarify that this
includes not exposing anything for synthetic events.
Improved ;-) There is that requirement for synthetic events elsewhere
though, so I don't think it needs repeating here.
5.3 Determining the target property for clipboard events
In an editable context, the event object's target property must refer
to the element that contains the start of the selection in document
order, i.e. the end that is closer to the beginning of the document.
iirc DOMRanges can have start after end to indicate that the user has
made a selection in reverse. Is there a reason to ignore that
information and give different targets each time the user extends the
selection?
As far as I remember this is just based on current implementations.
Calling getData() too many or too few arguments should throw
calling foo() _with_
Seems fixed.
Calling clearData() empties the system clipboard, or removes the
specified type of data from the clipboard. See HTML5 for details
[HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
That's outside the realm of the spec. There is a section on nuisance
potential, and I'd myself perhaps prefer a UA that implemented some
limitations, but in general the spec tries to enable cool things rather
than worrying about the few naughty sites that would cause nuisance.
Calling getData() from within a paste event handler will return the
clipboard data in the specified format. See HTML5 for details [HTML5].
doesn't explain what should happen when the web app tries to paste a
content type the user agent has decided it shouldn't have access to.
That's up to HTML5 but AFAIK it will just return an empty string.
The event is asyncronous but must be dispatched before keyup events for
the relevant keys.
asynchronous
Ops, thanks.
The user might paste hidden data which the user is not aware of.
.. not aware of is kinda messy. Also, perhaps hidden data already
indicates the user doesn't know about it?
Improved.
The implementation must not download referenced online resources and
expose their contents in the FileList.
s/and/or/
OK
Objects implementing the DataTransfer interface to return clipboard
data must not be available outside the ClipboardEvent event handler.
If a script stores a reference to an object implementing the
DataTransfer interface to use from outside the ClipboardEvent event
handler, all methods must be no-ops when called outside the expected
context
Implementations must not let scripts create synthetic clipboard
events to get access to real clipboard data
the last two points are missing periods
Fixed.
Implementations must handle scripts that try to place excessive amounts
of data on the clipboard gracefully.
I hope gracefully is flexible. If my impl wants to terminate the
page, it should be able to do so. (I don't expect it to do so, but I
reserve the right)
Certainly. Gracefully basically means something like don't crash the
OS, don't crash yourself, and don't make the computer run very, very
slowly while you're busy.
Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM,
INPUT, BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes.
For all mentioned elements except FORM, also remove all child nodes.
I can imagine doing magical things with a style tag...
So you think STYLE should be added?
However, removing the active value from a select seems suboptimal.
If you see:
State: [ |v]
And use it to get:
State: [ Washington |v]
When you copy it, do you
Re: CfC: new WD of Clipboard API and Events; deadline April 5
I think I have raised my concern before but what should happen if script calls getData() within a copy/cut event handler? Should it return the clipboard content after taking account the values set by setData? Or should it always return the same value? Or should script be banned from calling getData() during copy/cut events all together? Also, scripts shouldn't be able to call clearData() during copy/cut events, correct? For 10. Cross-origin copy/paste of source code, we might also want to consider stripping elements that can refer to external URLs such as link, meta, base, etc... - Ryosuke On Tue, Mar 29, 2011 at 4:37 AM, Arthur Barstow art.bars...@nokia.comwrote: This is a Call for Consensus to publish a new Working Draft of Hallvord's Clipboard API and Events spec: http://dev.w3.org/2006/webapi/clipops/clipops.html If you have any comments or concerns about this proposal, please send them to public-webapps by April 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Please note that during this CfC, Hallvord will continue to edit the ED and will create a Table of Contents before the spec is published in w3.org/TR/ . -Art Barstow
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, Apr 10, 2011 at 11:30, Charles McCathieNevile cha...@opera.comwrote:
comments on a couple of timeless' comments.
On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote:
Calling clearData() empties the system clipboard, or removes the specified
type of data from the clipboard. See HTML5 for details [HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
Yes - should that comment be on HTML5 though, or alternatively is there a
reason not to copy it?
I'm not sure the spec needs to go out of its way to guard against this.
Typically, when writing to a clipboard, you'd clear all the data on the
clipboard before writing the new data; otherwise, you might end up with text
from one window, HTML from another, and a URL from a third. A page that
wanted to stomp on user data could simply do something like
event.clipboardData.setData('text/plain', '').
Daniel
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow art.bars...@nokia.com wrote:
http://dev.w3.org/2006/webapi/clipops/clipops.html
If you have any comments or concerns about this proposal, please send them
to public-webapps by April 5 at the latest.
Sorry, i've been doing other stuff
[editorial]
Mathematical information
With content such as mathematics, simply copying rendered text and pasting it
into another application generally leads to most of the semantics being lost.
I think math is more appropriate here.
And probably leads to the loss of most of the semantics.
Also, the XML source could be placed in the clipboard with the appropriate
transformation occurring when pasting.
The XML source can also ...
I find when pasting problematic. At paste time might be better, or
some indication of which side is doing the transformation.
---
interface ClipboardEvent : Event {
void initClipboardEvent (in DOMString eventType, in boolean canBubble, in
boolean cancelable, in DOMString dataType, in DOMString data);
doesn't seem to allow for multiple flavors.
clipboardData of type DataTransfer, readonly
The clipboardData attribute is an instance of the DataTransfer interface
which lets a script read and manipulate values on the system clipboard during
user-initiated copy, cut and paste operations. The associated drag data store
is a live but filtered view of the system clipboard, exposing all data types
the implementation knows the script can safely access.
safely seems underspecified, you probably should clarify that this
includes not exposing anything for synthetic events.
5.3 Determining the target property for clipboard events
In an editable context, the event object's target property must refer to the
element that contains the start of the selection in document order, i.e. the
end that is closer to the beginning of the document.
iirc DOMRanges can have start after end to indicate that the user has
made a selection in reverse. Is there a reason to ignore that
information and give different targets each time the user extends the
selection?
Calling getData() too many or too few arguments should throw
calling foo() _with_
Calling clearData() empties the system clipboard, or removes the specified
type of data from the clipboard. See HTML5 for details [HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
Calling getData() from within a paste event handler will return the clipboard
data in the specified format. See HTML5 for details [HTML5].
doesn't explain what should happen when the web app tries to paste a
content type the user agent has decided it shouldn't have access to.
The event is asyncronous but must be dispatched before keyup events for the
relevant keys.
asynchronous
The user might paste hidden data which the user is not aware of.
.. not aware of is kinda messy. Also, perhaps hidden data already
indicates the user doesn't know about it?
The implementation must not download referenced online resources and expose
their contents in the FileList.
s/and/or/
Objects implementing the DataTransfer interface to return clipboard data
must not be available outside the ClipboardEvent event handler.
If a script stores a reference to an object implementing the DataTransfer
interface to use from outside the ClipboardEvent event handler, all methods
must be no-ops when called outside the expected context
Implementations must not let scripts create synthetic clipboard events to
get access to real clipboard data
the last two points are missing periods
Implementations must handle scripts that try to place excessive amounts of
data on the clipboard gracefully.
I hope gracefully is flexible. If my impl wants to terminate the
page, it should be able to do so. (I don't expect it to do so, but I
reserve the right)
Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM, INPUT,
BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes. For all
mentioned elements except FORM, also remove all child nodes.
I can imagine doing magical things with a style tag...
However, removing the active value from a select seems suboptimal.
If you see:
State: [ |v]
And use it to get:
State: [ Washington |v]
When you copy it, do you expect:
State: or State: Washington? I expect the latter, it's
considerably more useful.
Re: CfC: new WD of Clipboard API and Events; deadline April 5
comments on a couple of timeless' comments. On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote: On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow art.bars...@nokia.com wrote: http://dev.w3.org/2006/webapi/clipops/clipops.html If you have any comments or concerns about this proposal, please send them to public-webapps by April 5 at the latest. Sorry, i've been doing other stuff [editorial] Mathematical information With content such as mathematics, simply copying rendered text and pasting it into another application generally leads to most of the semantics being lost. I think math is more appropriate here. Disagree. In explanatory text the more correct term is clearer. math is only american in usage, and avoiding the feeling that it is a typo would reduce congitive dissonance without being incorrect. Calling clearData() empties the system clipboard, or removes the specified type of data from the clipboard. See HTML5 for details [HTML5]. This has issues. If the user has inserted something the user cares about into the system clipboard, then allowing a web page to stomp on it is annoying. Something needs to protect the user from such web apps. Yes - should that comment be on HTML5 though, or alternatively is there a reason not to copy it? The user might paste hidden data which the user is not aware of. .. not aware of is kinda messy. Also, perhaps hidden data already indicates the user doesn't know about it? not realising it is there? Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM, INPUT, BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes. For all mentioned elements except FORM, also remove all child nodes. I can imagine doing magical things with a style tag... However, removing the active value from a select seems suboptimal. If you see: State: [ |v] And use it to get: State: [ Washington |v] When you copy it, do you expect: State: or State: Washington? I expect the latter, it's considerably more useful. Agree. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, Apr 10, 2011 at 9:30 PM, Charles McCathieNevile cha...@opera.com wrote: Disagree. In explanatory text the more correct term is clearer. math is only american in usage, and avoiding the feeling that it is a typo would reduce congitive dissonance without being incorrect. ok not realising it is there? sounds good
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, 29 Mar 2011 13:37:46 +0200, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus to publish a new Working Draft of Hallvord's Clipboard API and Events spec: http://dev.w3.org/2006/webapi/clipops/clipops.html Please do... cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: CfC: new WD of Clipboard API and Events; deadline April 5
Is the process currently requesting us to publish a draft so that comments can be gathered from the public? paul Le 29 mars 2011 à 13:37, Arthur Barstow a écrit : This is a Call for Consensus to publish a new Working Draft of Hallvord's Clipboard API and Events spec: http://dev.w3.org/2006/webapi/clipops/clipops.html If you have any comments or concerns about this proposal, please send them to public-webapps by April 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Please note that during this CfC, Hallvord will continue to edit the ED and will create a Table of Contents before the spec is published in w3.org/TR/. -Art Barstow
Re: CfC: new WD of Clipboard API and Events; deadline April 5
Hi Paul, We welcome comments on all of WebApps' specs at any time. The W3C Process Document includes a so-called heart beat publication requirement that effectively says a WG should publish each spec in /TR/ at least every 3 months. For a variety of reasons, we aren't strict about that requirement in this WG. For this particular spec, it has been a very long time (2006) since it was lasted published in /TR/ and since that version has no link to the latest ED, one could easily conclude no work has been done on that spec. However, the reality is Hallvord has done significant work on the spec and as such, it facilitates setting expectations for us to publish a new WD. -Art Barstow On Mar/29/2011 10:22 AM, ext Paul Libbrecht wrote: Is the process currently requesting us to publish a draft so that comments can be gathered from the public? paul Le 29 mars 2011 à 13:37, Arthur Barstow a écrit : This is a Call for Consensus to publish a new Working Draft of Hallvord's Clipboard API and Events spec: http://dev.w3.org/2006/webapi/clipops/clipops.html If you have any comments or concerns about this proposal, please send them to public-webapps by April 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Please note that during this CfC, Hallvord will continue to edit the ED and will create a Table of Contents before the spec is published in w3.org/TR/. -Art Barstow
Re: CfC: new WD of Clipboard API and Events; deadline April 5
Well, so here are my comments: --- I would reformulate: MathML often needs to be transformed to be copied as plain text, for example to make sure to the power of is shown with the caret ^ sign. Also, the XML source could be placed in the clipboard with the appropriate transformation occurring when pasting. into: MathML often needs to be transformed to be copied as plain text, for example to make sure to the power of is shown with the caret ^ sign in a formula plain-text input. Also, the XML source could be placed in the clipboard with the appropriate transformation occurring when pasting. this is great! --- Since the API should be that of HTML5, I think it is important to have a more direct link to the appropriate HTML5 section. I also think the parameter names and arity should be repeated. -- I believe an example of typical data-types really is needed (yes to one of the question there!). HTML5 leaves it open to use native types or mime's media-types, but warns about spaces... it seems quite fussy. Hence best practice is wished. --- Le 29 mars 2011 à 16:46, Arthur Barstow a écrit : For this particular spec, it has been a very long time (2006) since it was lasted published in /TR/ and since that version has no link to the latest ED, one could easily conclude no work has been done on that spec. However, the reality is Hallvord has done significant work on the spec and as such, it facilitates setting expectations for us to publish a new WD. Please receive my personal approval to publish as a WD, even with none of my issues addressed. it's great to see it evolving. paul Le 29 mars 2011 à 13:37, Arthur Barstow a écrit : This is a Call for Consensus to publish a new Working Draft of Hallvord's Clipboard API and Events spec: http://dev.w3.org/2006/webapi/clipops/clipops.html If you have any comments or concerns about this proposal, please send them to public-webapps by April 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Please note that during this CfC, Hallvord will continue to edit the ED and will create a Table of Contents before the spec is published in w3.org/TR/. -Art Barstow
