On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard wrote:
> Hallvord: By the way, please add the editor of the HTML spec to the
> beginning of the list in your references. It's strange to list a bunch of
> author names, but not the person who actually writes the spec.
>
Is anything incorrect here?
So, the E-mail to Ben Peters bounced - he's no longer at Microsoft? Is
there anyone on the IE team present on the list who is able to comment on
this?
-Hallvord R
On Mon, Apr 20, 2015 at 10:38 PM, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:
>
> > In addition, from a security pers
> > In addition, from a security perspective, what stops a malicious website
> from embedding something like style="display:none"> in the markup?
>
> We disallow this on copy by stripping such references.
>
Hi Ben,
picking up this old thread..
So we need to add a "sanitize local references" step
Maybe it's just me but... I would personally never want the browser to
automatically assume what I wanted copied and into which clipboard
segments, with the possible exception of a Selection.
I would prefer something very explicit, e.g.:
```js
window.clipboard.copy({
"text/plain": "BLAH",
"te
Hallvord: By the way, please add the editor of the HTML spec to the
beginning of the list in your references. It's strange to list a bunch of
author names, but not the person who actually writes the spec.
On Fri, May 23, 2014 at 8:21 AM, James Greene wrote:
> This kind of copy does not implicit
Moreover, the clipboard is systemwide, when selection exists per document.
So in my opinion window is a better choice.
On Fri, May 23, 2014 at 3:21 PM, James Greene wrote:
> > I wouldn't put this on window though; why not put it on Selection?
>
> This kind of copy does not implicitly have anythin
> I wouldn't put this on window though; why not put it on Selection?
This kind of copy does not implicitly have anything to do with Selection,
unless we continue to have its default action be copying the currently
selected text. It is substantially more likely to be used for custom text
insertion
On 23/05/2014 14:33 , James Greene wrote:
I'm all in favor of a new API as well.
Me too, as discussed in
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0550.html.
I wouldn't put this on window though; why not put it on Selection?
--
Robin Berjon - http://berjon.com/ - @robinb
I'm all in favor of a new API as well.
Sincerely,
James Greene
On Fri, May 23, 2014 at 5:53 AM, Aryeh Gregor wrote:
> On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard wrote:
> > I think I'd suggest avoiding the mess of execCommand altogether, and add
> new
> > methods, eg. window.copy() an
On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard wrote:
> I think I'd suggest avoiding the mess of execCommand altogether, and add new
> methods, eg. window.copy() and window.cut() (or maybe just one method, with
> a "cut" option). execCommand is such a nonsensical way to expose an API
> that tryin
I think I'd suggest avoiding the mess of execCommand altogether, and add
new methods, eg. window.copy() and window.cut() (or maybe just one method,
with a "cut" option). execCommand is such a nonsensical way to expose an
API that trying to stay consistent with its commands is probably not much
of
On Tue, May 20, 2014 at 3:42 AM, Hallvord R. M. Steen wrote:
> >> a) The event is script-generated and has a data payload (new
> >> ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
>
> > I'm a little confused. Script-generated events never have a "default
> > action", except for
On Tue, May 20, 2014 at 12:16 PM, Hallvord R. M. Steen
wrote:
> The way HTML5 specs setData() and the other parts of the API shouldn't cause
> any problems for our use case, no?
I guess.
In any event, you should refer to the underlying concepts, not the API
side of things. If the underlying con
> Maybe. It seems some refactoring is needed either way. The underlying
> data model for .items is "drag data store item list" which is a term
> that's somewhat different from what we have here.
I think that's a feature, not a bug - for example, many operating systems let
you 'copy' and 'paste' f
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
wrote:
>> button.onclick = function(){
>> button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
>> data:'Hello world'});
>> // did that succeed or not? We don't have event.clipboardData on a clip
>> event object
> T
On Tue, May 20, 2014 at 12:01 PM, Hallvord R. M. Steen
wrote:
> On the other hand, perhaps we could just observe the clipboardData.items
> list? If this list is not empty, the payload must have been changed during
> processing. So if the default is prevented OR clipboardData.items.length > 0
>
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
wrote:
> button.onclick = function(){
> button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
> data:'Hello world'});
> // did that succeed or not? We don't have event.clipboardData on a clip
> event object
That sho
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
wrote:
> (...)
> Any better idea?
> -Hallvord
>
Well, since you need might a new API (because the fallback is just so
nasty and detection is not trivial), dump it somewhere like in the
navigator object: navigator.myClipboardFeatureEnabled
have a "default
action", except for a couple isolated web-compatibility hacks where
dispatching an event in script has side-effects, like click. As far as I
can tell, clipboard events (tested copy and paste) aren't in that category
in Firefox, at least (Chrome doesn't have Clipbo
>> Can you sanely explain those using a JavaScript implementation or would that
>> be some kind of weird stack-inspecting feature?
> My impression was that it would be something like:
>
> if (data) {
> this.preventDefault();
> }
Domenic: thanks for explaining, that's pretty much exactly what
> hasFeature() is pretty much killed (always returns true).
That sort of sucks .. I know the argument against it but the question I'm
looking at now shows that not all features are suitable for feature detection -
in this particular case because the whole point of the feature is about user
inte
> Why can't this feature be discovered? The clipboard cannot be made
> readable when you just copied to it using this technique?
How would that be discoverable? The feature would have to be supported and
triggered by a user before the status would be known. If the feature
wasn't supported, we wo
From: annevankeste...@gmail.com on behalf of Anne
van Kesteren
> Can you sanely explain those using a JavaScript implementation or would that
> be some kind of weird stack-inspecting feature?
My impression was that it would be something like:
if (data) {
this.preventDefault();
}
in the co
On Mon, May 19, 2014 at 3:50 PM, Hallvord R. M. Steen
wrote:
> a) The event is script-generated and has a data payload (new
> ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
> b) Any event listener calls setData() or modifies the DataTransfer payload
> some other way
>
> Though
Hi,
there's a very annoying gotcha in the clipboard events spec: the "default
action" of for example the copy event is to copy any selected text in the page
(and do nothing if there is no selection). This remains the default action even
if you use event.clipboardData.setData()
On Mon, May 19, 2014 at 3:09 PM, Hallvord R. M. Steen
wrote:
> Questions:
> 1) Is this a good idea?
> 2) What's the spec supposed to say to invoke hasFeature() and define a
> "feature" string for its argument list?
hasFeature() is pretty much killed (always returns true).
Why can't this feature
Hi,
I'm about to file a bug on implementing click-to-copy and click-to-cut per
latest clipboard events spec in Gecko / Firefox, and this reminds me we haven't
yet answered the question about discoverability. This functionality has a
fallback story (Flash shims for platforms with Fla
> Also on Mac, there is no and and the
> serialized markup copied into the clipboard (called pasteboard on Mac) needs
> to contain the precisely the markup that got copied by the user.
Good point. Perhaps we should make sure any OS specific items like
are not visible in developer APIs.
> It h
On Apr 9, 2014, at 1:58 PM, Ryosuke Niwa wrote:
> On Apr 7, 2014, at 3:37 PM, Ben Peters wrote:
>
>> After working with developers inside and outside Microsoft, it seems
>> there are several types of paste that make sense in various scenarios.
>> For instance,
>> 1- if pasting
On Apr 7, 2014, at 3:37 PM, Ben Peters wrote:
> After working with developers inside and outside Microsoft, it seems
> there are several types of paste that make sense in various scenarios.
> For instance,
> 1- if pasting into a rich document, it could be important to maintain
After working with developers inside and outside Microsoft, it seems there
are several types of paste that make sense in various scenarios. For
instance,
1- if pasting into a rich document, it could be important to maintain
source styling information.
2- When pasting in
>> How hard do you think this is to implement?
> Thanks for the code sample and thoughts! I'll run it by a few more
> developers to get deeper insight and get back to you.
Great! Note that the code samples are just to get us started thinking about the
issues we'll have to tackle if we're going t
>> One possibility would be to do something similar to Firefox, but also
>> include a text/css clipboard item, which contains styles relevant to
>> what is copied
>This seems like an excellent idea! I'm not sure how hard it is to implement,
>but it might be doable without too much effort. Some
> After working with developers inside and outside Microsoft, it seems there are
> several types of paste that make sense in various scenarios. For instance,
> 1- if pasting into a rich document, it could be important to maintain source
> styling information.
2- When pasting into a wiki from an e
After working with developers inside and outside Microsoft, it seems there are
several types of paste that make sense in various scenarios. For instance,
1- if pasting into a rich document, it could be important to maintain source
styling information.
2- When pasting into a wiki from an externa
Hi Daniel,
> I'm trying to make sure I correctly understand how the IE11 version of this
> works. From the sample
> (http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it looks
> like if a user pastes in some HTML that references local images, IE11
> automatically captures the
On Wed, Feb 12, 2014 at 1:25 AM, Hallvord R. M. Steen wrote:
> > Hi Hallvord!
>
> Hi Ben! Thanks for responding to my request for feedback - especially
> since the IE team has done some interesting work in this area and is
> arguably ahead of the rest! :-)
>
> > The IE11 API you mentioned is msCon
Second, can you provide the javascript for how a site would put them into
the pasted markup during paste?
>>> The way I thought this would work, would be that the site starts XHR
>>> uploads from the paste processing, and shows some intermediate 'loading'
>>> animation or something be
>> Of course it would be nice to support a script that wants to generate random
>> HTML with embedded files
>> use case for example with a CANVAS app where the script wants to copy the
>> state of the CANVAS
> I was thinking about images that aren't available cross-domain
Indeed, that's anot
> Of course it would be nice to support a script that wants to generate random
> HTML with embedded files to place on the clipboard (although I think most of
> those use cases can already be met by using URLs and assuming that any
> software reading HTML from the clipboard can understand URLs..)
: Thursday, January 23, 2014 5:30 PM
To: public-webapps
Subject: [clipboard events] seeking implementor feedback on using CID: URI
scheme for pasting embedded binary data
> Hi,
> pasting HTML that contains embeds (images, video) into a rich text editor is
> a use case we should co
> Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially since the
IE team has done some interesting work in this area and is arguably ahead of
the rest! :-)
> The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and
> it was designed as a
> sim
passes on file:/// URLs with local paths and all
[2], this is of course a bug.
* Right now I'm not sure what WebKit/Blink - based implementations do. Test
results welcome!
As the editor of the Clipboard Events spec, I'm proposing a somewhat different
take on this: "cid:&qu
> I'm eager to replace our flash clipboard bridge with this native api.
Uh, I'm glad you like it but I wouldn't hold my breath.. I hope implementors
will like it too but I have no way to tell when implementations will actually
be available.
> Would this be the correct code to write a string to
d as causing paste
> actions. document.execCommand('copy'|'cut'|'paste') is now from the spec's
> point of view just a shortcut for generating and firing synthetic events.
>
> There are two possible ways this works:
> 1) When creating syntheti
xecCommand('copy'|'cut'|'paste') is now from the spec's
point of view just a shortcut for generating and firing synthetic events.
There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data
pay
> > * Resolve URLs and links - the page script won't know the base URI to
> > resolve against (on Windows this is in the CF_HTML format's meta data
> > and the page script doesn't get access to it)
>
> Well presumably all the URLs should be made absolute in the copy/drag
> code, not the paste/
This discussion seems to raise the issue of what happens to URLs to images (or
other embedded objects) that are unresolved but become resolved when pasted.
E.g. file:///Users/anton/Library/AddressBook
(if that ever made sense)
Should these also be sanitized away so that they do not, suddenly bec
On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote:
>
> Now, I don't think that was the question Daniel Cheng was asking. If you
> look at the HTML/XHTML specific instructions for the paste event (in the
> processing model section:
> http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll
On Fri, 10 Feb 2012 01:24:05 +0100, Ian Hickson wrote:
We're going out of our way to do lots of special processing for HTML in
a paste. Why doesn't a drop of HTML get the same treatment?
This is a good question.
Presumably the scenario is that hostile page A provides some content and
gets t
On Wed, 18 May 2011, Daniel Cheng wrote:
> On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen wrote:
> >
> > Not 100% sure what you mean by "concerns" - do you mean for example if
> > I drag a selection that embeds local images from my local word
> > processing application to an online editor?
http://dev.w3.org/2006/webapi/clipops/clipops.html
Feedback especially welcome on the processing model:
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model
and the new list of data types an implementation must be "aware" of:
http://dev.w3.org/2006/webapi/clipops/clipops.html#mand
On Thu, 19 May 2011 09:43:33 +0900, João Eiras
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard content
On Thu, May 19, 2011 at 04:01, João Eiras wrote:
> On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht wrote:
> >
> > Le 19 mai 2011 à 02:11, João Eiras a écrit :
> >
> >> getData and setData must work outside clipboard events, like when
> clicking paste/c
On Wed, May 18, 2011 at 17:41, João Eiras wrote:
> On , Paul Libbrecht wrote:
>
>
>> Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
>>
>> To get a table started in the spec, could you give me a small list of
>>> (MIME) types one should mandate the UA to be aware of and be able to
>>> "r
On Wed, May 18, 2011 at 5:41 PM, João Eiras wrote:
> More generic
> - text/* (I've see in too many places mime-types like text/x-c-src, and
> text is text.)
> - application/*+xml
> - application/*script (ecmascript, javascript)
>
How do we know that these types don't contain invisible sensiti
On Wed, May 18, 2011 at 8:41 PM, João Eiras wrote:
> More generic
> - text/* (I've see in too many places mime-types like text/x-c-src, and
> text is text.)
> - application/*+xml
+1
> - application/*script (ecmascript, javascript)
Well, unlike the two above, there's no guarantee that all (fu
On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht wrote:
>
> Le 19 mai 2011 à 02:11, João Eiras a écrit :
>
>> getData and setData must work outside clipboard events, like when clicking
>> paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
>> exp
Le 19 mai 2011 à 02:11, João Eiras a écrit :
> getData and setData must work outside clipboard events, like when clicking
> paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
> exposed on the window, like in IE.
I fully disagree here.
This is exactly what has
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen wrote:
> Not 100% sure what you mean by "concerns" - do you mean for example if I
> drag a selection that embeds local images from my local word processing
> application to an online editor? I don't know how/if DnD handles this use
> case. CCing
On Wed, May 18, 2011 at 5:43 PM, João Eiras wrote:
> But there is no way to access the clipboard contents. Or does execCommand
> dispatch a synchronous event ?
>
It fires copy/paste events.
- Ryosuke
On , Hallvord R. M. Steen wrote:
On Thu, 19 May 2011 09:11:56 +0900, João Eiras
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to
On , Paul Libbrecht wrote:
Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
To get a table started in the spec, could you give me a small list of (MIME) types one
should mandate the UA to be aware of and be able to "roundtrip" to/from native
clipboard types? Just off the top of your
On Thu, 19 May 2011 09:11:56 +0900, João Eiras
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
--
Hallvord R. M. Steen, Core Tester, Opera Sof
items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
getData and setData must work outside clipboard events, like when clicking
paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
expose
On Mon, May 9, 2011 at 4:34 PM, Ian Hickson wrote:
>> On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson wrote:
>>
>> > > > Is it intended to also cover cut, copy and paste?
>> > >
>> > > Sorry, I don't understand the question.
>> >
>> > Well, for example, the 'cut' operation involves removing or mu
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or
On Wed, May 18, 2011 at 02:16, Hallvord R. M. Steen wrote:
> What do you think about the current spec text? I've moved the section
> http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
> where we prepare the paste event, because integrating this into the HT
On Wed, 18 May 2011 15:49:33 +0900, Daniel Cheng
wrote:
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the script calls getData('text/
On Tue, May 17, 2011 at 22:07, Hallvord R. M. Steen wrote:
> Should our implementation work harder to keep what we promise in
> clipboardData.items, or should we be content that such timing issues will be
> so rare that throwing is fine? After all, most applications manipulate the
> clipboard only
On Tue, 17 May 2011 16:12:50 +0900, Paul Libbrecht
wrote:
I would like to add all of the 3 MathML flavors:
- application/mathml-presentation+xml
- application/mathml-content+xml
- application/mathml+xml
Would any special processing be required for any of them?
If not, if we have a section
On Tue, 10 May 2011 05:34:17 +0900, Ian Hickson wrote:
(Sorry for the long delay in responding to this.)
No problem, I know what you've been up to :-p
I'm re-ordering this reply a bit to get to the main questions first.
There's no processing model. IMHO we need a list of steps
somewhere t
On Wed, 18 May 2011 08:14:42 +0900, Daniel Cheng
wrote:
Interesting. What, in your view, should the implementation do if it
discovers the contents has changed while a paste event thread is
running?
Safari returns an empty string from getData() if this happens. If the
caller
is using ev
On Tue, May 17, 2011 at 20:44, Hallvord R. M. Steen wrote:
> Do native OS clipboards generally tend to have a data type saying "this is
> some random binary data"? That's more or less what I think
> application/octet-stream indicates on the web. If there isn't a common
> format to map it to on the
On Wed, 18 May 2011 09:13:19 +0900, Daniel Cheng
wrote:
I'd suggest that if we want to support image formats in the spec, we
should
try to support the same set that Canvas::toDataURL() does.
I'll have a look at image formats, thanks for pointing me to toDataURL() :)
+1 for being able to
On Tue, May 17, 2011 at 16:26, Ryan Seddon wrote:
> What about image/webp?
>
I'd suggest that if we want to support image formats in the spec, we should
try to support the same set that Canvas::toDataURL() does.
> +1 for being able to copy/paste binary data either through
> application/octet-s
On Tue, May 17, 2011 at 2:23 PM, Hallvord R. M. Steen wrote:
> text/plain
> text/html
> image/jpg
> image/gif
> image/png
> application/xhtml+xml
> image/svg+xml
What about image/webp? +1 for being able to copy/paste binary data either
through application/octet-stream or perhaps using blobs wit
On Tue, May 17, 2011 at 14:03, Hallvord R. M. Steen wrote:
> On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng
> wrote:
>
> I believe this problem is solvable without a spec change.
>>
>
> OK. I'd like to put in some non-normative warning or note about this
> problem though.
>
>
> On Windows and
On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng
wrote:
I believe this problem is solvable without a spec change.
OK. I'd like to put in some non-normative warning or note about this
problem though.
On Windows and Mac, implementations can use a native clipboard sequence
number to deter
Le 17 mai 2011 à 19:06, Daniel Cheng a écrit :
> I would like to add all of the 3 MathML flavors:
>
> - application/mathml-presentation+xml
> - application/mathml-content+xml
> - application/mathml+xml
>
> paul
>
> I don't think we need all 3. Why not just application/mathml+xml?
Daniel,
you
On Tue, May 17, 2011 at 00:12, Paul Libbrecht wrote:
>
> Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
>
> > To get a table started in the spec, could you give me a small list of
> (MIME) types one should mandate the UA to be aware of and be able to
> "roundtrip" to/from native clipboard
On Tue, May 17, 2011 at 1:16 AM, Olli Pettay wrote:
>
> I think Webkit's and Gecko's behavior makes more sense.
> You paste to some location in the editable area, not to root of it.
>
But selection could be a range. Why would you arbitrarily pick one end
point?
- Ryosuke
On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen
wrote:
> to/from native clipboard types? Just off the top of your head? The typical
> Web MIME types would of course be something along the lines of
>
> text/plain
> text/html
> image/jpg
> image/gif
> image/png
> application/xhtml+xml
> image/
On 01/31/2011 11:02 AM, Ryosuke Niwa wrote:
On Tue, Jan 25, 2011 at 9:26 PM, Hallvord R. M. Steen
mailto:hallv...@opera.com>> wrote:
On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa mailto:rn...@webkit.org>> wrote:
In an editable context, the paste event's target property
Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
> To get a table started in the spec, could you give me a small list of (MIME)
> types one should mandate the UA to be aware of and be able to "roundtrip"
> to/from native clipboard types? Just off the top of your head? The typical
> Web M
On Mon, May 16, 2011 at 22:57, Ryosuke Niwa wrote:
> On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen
> wrote:
>
>> On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht
>> wrote:
>>
>>> A website maker for, say, a shop for furnitures that knows they can go
>>> into "my home plan maker" thro
On Mon, May 16, 2011 at 21:23, Hallvord R. M. Steen wrote:
> On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng
> wrote:
>
> I'd go one step further and say that there should be some agreement on
>> what
>> MIME types ought to be supported to try to insure somewhat consistent
>> behavior across di
I believe this problem is solvable without a spec change.
On Windows and Mac, implementations can use a native clipboard sequence
number to determine the contents of the clipboard have changed.
Linux is trickier. There's an X extension called XFixes which provides this
utility, but I don't know h
On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen wrote:
> On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht
> wrote:
>
>> A website maker for, say, a shop for furnitures that knows they can go
>> into "my home plan maker" through the clipboard will want to be able to
>> produce and export a
On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht
wrote:
there should be some agreement on what MIME types ought to be supported
Some types will be predefined but the door should stay opened for others.
I think what you are asking implies that the UA should "get out of the
way" and ju
On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng
wrote:
I'd go one step further and say that there should be some agreement on
what
MIME types ought to be supported to try to insure somewhat consistent
behavior across different platforms.
To get a table started in the spec, could you give
IMO getData() should be 'live' - i.e. return what's on the clipboard.
I think having it return live data could result in potential security
issues. Couldn't a script loop inside the paste event to keep sniffing
out live data?
What should we do about this? Should the spec mandate a timeout
On Tue, May 10, 2011 at 8:41 AM, timeless wrote:
> I'm not really excited by the return of the attack on context menus.
> Allowing web sites to hold user's browsers hostage is a bad starting
> point. It might be ok if the user had to first opt into rich editing -
> maybe.
>
> Note that we only rec
Can you expand on what kind of protection this was?
Isn't it simply the same as a "copy static content", "copy text", or "really
copy" kind of command?
paul
Le 10 mai 2011 à 09:41, timeless a écrit :
> Note that we only recently added protection for users against 'what
> you see is not what yo
The alternative is sites that attempt to implement this functionality by
preventing the default and clearing all the data on the clipboard instead.
I'm not really sure that's any better.
Daniel
On Tue, May 10, 2011 at 00:41, timeless wrote:
> I'm not really excited by the return of the attack o
I'm not really excited by the return of the attack on context menus.
Allowing web sites to hold user's browsers hostage is a bad starting
point. It might be ok if the user had to first opt into rich editing -
maybe.
Note that we only recently added protection for users against 'what
you see is not
Le 10 mai 2011 à 09:13, Daniel Cheng a écrit :
> I would expect scripts to want one of two things when they're preventing the
> default action:
> 1. They want to set their own data in the clipboard instead of what the
> browser would normally provide by default--for example, a document editor
On Mon, May 9, 2011 at 23:31, Paul Libbrecht wrote:
>
> Le 10 mai 2011 à 00:18, João Eiras a écrit :
>
> >> I would just model the 'copy' (and 'cut') events exactly as a
> 'dragstart'
> >> event, ideally so much so that you can literally use the same function
> for
> >> both. (Canceling 'cut' wou
Le 10 mai 2011 à 00:18, João Eiras a écrit :
>> I would just model the 'copy' (and 'cut') events exactly as a 'dragstart'
>> event, ideally so much so that you can literally use the same function for
>> both. (Canceling 'cut' would prevent the default deletion of the
>> selection, canceling 'copy
I think you'd want to push the script-added data regardless of whether the
event is canceled or not. Why would the script add the data otherwise?
I would just model the 'copy' (and 'cut') events exactly as a 'dragstart'
event, ideally so much so that you can literally use the same function for
1 - 100 of 136 matches
Mail list logo
