Re: New Progress draft (1.25)...

[Garrett Smith]

On Thu, Oct 23, 2008 at 6:38 AM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
>
> Garrett Smith wrote:
>>
>> On Tue, Oct 21, 2008 at 5:32 PM, Garrett Smith <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Tue, Oct 21, 2008 at 3:27 AM, Charles McCathieNevile
>>> <[EMAIL PROTECTED]> wrote:


 http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24

 Hopefully this draft is ready for last call. So please have a look
 through
>>>
>>> It was agreed that loadend should fire prior to abort | error | load.
>
> I do remember that we talked about it that way, and also talked about having
> the default action of the loadend event be to fire the appropriate
> abort/error/load event.
>
> However I'm not sure why that way is better? I.e. why would you want to
> prevent abort/error/load from firing?
>

I can't imagine why anyone would would do that. Seems like a red herring.

The goal is to know when a request has completed, to remove the
"loading state indicator" (e.g. progress bar, busy icon, overlay).
That is loadend's raison d'être, as I see it, and that is the exact
reason I proposed this to "Chaals" over a year ago (it is in the
archives).

If loadend fires after "load | abort | error", the "loading state
indicator" would be removed after that. I think that is less
desirable. We could have it one of two ways:

Garrett's way:
"I'm done" then "here's your data."

Chaals' way:
"here's your data" then "I'm done."

Garrett

>
> / Jonas
>
>

Re: New Progress draft (1.25)...

[Garrett Smith]

On Thu, Oct 23, 2008 at 7:01 AM, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
>
> On Thu, 23 Oct 2008 15:38:45 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:

>> I do like the symmetry in the current proposal where loadstart is the
>> first thing that fires, and loadend is the last thing. Seems very intuitive.
>
> I agree that dispatching loadend last makes sense.
>

Other than "liking the symmetry" can you provide a reason for why it
"makes sense"?

Garrett

>
> --
> Anne van Kesteren
> 
> 
>
>

Re: New Progress draft (1.25)...

[Anne van Kesteren]

On Thu, 23 Oct 2008 15:38:45 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
I do remember that we talked about it that way, and also talked about  
having the default action of the loadend event be to fire the  
appropriate abort/error/load event.


However I'm not sure why that way is better? I.e. why would you want to  
prevent abort/error/load from firing?


I do like the symmetry in the current proposal where loadstart is the  
first thing that fires, and loadend is the last thing. Seems very  
intuitive.


I agree that dispatching loadend last makes sense.


--
Anne van Kesteren

Re: New Progress draft (1.25)...

[Jonas Sicking]

Garrett Smith wrote:

On Tue, Oct 21, 2008 at 5:32 PM, Garrett Smith <[EMAIL PROTECTED]> wrote:

On Tue, Oct 21, 2008 at 3:27 AM, Charles McCathieNevile
<[EMAIL PROTECTED]> wrote:

http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24

Hopefully this draft is ready for last call. So please have a look through

It was agreed that loadend should fire prior to abort | error | load.


I do remember that we talked about it that way, and also talked about 
having the default action of the loadend event be to fire the 
appropriate abort/error/load event.


However I'm not sure why that way is better? I.e. why would you want to 
prevent abort/error/load from firing?


I do like the symmetry in the current proposal where loadstart is the 
first thing that fires, and loadend is the last thing. Seems very intuitive.


/ Jonas

[widgets] Widget locale

[Kapyaho Jere (Nokia-TP-MSW/Tampere)]

The definition of 'widget locale' is currently not in sync in the 'Widgets
1.0: Packaging and Configuration' [1] and 'Widget 1.0: APIs and Events' [2]
specs. The locale issue has been mentioned earlier by Addison Phillips
(comment #16 in [3]) and fixed, but I just noticed that the APIs spec
mentions ISO 639-2 codes, and not BCP 47 tags.

The question also remains how the widget engine reports the system locale to
the widget as a BCP 47 language tag, if the engine itself is implemented on
a platform that uses a different locale identification mechanism (which is
highly likely). In that case some mapping is inevitable, and even though
this is most likely implementation dependent, maybe a mention to that effect
would be useful. 

--Jere

[1] http://dev.w3.org/2006/waf/widgets/#widget13
[2] http://dev.w3.org/2006/waf/widgets-api/#members
[3] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0129.html

Re: ISSUE-77 (XHR2+loadend): XMLHttpRequestEventTarget should have attribute EventListener onloadend [XHR2]

[Anne van Kesteren]

On Thu, 23 Oct 2008 13:21:37 +0200, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:
On Thu, 23 Oct 2008 13:13:33 +0200, Web Applications Working Group Issue  
Tracker <[EMAIL PROTECTED]> wrote:

XHR2/upload should probably have onloadend attribute.
The spec should also mention when to dispatch loadend (maybe it is  
enough to refer to Progress Events spec)


What is the use case for loadend?


Oh, I think I get it now. It always dispatches whether or not things  
actually succeeded. Yeah, we should integrate that.



--
Anne van Kesteren

Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec

[Anne van Kesteren]

On Thu, 23 Oct 2008 12:59:58 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:

Would you be against making it a v1 spec in and of itself?


This e-mail thread is quite confusing.

From what I gathered during the Web Apps F2F this week people were not ok  
with not having some kind "blob" API. The ability to split up a large file  
in a number of smaller files so you can e.g. resume upload if something  
goes wrong from a particular point was important.


Everyone was ok with having access to the file data be asynchronous as far  
as I could tell.



--
Anne van Kesteren

Re: ISSUE-77 (XHR2+loadend): XMLHttpRequestEventTarget should have attribute EventListener onloadend [XHR2]

[Anne van Kesteren]

On Thu, 23 Oct 2008 13:13:33 +0200, Web Applications Working Group Issue  
Tracker <[EMAIL PROTECTED]> wrote:
ISSUE-77 (XHR2+loadend): XMLHttpRequestEventTarget should have attribute  
EventListener onloadend [XHR2]


http://www.w3.org/2008/webapps/track/issues/77

Raised by: Olli Pettay
On product: XHR2

XHR2/upload should probably have onloadend attribute.
The spec should also mention when to dispatch loadend (maybe it is  
enough to refer to Progress Events spec)


What is the use case for loadend?


--
Anne van Kesteren

ISSUE-77 (XHR2+loadend): XMLHttpRequestEventTarget should have attribute EventListener onloadend [XHR2]

[Web Applications Working Group Issue Tracker]

ISSUE-77 (XHR2+loadend): XMLHttpRequestEventTarget should have attribute 
EventListener onloadend [XHR2]

http://www.w3.org/2008/webapps/track/issues/77

Raised by: Olli Pettay
On product: XHR2

XHR2/upload should probably have onloadend attribute.
The spec should also mention when to dispatch loadend (maybe it is enough to 
refer to Progress Events spec)

Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec

[Maciej Stachowiak]

On Oct 17, 2008, at 11:46 AM, Arun Ranganathan wrote:


All,

Maceij wrote:



[1] http://lists.w3.org/Archives/Member/member-webapps/2008OctDec/0010.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0047.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0387.html


Were you referring to [3] above? I didn't actually realize that  
Apple

was proposing that as a v1 for the FileUpload spec. Apologies for
that, it was certainly not intended to be ignored.


Yes, [3] was our intended proposal for v1 of the file upload spec.  
I don't recall hearing any objection to publishing that as v1.


Arun did not ever respond to that email thread, and your only  
comment was "This sounds like a great idea to me."


1. Again, I apologize for embarking on a direction that wasn't what  
Apple envisioned, but your intention to make [3] above a "v1" in  
lieu of the a more expansive spec. wasn't clear to me.  Also, I  
didn't respond to the thread because Jonas' post affirming that it  
"... sounds like a great idea..." was sufficient.  Thus, I took the  
proposal as a key component in a more expansive spec., but not as a  
v1 spec. in and of itself.


Would you be against making it a v1 spec in and of itself?

Regards,
Maciej

RE: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Chris Wilson]

Paul Libbrecht wrote:
> Yesterday, discussion with Chris Wilson and Adrian Bateman, of MSIE
> team, revealed that allowing arbitrary flavours would be a big
> security hole for Windows at least (I believe this is Windows only but
> can't confirm yet).

I wouldn't call it a security hole as much as I would call it "unbounded attack 
surface area".  :)  At any rate, it would be surface area for any OS that 
allowed arbitrary types on the clipboard; this isn't a Windows implementation 
issue.

> A safer approach may be to require that the browsers make sure the
> things sipped into the clipboard/drag-content are only safe things.

That's the rub of my feedback, yes.

-Chris

Re: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Ian Hickson]

On Thu, 23 Oct 2008, Paul Libbrecht wrote:
> 
> Can you please respond to my request "how to implement other flavour 
> names"?

The getData() and setData() functions take arbitrary MIME types; does that 
cover it?


> Also, I would like to see test-cases and reports for the implementations 
> you indicate here.

Yes, that would be good. Implementors? Are there test cases for this 
section?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Paul Libbrecht]

(cross-posting to member-math and public-webapps, sorry if this bothers)

Interesting, meeting really helped,

Yesterday, discussion with Chris Wilson and Adrian Bateman, of MSIE  
team, revealed that allowing arbitrary flavours would be a big  
security hole for Windows at least (I believe this is Windows only but  
can't confirm yet).


So it seems the list of safe encodings is something that would need to  
be worked out.
A safer approach may be to require that the browsers make sure the  
things sipped into the clipboard/drag-content are only safe things.


Safe things include html without scripts, all picture formats  
(postscript as well?)  and most media, but not html with scripts, not  
windows metafiles, not OLE or MS-office documents.


Adrian indicated method to convert html to safe-html seem to be there  
in MSIE 8 already. Sanitization is probably the right term here.


paul


Le 22-oct.-08 à 17:02, Ian Hickson a écrit :


On Wed, 22 Oct 2008, Charles McCathieNevile wrote:


Sorry, I missed this - I was otherwise occupied at lunch (I am here,
BTW).

Having hopefully pretty much shifted Progress Events off my plate, I
hope to move back to the clipboard API stuff now - and the HTML5  
draft

is indeed an important reference...

Ian, how stable do you think this bit of the HTML5 spec is? (I  
haven't

looked yet...)


Drag and drop is very stable, it's implemented in three browsers now.
There's some outstanding feedback, but not much. The implementation of
copy and paste in terms of drag and drop (a design motivated  
primarily by
accessibility and security concerns) is not widely implemented,  
though I

have no pending feedback regarding changes to that.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'




smime.p7s
Description: S/MIME cryptographic signature

Re: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Paul Libbrecht]

Ian,

Can you please respond to my request "how to implement other flavour  
names"?


Also, I would like to see test-cases and reports for the  
implementations you indicate here.


paul




Le 22-oct.-08 à 17:02, Ian Hickson a écrit :

On Wed, 22 Oct 2008, Charles McCathieNevile wrote:
Ian, how stable do you think this bit of the HTML5 spec is? (I  
haven't

looked yet...)


Drag and drop is very stable, it's implemented in three browsers now.
There's some outstanding feedback, but not much. The implementation of
copy and paste in terms of drag and drop (a design motivated  
primarily by
accessibility and security concerns) is not widely implemented,  
though I

have no pending feedback regarding changes to that.




smime.p7s
Description: S/MIME cryptographic signature