Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

On 2/11/15 9:45 PM, Marc Fawzi wrote: this "backward compatibility" stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Pretty much, yep. this has worked so far, miraculously

Re: [clipboard API] platform integration stuff - in spec or out of scope?

Allow me to clarify my position. My expectation is NOT for the browsers' default action on "copy"/"cut" to convert HTML into RTF. I do not see any such implication of that behavior in the spec language [1]. Rather, I just want to ensure that browsers will honor/maintain that clipboard format/segm

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi wrote: > this "backward compatibility" stuff is making me think that the web is built > upon the axiom that we will never start over and we must keep piling up new > features and principles on top of the old ones Yup. > this has worked so far, miraculo

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

this "backward compatibility" stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones this has worked so far, miraculously and not without overhead, but I can only assume that it's at

Re: [clipboard] Feature detect Clipboard API support?

On Wed, Feb 11, 2015 at 12:34 PM, Michaela Merz wrote: > > AFAIK, you can't trigger a clip board request without human interaction. > > $('#element).off().on('click',function(e) { > var clip = new ClipboardEvent('copy'); > clip.clipboardData.setData('text/plain','some data'); > c

Re: [clipboard API] platform integration stuff - in spec or out of scope?

On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene wrote: > We never really came to a decision on if RTF ("application/rtf") should be > listed as a mandatory MIME type but the general consensus seemed to be > leaning toward "yes": > > https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of adding

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

Marc Fawzi wrote: << even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. ***But not by vague blather*** >> Sorry, I was too grumpy -- my apologies. I don't see much gr

Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group

On Wed, Feb 11, 2015 at 7:41 PM, Andrei Popov wrote: > This is part of a starting point proposal for the new working group; we > expect the documents to change. I think it would be best if the document was written in such a way that any API could be plugged on top. And that it leaves changing AP

Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

<< even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. ***But not by vague blather*** >> You're contradicting yourself within a single two-line paragraph, being vague in your

Re: [clipboard] Feature detect Clipboard API support?

AFAIK, you can't trigger a clip board request without human interaction. $('#element).off().on('click',function(e) { var clip = new ClipboardEvent('copy'); clip.clipboardData.setData('text/plain','some data'); clip.preventDefault(); e.target.dispatchEvent(clip); }); This

[clipboard] Feature detect Clipboard API support?

The current spec still leaves me a bit unclear about if implementors must include the ability to feature detect Clipboard API support, which I think is a critical requirement. In particular, I *need* to be able to detect support for the Clipboard API (click-to-copy support, in particular) in advan

Re: [clipboard API] platform integration stuff - in spec or out of scope?

We never really came to a decision on if RTF ("application/rtf") should be listed as a mandatory MIME type but the general consensus seemed to be leaning toward "yes": https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html Sincerely, James Greene On Sat, Jan 31, 2015 at

Re: IETF seeking feedback on proposed "Token Binding" Working Group

On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow wrote: > WebApps - please note the draft spec includes a new XHR property > "withRefererTokenBindingID" > . > > If anyone has feedback about the proposal, please send it to

IETF seeking feedback on proposed "Token Binding" Working Group

[ public-webapps should have been included but was not ] Forwarded Message Subject:IETF seeking feedback on proposed "Token Binding" Working Group Date: Wed, 11 Feb 2015 07:00:35 -0500 From: Arthur Barstow Reply-To: unbeara...@ietf.org CC: Stephen Farrell