Jonas,
When loadend was removed from media elements [2] I wished to determine
whether it was event overkill to also fire at successful reads. Sounds
like you want it back for successful reads as well?
But the reason why loadend *and load* was removed from video do not
apply here. The reason there was that they never guarentee that the
whole video is downloaded such that it can be accessed without further
need for network access.
Additionally we should follow the intent of the Progress Events spec.
Done.
(I was simply wrong about loadend, and citing media elements wasn't
helpful; I've changed the spec. to show that loadend should be fired,
and it now matches the behavior of the XHR2 editor's draft.)
Of the
two names you suggest, do you feel strongly about one over the others?
I'm not sure I love 'result' (it isn't intuitive as a response to a read),
and 'data' is used in other contexts on the platform and so may be
confusing. If you feel strongly (stronger than a 'maybe' ;-) ) about a
different name, I'm happy to change it.
I don't feel that strongly no. But i think 'result' the the most
correct name that I can think of.
Done.
*grumble grumble OK Jonas, in the interest of not bike shedding I've
renamed fileData to result*
Ah, ok. There was also some confusing wording in the definition of the
attribute:
"On getting, if progress events are queued for dispatch while
processing the readAsText read method, this attibute SHOULD return
partial file data in the format specified by the encoding
determination)"
However it should contain the data read so far even if there currently
aren't any progress events queued for dispatch. I.e. if a progress
event was just dispatched and no more data has been read so far, then
.fileData should still contain the same value as when the last
progress event was dispatched.
Fixed; this isn't harnessed to queuing ProgressEvents for dispatch anymore.
* I think someone had brought up a good argument for *not* throwing
when slice is called with start+offset > size. One of the main use
cases for slice is to slice up a file in several chunks when sending
with XHR. When that is done it's easy to end up with rounding errors
resulting in a slightly to large length being requested. In this case
it makes sense to just clamp to size rather than throwing an error.
OK -- sounds like slice should NOT throw an INDEX_SIZE_ERR at all, and only
clamp on size?
Yeah, I think so. Except if the 'start' attribute is bigger then size.
Though possibly we could even then clamp to a zero-sized Blob. I don't
really feel strongly.
Fixed
(I don't feel strongly about whether to throw or not, so I changed it to
*clamp.* It may offer conveniences to NOT throw, but I'd like to hear
from others).
http://dev.w3.org/2006/webapi/FileAPI/
-- A*
