Mouse.isDown is not just the left button

[shaleh]

The comment in the source says

{-| The current state of the left mouse-button.
True when the button is down, and false otherwise. -}

But in reality it is ANY mouse button. This leads to misbehaviour as described in issue elm/elm-lang.org#184. jQuery's docs say:

The mousedown event is sent when any mouse button is clicked. To act only on specific
buttons, we can use the event object's which property. Not all browsers support this property
(Internet Explorer uses button instead), but jQuery normalizes the property so that it is safe
to use in any browser. The value of which will be 1 for the left button, 2 for the middle button,
or 3 for the right button.

[jonathanhefner]

Here are some reasonably not-horrible cross-browser solutions for detecting which mouse button: http://stackoverflow.com/questions/3944122/detect-left-mouse-button-press

One of the comments there mentions a newer event.buttons property which is sufficient by itself, and seems to be supported by current versions of Firefox and Webkit, and by IE 9+:

• https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent.buttons
• https://msdn.microsoft.com/en-us/library/ie/ff974878%28v=vs.85%29.aspx

What is Elm's policy on legacy browser support?

[jonathanhefner]

Here are some reasonably not-horrible cross-browser solutions for detecting which mouse button: http://stackoverflow.com/questions/3944122/detect-left-mouse-button-press

One of the comments there mentions a newer event.buttons property which is sufficient by itself, and seems to be supported by current versions of Firefox and Webkit, and by IE 9+:

• https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent.buttons
• https://msdn.microsoft.com/en-us/library/ie/ff974878%28v=vs.85%29.aspx

What is Elm's policy on legacy browser support?

[jonathanhefner]

Also, I propose to rename Mouse.isDown to something like Mouse.left, with a corresponding Mouse.right.

Another alternative would be to define type MouseButton = None | Left | Right | Middle and have both Mouse.isDown and Mouse.clicks be Signal MouseButton. However, what should the behavior be if e.g. Left and Right are both down? (Send the most recent?)

Given either native solution, I think you can approximate the other in pure Elm, so perhaps the question is: which has least overhead?

[jonathanhefner]

Also, I propose to rename Mouse.isDown to something like Mouse.left, with a corresponding Mouse.right.

Another alternative would be to define type MouseButton = None | Left | Right | Middle and have both Mouse.isDown and Mouse.clicks be Signal MouseButton. However, what should the behavior be if e.g. Left and Right are both down? (Send the most recent?)

Given either native solution, I think you can approximate the other in pure Elm, so perhaps the question is: which has least overhead?

[TheSeamau5]

+1 for having both Mouse.left and Mouse.right.

As for the general case, I think that having the union type of MouseButton is best left for a library. I think we should match the same behavior as Javascript where we have a signal called Mouse.button which outputs :

• -1: No button pressed
• 0 : Main button pressed, usually the left button
• 1 : Auxiliary button pressed, usually the wheel button or themiddle button (if present)
• 2 : Secondary button pressed, usually the right button
• 3 : Fourth button, typically the Browser Back button
• 4 : Fifth button, typically the Browser Forward button

(from MDN docs)

This is the same kind of logic behind the use of strings for attributes in elm-html as opposed to union types. It allows for the core library to follow the spec as much as possible and then someone can write a "elm-mouse-types" library or something.

Finally, as for legacy browsers, again, it would be up to a library. I would recommend Elm to just focus on the spec. In this case it is just a matter of jumbling some numbers around.

That said, I would recommend normalizing Mouse.left and Mouse.right due to how commonly they are used and doing so like jQuery.

[TheSeamau5]

+1 for having both Mouse.left and Mouse.right.

As for the general case, I think that having the union type of MouseButton is best left for a library. I think we should match the same behavior as Javascript where we have a signal called Mouse.button which outputs :

• -1: No button pressed
• 0 : Main button pressed, usually the left button
• 1 : Auxiliary button pressed, usually the wheel button or themiddle button (if present)
• 2 : Secondary button pressed, usually the right button
• 3 : Fourth button, typically the Browser Back button
• 4 : Fifth button, typically the Browser Forward button

(from MDN docs)

This is the same kind of logic behind the use of strings for attributes in elm-html as opposed to union types. It allows for the core library to follow the spec as much as possible and then someone can write a "elm-mouse-types" library or something.

Finally, as for legacy browsers, again, it would be up to a library. I would recommend Elm to just focus on the spec. In this case it is just a matter of jumbling some numbers around.

That said, I would recommend normalizing Mouse.left and Mouse.right due to how commonly they are used and doing so like jQuery.

[kasbah]

In Helm we have something like:

data MouseButton
  = LeftMouse
  | MiddleMouse
  | RightMouse
  | X1Mouse
  | X2Mouse

isDownButton :: MouseButton -> Signal Bool

isDownButton used to be called isDown but I renamed it and introduced the following to bring it closer to Elm.

isDown :: Signal Bool
isDown = isDownButton LeftMouse

[kasbah]

In Helm we have something like:

data MouseButton
  = LeftMouse
  | MiddleMouse
  | RightMouse
  | X1Mouse
  | X2Mouse

isDownButton :: MouseButton -> Signal Bool

isDownButton used to be called isDown but I renamed it and introduced the following to bring it closer to Elm.

isDown :: Signal Bool
isDown = isDownButton LeftMouse

[evancz]

Not sure the solution, but this stuff lives in elm-lang/mouse now

[evancz]

Not sure the solution, but this stuff lives in elm-lang/mouse now