On Mon, Jul 14, 2014 at 4:26 AM, Adam Barth w...@adambarth.com wrote:
The launchURL() method requests that the User Agent launch the
protocol handler for the specified URL. If the User Agent itself is
the registered protocol handler for |url|, then the User Agent should
open the requested URL
On Jul 2, 2014, at 4:01 AM, Ryosuke Niwa rn...@apple.com wrote:
On May 15, 2014, at 10:01 AM, Elliott Sprehn espr...@chromium.org wrote:
On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@hixie.ch wrote:
I would feel more comfortable putting things on SVG, MathML, and HTML
explicitly.
On 14/07/2014 09:43, Dirk Schulze wrote:
However, I would like to know what use cases and problems Dirk is trying to
solve by moving these attributes from HTMLElement to Element. Dirk, could you
elaborate on that?
If you add contentEditable to an HMTL element and an SVG element is an
Craig Marsh
Graduate Dev in Test QA Platform
4th Floor, 10 Piccadilly
London, W1J 0DD
Email: craig.ma...@gamesys.co.uk
www.gamesyscorporate.com http://www.gamesyscorporate.com/
On 14/07/2014 10:09, David Carlisle dav...@nag.co.uk wrote:
On 14/07/2014 09:43, Dirk Schulze wrote:
However,
On 7/14/14, 3:35 AM, Anne van Kesteren wrote:
Is this observably different from
a target=_blank rel=noreferrer
somehow?
I think for a sandboxed iframe it might be...
Which raises a separate question, by the way: should a sandboxed iframe
(without allow-popups, in case that matters) be
Le 13/05/2014 18:21, Ian Hickson a écrit :
On Tue, 13 May 2014, Dirk Schulze wrote:
contentEditable can be fairly useful in SVG as well. It partly works for
inline SVG content in web browsers today.
The question is, should SVGElement add support for
contentEditable/isContentEditable and add it
Hi!
On 7/14/14, 7:40 AM, Michael[tm] Smith m...@w3.org wrote:
Adam Barth w...@adambarth.com, 2014-07-13 22:30 -0700:
On Sun, Jul 13, 2014 at 8:05 PM, Michael[tm] Smith m...@w3.org wrote:
It proposed a method that includes a successCallback
noHandlerCallback:
navigator.launchUri(uri,
On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke
konstantin.we...@citrix.com wrote:
How we use it:
* We try to launch our native application using a custom URI scheme
* If successful, we show some “success” UI
* If no handler installed, the user gets a download
* If we don’t get a callback
Hi Anne!
On 7/14/14, 4:44 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke
konstantin.we...@citrix.com wrote:
How we use it:
* We try to launch our native application using a custom URI scheme
* If successful, we show some “success” UI
* If no
From: Juan Ignacio Dopazo jdop...@yahoo-inc.com
Why would this not be passing a writable stream object as body parameter?
It would have to be a readable stream. Otherwise, how would the request be
able to consume it? So most people would have to pass a stream that is both
readable and
From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Domenic Denicola
dome...@domenicdenicola.com
Of these, 1 seems much nicer, based on my Node.js experience.
To be clearer as to why this is: stream APIs work much better when things you
write to are represented as writable streams
On Mon, Jul 14, 2014 at 5:43 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Does this make sense? Does it work?
No.
If I submit a form and there's a service worker installed, the service
worker will want to do this:
var data = event.request.body.toFormData()
--
On Mon, Jul 14, 2014 at 5:44 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke
konstantin.we...@citrix.com wrote:
How we use it:
* We try to launch our native application using a custom URI scheme
* If successful, we show some “success” UI
*
On Monday, July 14, 2014 12:44 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Juan Ignacio Dopazo jdop...@yahoo-inc.com
Thus I'd suggest renaming FetchBodyStream to ResponseBodyStream
(FetchResponseBodyStream?) and introducing a new RequestBodyStream without the
readAsX()
From: Juan Ignacio Dopazo jdop...@yahoo-inc.com
I agree that Node's design sounds a bit better for piping. But where would
you put the FetchResponseBodyStream? fetch() returns a promise for a
Response. Why would the response have a writable stream for the request?
There are two options:
On 14 July 2014 17:17, Domenic Denicola dome...@domenicdenicola.com wrote:
From: Juan Ignacio Dopazo jdop...@yahoo-inc.com
I agree that Node's design sounds a bit better for piping. But where
would you put the FetchResponseBodyStream? fetch() returns a promise for a
Response. Why would the
On Mon, Jul 14, 2014 at 12:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 14, 2014 at 4:26 AM, Adam Barth w...@adambarth.com wrote:
The launchURL() method requests that the User Agent launch the
protocol handler for the specified URL. If the User Agent itself is
the registered
Hey all,
I'm just back from leave and catching up on responses, but I think my colleague
Kosta responded with most of our concerns.
Re: promises:
Yes, I think this is pretty clearly an appropriate place for them. They aren't
there now because:
a) The initial draft was pretty much just a port
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at this in more detail in due course, but FWIW this appears to
be more
On Mon, Jul 14, 2014 at 10:42 AM, Ian Hickson i...@hixie.ch wrote:
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at
On Mon, 14 Jul 2014, Adam Barth wrote:
The difference is that window.open opens a new browser window even if
the URL is handled by an external protocol handler. Even if we changing
current browsers to detect whether the URL will be handled by an
external protocol handler before opening
Just doublechecking...does this API allow the user agent to specify the
Content-Length in the request? Or is chunked transfer encoding required for
fetch()? I don't see any mention of a length attribute for streams in
https://whatwg.github.io/streams/ (let me know if I'm looking in the wrong
On Mon, Jul 14, 2014 at 2:10 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 14 Jul 2014, Adam Barth wrote:
The difference is that window.open opens a new browser window even if
the URL is handled by an external protocol handler. Even if we changing
current browsers to detect whether the URL
On Mon, Jul 14, 2014 at 8:56 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Domenic
Denicola dome...@domenicdenicola.com
Of these, 1 seems much nicer, based on my Node.js experience.
To be clearer as to why this is: stream
On Mon, 14 Jul 2014, Adam Barth wrote:
I'm skeptical of features that only have a benefit during a short
transition phase. Suppose it's five years from now and now everyone
implements window.open() in this cleaner way and everyone also has
launchURL(). Why is it good that we have
On Mon, Jul 14, 2014 at 3:28 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 14 Jul 2014, Adam Barth wrote:
I'm skeptical of features that only have a benefit during a short
transition phase. Suppose it's five years from now and now everyone
implements window.open() in this cleaner way and
26 matches
Mail list logo
