date:20091020

On Tue, 20 Oct 2009 02:10:43 +0200, Charles McCathieNevile  
cha...@opera.com wrote:
On Mon, 19 Oct 2009 20:13:23 +0200, Anne van Kesteren ann...@opera.com  
wrote:
If only a subset of the attributes ends up being used, i.e. appcache is  
not going to dispatch progress events more often than one per file, I  
do not think this feature is worth it to be honest. Because for  
appcache total and loaded would always be 0 and for XMLHttpRequest  
totalItems and loadedITems would always be 0.


Quite true. The hypothesis is that appcache may end up dealing with  
files where progress events *are* disaptched more than once per file,  
for example collecting a cache which has a 1MB video over a slow line.


I suppose, but the specification would have to change first.



Are there any other cases worth considering?


The other use case [1] that motivated this was a mail client downloading  
a number of distinct emails as objects, where some of them could be very  
large.


My assumption is that these are real use cases, which is why I made the  
proposal (and bothered doing the thinking to try and spec it out). It's  
up to the group to decide, of course.


[1] http://www.w3.org/mid/op.u0xi82ucwxe...@widsith.eng.oslo.osa


The problem with this use case is that it does not map to any API. If you  
would implement this the fetching of emails might happen over  
XMLHttpRequest in which case there would only be one object at a time.  
Other than appcache there is no API that I know of that downloads multiple  
separate objects of which the total is sort of known in advance.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Proposal for sending multiple files via XMLHttpRequest.send()

On Tue, 20 Oct 2009 08:55:21 +0200, Darin Fisher da...@chromium.org  
wrote:

I'd like to revive the Proposal for sending multiple files via
XMLHttpRequest.send() thread
started by Jian Li back in September.

As pointed out on that thread, sending a JS array of strings and File
references isn't going
to fly due to an array of strings already having meaning.

That thread concluded with Jonas Sicking saying:


I definitely think that we need to add some way of sending a stream
that is a concatenation of strings, binary data, and files, without
requiring the files to be read.


What should this look like?  Should there be a new global constructor  
for an

object that supports methods like appendText and appendFile?  Like this:

var data = new UploadData;
data.appendText(foo);
data.appendFile(fileRef);
xhr.send(data);

I like the idea of creating a primitive that does not enforce any  
encoding.


Thoughts?


I think for a lot of authors the easiest would be easiest if it was in the  
form of multipart/form-data as then they do not have to do anything  
special to get the data on the server.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Proposal for sending multiple files via XMLHttpRequest.send()

2009-10-20 Thread Darin Fisher

On Tue, Oct 20, 2009 at 1:37 AM, Anne van Kesteren ann...@opera.com wrote:

 On Tue, 20 Oct 2009 08:55:21 +0200, Darin Fisher da...@chromium.org
 wrote:

 I'd like to revive the Proposal for sending multiple files via
 XMLHttpRequest.send() thread
 started by Jian Li back in September.

 As pointed out on that thread, sending a JS array of strings and File
 references isn't going
 to fly due to an array of strings already having meaning.

 That thread concluded with Jonas Sicking saying:

  I definitely think that we need to add some way of sending a stream
 that is a concatenation of strings, binary data, and files, without
 requiring the files to be read.


 What should this look like?  Should there be a new global constructor for
 an
 object that supports methods like appendText and appendFile?  Like this:

 var data = new UploadData;
 data.appendText(foo);
 data.appendFile(fileRef);
 xhr.send(data);

 I like the idea of creating a primitive that does not enforce any
 encoding.

 Thoughts?


 I think for a lot of authors the easiest would be easiest if it was in the
 form of multipart/form-data as then they do not have to do anything special
 to get the data on the server.



That does address the primary use case, but do you really think that we
should rule out the use case of custom encodings?

(At least for Gecko and WebKit, it is really trivial to support the more
free-form interface since the underlying network layers speak in terms of a
list of strings and file references.)

If we do go the more specific route, then it could look like this:

var data = new FormData;
data.appendText(name1, value);
data.appendFile(name2, fileData);
xhr.send(data);

The UA could populate the filename attribute of the Content-Disposition
header based on the given fileRef.  Same goes for the Content-Type header.

Hmm... this may indeed be a good way to go since I don't think the proposed
FileData (
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileData-if)
interface includes a name attribute.

-Darin




 --
 Anne van Kesteren
 http://annevankesteren.nl/

Re: Use cases (appcache, etc) [progress]


On Tue, 20 Oct 2009 10:26:08 +0200, Anne van Kesteren ann...@opera.com
wrote:

On Tue, 20 Oct 2009 02:10:43 +0200, Charles McCathieNevile  
cha...@opera.com wrote:
On Mon, 19 Oct 2009 20:13:23 +0200, Anne van Kesteren  
ann...@opera.com wrote:
If only a subset of the attributes ends up being used, i.e. appcache  
is not going to dispatch progress events more often than one per file,  
I do not think this feature is worth it to be honest. Because for  
appcache total and loaded would always be 0 and for XMLHttpRequest  
totalItems and loadedITems would always be 0.


Quite true. The hypothesis is that appcache may end up dealing with  
files where progress events *are* disaptched more than once per file,  
for example collecting a cache which has a 1MB video over a slow line.


I suppose, but the specification would have to change first.


Or someone could just implement this (since it is foreshadowed as a
possibility) and then suggest the spec change. That happens quite a lot,
and is one of the reasons for coordinating loosely coupled but seperate
specs.


Are there any other cases worth considering?


The other use case [1] that motivated this was a mail client  
downloading a number of distinct emails as objects, where some of them  
could be very large.


My assumption is that these are real use cases, which is why I made the  
proposal (and bothered doing the thinking to try and spec it out). It's  
up to the group to decide, of course.


[1] http://www.w3.org/mid/op.u0xi82ucwxe...@widsith.eng.oslo.osa


The problem with this use case is that it does not map to any API. If  
you would implement this the fetching of emails might happen over  
XMLHttpRequest in which case there would only be one object at a time.


Sure. But note today's request [1] for allowing XHR to shift a collection
of objects. The current pattern of having to zip up a bunch of things, or
make multiple XHR transfers, works. But in some cases it is frustrating.

Other than appcache there is no API that I know of that downloads  
multiple separate objects of which the total is sort of known in advance.


No, I don't know of an API today that does this either, although I know of
various use cases. My proposal assumes that these use cases will lead to
such an API. Disambiguating the appcache case from the XHR case now allows
for such an API to use the spec as is, while in practice implementations
may or may not do something with the full possibility before such APIs are
specified.

You are quite right that this is sailing close to the inventing
technology in a standards group wind. It makes me a little nervous. But I
don't think it is completely inventing it - the disambiguation is based on
real cases. It raises the issues of how the interaction works, which Ian
asked about and at least Simon found obvious enough from my half-baked
preliminary explanation to explain quite quickly. It also raises the
question of what events fire per-object and what fire for the whole
transaction (ISSUE-107) which is directly relevant to appcache anyway -
i.e. is just a question of making sure that the disambiguation is done
cleanly without forgetting any obvious potential clash.

I should be clear that I haven't yet checked closely with the guys at
Opera who would implement this whether they think it makes sense - and I
may yet withdraw the proposal on the grounds that it is just too complex.
But it seems to me worthwhile investing a bit of my time to make them (and
everyone else) a proposal that is sufficiently fleshed out for them to at
least make that judgement.

[1]  
http://www.w3.org/mid/bd8f24d20910192355p4fe48531n965c0198039af...@mail.gmail.com


cheers

Chaals

--
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

[Widgets] Compatibility Matrix for Packaging and Configuration

2009-10-20 Thread Marcos Caceres

Just wanted to let people know about the Widgets Compatibility Matrix 
for Packaging and Configuration that our Invited Experts, Samuel Santos 
and Daniel Silva from Present Technologies, and myself, are 
collaborating on.


See:

http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html

The compatibility matrix, which we will soon move over to the W3C site, 
currently compares UAs from Opera, Microsoft, RIM, Samsung, LG, BONDI, 
and Apache.


If you are implementing and want to be included in the testing, please 
let us know and we will work with you to get your test results included.


The purpose is to create an official record of implementation support, 
which we will then use for:


1. Identifying any superfluous features (part of CR) and weeding them 
out if need be.


2. progressing the specs to PR - Two implementations must pass every 
test in the test suite for us to progress the spec.


It is our intention to have the Working Group publish the results as a 
Working Group Note.


If you are an implementer, we need your help as there are many aspects 
which we simply cannot test manually on currently available UAs.


Kind regards,
Marcos

Re: Use cases (appcache, etc) [progress]

On Tue, 20 Oct 2009 11:34:16 +0200, Charles McCathieNevile  
cha...@opera.com wrote:

On Tue, 20 Oct 2009 10:26:08 +0200, Anne van Kesteren ann...@opera.com
wrote:
The problem with this use case is that it does not map to any API. If  
you would implement this the fetching of emails might happen over  
XMLHttpRequest in which case there would only be one object at a time.


Sure. But note today's request [1] for allowing XHR to shift a collection
of objects. The current pattern of having to zip up a bunch of things, or
make multiple XHR transfers, works. But in some cases it is frustrating.


Actually that request would not change anything. As far as XMLHttpRequest  
goes it would still transfer only a single entity.



Other than appcache there is no API that I know of that downloads  
multiple separate objects of which the total is sort of known in  
advance.


No, I don't know of an API today that does this either, although I know  
of various use cases. My proposal assumes that these use cases will lead  
to
such an API. Disambiguating the appcache case from the XHR case now  
allows for such an API to use the spec as is, while in practice  
implementations
may or may not do something with the full possibility before such APIs  
are specified.


I do think it would make sense for appcache to have a progress event that  
is dispatched more often that once for every file and in that case the  
additional members would be of some use, though I'm not sure it makes  
sense to have two meaningless members whenever XMLHttpRequest dispatches a  
progress event. Should there be two interfaces, one inheriting from the  
other?




You are quite right that this is sailing close to the inventing
technology in a standards group wind. It makes me a little nervous. But  
I don't think it is completely inventing it - the disambiguation is  
based on real cases. It raises the issues of how the interaction works,  
which Ian

asked about and at least Simon found obvious enough from my half-baked
preliminary explanation to explain quite quickly. It also raises the
question of what events fire per-object and what fire for the whole
transaction (ISSUE-107) which is directly relevant to appcache anyway -
i.e. is just a question of making sure that the disambiguation is done
cleanly without forgetting any obvious potential clash.


I still agree with Ian that the progress event specification should not  
define at all which events are to be dispatched. It should give some  
guidance for event names, define the interface, and leave all the other  
normative details to other specifications.




I should be clear that I haven't yet checked closely with the guys at
Opera who would implement this whether they think it makes sense - and I
may yet withdraw the proposal on the grounds that it is just too complex.
But it seems to me worthwhile investing a bit of my time to make them  
(and everyone else) a proposal that is sufficiently fleshed out for them  
to at

least make that judgement.

[1]  
http://www.w3.org/mid/bd8f24d20910192355p4fe48531n965c0198039af...@mail.gmail.com



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Proposal for sending multiple files via XMLHttpRequest.send()

On Tue, 20 Oct 2009 10:56:47 +0200, Darin Fisher da...@chromium.org  
wrote:
On Tue, Oct 20, 2009 at 1:37 AM, Anne van Kesteren ann...@opera.com  
wrote:
I think for a lot of authors the easiest would be easiest if it was in  
the form of multipart/form-data as then they do not have to do anything  
special to get the data on the server.


That does address the primary use case, but do you really think that we
should rule out the use case of custom encodings?

(At least for Gecko and WebKit, it is really trivial to support the more
free-form interface since the underlying network layers speak in terms  
of a list of strings and file references.)


I do not want to rule anything out, but a request I repeatedly hear is  
duplicating form functionality with XMLHttpRequest. Support for  
multipart/form-data furthermore is extremely widespread and resembles  
quite closely what is desired so it seems good to use it.


If eventually we get native support for octet-arrays and all we can at  
that point add the ability to XMLHttpRequest so you can send anything you  
want.




If we do go the more specific route, then it could look like this:

var data = new FormData;
data.appendText(name1, value);
data.appendFile(name2, fileData);
xhr.send(data);

The UA could populate the filename attribute of the Content-Disposition
header based on the given fileRef.  Same goes for the Content-Type  
header.


Hmm... this may indeed be a good way to go since I don't think the  
proposed

FileData (
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileData-if)
interface includes a name attribute.


This looks reasonable to me.


I suppose we also want support passing File[Data] and FileList directly as  
I believe WebKit might have already added. Do you happen to know the  
implementation details?



(I'm planning to wait with defining this until at least after TPAC. I  
expect more discussion to happen there and I also want to keep focus on  
the CSSOM before switching tasks again. It would be good to have most of  
the details before than though.)



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Proposal for sending multiple files via XMLHttpRequest.send()

On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher da...@chromium.org  
wrote:
On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren ann...@opera.com  
wrote:
If eventually we get native support for octet-arrays and all we can at  
that point add the ability to XMLHttpRequest so you can send anything  
you want.


Hmm, OK


If you envision things differently, by all means say so :-)



 If we do go the more specific route, then it could look like this:


var data = new FormData;
data.appendText(name1, value);
data.appendFile(name2, fileData);
xhr.send(data);

The UA could populate the filename attribute of the Content-Disposition
header based on the given fileRef.  Same goes for the Content-Type  
header.


Hmm... this may indeed be a good way to go since I don't think the
proposed
FileData (
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileData-if
)
interface includes a name attribute.



This looks reasonable to me.


I suppose we also want support passing File[Data] and FileList directly  
as I believe WebKit might have already added. Do you happen to know the

implementation details?


WebKit presently supports sending File.  It does not support FileData  
yet.


Is Content-Type set to anything specific if the author has not set it? I  
assume what is being transferred is the file data, octet-for-octet, as it  
is represented on the disk? Does it make a straight copy of the file or  
can modifying the file cause potential problems?




I'm not sure about supporting FileList.  If it were to be encoded using
multipart/form-data, then how would the form field names be chosen?   
Would they just be excluded from the encoding?


If we have something like the FormData type proposed above, then we  
wouldn't need to support sending a FileList.  People could just iterate  
a FileList

and call appendFile for each element of the FileList.


True.



(I'm planning to wait with defining this until at least after TPAC. I
expect more discussion to happen there and I also want to keep focus on  
the CSSOM before switching tasks again. It would be good to have most  
of the

details before than though.)


OK

I'm interested in having a WebKit implementation for this soon.


After TPAC means the week of November 9. Does that work?


Meanwhile my basic idea based on your proposal is:

  [Constructor] interface FormData {
void append(DOMString name, DOMString value);
void append(DOMString name, FileData value);
  }

Then when send() is invoked with a FormData object I assume the easiest  
would be to make a copy of the object serialize it per the rules of RFC  
2388 (encoding DOMString values as UTF-8) and done.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Use cases (appcache, etc) [progress]

On Tue, 20 Oct 2009 13:14:00 +0200, Anne van Kesteren ann...@opera.com  
wrote:


On Tue, 20 Oct 2009 11:34:16 +0200, Charles McCathieNevile  
cha...@opera.com wrote:

On Tue, 20 Oct 2009 10:26:08 +0200, Anne van Kesteren ann...@opera.com
wrote:
The problem with this use case is that it does not map to any API. If  
you would implement this the fetching of emails might happen over  
XMLHttpRequest in which case there would only be one object at a time.


Sure. But note today's request [1] for allowing XHR to shift a  
collection of objects...


Actually that request would not change anything. As far as  
XMLHttpRequest goes it would still transfer only a single entity.


In the sense that it is a single transaction, sure. But conceptually it is  
transferring something known to be divisible into a set of entities  
(that's the point of the request :) ).


...
I do think it would make sense for appcache to have a progress event  
that is dispatched more often that once for every file and in that case  
the additional members would be of some use, though I'm not sure it  
makes sense to have two meaningless members whenever XMLHttpRequest  
dispatches a progress event. Should there be two interfaces, one  
inheriting from the other?


Yes, I had sort of half thought that through (the constructor half) in  
today's draft. But it probably does make sense, and should also make  
people who have implemented something like the old version happier.



You are quite right that this is sailing close to the inventing
technology in a standards group wind. It makes me a little nervous.  
But I don't think it is completely inventing it - the disambiguation is  
based on real cases. It raises the issues of how the interaction works,  
which Ian asked about and at least Simon found obvious enough from my

half-baked preliminary explanation to explain quite quickly. It also
raises the question of what events fire per-object and what fire for
the whole transaction (ISSUE-107) which is directly relevant to
appcache anyway - i.e. is just a question of making sure that the
disambiguation is done cleanly without forgetting any obvious potential
clash.


I still agree with Ian that the progress event specification should not  
define at all which events are to be dispatched. It should give some  
guidance for event names, define the interface, and leave all the other  
normative details to other specifications.


Yeah, I am sort of coming to that view. I still think it is useful for the  
spec to give guidance about normal usage, and for other specs to follow  
common patterns, so authors don't have to learn a different and  
conflicting kind of magic for each API that uses progress events. IMHO  
that's one of the major reasons for having the spec in the first place.


cheers

Chaals

--
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: Proposal for sending multiple files via XMLHttpRequest.send()

On Tue, 20 Oct 2009 18:47:59 +0200, Anne van Kesteren ann...@opera.com  
wrote:


On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher da...@chromium.org  
wrote:
On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren ann...@opera.com  
wrote:
If eventually we get native support for octet-arrays and all we can at  
that point add the ability to XMLHttpRequest so you can send anything  
you want.


Hmm, OK


If you envision things differently, by all means say so :-)


So, I envision things a bit differently from Anne (as he and I have  
discussed in relation to Progress events).



 If we do go the more specific route, then it could look like this:


var data = new FormData;
data.appendText(name1, value);
data.appendFile(name2, fileData);
xhr.send(data);

The UA could populate the filename attribute of the  
Content-Disposition
header based on the given fileRef.  Same goes for the Content-Type  
header.

...

My rough idea is that you have a set of things being sent, as per  
appcache. You collect them somehow (I have no particular opinion on  
formdata or something else), and send them, as transaction that sends a  
bunch of objects.


The thinking behind adding loadedItems and totalItems to progress events  
(as Anne says, maybe having the existing simple interface and a longer one  
that inherits and adds the extra attributes is a good idea) was that you  
could then provide progress information both on a what object has gone  
basis, and how much of this object has gone.


The way I came up with effectively supposes an array of items, and the  
loadedItems (where present) acts as an index to the array. A natural  
consequence of this is that if somehow you are sending the objects out of  
order, you still give progress information on a per-object basis. (This  
wasn't actually a goal, it just happens that way).


The point of ISSUE-107 was that I envisaged sending a load event for each  
object (as currently written appcache sends a progress event) when it is  
loaded, with a single loadstart and a single loadend for the entire  
transaction. Optionally, you can send a progress event where part of an  
object has been transmitted. Obviously this is a change to appcache -  
albeit I believe a relatively small one, substituting the current events  
sent for slightly different ones. In principle you would add the size of  
the object, as the loaded attribute of the load event sent, but in  
practice that's probably not necessary (note to self - the spec doesn't  
say what you put. Maybe it should allow a dummy value, but maybe not...).


A consequence of this model is that when you get the events you can find  
out which things got shifted, and decide whether to go back and try again  
if something dropped. I have repeatedly seen, because it takes nothing  
more than looking, pages come through apparently missing an icon or  
something which doesn't matter, in which case it would be useful if the  
app started working and just tried to refetch the missing icon in the  
background. If some critical script is missing, you need to go back and  
get it. As Anne says, this is potentially more complicated - but nothing  
obliges you to use it. If you get any error or abort instead of a load you  
can simply insist on reloading until you have everything. But it seems to  
me this provides authors with the ability to write applications that are  
more robust on flaky networks (or dealing with flaky servers), if they  
choose to do so.


As far as I can tell it would be feasible to implement this without  
changing Anne's proposal. At the same time, this would allow for other  
APIs (appcache5, or fetchMail, or whatever) to use progress events more or  
less as they are in the new editor's draft [1]. However, this week I will  
talk to the implementors at Opera and see what they think - and I hope  
also to get feedback from Hixie on this.


[1]  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32


thoughts?

cheers

Chaals

--
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: Use cases (appcache, etc) [progress]

On Tue, 20 Oct 2009 20:00:27 +0200, Charles McCathieNevile  
cha...@opera.com wrote:
On Tue, 20 Oct 2009 13:14:00 +0200, Anne van Kesteren ann...@opera.com  
wrote:
Actually that request would not change anything. As far as  
XMLHttpRequest goes it would still transfer only a single entity.


In the sense that it is a single transaction, sure. But conceptually it  
is transferring something known to be divisible into a set of entities  
(that's the point of the request :) ).


Most things are divisible into a set of entities. Fact remains that we're  
dealing with a single entity body here as far as HTTP is concerned and  
that progress events are supposed to deal with entity bodies. Changing  
that for FormData does not make sense.



I still agree with Ian that the progress event specification should not  
define at all which events are to be dispatched. It should give some  
guidance for event names, define the interface, and leave all the other  
normative details to other specifications.


Yeah, I am sort of coming to that view. I still think it is useful for  
the spec to give guidance about normal usage, and for other specs to  
follow common patterns, so authors don't have to learn a different and  
conflicting kind of magic for each API that uses progress events. IMHO  
that's one of the major reasons for having the spec in the first place.


From what has happened so far around progress events I'm sort of doubtful  
the specification is the right coordination point for this. It seems  
review and communication works a lot better.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Use cases (appcache, etc) [progress]

On Tue, 20 Oct 2009 20:45:16 +0200, Anne van Kesteren ann...@opera.com  
wrote:


On Tue, 20 Oct 2009 20:00:27 +0200, Charles McCathieNevile  
cha...@opera.com wrote:
On Tue, 20 Oct 2009 13:14:00 +0200, Anne van Kesteren  
ann...@opera.com wrote:
Actually that request would not change anything. As far as  
XMLHttpRequest goes it would still transfer only a single entity.


In the sense that it is a single transaction, sure. But conceptually it  
is transferring something known to be divisible into a set of entities  
(that's the point of the request :) ).


Most things are divisible into a set of entities. Fact remains that  
we're dealing with a single entity body here as far as HTTP is concerned  
and that progress events are supposed to deal with entity bodies.


It doesn't say that anywhere. It says that is the typical case, but specs  
can define what they deal with.



Changing that for FormData does not make sense.


You mean changing what the XHR spec says causes progress events to fire  
(e.g. by looking inside the data sent for boundaries of enitities)? Quite  
possibly not. It's just mentioned as a possibility.


If you want to build more interesting UIs, and allow authors to use things  
as they arrive, then there are quite some changes to make and they are  
probably not trivial. Maybe trying to layer all that on top of FormData is  
a mistake - but considering the question of whether that means you go for  
a more complex solution than formadata, or give away the extra possibility  
for now, is probably worth giving people a few minutes to consider.


Personally I suspect the answer is to go with FormData and skip the  
complexity, because I can't see compelling use cases for trying to make a  
more complicated approach to loading data. But I have been wrong before.


(Not sure that I would suggest anyone spend a lot longer on it - different  
people's perspectives seem as likely to lead to the right answer as one  
person trying to think of everything).


cheers

Chaals

--
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: childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)



On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:

On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers schep...@w3.org  
wrote:
So, rather than dwell on an admittedly imperfect spec, I personally  
suggest
that we urge WebKit developers to implement .children  
and .children.length,
in the anticipation that this will be in a future spec but can be  
useful to

authors today.


They already do. Which casts some amount of doubt on Maciejs argument
that it was too performance heavy to implement in WebKit. :)


What I said way back in the day (about childElements) was this:
I suggest leaving this out, because it's not possible to implement  
both next/previous and indexed access in a way that is efficient for  
all cases (it's possible to make it fast for most cases but pretty  
challenging to make it efficient for all). This is especially bad with  
a live list and an element whose contents may be changing while you  
are iterating. If all you care about is looping through once, writing  
the loop with nextElementSibling is not significantly harder than  
indexing a list.
I stand by that remark. It is indeed hard to get both indexed and  
previous/next access efficient in all cases. Of course, we are not  
going to let that stop us from interoperating with de facto standards,  
and we do our best (as for other kinds of NodeLists and  
HTMLCollections), but I'd rather not have new APIs follow this pattern.


In this particular case, I think anything that's implemented in all of  
the major browser engines should be an official standard, not just de  
facto.


Regards,
Maciej

Re: childElements, childElementCount, and children

2009-10-20 Thread Doug Schepers


Hey-

Maciej Stachowiak wrote (on 10/20/09 4:42 PM):


On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:


On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers schep...@w3.org
mailto:schep...@w3.org wrote:

So, rather than dwell on an admittedly imperfect spec, I personally
suggest
that we urge WebKit developers to implement .children and
.children.length,
in the anticipation that this will be in a future spec but can be
useful to
authors today.


They already do. Which casts some amount of doubt on Maciejs argument
that it was too performance heavy to implement in WebKit. :)


What I said way back in the day (about childElements) was this:

I suggest leaving this out, because it's not possible to implement
both next/previous and indexed access in a way that is efficient for
all cases (it's possible to make it fast for most cases but pretty
challenging to make it efficient for all). This is especially bad
with a live list and an element whose contents may be changing while
you are iterating.

If all you care about is looping through once, writing the loop with
nextElementSibling is not significantly harder than indexing a list.

I stand by that remark. It is indeed hard to get both indexed and
previous/next access efficient in all cases. Of course, we are not going
to let that stop us from interoperating with de facto standards, and we
do our best (as for other kinds of NodeLists and HTMLCollections), but
I'd rather not have new APIs follow this pattern.


I got similar feedback from mobile vendors, who had not optimized live 
lists, so I think Maciej's point was valid for the design constraints of 
Element Traversal.


Where we now take the idea of an element-node-based API is another matter.



In this particular case, I think anything that's implemented in all of
the major browser engines should be an official standard, not just de facto.


Agreed, which is why I've started off DOM4 Core as I did.

I don't feel too strongly about having both .children and 
.childElements, but I do think that .children is a little problematic 
for authors... they will always have to check to see if Comment nodes 
are included, because of the large marketshare for older versions of IE, 
while .childElements allows them to write simple, clean, efficient code, 
which is the whole point of an element-based API.


I also prefer ElementCollection over HTMLCollection, especially for 
environments where more XML is used.  I don't know if there are any 
deeper issues that would advantage one over the other, but I think it 
would be confusing to authors to collect non-HTML elements in something 
labeled HTMLCollection.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: solving the CPU usage issue for non-visible pages

On Wed, Oct 21, 2009 at 11:59 AM, Ennals, Robert robert.enn...@intel.comwrote:

 Should we also consider the case where a web site wants to keep its
 interface up to date with some server state and is using up CPU time and
 network resource to do so?


You could abuse my proposal to do this, by periodically (as frequently as
you run script now) calling requestAnimationFrame and seeing if you actually
get a paint event. Maybe that's not an ideal solution, though.

Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]

Editor's Response in the proposed process (with particular note of spec diff links)

Hello WG Editors,

I think it's time to start including the Editor's Response notes in
bugzilla bug resolutions. We're informally starting to use other parts
of the proposed Decision Policy and I'd like to start using the parts
that apply to editor actions. I would also like to address Adrian
Bateman's concern about

I'd like to ask editors to include the following boilerplate text
(with the fields filled in appropriately) when resolving bugzilla
bugs. Note: detailed rationale is not generally needed for minor
editorial issues like typos. In general, bugs marked with the NE
keyword should be considered non-editorial, i.e. they likely *do* need
rationale. When in doubt, just put something brief like Commenter was
correct or This is not a typo, it's by design or something along
those lines.

(Boilerplate is between the rows of dashes.)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If
you are satisfied with this response, please change the state of this
bug to CLOSED. If you have additional information and would like the
editor to reconsider, please reopen this bug. If you would like to
escalate the issue to the full HTML Working Group, please add the
TrackerRequest keyword to this bug, and suggest title and text for the
tracker issue; or you may create a tracker issue yourself, if you are
able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html
.

Status: [Accepted/Partially Accepted/Rejected]
Change Description: [no spec change, or explain actual spec change]
Rationale: [give rationale for change or lack of change here]

---

Ian, Manu, please let me know if there are any issues with this.

The other piece of information we would like in every resolved
bugzilla bug is a link to the relevant revision of the spec. I've
talked to Ian about this so far, not yet other editors. He is
including the bugzilla bug number in every commit. Ian tells me that,
given the way he edits the spec (with a long processing pipeline
before the change is fully committed,

Therefore: I'd like to ask for a volunteer to write a tool to add the
spec diff information to bugzilla bugs. It should be a simple matter
of looking at commit messages for completed commits, and adding the
appropriate comment programatically. I'd like the comment to have this
format: Diffs to Spec Text: http://dev.w3.org/cvsweb/html5/spec/Overview.html.diff?r1=1.3360r2=1.3361
. Can any of the people familiar with the spec production toolchain
please help with this?

I'd like to ask other editors of specs with a Working Draft (I think
only Manu currently) to please include the bug number in their commit
messages, or just include a line in the above format in the EDITOR'S
RESPONSE template itself.

Adrian: given the current status (bug numbers being included in the
commit messages), are you satisfied in your concerns, or would you
like to wait until we have the final automated step integrated into
the production pipeline?

Regards,
Maciej

Re: solving the CPU usage issue for non-visible pages

2009-10-20 Thread Jonas Sicking

On Tue, Oct 20, 2009 at 4:44 PM, Robert O'Callahan rob...@ocallahan.org wrote:
 On Wed, Oct 21, 2009 at 11:59 AM, Ennals, Robert robert.enn...@intel.com
 wrote:

 Should we also consider the case where a web site wants to keep its
 interface up to date with some server state and is using up CPU time and
 network resource to do so?

 You could abuse my proposal to do this, by periodically (as frequently as
 you run script now) calling requestAnimationFrame and seeing if you actually
 get a paint event. Maybe that's not an ideal solution, though.

Yeah, I think having an API that lets you check if the page is
visible, as well as an event that lets you know when the visibility
changes, would be a good idea. That's better than adding *WhenVisible
APIs, like setTimeoutWhenVisible, EventSourceWhenVisible, etc.

/ Jonas

Re: Editor's Response in the proposed process (with particular note of spec diff links)

Whoops, sent this to the wrong list, my apologies.

- Maciej

On Oct 20, 2009, at 5:30 PM, Maciej Stachowiak wrote:

Hello WG Editors,

I think it's time to start including the Editor's Response notes in
bugzilla bug resolutions. We're informally starting to use other
parts of the proposed Decision Policy and I'd like to start using
the parts that apply to editor actions. I would also like to address
Adrian Bateman's concern about

I'd like to ask editors to include the following boilerplate text
(with the fields filled in appropriately) when resolving bugzilla
bugs. Note: detailed rationale is not generally needed for minor
editorial issues like typos. In general, bugs marked with the NE
keyword should be considered non-editorial, i.e. they likely *do*
need rationale. When in doubt, just put something brief like
Commenter was correct or This is not a typo, it's by design or
something along those lines.

(Boilerplate is between the rows of dashes.)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If
you are satisfied with this response, please change the state of
this bug to CLOSED. If you have additional information and would
like the editor to reconsider, please reopen this bug. If you would
like to escalate the issue to the full HTML Working Group, please
add the TrackerRequest keyword to this bug, and suggest title and
text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this
document: http://dev.w3.org/html5/decision-policy/decision-policy.html
.

Status: [Accepted/Partially Accepted/Rejected]
Change Description: [no spec change, or explain actual spec change]
Rationale: [give rationale for change or lack of change here]

---

Ian, Manu, please let me know if there are any issues with this.

The other piece of information we would like in every resolved
bugzilla bug is a link to the relevant revision of the spec. I've
talked to Ian about this so far, not yet other editors. He is
including the bugzilla bug number in every commit. Ian tells me
that, given the way he edits the spec (with a long processing
pipeline before the change is fully committed,

Therefore: I'd like to ask for a volunteer to write a tool to add
the spec diff information to bugzilla bugs. It should be a simple
matter of looking at commit messages for completed commits, and
adding the appropriate comment programatically. I'd like the comment
to have this format: Diffs to Spec Text: http://dev.w3.org/cvsweb/html5/spec/Overview.html.diff?r1=1.3360r2=1.3361
. Can any of the people familiar with the spec production toolchain
please help with this?

I'd like to ask other editors of specs with a Working Draft (I think
only Manu currently) to please include the bug number in their
commit messages, or just include a line in the above format in the
EDITOR'S RESPONSE template itself.

Regards,
Maciej

Re: childElements, childElementCount, and children

2009-10-20 Thread John Resig

 I don't feel too strongly about having both .children and .childElements,
 but I do think that .children is a little problematic for authors... they
 will always have to check to see if Comment nodes are included, because of
 the large marketshare for older versions of IE, while .childElements allows
 them to write simple, clean, efficient code, which is the whole point of an
 element-based API.

That's not completely true - if a code base were to make use of
.children for efficiency it would probably write code like the
following:

var getChildren = (function(){
  var div = document.createElement(div);
  div.innerHTML = !--div--;
  if ( div.children  div.children.length === 0 ) {
return function(elem){
  return elem.children;
};
  } else {
return function(elem){
  var ret = [], child = elem.children || elem.childNodes;
  for ( var i = 0, l = child.length; i  l; i++ ) {
if ( child[i].nodeType === 1 ) {
  ret.push( child[i] );
}
  }
  return ret;
};
  }
})();

That way they'd have one clean function for .children in browsers that
handle it nicely and another for ones that don't.

In comparison, the following is a sample of the code that would need
to exist to use .childElements

var getChildren = (function(){
  if ( document.documentElement.childElements ) {
return function(elem){
  return elem.childElements;
};
  } else {
return function(elem){
  var ret = [], child = elem.children || elem.childNodes;
  for ( var i = 0, l = child.length; i  l; i++ ) {
if ( child[i].nodeType === 1 ) {
  ret.push( child[i] );
}
  }
  return ret;
};
  }
})();

In the end, not much of a change - at least not enough to warrant a
completely new property. (Note: The above code aggregates an array of
DOM elements, it's likely that you would want to avoid the extra loop
in a high performance situation. Also, elem.children ||
elem.childNodes is used to get a minor perf boost in IE, since it'll
have to search through less nodes. Also, if .childElements did exist
it's likely that some code bases would start to have an if (
childElements ) {} else if ( children ) {} else {} - which wouldn't
make a ton of sense if IE never implements the new property.)

--John

RE: solving the CPU usage issue for non-visible pages

2009-10-20 Thread Ennals, Robert

 On Tuesday, October 20, 2009 at 5:37 PM, Jonas Sicking jo...@sicking.cc 
 wrote:
 On Tue, Oct 20, 2009 at 4:44 PM, Robert O'Callahan
 rob...@ocallahan.org wrote:
  On Wed, Oct 21, 2009 at 11:59 AM, Ennals, Robert
 robert.enn...@intel.com
  wrote:
 
  Should we also consider the case where a web site wants to keep its
  interface up to date with some server state and is using up CPU time
 and
  network resource to do so?
 
  You could abuse my proposal to do this, by periodically (as
 frequently as
  you run script now) calling requestAnimationFrame and seeing if you
 actually
  get a paint event. Maybe that's not an ideal solution, though.
 
 Yeah, I think having an API that lets you check if the page is
 visible, as well as an event that lets you know when the visibility
 changes, would be a good idea. That's better than adding *WhenVisible
 APIs, like setTimeoutWhenVisible, EventSourceWhenVisible, etc.

One thing I like about the requestAnimationFrame approach is that it makes it 
easy to do the right thing. If the simplest approach burns CPU cycles, and 
programmers have to think a bit harder to avoid doing this, then I suspect the 
likely outcome would be that many programmers will take the shortest path, and 
not check whether their page is visible.  

I'd even be tempted to risk breaking existing applications a little bit and 
make the *default* behavior for HTML5 pages be that time stops when a page is 
not visible. If a programmer has a good reason to run javascript on an 
invisible page then they should have to pass an option to make it clear that 
they know what they are doing.

I'm sure there are lots of reasons why this wouldn't work, but you get the idea 
:-)


-Rob

Re: solving the CPU usage issue for non-visible pages



On Oct 20, 2009, at 7:13 PM, Ennals, Robert wrote:



One thing I like about the requestAnimationFrame approach is that  
it makes it easy to do the right thing. If the simplest approach  
burns CPU cycles, and programmers have to think a bit harder to  
avoid doing this, then I suspect the likely outcome would be that  
many programmers will take the shortest path, and not check whether  
their page is visible.


It's nice if you are able to re-engineer your animations enough to  
make use of it. The other approaches discussed seem easier to bolt on  
to existing code.


Note: if you really want to optimize CPU use, then the best thing IMO  
is to use CSS Transitions or CSS Animations, that way the browser is  
fully in control of the frame rate and in many cases can do most of  
the work on the GPU, with no need to execute any script as the  
animation goes. I think this has the potential to be more CPU-friendly  
than the requestAnimationFrame approach, though obviously it's not  
applicable in some cases (e.g. canvas drawing).




I'd even be tempted to risk breaking existing applications a little  
bit and make the *default* behavior for HTML5 pages be that time  
stops when a page is not visible. If a programmer has a good reason  
to run javascript on an invisible page then they should have to pass  
an option to make it clear that they know what they are doing.


One challenge with this approach is that there's no good way at  
present to make time stop for a plugin. I suspect more generally that  
this approach would cause compatibility bugs.


Regards,
Maciej

Re: solving the CPU usage issue for non-visible pages

On Wed, Oct 21, 2009 at 3:41 PM, Maciej Stachowiak m...@apple.com wrote:

 On Oct 20, 2009, at 7:13 PM, Ennals, Robert wrote:


 One thing I like about the requestAnimationFrame approach is that it
 makes it easy to do the right thing. If the simplest approach burns CPU
 cycles, and programmers have to think a bit harder to avoid doing this, then
 I suspect the likely outcome would be that many programmers will take the
 shortest path, and not check whether their page is visible.


 It's nice if you are able to re-engineer your animations enough to make use
 of it. The other approaches discussed seem easier to bolt on to existing
 code.


I'd hoped it would be easy to retrofit. Given

var timer = setInterval(doStuff, /*some inappropriately chosen frame
duration*/);
...
clearInterval(timer);

you can just change it to

var cancelled = false;
window.addEventListener(beforePaint,
  function() { doStuff(); if (!cancelled) window.requestAnimationFrame(); },
false);
window.requestAnimationFrame();
...
cancelled = true;

Note: if you really want to optimize CPU use, then the best thing IMO is to
 use CSS Transitions or CSS Animations, that way the browser is fully in
 control of the frame rate and in many cases can do most of the work on the
 GPU, with no need to execute any script as the animation goes. I think this
 has the potential to be more CPU-friendly than the requestAnimationFrame
 approach, though obviously it's not applicable in some cases (e.g. canvas
 drawing).


That is absolutely true, but there will always be lots of situations where
declarative animation is insufficiently flexible --- games, physics
simulations, etc. And of course the ease of retrofitting existing
script-based animations is an issue.

Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]

RE: solving the CPU usage issue for non-visible pages

2009-10-20 Thread Ennals, Robert

[my last attempt at an inline reply seems to have interacted strangely with 
Maciej's email client, so I'm going to top-post for the moment until I work out 
what was going on]

Good point. I don't know what other people are thinking, but when I say 
invisible I'm thinking about pages that have been minimized or are in an 
invisible tab. Changing the semantics of a page when it is occluded by another 
page could be confusing.

-Rob

 -Original Message-
 From: Brian Kardell [mailto:bkard...@gmail.com]
 Sent: Tuesday, October 20, 2009 7:58 PM
 To: Maciej Stachowiak
 Cc: Ennals, Robert; Jonas Sicking; rob...@ocallahan.org; public-
 weba...@w3.org
 Subject: Re: solving the CPU usage issue for non-visible pages
 
 So... in describing this feature:
 
 Is it really the visibility of the page that is being queried - or the
 some kind of state of a window?  Maybe it's a silly bit of semantics,
 but it seems clearer to me that most of the things discussed here are
 about a whole window/tab being minimized (either to a taskbar or tab
 or something).  If I have one app open and it is covering a browser
 window - the browser window is not visible (it's lower in the stacking
 order).  Likewise, a page is generally partially visible
 (scrollbars) so that seems more confusing than it needs to be too.
 
 
 On Tue, Oct 20, 2009 at 7:41 PM, Maciej Stachowiak m...@apple.com
 wrote:
 
  On Oct 20, 2009, at 7:13 PM, Ennals, Robert wrote:
 
  One thing I like about the requestAnimationFrame approach is that
 it makes
  it easy to do the right thing. If the simplest approach burns CPU
 cycles,
  and programmers have to think a bit harder to avoid doing this, then
 I
  suspect the likely outcome would be that many programmers will take
 the
  shortest path, and not check whether their page is visible.
 
  It's nice if you are able to re-engineer your animations enough to
 make use
  of it. The other approaches discussed seem easier to bolt on to
 existing
  code.
  Note: if you really want to optimize CPU use, then the best thing IMO
 is to
  use CSS Transitions or CSS Animations, that way the browser is fully
 in
  control of the frame rate and in many cases can do most of the work
 on the
  GPU, with no need to execute any script as the animation goes. I
 think this
  has the potential to be more CPU-friendly than
 the requestAnimationFrame
  approach, though obviously it's not applicable in some cases (e.g.
 canvas
  drawing).
 
  I'd even be tempted to risk breaking existing applications a little
 bit and
  make the *default* behavior for HTML5 pages be that time stops when
 a page
  is not visible. If a programmer has a good reason to run javascript
 on an
  invisible page then they should have to pass an option to make it
 clear that
  they know what they are doing.
 
  One challenge with this approach is that there's no good way at
 present to
  make time stop for a plugin. I suspect more generally that this
 approach
  would cause compatibility bugs.
  Regards,
  Maciej

Re: solving the CPU usage issue for non-visible pages

On Wed, Oct 21, 2009 at 3:57 PM, Brian Kardell bkard...@gmail.com wrote:

 Is it really the visibility of the page that is being queried - or the
 some kind of state of a window?  Maybe it's a silly bit of semantics,
 but it seems clearer to me that most of the things discussed here are
 about a whole window/tab being minimized (either to a taskbar or tab
 or something).  If I have one app open and it is covering a browser
 window - the browser window is not visible (it's lower in the stacking
 order).  Likewise, a page is generally partially visible
 (scrollbars) so that seems more confusing than it needs to be too.


There are lots of reasons why the browser might deduce that the user is not
paying attention to a document, e.g.
-- the browser window containing the document is minimized
-- the tab containing the document is hidden
-- the document is in an IFRAME and scrolled offscreen
-- the browser window is buried behind other windows on the desktop
-- the screen is dimmed for power saving
-- gaze tracking detects that the user is looking somewhere else
-- ultrasonic pings detect that the user is not there

If we need an API beyond just animation, you might as well call it something
like window.hasAttention so browsers can cover all of those cases.

Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]

Re: childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)

On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak m...@apple.com wrote:

 I agree. The reason I phrased it as I did was to contrast with my previous
 remarks. The children attribute should be part of a standard, even though
 it creates what I think is a poor design pattern (mix of previous/next and
 indexed access to the same collection).


It might be worth adding annotations to the spec to say this API is
terrible, do not use and this API is terrible, do not follow its design.

Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]

Re: childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)



On Oct 20, 2009, at 8:22 PM, Robert O'Callahan wrote:

On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak m...@apple.com  
wrote:
I agree. The reason I phrased it as I did was to contrast with my  
previous remarks. The children attribute should be part of a  
standard, even though it creates what I think is a poor design  
pattern (mix of previous/next and indexed access to the same  
collection).


It might be worth adding annotations to the spec to say this API is  
terrible, do not use and this API is terrible, do not follow its  
design.


Are there any DOM Core methods where those notes would not apply? :-)

 - Maciej

Re: solving the CPU usage issue for non-visible pages