headers
Simon Heckmann | 1 May 2011 16:49
Picon

Re: 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 <glenn@...> wrote:
> 
>> On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan <robert@...>
>> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Göran Eriksson AP | 1 May 2011 18:31
Picon
Favicon

Re: 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" <simon@...> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Boris Zbarsky | 1 May 2011 18:56
Picon
Favicon

Re: "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
Permalink | Reply | 1 comment |
headers
Michal Zalewski | 1 May 2011 19:02
Gravatar

Re: "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
Permalink | Reply | 0 comments |
headers
Simon Heckmann | 1 May 2011 19:05
Picon

Re: Proposal for a web application descriptor

Well, the API should work in both cases, I guess. On mobile devices the UI design would be more challenging,
but the idea is the same. If desired I could also design mock-ups for phones.

Am 01.05.2011 um 18:31 schrieb Göran Eriksson AP <goran.ap.eriksson <at> ericsson.com>:

> 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" <simon@...> 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
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Göran Eriksson AP | 1 May 2011 21:17
Picon
Favicon

Re: Proposal for a web application descriptor

I think making mock-ups would be great- it will make it easier to check
the UX behavior in such context, where as always the user attention and
the handling of the device is slightly different.

Mock-ups will make it easier to also make the design similar- or rather
recognizable- between usage contexts, which i think is a desired feature
of the solution.

And the API should be the same, I agree.

---Göran

On 2011-05-01 19.05, "Simon Heckmann" <simon@...> wrote:

>Well, the API should work in both cases, I guess. On mobile devices the
>UI design would be more challenging, but the idea is the same. If desired
>I could also design mock-ups for phones.
>
>Am 01.05.2011 um 18:31 schrieb Göran Eriksson AP
><goran.ap.eriksson@...>:
>
>> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles McCathieNevile | 1 May 2011 22:29
Picon
Favicon

Re: Mechanism to find available events

On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith <dhtmlkitchen@...m>  
wrote:

> On 4/29/11, Ian Hickson <ian@...> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hallvord R M Steen | 2 May 2011 03:14
Picon

questions regarding submit event timing

Some questions related to possibly clarifying this section:
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit

1) What methods exactly cause the "scripted submit" flag to be set?
It's obviously set if you call form.submit(), but will it be set in
these two cases:

HTML: <form><input type="submit"></form>
JS: form.elements[0].click()

or
HTML: <form><input type="submit"></form>
JS: form.elements[0].dispatchEvent( evt ) /* where evt is a 'click'
event object  */

I believe the answer should be yes in both cases but I'm not sure if
it's clear from the spec.

2) Is the event fired synchronously? (And is it fired synchronously
for all three cases of scripted submits mentioned above?)
Again, I think the answer is yes but I couldn't find this information
in the spec when looking for it.

--

-- 
Hallvord R. M. Steen
Permalink | Reply | 6 comments |
headers
Garrett Smith | 2 May 2011 07:40
Picon
Gravatar

Re: Mechanism to find available events

On 5/1/11, Charles McCathieNevile <chaals@...> wrote:
Unsupported, uninformed opinion and red herrings.

> On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith <dhtmlkitchen@...>
> wrote:
>
>> On 4/29/11, Ian Hickson <ian@...> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cedric Vivier | 2 May 2011 07:50

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane