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?
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 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 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
> 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
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 Flash support, c
16 matches
Mail list logo
