- From: Rick Byers <rbyers@google.com>
- Date: Thu, 4 Sep 2014 11:44:31 -0400
- To: Matt Gaunt <mattgaunt@chromium.org>
- Cc: "public-touchevents@w3.org" <public-touchevents@w3.org>, Arthur Stolyar <nekr.fabula@gmail.com>, "Patrick H. Lauke" <redux@splintered.co.uk>
- Message-ID: <CAFUtAY_gsDN=6CUQVMqUa4YE+3mK7gHVkvcT8FcfaqtkpmsaUw@mail.gmail.com>
On Thu, Sep 4, 2014 at 4:29 AM, Matt Gaunt <mattgaunt@chromium.org> wrote:
> I'm in favour of Patrick's idea of a generic name if we go down this
> route. I would have expected it to have made the variable true in the event
> of a developers callback existing but the compat event is still fired
> because of no evt.preventDefault(). For IE if pointer event callback is
> used but another event is called, then I'd deem it a compat callback.
>
Are you saying that whether or not an event is marked as a "compatibility
event" would depend on whether some other more authoritative event handler
had been invoked for it? Eg. some new "depthevent" is added that fires
mouse events for compatibility - most pages will see those mouse events
without the compatibility flag set because they have no depthevent
handlers. But then if something on the page adds a depthevent handler in
the event chain somewhere, now the compatbility bit on the mouse events
would be set? This would make sense for a monolithic application, but
would be brittle for a mashup of components (especially when those
components can be updated independently from eachother).
I'm afraid that if we try to come up with a vague name and definition that
allows future scenarios, we'll ultimately find we can't actually implement
any of those future scenarios without breaking websites. And so we'll have
a vague (probably misused) property that ends up actually having a more
specific implementation, and we'll have to introduce some other new
property for the new scenarios, adding to the confusion.
Of course if we can come up with something more general that actually
solves the problems today while being flexible enough to reliably enable
more scenarios in the future then I'm all for that! We just need to think
through carefully the component / versioning implications for all the ways
we think people may reasonable use the new API. That's hard and I think
the web is full of all sorts of examples of interoperability and confusion
problems where these sorts of things weren't thought out carefully enough.
That's why I'm in favor of a very precise / unambiguous definition of the
semantics for any such new API.
> I do still believe the main issue is how we can get out of these compat
> scenarios altogether (I.e. stop firing them in the first place). If you
> think of the web manifesto, surely the goal here is to create the
> primitives that people can build on - in this case touch and mouse events
> firing for touch or mouse respectively and no cross firing.
>
Yes, if we can get to the point where enough websites listen to both touch
and mouse events and so don't depend on mouse* events to function with
touchscreen input, then we'd definitely want to stop firing mouse* events.
I think 'click' (and 'contextmenu') is different though - it represents a
higher-level concept I think we'll always want to support (although in an
idealized world it might be replaced with something like DOMActivate to
have a better name - but I think we're better off accepting that the poorly
named 'click' is here to stay). In that case I think there would still be
scenarios where developers would want to know whether the 'click' is
logically derived from mouse or touch events. WDYT?
> But I can't think of a scenario in the web where this has been achieved
> without creating a completely new API.
> On 3 Sep 2014 15:41, "Rick Byers" <rbyers@google.com> wrote:
>
>> On Tue, Sep 2, 2014 at 7:26 PM, Arthur Stolyar <nekr.fabula@gmail.com>
>> wrote:
>>
>>> It would be good to have js property on DOM node or css property if it's
>>> better which can disable compatibility events, e.g.
>>>
>>> element.compatibilityMouseEvents = false;
>>>
>>
>> One of the main problems I'm trying to solve here is that JS components
>> are reluctant to call preventDefault on TouchEvents because of the
>> potential impact on other components. Really the code wants to affect it's
>> own event handling logic without affecting the logic of anyone else that
>> may be watching the events. So I don't think having an explicit properly
>> to enable/disable the compatibility mouse events will really solve the
>> problem.
>>
>> By the way, as I know touch-action with 'none' value disables delay on
>>> click events. Can we consider ability of touch-action to disable
>>> compatibility events? E.g. if developer uses any value other than auto,
>>> compatibility events are not sent to that region.
>>>
>>> I do not any case where developer need both touch and compatibility
>>> events. One possible case if third-party widgets, but for those widgets
>>> tocuh-action might be set back to auto to enable compatibility mouse events.
>>>
>>
>>>
>>> 2014-09-03 1:26 GMT+03:00 Patrick H. Lauke <redux@splintered.co.uk>:
>>>
>>> On 02/09/2014 19:21, Rick Byers wrote:
>>>>
>>>>> Ping, any thoughts?
>>>>>
>>>>> Adding public-touchevents as I suspect people there will have feedback
>>>>> on this idea.
>>>>>
>>>>
>>>> Very first impression: why derivedFromTouchEvent and not something more
>>>> generic, such as compatibilityEvent or similar, leaving the door open for
>>>> other types of "emulated" mouse events (as a result of, say, a kinect-style
>>>> control).
>>>>
>>>> P
>>>>
>>>> Rick
>>>>>
>>>>>
>>>>> On Wed, Aug 27, 2014 at 10:26 AM, Rick Byers <rbyers@chromium.org
>>>>> <mailto:rbyers@chromium.org>> wrote:
>>>>>
>>>>> Hi,
>>>>> Web developers have long struggled to reliably identify which mouse
>>>>> events are actually derived from touch events. Sites need to know
>>>>> this to avoid double handling (eg. on both a touchend and click
>>>>> event), and have often just ignored all mouse events on a browser
>>>>> that supports touch events - seriously breaking functionality on
>>>>> devices with both a mouse and touchscreen.
>>>>>
>>>>> We (blink team) have tried for over a year to address this problem
>>>>> through evangelism (eg. encouraging
>>>>> <http://www.html5rocks.com/en/mobile/touchandmouse/> calling
>>>>> <https://www.youtube.com/watch?v=DujfpXOKUp8> preventDefault on
>>>>>
>>>>> handled touch events to suppress the generated mouse events). The
>>>>> situation has improved, but it's still a major problem (eg. it's
>>>>> the
>>>>> reason we haven't yet been able to rationalize Chrome's support for
>>>>> TouchEvents
>>>>> <https://code.google.com/p/chromium/issues/detail?id=392584>
>>>>> across
>>>>>
>>>>> devices, and the reason the IE team says
>>>>> <http://lists.w3.org/Archives/Public/public-touchevents/
>>>>> 2014Jul/0025.html> they
>>>>>
>>>>> implement touch events only on phones, not laptops).
>>>>>
>>>>> I recognize now that avoiding
>>>>> <https://code.google.com/p/chromium/issues/detail?id=115475#c13>
>>>>> adding a new simple API for this was a *big mistake*. There are
>>>>>
>>>>> legitimate reasons why the available workarounds are inadequate.
>>>>> For
>>>>> example, you may want to suppress/ignore mouse events without
>>>>> disabling browser behavior like focusing, activating links, etc.
>>>>> Or
>>>>> some listeners may want to ignore certain mouse events whose
>>>>> handling is redundant with that for touch events without affecting
>>>>> other listeners (perhaps in other components written by other
>>>>> developers).
>>>>>
>>>>> After considering a number of more general alternatives
>>>>> <https://docs.google.com/a/chromium.org/document/d/1-
>>>>> ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#>,
>>>>> I'd like to propose a very simple and targeted *addition to
>>>>> MouseEvent:* *a boolean 'derivedFromTouchEvent' property*. Note
>>>>>
>>>>> that this intentionally says the event represents input that was
>>>>> already reported via some other event, NOT that the event
>>>>> represents
>>>>> input from a touchscreen device (eg. browsers on Android send touch
>>>>> events for mouse and stylus, not just touch input). With this we
>>>>> could encourage sites to trivially transform this common broken
>>>>> pattern:
>>>>>
>>>>> if (‘ontouchstart’ in window)
>>>>> document.addEventListener(‘touchstart’, doStuff);
>>>>> else
>>>>> document.addEventListener(‘mousedown’, doStuff);
>>>>>
>>>>>
>>>>> Into this:
>>>>>
>>>>> document.addEventListener(‘touchstart’, doStuff);
>>>>> document.addEventListener(‘mousedown’, function(e) {
>>>>> if (!e.derivedFromTouchEvent) doStuff(e);
>>>>> });
>>>>>
>>>>>
>>>>> This new API can be trivially polyfilled on browsers (like Safari)
>>>>> which never support mouse and touch input at the same time with
>>>>> just:
>>>>>
>>>>> if (!('derivedFromTouchEvent' in MouseEvent.prototype))
>>>>>
>>>>> MouseEvent.prototype.derivedFromTouchEvent =
>>>>> ‘ontouchstart’
>>>>> in window;
>>>>>
>>>>>
>>>>> See this document
>>>>> <https://docs.google.com/a/chromium.org/document/d/1-
>>>>> ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#>
>>>>>
>>>>> for more details and other alternative proposals.
>>>>>
>>>>> Thanks,
>>>>> Rick
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Patrick H. Lauke
>>>>
>>>> www.splintered.co.uk | https://github.com/patrickhlauke
>>>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>>>
>>>>
>>>
>>>
>>> --
>>> @nekrtemplar <https://twitter.com/nekrtemplar>
>>>
>>
>>
Received on Thursday, 4 September 2014 15:45:20 UTC