Input psuedo element styling doesn't work on Chrome when declared with other rules-CodePudding

I have an input slider.

<input type="range" min="1" max="100" value="70"  id="volume-slider">

When trying to style the track like this for Firefox and Chrome

input[type=range]::-moz-range-track,
input[type=range]::-webkit-slider-runnable-track {
  background: red;
}

It works on Firefox but not Chrome. But when I separate this into separate declaration blocks like this:

input[type=range]::-moz-range-track {
  background: red;
}

input[type=range]::-webkit-slider-runnable-track {
  background: red;
}

It now works on Chrome too. What is happening here?

CodePudding user response：

It is specified to be this way. Invalid selector in selector list normally invalidates entire rule-set. In this case for Chrome anything ::-moz-<…> prefixed will be unknown so it would invalidate whole rule; since ::-webkit-<…> prefixed pseudo-elements are historical exception, because they managed to spawn wildly and due WebKit/Blink hegemony established themselves, now the specs explicitly dictates that anything ::-webkit-<…> must be treated as valid:

https://www.w3.org/TR/selectors-4/#compat

Due to legacy Web-compat constraints, user agents expecting to parse Web documents must support the following features:

All pseudo-elements whose names begin with the string “-webkit-” (matched ASCII case-insensitively) and that are not functional notations must be treated as valid at parse time. (That is, ::-webkit-asdf is valid at parse time, but ::-webkit-jkl() is not.) If they’re not otherwise recognized and supported, they must be treated as matching nothing, and are unknown -webkit- pseudo-elements.

Side note: this exception was added to the standard somewhere around 2018 and presumably Firefox behaved that way at that time already. But as a rule of thumb, if you want to target widest possible range of "unknown"/outdated browsers, you should always duplicate rule-sets with suspicious selectors. (Or do feature detection.)