hence the compatibility argument for supporting this interface and its
properties is no longer present. Usage data is also very low, and
coupled with the trivial renaming changes required for any content still
using the interface's properties, removal seems appropriate and
achievable without noteworthy upset.
Right, but Firefox and Internet Explorer are not so common on mobile. Do we have more mobile oriented numbers?
(Internet Explorer 11 does not show both of these on ProgressEvent and also does not have the mentioned interface)
Since the code to maintain this is really small and trivial anyway (it seems), it is not like we are in a rush.
收件者：PhistucK、Eric Seidel、Adam Barth、blink-dev
Den 11.08.2014 19:35, skreiv PhistucK:
> Right, but Firefox and Internet Explorer are not so common on mobile. Do we
> have more mobile oriented numbers?
> (Internet Explorer 11 does not show both of these on ProgressEvent and also
> does not have the mentioned interface)
Yes, as stated on the intent-to-remove.
> Since the code to maintain this is really small and trivial anyway (it
> seems), it is not like we are in a rush.
We can of course wait it out a little longer and go via deprecation, if
that's the consensus. FF removed it mid-2013, and I haven't come across
compat issues being reported.
Regarding deprecation and mobile-focused applications - do we have
data/known cases on deprecation reporting being effective for those? (It
strikes me as being a desktop UA-friendly user reporting mechanism.)
收件者：Sigbjorn Finne、PhistucK、Adam Barth、blink-dev
I know of no data showing that our deprecation messages do anything, no.
I expect an intrepid researcher could look at our historical usage
data and compare it to when features began logging deprecation
messages and see if there was correlation. :)
Given that dividing by undefined just evaluates to NaN rather than throwing an exception, I suspect many uses will degrade gracefully anyway. The Emscripten one, for instance, will just set percentComplete to NaN. From there, I assume that calling an Emscripten-compiled function which expects an int will just convert it to 0 (NaN|0 = 0 because it converts to int32 first). And so the request will not give accurate progress until the load completes (the progress will stay at zero), but otherwise the page will not get horribly confused.
Den 11.08.2014 23:05, skreiv Kouhei Ueno:
> On Mon, Aug 11, 2014 at 1:56 PM, PhistucK <phis...@gmail.com> wrote:
>> Do you have this throttler for the ProgressEvent of XMLHttpRequest as well?
> Sorry I misunderstood the proposal. We need to keep the throttler anyway
> for the ProgressEvent.