Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling.

I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.

That is how it worked, but people still found it problematic. E.g., from one of the comments on the issue:

> In step (3) here, if you do several mousewheel-spins while also subtly moving the mouse (just from placing your hand on it), it's quite easy/possible for the first spin to inadvertently change the value that you just entered (since step 1 had left the cursor hovering the input field, so that's where it starts), and then for the subsequent mousewheel-spins to successfully scroll the page. This can mean you change the number you just entered without noticing (and also without it being "in the middle of an existing scroll action", hence my note that this suggested mitigation wouldn't necessarily help).

The cause being that people don't look at where their cursor is before they start scrolling, and don't look at the value since they've finished entering it.

That's almost correct. I generally agree with hover == focus as a Window Manager level thing, but for document inputs within an application I still prefer required user interaction to set the focus location. E.G. a click, a tab, just move the line forward.

The correct context model is to not select an element for scrolling until it has been made the active element, and that UI element SHOULD have some sort of embellishment to make it obvious that's the focus.