Re: Historical points API implementation interest in Gecko?

Thanks Stone, I understand.

Navid, it sounds like we should probably move the PR to a new document then
(can just use a respect "community draft" template or something).

By the way, my suggestion of aiming for REC in ~6 months is fairly
arbitrary.  Our charter lasts until Jan 2018 so if the group thought it was
worthwhile we could run for another year or so.  But perhaps it's best to
aim for REC in mid 2017 and (if we need more time to get passing tests in 2
impls) slip as needed.  We can always pull new APIs back into the spec if
implementations end up looking like they'll ship in time (and it doesn't
reset our last-call or anything).

Rick

On Fri, Oct 21, 2016 at 10:31 AM, Stone Shih <sshih@mozilla.com> wrote:

> Hi Rick,
> Sorry for replying late. We had some discussions about this API and we're
> interested in implementing it in Gecko. But we don't have a concrete
> schedule for it at this moment. We are still busy in other PE
> functionalities and won't start it soon. Maybe it's better not to expect it
> to happen in the next 6 months.
>
> Stone
>
> On Thu, Oct 20, 2016 at 12:14 AM, Rick Byers <rbyers@chromium.org> wrote:
>
>> Hey,
>> As discussed in the PEWG call today, we're interested in implementing the
>> historical points API <https://github.com/w3c/pointerevents/issues/22>
>> in blink.  We care mainly because it allows us to improve smoothness and
>> performance of common scenarios (by better coalescing and aligning
>> pointermove events to vsync), while still giving art scenarios a mechanism
>> for getting the full position detail for input devices whose frequency is
>> greater than the display frequency (following the same model already common
>> on iOS and Android).  For example, we consider Android stylus art scenarios
>> to already be pretty crippled without this feature (since on Android the OS
>> already throttles input events to vsync so we're already limited to 60hz
>> reporting rate).
>>
>> Ted says this API is unlikely to make it into Edge in the next year.  So
>> the question is whether there's any interest from Mozilla in implementing
>> it in Gecko eg. in the next 6 months or so.  If not then we likely can't
>> take Pointer Events v2 to REC with this API in there, and we should just
>> move it now to a separate post-v2 incubation document.  But if it might
>> make it into Gecko in time for V2 to go REC then we might as well put it
>> into the V2 spec.  Of course we can always pull it out later if we guess
>> wrong and don't want to hold REC on this, but we might as well make our
>> best guess now.
>>
>> So what do you think, worth planning on Gecko having this API sometime in
>> time for REC (eg. the next 6 months), or better to expect that it will not?
>>
>> Thanks,
>>    Rick
>>
>> On Tue, Oct 4, 2016 at 4:50 PM, Rick Byers <rbyers@chromium.org> wrote:
>>
>>> Hey,
>>> Chatting with some folks at TPAC, Once Chrome's implementation hits
>>> stable (and hopefully Firefox isn't far behind) I expect we'll start
>>> feeling the pressure to get PEL2 to REC status.  To do this I suggest we
>>> start by triaging issues and adding the "v2-blocking" label to those we
>>> think should be resolved before trying to go to CR
>>> <https://www.w3.org/2015/Process-20150901/#candidate-rec>.  IMHO
>>> (without being an expert on the W3C process) I think this should include:
>>>
>>>    - Any issues where the spec deviates from multiple implementations
>>>    in a non-trivial way
>>>    - All outstanding test issues (eg. incorrect failures) - we'll be
>>>    required to explain any test failures (though it's probably OK if we have a
>>>    couple - no software is bug free).
>>>    - Any high-priority features with impl plans in more than one
>>>    browser.
>>>       - The only one I can think of from the blink side is the
>>>       historical points API
>>>       <https://github.com/w3c/pointerevents/issues/22>, which is now
>>>       urgent for us.  Is Microsoft or Mozilla also interested in implementing
>>>       this, say, sometime in the next 6 months or so?  If not, then we could move
>>>       it from PEL2 into incubation instead (eg. a separate WICG spec that extends
>>>       PEL2).
>>>    - Any little things that are relatively easy to just fix (no point
>>>    carrying a bunch of little easy issues)
>>>
>>> In contrast, things that are probably not v2-blocking include:
>>>
>>>    - New features without concrete implementation plans in 2 or more
>>>    implementations
>>>       - we can continue to iterate on these in an incubation mode, eg.
>>>       either in a separate spec somewhere or, if we prefer, a branch.  But they
>>>       shouldn't delay the substantial benefits of getting our spec to REC.
>>>    - Issues that track a deviation in behavior in one browser of the 3,
>>>    especially when developers are unlikely to be hit by it
>>>       - Ideally we'll still address all of these, but they don't seem
>>>       worth blocking L2 on to me (none of us has bug-free software). As long as
>>>       we have 2 implementations matching the spec in each area that's good enough
>>>       for REC.
>>>    - Editorial issues that are hard to get consensus on or otherwise
>>>    address
>>>       - Again we should try to make progress, but probably not worth
>>>       blocking REC.  My personal opinion is that as long as we have good tests
>>>       that explain concretely what we mean, we can live with some less than ideal
>>>       spec text.
>>>
>>> Sound reasonable?
>>>
>>> BTW I have a conflict tomorrow and won't be able to make a call, but
>>> perhaps it'll be cancelled anyway?  We can iterate on e-mail / GitHub.
>>>
>>> Rick
>>>
>>>
>>
>