InitialMousedown complexity

[Confidenceman02]

the elm-select code inherits a lot of complexity from the original Kaizen design system code. There is a lot of tracking about what node gets a mousedown event fired first. The update function then reacts to this and calculates what to do.

e.g A SelectInput gets a mousedown, it dispatches the InputMouseDowned Msg. Because the SelectInput lives inside the container which also is listening for mousedown event it also gets fired with a ContainerMouseDowned Msg. If it finds that the InitialMousedown was the InputMouseDown it adjusts state accordingly.

Proposed Solution

Instead of all this InitialMouseDown trickery we can simply stop propagation when it makes sense to do so. For the example above we could stop propagation and handle all the necessary state changes from the InputMouseDowned Msg update instead of ContainerMouseDowned needing to check what was mousedowned first.

InputMouseDowned is a great candidate to try this change on first.

[Confidenceman02]

I did improve this a bit in this diff. Essentially I was forced to to make the menu variants work.

You might need to open the Select.elm part of that diff for it to highlight properly.