Re: [whatwg] Proposal for a web application descriptor
Hello everyone, After reading all your comments I partly re-tought some of my ideas. First of all it might not be the best idea to create a full application descriptor if it would only be used to specify permissions. Additionally, I can see why people do not want to be asked for all permissions at once. However, I on the other hand do not want to be asked for all permissions separately. After reading some of the links posted in this discussion I modified my proposal a little. You can find the new version here: http://www.simonheckmann.de/proposal/draft2 While the first part has not changed much, the second part is all-new and includes two completely re-modeled mock-ups. Again, comments are welcome. Kind regards, Simon Heckmann Am 30.04.2011 um 17:23 schrieb Robert O'Callahan: On Sun, May 1, 2011 at 1:52 AM, Glenn Maynard gl...@zewt.org wrote: On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan rob...@ocallahan.org wrote: The application could have a settings page with a checkbox Enable desktop notifications. When you click on that box, the browser shows its (passive, asynchronous) UI for enabling desktop notifications for that application. This still implies having an API to ask for permission for a feature before using it. (Web Notifications has a draft for this: http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html .) Also, many developers won't want a UI like that, since when you disable a feature and expect users to enable it in settings, a lot of them won't. Many people never look at settings pages at all. Pages are more likely to request permissions as soon as they can. Notifications are a particularly hard case for the principle of requesting permissions in response to user action, because the whole point of notifications is that they happen when the user isn't giving the application attention :-). Another possible approach would be to have the default be for notifications to show up in browser UI associated with the page --- e.g., highlight the tab title and show the notification(s) at the top of the page if you switch to the tab --- and in that notification-showing UI, offer a show on desktop button which lets the notifications for that application migrate to the desktop --- effectively a permission grant. Of course, asking each of these while using the application would also be painfully annoying, and it's not obvious how to make permissions meaningful to the user (eg. when you use its feature) while also scaling to lots of permissions. I think we have to consider specific cases. For Skype, it depends on whether all those permissions are really needed, and why... It might not be that hard to figure out how to make on-demand permission grants intelligible. We owe it to users to try. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal for a web application descriptor
Hi Simon, Just to be certain, I'd like to ask if You are targeting desktop browser in mobile devices, such as iPad and iPhones, as well, or is Your proposal focused on PC/laptop devices? Kind Regards Göran On 2011-05-01 16.49, Simon Heckmann si...@simonheckmann.de wrote: Hello everyone, After reading all your comments I partly re-tought some of my ideas. First of all it might not be the best idea to create a full application descriptor if it would only be used to specify permissions. Additionally, I can see why people do not want to be asked for all permissions at once. However, I on the other hand do not want to be asked for all permissions separately. After reading some of the links posted in this discussion I modified my proposal a little. You can find the new version here: http://www.simonheckmann.de/proposal/draft2 While the first part has not changed much, the second part is all-new and includes two completely re-modeled mock-ups. Again, comments are welcome. Kind regards, Simon Heckmann Am 30.04.2011 um 17:23 schrieb Robert O'Callahan: On Sun, May 1, 2011 at 1:52 AM, Glenn Maynard gl...@zewt.org wrote: On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan rob...@ocallahan.org wrote: The application could have a settings page with a checkbox Enable desktop notifications. When you click on that box, the browser shows its (passive, asynchronous) UI for enabling desktop notifications for that application. This still implies having an API to ask for permission for a feature before using it. (Web Notifications has a draft for this: http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermission s.html .) Also, many developers won't want a UI like that, since when you disable a feature and expect users to enable it in settings, a lot of them won't. Many people never look at settings pages at all. Pages are more likely to request permissions as soon as they can. Notifications are a particularly hard case for the principle of requesting permissions in response to user action, because the whole point of notifications is that they happen when the user isn't giving the application attention :-). Another possible approach would be to have the default be for notifications to show up in browser UI associated with the page --- e.g., highlight the tab title and show the notification(s) at the top of the page if you switch to the tab --- and in that notification-showing UI, offer a show on desktop button which lets the notifications for that application migrate to the desktop --- effectively a permission grant. Of course, asking each of these while using the application would also be painfully annoying, and it's not obvious how to make permissions meaningful to the user (eg. when you use its feature) while also scaling to lots of permissions. I think we have to consider specific cases. For Skype, it depends on whether all those permissions are really needed, and why... It might not be that hard to figure out how to make on-demand permission grants intelligible. We owe it to users to try. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Content-Disposition property for a tags
On 4/30/11 2:24 PM, Michal Zalewski wrote: Note that somewhat counterintuitively, there would be some security concerns with markup-level content disposition controls (or any JS equivalent). For example, consider evil.com doing this: a href='http://example.com/user_content/harmless_text_file.txt' disposition='attachment; filename=Important_Security_Update.exe' At least in the case of Firefox for that particular case on Windows the filename will be sanitized... But yes, there are other situations where things could be more problematic. -Boris
Re: [whatwg] Content-Disposition property for a tags
At least in the case of Firefox for that particular case on Windows the filename will be sanitized... Yes, but Firefox is an exception, not a rule; and even that mechanism is very imperfect (it relies on explicit mappings that are not guaranteed to be in sync with other OS components; when downloading a less known MIME type, like image/jpeg2000, the user is still in trouble). /mz
Re: [whatwg] Mechanism to find available events
On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/29/11, Ian Hickson i...@hixie.ch wrote: [...] We need a mechanism to detect accurately the features of the browser our code's running in, without relying to UA sniffing madness. No such mechanism can exist without actually using the feature, because there's no way to guarantee that a browser will accurately report what it supports. Every time we've had such a feature (e.g. DOM hasFeature()) vendors have ended up returning inaccurate values. Is it possible to design something better than hasFeature? Method hasFeature can be expected to have the problems it has because it is not related to any specific object (Node, window, document). As such, this method requires the implementation (browser) to make an unreasonable generalization. Requiring the unreasonable is unreasonable. True, but I think there is a deeper problem. Browsers need to be roughly compatible with sites. From a user perspective, that means it more or less works while from a site developer's perspective that often means it works exactly as I designed it. This puts the browser and the site author in direct conflict, and while the site developer might feel that the user is being unfairly hampered if the browser doesn't perform as desired torender the site to its best advantage, the browser feels the user is unfairly served if they are being told to go through the hassle of changing browsers because of some trivial difference in rendering or performance. So we can make all the technical improvements we want. But so long as there is a conflict in goals for how to use a feature, as there often is with hasFeature(), it is extremely unlikely that we can make that feature work in a way that satisfies everyone. If instead, there were a method designed to check the object in question, it could be specified to require the implementation also check that object's capabilities. I'm not suggesting unequivocal (e.g. right click triggers a context menu) -- that seems too much. I'm suggesting a more closely related inference check. Is a mechanism such as this possible? Why rule it out? It is possible, but it isn't clear that it will work as you anticipate, and reasonably likely that it won't for the same non-technical reasons hasFeature() doesn't. Improving (or replacing) hasFeature isn't an intrinsically bad idea, but it isn't useful without working out how to resolve those non-technical issues. The mobile world (whose UA-sniffing requirements make the one-Web goal on Desktop look like a solid reliable reality where developers' lives are trouble-free and pleasant) has an alternative solution that is based around crowd-sourcing the information on whether something is supported. It *is* UA-sniffing madness by most definitions, and it relies on huge amounts of data and a system for managing conflicting statements via simple trust modelling (it theoretically offers massive scope for abuse that permits direct market manipulation), but it has worked well enough for them that it is extremely widely used, and the approach has been repeated, merely making technical refinements, over successive generations of the technology. Going down that path of course doesn't allow you to do the work client-side, which is also a problem for the use-case you're looking at. But in an area where I mostly see bad alternatives, it is another option that could be the lesser of the available evils in some circumstances. cheers Chaals On Wed, 29 Dec 2010, Garrett Smith wrote: However, how can a program determine if a particular event is generated by the browser and fired at a particular object? The `(onhashchange in window)` test should theoretically work, but as mentioned, that isn't interoperable at this point. Neither is a mechanism to find out if an event is going to be fired. :-) The *proposed* mechanism isn't interoperable -- is that what you're hinting at? New events are what will need to be detected. Just like contextmenu was not interoperable at one point. Now if, prior to that, there had been a mechanism to determine if contextmenu events, the developer would not know exactly under which circumstances that would occur, but he would at least be in a better position to judge than using existence inference? Let's get what we have already got implemented correctly before adding new features that do more or less the same thing. Already got what? -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Mechanism to find available events
On 5/1/11, Charles McCathieNevile cha...@opera.com wrote: Unsupported, uninformed opinion and red herrings. On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/29/11, Ian Hickson i...@hixie.ch wrote: [...] We need a mechanism to detect accurately the features of the browser our code's running in, without relying to UA sniffing madness. No such mechanism can exist without actually using the feature, because there's no way to guarantee that a browser will accurately report what it supports. Every time we've had such a feature (e.g. DOM hasFeature()) vendors have ended up returning inaccurate values. Is it possible to design something better than hasFeature? Method hasFeature can be expected to have the problems it has because it is not related to any specific object (Node, window, document). As such, this method requires the implementation (browser) to make an unreasonable generalization. Requiring the unreasonable is unreasonable. True, but I think there is a deeper problem. Browsers need to be roughly compatible with sites. From a user perspective, that means it more or less works while from a site developer's perspective that often means it works exactly as I designed it. This puts the browser and the site author in direct conflict, and while the site developer might feel that the user is being unfairly hampered if the browser doesn't perform as desired torender the site to its best advantage, the browser feels the user is unfairly served if they are being told to go through the hassle of changing browsers because of some trivial difference in rendering or performance. Red herring. Subject is: Re: [whatwg] Mechanism to find available events So we can make all the technical improvements we want. But so long as there is a conflict in goals for how to use a feature, as there often is with hasFeature(), it is extremely unlikely that we can make that feature work in a way that satisfies everyone. Nobody proposed improving hasFeature. I have said many times that the feature can't be expected to work; it's broken by design. If instead, there were a method designed to check the object in question, it could be specified to require the implementation also check that object's capabilities. I'm not suggesting unequivocal (e.g. right click triggers a context menu) -- that seems too much. I'm suggesting a more closely related inference check. Is a mechanism such as this possible? Why rule it out? It is possible, but it isn't clear that it will work as you anticipate, What it? Nevermind, I probably shouldn't ask. and reasonably likely that it won't for the same non-technical reasons hasFeature() doesn't. Improving (or replacing) hasFeature isn't an intrinsically bad idea, but it isn't useful without working out how to resolve those non-technical issues. The mobile world (whose UA-sniffing requirements make the one-Web goal on Desktop look like a solid reliable reality where developers' lives are trouble-free and pleasant) has an alternative solution that is based around crowd-sourcing the information on whether something is supported. It *is* UA-sniffing madness by most definitions, and it relies on huge amounts of data and a system for managing conflicting statements via simple trust modelling (it theoretically offers massive scope for abuse that permits direct market manipulation), but it has worked well enough for them that it is extremely widely used, and the approach has been repeated, merely making technical refinements, over successive generations of the technology. Oh boy ,here we go... When if ever is browser sniffing a requirement? It is (euphamistically speaking) technological solution. The discussion of why it is an awful solution to the too many browsers problem is off topic. Yep, this is another red herring. It's so outlandish that it almost appears as trolling or flame bait. But again, we can forget all about that. Going down that path of course doesn't allow you to do the work client-side, which is also a problem for the use-case you're looking at. But in an area where I mostly see bad alternatives, it is another option that could be the lesser of the available evils in some circumstances. You're imagining something here. cheers You have sidetracked the discussion. -- Garrett
[whatwg] Proposal to change getContext to support unavailable context at run-time.
Hello group, For WebGL, we need getContext to possibly fail whereas the browser supports contextId webgl. Indeed it is possible the browser fails creating a new 3D context for many different reasons at run-time, which means a given contextId might not be available at any given time. This is in relation to [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-getcontext We are investigating two options : Option #1 - modify getContext specified context creation steps so that null can be returned at a later stage than step 3. In a nutshell, allow the contextId specification to fail new context initialization, reorder setting primary context only after the new context object has been successfully initialized. For this option (which is the current behavior of WebGL 1.0 spec), I'd like to propose [1]'s steps 4 to 6 to be replaced with : 4. If the getContext() method has already been invoked on this element for the same contextId, return the same object as was returned that time, and abort these steps. The additional arguments are ignored. [! this was step 5] 5. Attempt to create a new context object, as defined by the specification given for contextId's entry in the WHATWG Wiki CanvasContexts page. [WHATWGWIKI] 6. If the new context object could not be initialized successfully, return null and abort these steps. 7. If the element does not have a primary context, let the element's primary context be contextId. [! this was step 4] 8. Return the new context object. Option #2 - allow getContext to throw an exception. We still need the modification of the spec as above, with step 6 as : 6. If the new context object could not be initialized successfully, throw an exception and abort these steps. We'd probably also need to specify the kind of exception object to be thrown. Regards,
