Re: TouchEvent sub-pixel precision

While it makes sense, the IDL as it looks like today was mostly because of
interoperability with the existing implementations. In practice, this will
make very little difference in the code that makes use of the events so
it's probably very safe to make the changes. (I can't think of any cases
this would break content from the back of my head, at least)

I'm not sure if we can get all implementations to agree on this (I know one
that probably won't change, which is why we had to pull some of the stuff
out to the extensions note..) - and sadly I don't think we'll ever
implement fractional coordinates on Presto. Will Gecko adopt these changes
as well? (Opera 20+ sadly does not count as a independent implementation,
afaik - if Blink is the only implementation that is intending to implement
the change - personal opinion is to keep it as is, even if it's not very
pretty)

One possibility would be to modify it in the Touch Events Extensions WG
note as a partial interface, and try to formalize that in the scope of the
CG.


On Sat, May 17, 2014 at 1:53 AM, Rick Byers <rbyers@google.com> wrote:

> Doug,
> I think we should use this change as the first test of our TouchEvents
> errata process.  It's a simple and non-controversial change, so it's mostly
> mechanics.  We just need to replace each "long" for pageX/Y clientX/Y
> screenX/Y values in the spec to "double".  What can I do to help make that
> happen ASAP?
>
> Thanks,
>    Rick
>
>
> On Wed, Dec 18, 2013 at 1:09 PM, Scott González <scott.gonzalez@gmail.com>wrote:
>
>> I agree that Mouse and Touch should have the same precision.
>>
>>
>> On Tue, Dec 17, 2013 at 7:11 PM, Rick Byers <rbyers@google.com> wrote:
>>
>>> Hi,
>>> The latest CSSOM View editors draft proposes a modification to
>>> MouseEvent (and others) to enable fractional co-ordinates:
>>> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface.
>>>  This is most valuable in high-dpi scenarios (i.e. essentially all
>>> tablets/phones and now many laptops) to provide more precise co-ordinates
>>> to applications, so that they can result in maximum smoothness for slowly
>>> moving elements.
>>>
>>> I've suggested (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24095)
>>> that if they're going to modify MouseEvent for this, they should modify
>>> Touch at the same time.  Without this, for example, it's impossible to
>>> implement scrolling in JavaScript that is as smooth as browser native
>>> scrolling.  I don't think there's any good reason for Touch to be 2nd class
>>> to mouse in this regard.
>>>
>>> Thoughts?
>>>   Rick
>>>
>>>
>>
>


-- 
Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan