I think we didn't apply it because Chrome and Safari don't display a focus indicator when you mouse click on a range input. However I just realized that Firefox does show a focus indicator when you mouse click a range input...

Browser sniffing seems like a bad option, so I think the only solution here would be to make the polyfill's behavior inconsistent in some browsers (which it already is).

@alice wdyt?

My use case is to apply some styles to a "fake range" I'm building when the native range is keyboard focused, so:

input[type=range].focus-visible:focus + .fake-range {
  background-color: whatever;
}

This isn't currently possible but I don't know if I'm incorrectly repurposing the polyfill here.

Marked as non substantive for IPR from ash-nazg.

@jjenzz If I understand correctly I think you would want:

input[type="range"].focus-visible + .fake-range {
  background: pink;
}

Example: https://jsbin.com/buyuyefuzo/1/edit?html,output

@robdodson yep, I'd like to be able to do that but the focus-visible class doesn't get added to range inputs. That's the purpose of this PR. Or at least, I thought that's what this whitelist allows 😬

Try testing your JS Bin in Chrome. The .fake-range element doesn't change pink when using keyboard.

It seems to work for me in Chrome. I mouse clicked on the text, then pressed Tab to send focus to the range input. The whitelist is used to add .focus-visible to an element if someone clicks on it with a mouse. For example, a <input type="text"> is in the whitelist because we want it to show :focus-visible if it receives keyboard focus or mouse focus.

Ah, I just realised the problem is that I tested in Brave Browser where that doesn't work. I thought Brave was based on Chrome so that's interesting.

Either way, I have misunderstood the purpose of this whitelist so I will close this PR. Thank you for the explanation and help @robdodson 🖤