Re: [whatwg] Proposal: navigator.launchURL
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 in a new browsing context in a new unit of related browsing contexts. Is this observably different from a target=_blank rel=noreferrer somehow? -- http://annevankesteren.nl/
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
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. I don't think we want contenteditable in SVG or MathML. Almost all of the operations don't make sense. What does intending in SVG do? What does making something italic? What happens when you hit enter? We can't just insert a new line in SVG, does it add some space between all the shapes? Where does your caret actually appear? The question about “hitting enter” is valid. However, these kind of questions don’t seem to be clarified for HTML either. Every UA is doing something different. To the other questions: just text in text, textPath and tspan are affected. In all other cases the general processing rules of SVG apply. We might want some new kind of Web Editing API, but contenteditable/execCommand are both pretty specific to HTML. contenteditable isn't just for execCommand. We could simply enable plaintext editing inside SVG text element for example. 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 descendant of this element, SVG text is editable as well. If you add contentEditable to an SVGElement itself, it doesn’t work. That is an observation that can be see in all browsers IIRC. SVG folks actually get asked to support contentEditable. People want to use text along a path, have it selectable and editable. Just SVG can do that — but with the hack of above. Should we add contentEditable to SVGElement or Element seems to be the remaining question. This depends if there are similar scenarios in MathML (and other markup languages) as well. Greetings, Dirk - R. Niwa
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
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 descendant of this element, SVG text is editable as well. If you add contentEditable to an SVGElement itself, it doesn’t work. That is an observation that can be see in all browsers IIRC. SVG folks actually get asked to support contentEditable. People want to use text along a path, have it selectable and editable. Just SVG can do that — but with the hack of above. Should we add contentEditable to SVGElement or Element seems to be the remaining question. This depends if there are similar scenarios in MathML (and other markup languages) as well. The MathML element case is similar to SVG the token elements such as mtext are basically just like span as far as text is concerned and editing the text in such an element is a perfectly natural requirement. change the variable x to y in e^x... editing the more structural elements such as mfrac requires more editing support (or can be disallowed, whichever fits in best with the rest of the platform) same is true of SVG (or HTML tables for that matter). Dirk's observation above about having to put contentEditable on an ancestor HTML element reminds me of the arguments for adding .innerHTML and friends to MathML (by way of adding them to Element). As originally defined you couldn't use .innerHTML on MathML elements but if you wrapped them in a span the browser had to be able to generate the innerHTML serialisation of all the descendents of that span including the MathML, so innerMathML could be faked on MathML by wrapping it in a spurious span and then removing the span from the result. Allowing the innerHTML directly on the mathml elements just made the system more logical and more convenient. It seems contentEditable is similar. David
[whatwg] Please unsubscribe me, thanks
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, 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 descendant of this element, SVG text is editable as well. If you add contentEditable to an SVGElement itself, it doesn¹t work. That is an observation that can be see in all browsers IIRC. SVG folks actually get asked to support contentEditable. People want to use text along a path, have it selectable and editable. Just SVG can do that ‹ but with the hack of above. Should we add contentEditable to SVGElement or Element seems to be the remaining question. This depends if there are similar scenarios in MathML (and other markup languages) as well. The MathML element case is similar to SVG the token elements such as mtext are basically just like span as far as text is concerned and editing the text in such an element is a perfectly natural requirement. change the variable x to y in e^x... editing the more structural elements such as mfrac requires more editing support (or can be disallowed, whichever fits in best with the rest of the platform) same is true of SVG (or HTML tables for that matter). Dirk's observation above about having to put contentEditable on an ancestor HTML element reminds me of the arguments for adding .innerHTML and friends to MathML (by way of adding them to Element). As originally defined you couldn't use .innerHTML on MathML elements but if you wrapped them in a span the browser had to be able to generate the innerHTML serialisation of all the descendents of that span including the MathML, so innerMathML could be faked on MathML by wrapping it in a spurious span and then removing the span from the result. Allowing the innerHTML directly on the mathml elements just made the system more logical and more convenient. It seems contentEditable is similar. David
Re: [whatwg] Proposal: navigator.launchURL
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 able to do this? -Boris
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
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 to its interface? Or should both attributes move to the Element interface instead? I would be very careful about moving global attributes to Element. Doing so implies that we are adding them to _all_ XML namespaces. That's a huge change to propose. Even with class it's IMHO going a bit far (we're saying that the semantics of myvocab:teacher class=.../ are that it's a space-separate list of CSS class names, even if the vocab designer intended it to be a room name or whatever). I would feel more comfortable putting things on SVG, MathML, and HTML explicitly. It might make sense to split the current HTMLElement interface and create a partial interface so it can be more easily reused in SVG and MathML. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26329 for that purpose. David
Re: [whatwg] Proposal: navigator.launchURL
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, successCallback, noHandlerCallback) No, I missed that. Looks very similar. A more modern idiom would be to return a promise to inform the caller of success or failure. We modeled this proposal roughly after the msLaunchUri API introduced in Windows 8 for IE: (The docs say that this is IE 10+, but it’s actually Windows 8+) http://msdn.microsoft.com/en-us/library/ie/jj154912(v=vs.85).aspx Is there a use case for reporting success or failure? I thought about including that, but it wasn't necessary for the use cases I'm aware of. Konstantin mentioned: We would like to have a stable, well-defined API for this that also allows to handle the “user declined / protocol handler is not installed” case gracefully. As an example, the web page could show a UI to tell the user how to install an SSH client. http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0797.html Yes, the success/failure callback are very important to have a good user experience. Most important is whether the information that handler is not available (so that you can e.g. provide a download to install the application instead). Having a success callback is very nice to provide a good UX. In the end, it’s a privacy tradeoff: Do you want to mix “handler not available” and “user declined the launch” into one callback, so that the web page does not know whether X is installed or the user just didn’t want to launch it? (However, that information might be accessible from the timings…) What the msLaunchUri call does: * successCallback if the app was launched * noHandlerCallback if no URI handler was installed * if you get no callback that means either the user declined the launch or has not click anything yet (if there was a confirmation dialog). 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 (= user declined or undecided), the user can choose between trying again and downloading the application. I’m not decided on promises vs. callbacks. I guess promises are the more modern approach. Either would work fine here and it’s easy to wrap one into the other if needed. Anne van Kesteren asked: Is this observably different from a target=_blank rel=noreferrer somehow? (Sorry for moving this mail into here, but I wasn’t subscribed to whatwg when the question was asked so I don’t have access to it to reply to it regularly) There are two very big differences: 1. The web pages doesn’t know whether launching works (UX issue, see above) 2. Browser behavior if the URI scheme is not registered varies wildly. If we implement such a launchURL or launchUri call, we can specify this behavior (as Microsoft did for msLaunchUri, see msdn link above). As an example, what browsers currently do when trying to launch an unregistered URI scheme: * Chrome/Desktop ignore it completely (good behavior) (same for Opera these days) * Chrome/Android shows a blank “not found” page with the custom URI in the navigation bar (on this platform, using intent: links is recommended to launch custom URL schemes / open to Google Play store if the app is not installed) * Firefox/Desktop shows a dialog asking the user to choose the application to handle these URIs with (this is ok for some cases like ssh://, but in the worst case the user can really misconfigure their browser here) * Firefox Android shows an error dialog * Safari/Mac asks to look on the Mac App Store for it (bad if the application is not on the app store) * Safari/iOS ignores it and users stays on the page (good) (Same for Chrome/iOS) * IE shows some error message * IE on Windows RT/Windows Phone 8 asks to look in the Windows Store So all in this is a huge mess to work with :) That’s why a standardized API would be a very neat thing! Also, note that most pages using custom URI schemes have some weird way to detect whether or not the custom URI scheme is installed to work around this issue. For example, the iTunes pages check whether some Apple plugin is available that comes bundled with iTunes (on Windows/Mac). (On iOS, they assume the “App Store” app is installed, of course) Boris Zbarsky asked: Which raises a separate question, by the way: should a sandboxed iframe (without allow-popups, in case that matters) be able to do this? (Again, sorry to move your question in here, same reason as for Anne) I think it should be allowed in sandboxed iframes (but maybe I’m biased as I want to use this API). At the very least, there should be a sandbox attribute that allows using this API. Cheers, Konstantin Welke -- Senior Software Developer Citrix Online
Re: [whatwg] Proposal: navigator.launchURL
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 (= user declined or undecided), the user can choose between trying again and downloading the application. This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. Anne van Kesteren asked: Is this observably different from a target=_blank rel=noreferrer somehow? There are two very big differences: 1. The web pages doesn’t know whether launching works (UX issue, see above) The privacy implications seem somewhat tricky. Although since the user first has to go through some UI, it might not be too bad. 2. Browser behavior if the URI scheme is not registered varies wildly. If we implement such a launchURL or launchUri call, we can specify this behavior (as Microsoft did for msLaunchUri, see msdn link above). This seems like something we need to fix either way. We should have this navigation behavior nailed down. As an example, what browsers currently do when trying to launch an unregistered URI scheme: * Chrome/Desktop ignore it completely (good behavior) (same for Opera these days) Is this when you target iframe or in general? * Firefox/Desktop shows a dialog asking the user to choose the application to handle these URIs with (this is ok for some cases like ssh://, but in the worst case the user can really misconfigure their browser here) What is a worst case? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.launchURL
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 handler installed, the user gets a download * If we don’t get a callback (= user declined or undecided), the user can choose between trying again and downloading the application. This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. Well as long as web pages are not as powerful as web apps, there’s reasons to start external applications for some functionality. The SSH client is an easy example, unless we allow web pages to connect to arbitrary hosts and ports (implementing SSH is still not possible with WebRTC, right?). Another example, Apples uses a custom URI scheme to launch iTunes, which can e.g. sync with iPhones over USB and/or WiFi - which I don’t see as a web app in the foreseeable future. At Citrix, this is also used to launch native applications for functionality not implementable as a web app (e.g. screen sharing session that transmits a Windows UAC dialog or installing a Windows Service). Anne van Kesteren asked: Is this observably different from a target=_blank rel=noreferrer somehow? There are two very big differences: 1. The web pages doesn’t know whether launching works (UX issue, see above) The privacy implications seem somewhat tricky. Although since the user first has to go through some UI, it might not be too bad. Yes, this is also the reason why I favor a launchUri() call over a isProtocolRegistered() call. This way, if a web page abuses the API it will be more annoying to the user. It is the web page’s self-interested not to annoy the user too much. 2. Browser behavior if the URI scheme is not registered varies wildly. If we implement such a launchURL or launchUri call, we can specify this behavior (as Microsoft did for msLaunchUri, see msdn link above). This seems like something we need to fix either way. We should have this navigation behavior nailed down. I agree. However it is easier for JavaScript to check whether e.g. navigator.launchUri exists and assume it behaves correctly if it exists. Using a plain link, JS would need to detect whether this is one of the browsers that implement launching external apps “as specified” . Also, a plain link can’t return a promise (if we can agree on this kind of feedback). As an example, what browsers currently do when trying to launch an unregistered URI scheme: * Chrome/Desktop ignore it completely (good behavior) (same for Opera these days) Is this when you target iframe or in general? For Chrome/Desktop, this seems to be the case in general. Here’s a test page that provides 3 ways of launching “nonexistent://foo.bar” (which I hope is not registered for an external application anywhere): http://lastpageofthe.net/nonexistent.html Note that for other browsers, the behavior usually varies between iframe, plain link and setting document.location. E.g. I just re-tested with Firefox/Mac and it shows an empty web page with the custom URI in the navigator bar for the plain link as well as when setting document.location. However, when using an iframe, a JS exception appears in the JS logs and no user-visible UI. * Firefox/Desktop shows a dialog asking the user to choose the application to handle these URIs with (this is ok for some cases like ssh://, but in the worst case the user can really misconfigure their browser here) What is a worst case? If the user chooses an application that cannot handle the protocol and checks “Remember my choice”, Firefox will always launch the wrong application without further prompting the user. This can be fixed in the Firefox settings, but is hard to figure out for the user. However, at least from superficial testing it seems that Firefox changed their behavior and now simply ignore unknown protocols when they are being launched via iframe. -- Cheers, Konstantin Welke Senior Software Developer Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe http://www.citrixonline.com http://www.citrixonline.com/ Work better. Live better. Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe Geschäftsführer: Tommy Ahlers | David Zalewski | Michael DiFilippo Sitz der Gesellschaft: Karlsruhe | Registergericht: Amtsgericht Mannheim HRB 713721 Citrix Online UK Ltd http://www.citrixonline.com/imprint-en.tmpl
Re: [whatwg] Questions about the Fetch API
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 writable.
Right. The creator of a writable stream can set up a relationship between the
user-facing stream and the underlying source (in this case, the HTTP request
body). So we have two options:
1. The fetch API creates a writable stream tied to the request body as its
underlying source, and hands out a reference to that stream to the fetch API
caller. Then, writes go directly from the caller to the underlying source via
the stream mechanism. In this way, we have a writable stream representing the
HTTP request body.
2. The fetch API accepts a readable stream from the API caller, and reads from
it. As data is read by fetch, it then gets written to the HTTP request body. In
this case, there is no writable stream representing the HTTP request body. If a
fetch API caller wants to stream data into the request body, they have to set
up a pass-through {WritableStream input, ReadableStream output} pair and pass
the output to the fetch API while writing into the input. (This will likely be
doable pretty easily with the streams API, perhaps via `var { input, output } =
new TransformStream({ transform(x) { return x; })` or even `var { input, output
} = new TransformStream()` if we add a default.)
Of these, 1 seems much nicer, based on my Node.js experience.
My first thought looking at the existing API is that FetchBodyStream is being
used in two ways:
- As a request body stream
- As a response body stream
Its methods right now are geared entirely toward reading, but in reality, you
write to a request body, and read from a response body. The fact that, in the
current API, you can read from a request body, is actually quite bad: it means
you cannot do proper fire-and-forget writes to the request socket, but instead
have to do buffer-copies of everything written to the socket in case someone
does readAsJSON() on the request body any time before the request body is GCed.
Thus I'd suggest renaming FetchBodyStream to ResponseBodyStream
(FetchResponseBodyStream?) and introducing a new RequestBodyStream without the
readAsX() methods. For now I think it'd be empty? But later it would become a
WritableStream.
Does this make sense? Does it work?
Re: [whatwg] Questions about the Fetch API
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 (option 1), instead of representing them as functions that accept readable streams (option 2).
Re: [whatwg] Questions about the Fetch API
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() -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.launchURL
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 * If no handler installed, the user gets a download * If we don’t get a callback (= user declined or undecided), the user can choose between trying again and downloading the application. This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. As a person working for a company with a big mobile game catalogue, I'd say this is a reality and happening already, and unfortunately I've seen this currently done in some pretty gross, uninteroperable and user-hostile ways and would love to see those go away. If we specify the way this should be done, this will also let the UA be more aware of what the web app is trying to do, so for people like me who hate websites trying to open an app, the UA could have an option to always reject these attempts. I think the overall compelling thing here is providing a good UX for something that may or may not be a good thing, but is happening already, with poor UX. - Jussi
Re: [whatwg] Questions about the Fetch API
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() methods. For now I think it'd be empty? But later it would become a WritableStream. Does this make sense? Does it work? 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: 1- Have fetch() return a promise for an object with request and response properties 2- Have fetch() return something that is not a promise Juan
Re: [whatwg] Questions about the Fetch API
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:
1- Have fetch() return a promise for an object with request and response
properties
2- Have fetch() return something that is not a promise
3- have fetch() take a writable stream as a parameter, e.g.
var request = new Request(http://example.com;, { method: POST });
myReadableStream.pipeTo(request.body);
fetch(request);
(this is not great ergonomically, but seems to be the direction the current API
points to...)
Re: [whatwg] Questions about the Fetch API
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 response have a writable stream for the request?
There are two options:
1- Have fetch() return a promise for an object with request and
response properties
2- Have fetch() return something that is not a promise
3- have fetch() take a writable stream as a parameter, e.g.
var request = new Request(http://example.com;, { method: POST });
myReadableStream.pipeTo(request.body);
fetch(request);
(this is not great ergonomically, but seems to be the direction the
current API points to...)
The current API is
var request = new Request(http://example.com;, {
method: POST,
body: myReadableStream
});
Re: [whatwg] Proposal: navigator.launchURL
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 protocol handler for |url|, then the User Agent should open the requested URL in a new browsing context in a new unit of related browsing contexts. Is this observably different from a target=_blank rel=noreferrer somehow? Yes, that causes a blank window to be created before launching the external protocol handler. On Mon, Jul 14, 2014 at 4:39 AM, Boris Zbarsky bzbar...@mit.edu wrote: Which raises a separate question, by the way: should a sandboxed iframe (without allow-popups, in case that matters) be able to do this? Nope, I think we should block that. On Mon, Jul 14, 2014 at 6:47 AM, Konstantin Welke konstantin.we...@citrix.com wrote: Yes, the success/failure callback are very important to have a good user experience. Most important is whether the information that handler is not available (so that you can e.g. provide a download to install the application instead). Having a success callback is very nice to provide a good UX. Makes sense. In the end, it’s a privacy tradeoff: Do you want to mix “handler not available” and “user declined the launch” into one callback, so that the web page does not know whether X is installed or the user just didn’t want to launch it? (However, that information might be accessible from the timings…) What the msLaunchUri call does: * successCallback if the app was launched * noHandlerCallback if no URI handler was installed * if you get no callback that means either the user declined the launch or has not click anything yet (if there was a confirmation dialog). If the user declines, we should probably reject the promise. I’m not decided on promises vs. callbacks. I guess promises are the more modern approach. Either would work fine here and it’s easy to wrap one into the other if needed. Promises are the future. New APIs should use them instead of having a pair of success and failure callbacks. I think it should be allowed in sandboxed iframes (but maybe I’m biased as I want to use this API). At the very least, there should be a sandbox attribute that allows using this API. IMHO, the allow-popups should enable the feature, just like it enables window.open. On Mon, Jul 14, 2014 at 7:44 AM, Anne van Kesteren ann...@annevk.nl wrote: This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. It's about user choice. Users might choose to use a web-based SSH client or they might choose to use a native application as their SSH client. The web site that's launching the SSH session doesn't need to care. They can all share the same URI scheme: ssh. Adam
Re: [whatwg] Proposal: navigator.launchURL
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 of the IE API to open a discussion. b) I was unsure of the current status of promises for new proposals; I now understand they're expected at this point in time. Cheers, Ben -Original Message- From: Konstantin Welke Sent: Monday, July 14, 2014 6:48 AM To: Michael[tm] Smith; Adam Barth; ann...@annevk.nl; bzbar...@mit.edu Cc: wha...@whatwg.org; Ben Johnson Subject: Re: [whatwg] Proposal: navigator.launchURL 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, successCallback, noHandlerCallback) No, I missed that. Looks very similar. A more modern idiom would be to return a promise to inform the caller of success or failure. We modeled this proposal roughly after the msLaunchUri API introduced in Windows 8 for IE: (The docs say that this is IE 10+, but it’s actually Windows 8+) http://msdn.microsoft.com/en-us/library/ie/jj154912(v=vs.85).aspx Is there a use case for reporting success or failure? I thought about including that, but it wasn't necessary for the use cases I'm aware of. Konstantin mentioned: We would like to have a stable, well-defined API for this that also allows to handle the “user declined / protocol handler is not installed” case gracefully. As an example, the web page could show a UI to tell the user how to install an SSH client. http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0797.html Yes, the success/failure callback are very important to have a good user experience. Most important is whether the information that handler is not available (so that you can e.g. provide a download to install the application instead). Having a success callback is very nice to provide a good UX. In the end, it’s a privacy tradeoff: Do you want to mix “handler not available” and “user declined the launch” into one callback, so that the web page does not know whether X is installed or the user just didn’t want to launch it? (However, that information might be accessible from the timings…) What the msLaunchUri call does: * successCallback if the app was launched * noHandlerCallback if no URI handler was installed * if you get no callback that means either the user declined the launch or has not click anything yet (if there was a confirmation dialog). 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 (= user declined or undecided), the user can choose between trying again and downloading the application. I’m not decided on promises vs. callbacks. I guess promises are the more modern approach. Either would work fine here and it’s easy to wrap one into the other if needed. Anne van Kesteren asked: Is this observably different from a target=_blank rel=noreferrer somehow? (Sorry for moving this mail into here, but I wasn’t subscribed to whatwg when the question was asked so I don’t have access to it to reply to it regularly) There are two very big differences: 1. The web pages doesn’t know whether launching works (UX issue, see above) 2. Browser behavior if the URI scheme is not registered varies wildly. If we implement such a launchURL or launchUri call, we can specify this behavior (as Microsoft did for msLaunchUri, see msdn link above). As an example, what browsers currently do when trying to launch an unregistered URI scheme: * Chrome/Desktop ignore it completely (good behavior) (same for Opera these days) * Chrome/Android shows a blank “not found” page with the custom URI in the navigation bar (on this platform, using intent: links is recommended to launch custom URL schemes / open to Google Play store if the app is not installed) * Firefox/Desktop shows a dialog asking the user to choose the application to handle these URIs with (this is ok for some cases like ssh://, but in the worst case the user can really misconfigure their browser here) * Firefox Android shows an error dialog * Safari/Mac asks to look on the Mac App Store for it (bad if the application is not on the app store) * Safari/iOS ignores it and users stays on the page (good) (Same for Chrome/iOS) * IE shows some error message * IE on Windows RT/Windows Phone 8 asks to look in the Windows Store So all in this is a huge mess to work with :) That’s why a standardized API would be a very neat thing! Also, note that most pages using custom URI schemes have some weird way to detect
Re: [whatwg] Proposal: navigator.launchURL
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 or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
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 this in more detail in due course, but FWIW this appears to
be more or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
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 the window, web sites
won't be able to feature-detect which browsers have this new behavior
and therefore won't be able to move away from iframe@src hacks until
all the browsers they care about have the behavior change. By
contrast, sites can feature detect navigator.launchURL and fall back
to iframe@src in UAs that lack the new API.
Adam
Re: [whatwg] Proposal: navigator.launchURL
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 the window, web sites won't be able to feature-detect which browsers have this new behavior and therefore won't be able to move away from iframe@src hacks until all the browsers they care about have the behavior change. By contrast, sites can feature detect navigator.launchURL and fall back to iframe@src in UAs that lack the new API. 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 both? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Questions about the Fetch API
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
place). Or is there a requestType analog for XHR's responseType?
Cheers.
On Mon, Jul 14, 2014 at 9:24 AM, Jake Archibald jaffathec...@gmail.com
wrote:
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 response have a writable stream for the request?
There are two options:
1- Have fetch() return a promise for an object with request and
response properties
2- Have fetch() return something that is not a promise
3- have fetch() take a writable stream as a parameter, e.g.
var request = new Request(http://example.com;, { method: POST });
myReadableStream.pipeTo(request.body);
fetch(request);
(this is not great ergonomically, but seems to be the direction the
current API points to...)
The current API is
var request = new Request(http://example.com;, {
method: POST,
body: myReadableStream
});
Re: [whatwg] Proposal: navigator.launchURL
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 will be handled by an external protocol handler before opening the window, web sites won't be able to feature-detect which browsers have this new behavior and therefore won't be able to move away from iframe@src hacks until all the browsers they care about have the behavior change. By contrast, sites can feature detect navigator.launchURL and fall back to iframe@src in UAs that lack the new API. 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 both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. If developers don't adopt a feature, browser vendors are less likely to adopt the feature. That's why the bootstrapping process is an important consideration. Adam
Re: [whatwg] Questions about the Fetch API
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 APIs work much better when things you write to are represented as writable streams (option 1), instead of representing them as functions that accept readable streams (option 2). Can you explain this in more detail? AFAICT, the fundamental difference we're talking about here is push vs pull sources. Option 1 is a push model, where fetch() creates a writable stream that has an underlying sink (Domenic, did I get that right? I assume you meant sink and not source) of the request body. And the user code writes to the stream to stream output to the request body. In contrast, option 2 is a pull model, where fetch() accepts as input a readable stream and pulls from it as the network is ready to write the request body out. I'm willing to believe that the push model might result in easier APIs for piping. I haven't thought about it. But I want to assert that the push model has significant downsides in comparison to the pull model. First, observe that a stream is a reliable (in the network sense, a la TCP), ordered sequence of data. The reliability and ordering requirement are key to understanding the performance issues. That effectively transforms a stream into a FIFO queue. The sooner you push data into a FIFO queue, the sooner the source has to commit to the ordering of data. Now, observe that committing to the ordering of data sooner prevents the source from reordering later. Why might one want to reorder later? Prioritization. Delaying the binding of data to a stream allows the source to better prioritize data. For example, let's say that I have a server. I have multiple clients issuing requests. I have a single backend connection (database backend, file serving backend, whatever). So I'm multiplexing requests from multiple clients over a single connection. If I want to prioritize the order in which I utilize the single backend [connection], I had best delay the commit of a request blob to the backend connection stream. It's better for the backend connection stream to *pull* rather than for the server to *push* to the backend, because it facilitates this delayed decision making process. For a real example of the push vs pull model and its relation to prioritization, I've got an old blog post ( https://insouciant.org/tech/prioritization-only-works-when-theres-pending-data-to-prioritize/) I wrote before about Google Maps engineers complaining to me that prioritization didn't work. The root cause of the problem was the push model and excessive buffering (in the kernel sink, which defeated our user space prioritization at the source). Of course, you can simulate a pull model with a push model by applying backpressure super aggressively, which I discuss later on in that same blog post ( https://insouciant.org/tech/prioritization-only-works-when-theres-pending-data-to-prioritize/#The_Solution). By reducing the amount of buffering, you incur more context switches instead. In the blog post, a context switch is an actual kernel / user space OS context switch. In a web browser model, it would be a context switch between the different layers within the browser platform and the user code, which can get especially expensive in a multiprocess resource loading model, such as the one that the Chromium browser uses. There are many other nuances here but I've neglected to mention out of brevity. Let me know if more details would help. Cheers. PS: I document many of my/Chromium's struggles to undo the push model in our network stack and the resulting payoffs here - https://insouciant.org/tech/connection-management-in-chromium/#socket_late_binding .
Re: [whatwg] Proposal: navigator.launchURL
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 both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius It doesn't really matter how long it takes. The time until authors can stop using the iframe hack is the same whether we provide a new API or have a legacy API that needs updating to be slightly less annoying. If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
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 everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius It doesn't really matter how long it takes. The time until authors can stop using the iframe hack is the same whether we provide a new API or have a legacy API that needs updating to be slightly less annoying. If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. Ok, we can try the window.open approach first. Adam
