> > If this is really the case, it seems that separating Copy from Paste
would be proper.
>
> The spec sort of distinguishes them (but this should probably be spelled
out in detail): per the current spec text, copy/cut can be triggered from
any trusted or semi-trusted event, while paste is only all
You're probably think of IE's Pinned Sites concept on Windows 8:
http://msdn.microsoft.com/en-us/library/gg491731.aspx
Sincerely,
James Greene
Sent from my [smart?]phone
On May 31, 2014 10:35 AM, "Mounir Lamouri" wrote:
> On Sat, 31 May 2014, at 10:40, Jeffrey W
ecific parts of the spec since `cut` requires
an active Selection, right?
Sincerely,
James Greene
On Fri, May 23, 2014 at 10:13 AM, 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 stra
tom text
insertion.
Sincerely,
James Greene
On Fri, May 23, 2014 at 7:43 AM, Robin Berjon wrote:
> 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-weba
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
> &
;t supported, we would never know.
Sincerely,
James Greene
On Mon, May 19, 2014 at 8:18 AM, Anne van Kesteren wrote:
> 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 suppos
OK. Thanks for the clarifications, Konstantin & Ben!
Sincerely,
James Greene
On Mon, Mar 31, 2014 at 12:55 PM, Ben Johnson wrote:
> Kosta has pretty much covered it. Web Intents as well as current browser
> implementations are heavily geared towards web-based protoco
Would this be similar to the Web Intents spec proposal that Google was
championing (based on Android Intents)?
Sincerely,
James Greene
On Thu, Mar 27, 2014 at 5:52 PM, Ben Johnson wrote:
> Hi all,
>
>
>
> I’ve been working on a draft specification for a creating a de
rrect that this fact should be
explicitly called out somewhere as well.
[1]
http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interfaces
[2] http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model
Sincerely,
James Greene
Sent from my [smart?]phone
On Mar 8, 2014 1
atches our expectations?
Sincerely,
James Greene
Sent from my [smart?]phone
On Mar 4, 2014 8:59 AM, "Arthur Barstow" wrote:
> Hallvord is working toward publishing a new WD of Clipboard API and Events
> on (or around) March 11, based on [ED].
>
> If you have any comments abou
also still resolve/execute in a
semi-trusted state.
cc: Hallvord R. M. Steen
[1] http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
[2]
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()
Sincerely,
James Greene
Se
the cache out on the fly as resources are loaded.
I'm not opposed to just punted and saying that ServiceWorker is the way to
deal
with this, though. I have no personal use cases at the moment for this
functionality... just playing devil's advocate for the OP. :)
Sincerely,
James
e ability to "feature test" for file support instead? Then
the browsers can be the trusted source instead of everyone having to create
new divergent browser file support inference hacks.
Sincerely,
James Greene
On Mon, Nov 25, 2013 at 9:30 AM, pira...@gmail.com wrote:
> > T
2013 5:44 AM, "James Greene" wrote:
> Would it be possible to add RTF (MIME type of "application/rtf") [1] to
> the "mandatory data types" [2] list?
>
> While it is a proprietary file format held by Microsoft, it also has
> public specs [3][4] and i
types-1
[3] RTF spec v1.8
http://www.microsoft.com/en-us/download/details.aspx?id=7105
[4] RTF spec v1.9.1
http://www.microsoft.com/en-us/download/details.aspx?id=10725
Sincerely,
James Greene
Could we change the method name under discussion to `postMessageSync`
instead of `postSyncMessage`? I know they're not grammatically equivalent
but I've always found the *Sync suffixes used on pertinent Node.js APIs to
be much more intuitive than trying to guess which position within a string
of wo
;Rick Waldron" wrote:
>
>
> On Sunday, October 13, 2013, James Greene wrote:
>
>> Oh, does `yield` work anywhere? I thought it was only for use within
>> generators. Admittedly, I haven't been keeping up with the latest ES6
>> changes.
>>
>
> yield may
> that's a way to stop (ie. sleep) the execution of a script to allow another
> to work and restart from there. It's not their main function, but allow to
> create what's called "greenlets", green threads, and that's how I seen sync
> APIs are build
elieve my original assertions are still correct with
regard to writing a sync wrapper in JS.
On Oct 13, 2013 9:09 AM, "James Greene" wrote:
> Thanks for adding clarification. That CAN be true but it depends on the
> environment [so far as I can see].
>
> For example, such an A
s browsers won't interrupt the synchronous flow of the
JS busy loop to trigger `onmessage` handlers for async messages sent from
the Worker.
If I'm mistaken, please consider providing a code snippet, gist, etc. to
get me back on track. Thanks!
On Oct 13, 2013 5:06 AM, "David Rajchenbach-Teller&
You can only build a synchronous API on top of an asynchronous API if they
are (a) running in separate threads/processes AND (b) the sync thread can
synchronously poll (busy loop) for the progress/completion of the async
thread.
On Oct 12, 2013 1:23 AM, "pira...@gmail.com" wrote:
> >> Synchronous
comma and prior. Does that make sense to others?
Sincerely,
James Greene
On Thu, Sep 19, 2013 at 11:10 PM, Julian Aubourg wrote:
> It's a malformed data URI for now. What I'm wondering is if we're sure
> we'll never have an encoding that makes it impossible to de
XHRs for `mailto:`? :)
Kidding, though that would be kind of interesting.
On Sep 19, 2013 6:28 PM, "Jonas Sicking" wrote:
> That's true for too. Technically that's also not
> needed. Same with
>
> I think there's a lot of value in ensuring that all URL schemes work
> in all APIs that handle UR
So does this imply that someone (i.e. Hallvord :)) needs to move it
elsewhere?
Sincerely,
James Greene
On Wed, Sep 18, 2013 at 12:17 PM, Tab Atkins Jr. wrote:
> On Wed, Sep 18, 2013 at 10:06 AM, James Greene
> wrote:
> > On Sep 18, 2013 10:42 AM, "Anne van Kesteren&quo
I'm lost. Is there an explanation of this somewhere?
On Sep 18, 2013 10:42 AM, "Anne van Kesteren" wrote:
> On Wed, Sep 18, 2013 at 10:09 AM, James Greene
> wrote:
> > Remember that the URL referenced is not for the latest version of this
> spec.
> > Corr
html5 clipboard api".
:-\
It does show up as the top result for me if I search "clipboard spec" or
"html|html5 clipboard spec", though.
Sincerely,
James Greene
On Wed, Sep 18, 2013 at 10:14 AM, Boris Zbarsky wrote:
> On 9/18/13 10:09 AM, James Greene wrote:
&
Remember that the URL referenced is not for the latest version of this
spec. Correct URL:
http://www.w3.org/TR/clipboard-apis/
On Sep 18, 2013 8:54 AM, "Anne van Kesteren" wrote:
> On Wed, Sep 18, 2013 at 9:05 AM, Hallvord Steen
> wrote:
> > At some point I started using respec.js and switche
clipboard injection is that this could legitimately be restricted to just
the site domains, thus avoiding having annoying ads from another domain
injecting into your clipboard.
Thoughts from others?
Sincerely,
James Greene
On Wed, Aug 7, 2013 at 12:34 PM, James Babcock wrote:
> C
turns `true` anyway) when
the user is working within a "contenteditable" element, right?
Sincerely,
James Greene
On Fri, Sep 13, 2013 at 10:10 AM, James Greene wrote:
> Excellent. Thank you!
>
> Should we be including touch device events, too? e.g. "touchend",
Excellent. Thank you!
Should we be including touch device events, too? e.g. "touchend",
"pointerup", etc.
Sincerely,
James Greene
On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen wrote:
> >> AFAIK Flash shipped with a more liberal model first, but
Flash docs I've linked to, it's important to notice when
they differentiate between when the context of Adobe AIR (where there are
no such clipboard restrictions) and Adobe Flash Player (where there are).
Sincerely,
James Greene
On Fri, Jul 26, 2013 at 9:37 AM, Hallvord Steen
*Correction:*
leaving it up to the browser vendors WITHOUT an agreed upon standard (or at
least "marching direction") means zero progress.
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 8:11 PM, James Greene wrote:
> Ryosuke & Anne —
> Agreed with Anne, leaving
e
text selection.
I actually think that kind of analytics is awesome — so long as it isn't
being used for evil, of course. :)
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 8:07 PM, James Greene wrote:
> Paul:
>
> Looking at TimBL's 2010 post, I feel like it's from a sl
Ryosuke & Anne —
Agreed with Anne, leaving it up to the browser vendors an agreed upon
standard (or at least "marching direction") means zero progress.
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 7:32 PM, Anne van Kesteren wrote:
> On Jul 12, 2013, at 12:57 PM, Jame
e a bit of a stretch... happy to see that
I am wrong. :)
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 5:34 PM, Hallvord Steen wrote:
> [Replying to Paul's mail but it's really a response to James - sorry,
> Paul..]
>
> On 12 juil. 2013, at 21:57, James Greene
extensions myself if it helps push
my agenda. ;)
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 3:22 PM, Paul Libbrecht wrote:
>
> James,
>
> I personally think it would be a really good idea. But I am not a browser
> implementor.
>
> Overall, I agree with you tha
a stack trace, exit the process, etc.
Sincerely,
James Greene
On Fri, Jul 12, 2013 at 3:07 PM, Daniel Cheng wrote:
> The problem is backwards compatibility. There are sites that use the
> copy/cut event handler, and the proposal reverses the behavior.
> Suppose it were impl
m/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()>
after
a user's click or keypress. :(
Thoughts?
Sincerely,
James Greene
http://jamesgreene.net/
s someone who is not a browser vendor employee, this sounds very doable.
;)
Sincerely,
James Greene
On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng wrote:
> On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht
> wrote:
> > Is there any reason to justify the requirement to populat
39 matches
Mail list logo
