Re: [w3c/FileAPI] Don't update FileReader's result until "LOAD" (#79)

(did some more digging into this), the chrome implementation at least seems to match the spec as it was when it was implemented (in 2010) until around 2013. https://www.w3.org/TR/2012/WD-FileAPI-20121025/#filedata-attr still explicitly says " the result attribute should return partial Blob data " for readAsText and readAsArrayBuffer (but not for readAsDataURL), which exactly matches chromes behavior. The next version of the spec no longer has that language and instead queues tasks at load complete to update the result attributes once and only once.

Also this subject was brought up in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0289.html (as point 4), but it doesn't seem like anybody ever replied to that point.

Ah, later that year another thread was started specifically about this subject, http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0357.html, which doesn't seem to have gotten very far either, but it seems like the spec was updated to reflect that change anyway.

So yeah, it would make sense to make the spec a bit more explicit here, even though it already sort of implies that only final result should be available. Fortunately it doesn't seem like reading partial results is used a lot (https://www.chromestatus.com/metrics/feature/timeline/popularity/2158), so seems like this should be fairly safe to change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/79#issuecomment-371328631