Re: [whatwg] Proposal to extend registerProtocolHandler
Peter Kasting wrote: On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafaio...@chromium.org wrote: Do any browser vendors agree with this or have objections? From my work on the Chrome UI side of this, I would very much like to see something like isRegistered(). This would allow sites to conditionalize requests for the protocol handler. This is important to me because I would also like to experiment (after that point) with requiring a user gesture for this request (much like browsers typically require user gestures for window.open()), so sites cannot hammer the user with requests outside of some sort of interaction-based workflow. I've also been thinking along these lines for things that require some user interaction at the chrome level. The idea would be to emulate window.open functionality to the point that something happens only if a _user-initiated_ click event occurs. If an event is invoked by a script synthesizing its event via e.g. anchor.click() then that should not invoke any UI stuff. Only if window.open is invoked by a user does the popup blocker not kick-in and the popup pages open. It would be nice to have that same principle work for registerProtocolHandler. FWIW, I proposed something to the effect you are describing in the W3C Contacts API [1]. window.open seems a little under-defined when it comes to the pseudo-standard behavior of blocking window.open calls outside of a user-initiated event. br/ Rich [1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events
Re: [whatwg] Proposal to extend registerProtocolHandler
Rich Tibbett wrote: Peter Kasting wrote: On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafaio...@chromium.org wrote: Do any browser vendors agree with this or have objections? From my work on the Chrome UI side of this, I would very much like to see something like isRegistered(). This would allow sites to conditionalize requests for the protocol handler. This is important to me because I would also like to experiment (after that point) with requiring a user gesture for this request (much like browsers typically require user gestures for window.open()), so sites cannot hammer the user with requests outside of some sort of interaction-based workflow. I've also been thinking along these lines for things that require some user interaction at the chrome level. The idea would be to emulate window.open functionality to the point that something happens only if a _user-initiated_ click event occurs. If an event is invoked by a script synthesizing its event via e.g. anchor.click() then that should not invoke any UI stuff. Only if window.open is invoked by a user does the popup blocker not kick-in and the popup pages open. It would be nice to have that same principle work for registerProtocolHandler. FWIW, I proposed something to the effect you are describing in the W3C Contacts API [1]. window.open seems a little under-defined when it comes to the pseudo-standard behavior of blocking window.open calls outside of a user-initiated event. The behavior implied in [1] can be demoed against window.open here http://jsfiddle.net/nRJrz/3/ Should we document this psuedo-standard UA behavior wrt window.open? It would be nice to have a reference of this behavior on which to build other interactive UI experiences in the future. Tested in Opera 11.5, Chrome 12, Firefox 5 and Safari 5. br/ Rich [1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, 05 Jul 2011 00:41:13 +0200, Peter Kasting pkast...@google.com wrote: In general, I echo Michael's comment that we follow the notifications model. That means using http://dev.w3.org/2009/dap/perms/FeaturePermissions.html I take it? I am still somewhat dubious about that idea given http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html but on the other hand it is annoyingly hard to find an alternative. :( -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Using footer in blockquote for attribution
2011-07-01 11:26, Simon Pieters wrote: Simon felt that “Content inside a blockquote must be quoted from another source” excludes footer. s/footer/attribution/ Indeed since it's a conformance requirement, in valid documents the content inside blockquote is quoted from another source. If the spec were to allow attribution inside blockquote, the above conformance requirement would need to be changed to allow it. I was pretty sure that I had seen an example where a blockquote element contained an attribution in a footer. Alas, the “living standard” does not seem to have a version history where I could conveniently check this out. Admittedly, there is some logic in requiring that the content of blockquote be quoted from an external source and nothing more. I wonder whether this disallows common constructs like “[foo]” to indicate that “foo” has been added for clarification and is not present in the source. Anyway, having a blockquote element but no markup for attribution is very illogical. It is a prime rule in proper quotations, and widely even required by the copyright laws, that a quotation be accompanied by an indication of the quoted author and the source of the quotation. I guess we are supposed to believe in the cite attribute—which is not supported by browsers or used by authors, and I don’t see how HTML5 could break this vicious circle. (There is no obvious way how browsers _could_ support it, in a manner that makes sense, i.e. is understandable to users—there is no common paradigm for presenting attributions when you only have a URL to play with.) Besides, it’s clearly insufficient since only the URL can be specified, and surely not all works have URLs, and other types attributions are often far more permanent than URLs. The actual usage of blockquote is mostly for indentation. In practice, it means “indent,” though occasionally the motivation for indentation might be that the text is quoted. Any software that does something on the assumption that blockquote actually means quoted text will get things wrong more often than not. Thus, the attempt at semantic purification will probably achieve nothing. People and authoring tools that use blockquote to indent will keep doing so. People who wish to use proper semantic markup will find out that they cannot: blockquote isn’t a working solution (it’s already tainted as presentational markup), and it’s even less so than previously, since you cannot even “validly” include an attribution in the element but need to use some random element after the blockquote element. However, I don't know if there's any specific way to mark this up. It's a common pattern, so it would be a good candidate for adding here: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#common-idioms-without-dedicated-elements It's useful to be able to put the author info in its own element so that you can style it differently. People can do that. But this does not result in any useful default rendering, and it does not help indexing robots at all. For block quotations, a fresh start might be better than playing with the blockquote element, which really belongs to the “compatibility area”: its default effect on rendering should be clearly specified, and it could be added that in previous specifications, it has been defined to mean a block quotation from an external source and it has been used in that meaning to some extent. If you think that a semantic element for quotations is needed, then it’s best to add new elements, at least for a quotation and for an associated attribution. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Proposal to extend registerProtocolHandler
For rPH, please don't require a user-initiated click for the call. That's one very annoying thing about notifications - it takes users two clicks to enable them, and every app has to find some suitable in-page UI to ask users to make the first click. Since both notifications and rPH are confirmed by the UA, it seems silly to require a user-initiated click. Prompting for permissions is much less annoying than opening a new window, so I don't think the same standards should apply. It's also very easy for users to prevent sites from asking in the future by just denying the permission. Michael On Mon, Jul 4, 2011 at 3:41 PM, Peter Kasting pkast...@google.com wrote: In general, I echo Michael's comment that we follow the notifications model. On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. Can UAs not be expected to handle this properly, like they do with repeated alerts? It's not a problem on the UA side, but the web page side. Assume we want to limit action on this call to cases where there's a user gesture (to prevent bad sites from annoying you quite as easily, though I admit it is not a huge roadblock). Now you're Gmail and you want to give the user the ability to register you as a mailto: handler. So you whip up some button that will make the rPH() call and some UI around it that calls attention to it. Without the ability to check if you're already the default handler, you have to show this UI all the time, which is not at all appealing, or else bury it somewhere, which means it will never get seen by most users. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/5/11 3:58 PM, Michael Davidson wrote: Prompting for permissions is much less annoying than opening a new window That's unclear. Especially if permission grants are persistent. so I don't think the same standards should apply. If anything, persistent permission grants should have a _higher_ bar than opening a temporary pop-up window... -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 1:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: so I don't think the same standards should apply. If anything, persistent permission grants should have a _higher_ bar than opening a temporary pop-up window... Granting permission, yes. But just asking for permission? I say it's less annoying because (in Chrome, anyway), the infobar that asks for permission to be granted isn't modal, and the user can continue with her work. The UA should make it as clear as possible what the consequences are of granting persistent permissions and how to turn them off. But requiring an in-page click to trigger the permission in the UA doesn't seem useful to me. If, for example, Amazon wanted to show me desktop notifications I'd just cilck no. I'd rather do that once then have some persistent part of the Amazon UI dedicated to asking me to let it ask for permissions. Michael -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/5/11 4:48 PM, Michael Davidson wrote: Granting permission, yes. But just asking for permission? If the asking for permission can happen in a context in which the user can't tell what's being asked for, it's a really bad idea... I say it's less annoying because (in Chrome, anyway), the infobar that asks for permission to be granted isn't modal, and the user can continue with her work. This is the one reason that permission requests don't have that higher bar yet, yes. The UA should make it as clear as possible what the consequences are of granting persistent permissions That's really difficult if the site asks for a bunch of permissions in a flurry. -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/5/11 4:48 PM, Michael Davidson wrote: Granting permission, yes. But just asking for permission? If the asking for permission can happen in a context in which the user can't tell what's being asked for, it's a really bad idea... Can you clarify what you mean? Requiring an in-page click doesn't mean that the user understands either. Malicious pages can just lie in the text. Seems like it's up to UAs to make sure users understand, and requiring an in-page click won't help that. I say it's less annoying because (in Chrome, anyway), the infobar that asks for permission to be granted isn't modal, and the user can continue with her work. This is the one reason that permission requests don't have that higher bar yet, yes. Sadly, they do for desktop notifications. Fortunately, they do not for rPH. :) The UA should make it as clear as possible what the consequences are of granting persistent permissions That's really difficult if the site asks for a bunch of permissions in a flurry. I'm all in favor of UAs throttling or doing whatever needs to be done in order to help the user make educated decisions. I don't believe that requiring an in-page click will help users at all. Michael -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/5/11 5:04 PM, Michael Davidson wrote: If the asking for permission can happen in a context in which the user can't tell what's being asked for, it's a really bad idea... Can you clarify what you mean? Requiring an in-page click doesn't mean that the user understands either. Malicious pages can just lie in the text. Seems like it's up to UAs to make sure users understand, and requiring an in-page click won't help that. Yes, I'm not saying in-page click is a solution. It works for popups, sort of, but I don't think it does for permission request notifications. This is the one reason that permission requests don't have that higher bar yet, yes. Sadly, they do for desktop notifications. Fortunately, they do not for rPH. :) To be clear, I meant a higher bar than popup windows. -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, I'm not saying in-page click is a solution. It works for popups, sort of, but I don't think it does for permission request notifications. To be truly honest, requiring a user gesture probably doesn't work for rPH() because it doesn't actually work for window.open, or allowing executable files to download, or any other purpose we've keyed off in UAs so far. That's because a click is not at all a good indicator of some sort of of user understanding and intent. The only thing it buys you is the possibility that a visible UI change happens immediately after a user's click and thus that in theory the user _might_ be able to guess that the click triggered the UI change. In any case I am not suggesting we spec anything regarding user gestures for rPH() for now, it was an example of something we could try that isn't really possible to consider unless we give webpages some sort of way to check registration. Also, I happen to agree with Boris that prompting for permissions is not, in fact, less annoying than opening a new window. Making prompts be non-modal infobars does not mean they're suddenly friction-free and OK to show all the time. It's much harder to close an infobar, for example (no keyboard shortcuts or OS allowances). And the consequences of a user clicking OK randomly to close a grant permission infobar are much greater than the consequences of a user clicking a popup's close box. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
I don't think browsers need to prompt for registerProtocolHandler. Instead, I would simply allow any site to register as a protocol handler for almost anything, and remember all such registrations. When the user navigates to a URI whose protocol has had an app newly registered for it since the last such navigation, then prompt the user to choose which app to use. The UI for that prompt would give prominence to the previously-seected app (if any), followed by any newly registered app(s), and would remember the choice. The UI could be modal or non-modal. It seems to me that this approach would address the issues James Kozianski raised in part 1 of his email, obviating the need for an isRegistered() function. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Peer-to-peer communication, video conferencing, device, and related topics
On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
On 2011-03-18 05:45, Ian Hickson wrote:
On Thu, 16 Sep 2010, Jonathan Dixon wrote:
Further, it could be useful to provide a way to query the video source
as to whether the camera is oriented relative to the screen (if the
underlying system knows; consider a phone device with both a main
camera
and self-view camera). This is needed to drive the decision on whether
to do this horizontal flip or not. In fact, such an application may
want
to somehow indicate a preference for the self-view camera when multiple
cameras are present in the selection list. c.f. a movie-making app
which
would prefer the outward facing camera.
Interesting.
In getUserMedia() the input is extensible; we could definitely add
prefer-user-view or prefer-environment-view flags to the method
(with
better names, hopefully, but consider that 'rear' and 'front' are
misleading terms -- the front camera on a DSLR faces outward from the
user, the front camera on a mobile phone faces toward the user). The
user
still has to OK the use of the device, though, so maybe it should just
be
left up to the user to pick the camera? They'll need to be able to
switch
it on the fly, too, which again argues to make this a UA feature.
We could just add flags to the options string like this:
video;view=user, audio or video;view=environment, audio
It's worth pointing out that The HTML Media Capture draft from the DAP
WG uses the terms camera and camcorder for this purpose, but I find
these terms to be very ambiguous and inappropriate, and so we should not
use them here.
Just wanted to know whether there is any consensus on this or not? Mobile
phones are coming out with dual cameras (front and back facing) and
depending on the use case, the developer might want access to either the
front or back one. (For example, for a simple camera app, a back facing
will do, but for a web conferencing app, the front facing will be
required). At least, the developer should be able to specify which one to
enable by default, which then can be changed the user if needed.
Another question is flash. As far as I have seen, there seems to be no
option to specify whether the camera needs to use flash or not. Is this
decision left up to the device? (If someone is making an app which is just
clicking a picture of the person, then it would be nice to have the camera
use flash in low light conditions).
http://dev.w3.org/2009/dap/camera/
Similarly for exposing the kind of stream: we could add to
GeneratedStream
an attribute that reports this kind of thing. What is the most useful
way
of exposing this information?
I'm not entirely clear about what the use cases are for knowing if the
camera is either user-view or environment-view. It seems the more
useful information to know is the orientation of the camera. If the
user switches cameras, that could also be handled by firing orientation
events.
Lachlan Hunt wrote:
There are some use cases for which it would be useful to know the
precise orientation of the camera, such as augmented reality
applications. The camera orientation may be independent of the
device's
orientation, and so the existing device orientation API may not be
sufficient.
It seems like the best way to extend this would be to have the Device
Orientation API apply to GeneratedStream objects, either by just having
the events also fire on GeneratedStream objects, or by having the API be
based on a pull model rather than a push model and exposing an object on
GeneratedStream objects as well as Window objects.
This could work. But it would make more sense if there were an object
representing the device itself, as in Rich's proposal, and for the
events to be fired on that object instead of the stream.
On Mon, 24 Jan 2011, Anne van Kesteren wrote:
There is a plan of allowing direct assigning to IDL attributes besides
creating URLs.
I.e. being able to do:
audio.src = blob
(The src content attribute would then be something like
about:objecturl.)
I am not sure if that API should work differently from creating URLs
and
assigning those, but we could consider it.
Could you elaborate on this plan?
This is basically what Philip and I were discussing in the other thread
yesterday, where we avoid the unnecessary overhead of creating a magic
URL, and instead just assign the object directly to the src property.
This lets the implementation handle all the magic transparently in the
background, without bothering to expose a URLs string to the author.
This is what we had implemented in our experimental implementation of
the device element, and now getUserMedia.
i.e.
video/video
script
var v = document.querySelector(video);
navigator.getUserMedia(video, function(stream) {
v.src = stream;
v.play();
});
/script
The getter for v.src then returns about:streamurl.
My understanding is that
