[brundolf]

Yeah, I believe so. They pull some additional tricks to keep the scroll bar from going crazy, probably by (I'm guessing) measuring the height of the segments being removed from the DOM and then explicitly padding things to match that size dynamically.

There's a more general principle here where, once you start trying to override core browser behaviors, you usually end up with a never-ending rabbit hole of corner cases that you now have to cover yourself that used to be handled for free (and probably with better performance, and stability, and accessibility...), and an ensuing complexity-explosion in your code. I won't say it's never worth it, but it's something you should really really put a lot of thought into before you go down that road. All other options should be exhausted first.

[mooreds]

+1 for letting the browser do what it's good at. So many people try to re-invent the browser in HTML/the DOM and end up doing it poorly.

[brundolf]

Sometimes there is no choice. For example, want tooltips for each option in your dropdowns? Well, that's simply impossible in the native HTML version.

So if you want them, you're going to have to implement your own dropdown from scratch. Complete with keeping things from going off-screen, overflow behavior, type-in behavior, some sort of mobile-friendly UX for touch devices, etc etc. Oh, and screen readers/accessibility browsers will almost certainly not understand it.

So then the question you have to ask yourself (or your PM) is: how badly do we really need those tooltips? Sometimes the answer is, "our product will be a complete failure without those dropdown-tooltips". Oftentimes, it isn't.