Additionally, other selectors stopped working aswell. Such as the attribute selector (`[attr]`), and pseudo‐classes (`:hover`). It makes no sense to have them not work with input pseudo‐elements, but have them work with scrollbar pseudo‐elements (`::-webkit-scrollbar-thumb:hover`).

Sorry, nevermind. Pseudo‐classes are working fine. What isn’t is pseudo‐elements and the attribute selector.

As far as I know, the specification does not (currently) allow having pseudo elements on pseudo elements. So you first have to change the specification and only then browsers will likely follow.

Of course, the specification doesn’t say anything about vendor‐prefixed pseudo‐elements.

I also think that it’s important to highlight once again the fact that this used to work in the past. In fact, I have written a bunch of styles back then that made use of these multi‐pseudo‐elements that currently don’t work.

The specification does not distinguish vendor prefixed pseudo element. Pseudo elements cannot have pseudo elements. That was an intentional change to conform with the specification and you were relying on hacks, unfortunately.

The specification prohibits the use of pseudo‐elements on pseudo‐elements because it mostly doesn’t make sense. But these specific `-webkit` pseudo‐elements are referring to regular non‐pseudo elements inside the user‐agent shadow‐root; it makes sense to allow them to have pseudo‐elements. I honestly cannot see any downsides of allowing it.

> The specification prohibits the use of pseudo‐elements on pseudo‐elements because it mostly doesn’t make sense.
Do you have any reference to this?

> But these specific `-webkit` pseudo‐elements are referring to regular non‐pseudo elements inside the user‐agent shadow‐root
There are non-prefixed (not necessarily implemented in Chrome non-prefixed at the moment) pseudo elements that are basically in a user-agent shadow root (though that is an implementation detail and should not affect content). An example is ::placeholder (and its equivalent, ::-webkit-input-placeholder).

In general, since Chrome tends to move away from prefixed feature, the chance of Chrome implementing features and exceptions for prefixed stuff is slim.

Anyway, the right way to go about this, in my opinion, is to either add this to the specification, or ask (at https://discourse.wicg.io/ for example) for more pseudo elements that will help you meet your actual goal (styling <input type=range before the marker and after the marker, I assume?).

Well, if you don’t want to reimplement this, then I think that the best way to go about this is using CSS `@appy` to style these `-webkit` pseudo‐elements:

    input
    {
        -webkit-inner-spin-button:
        {
            &::before
            {
                /* ... */
            }
        };
    }

Please note how using a single dash avoid collision with CSS variables.

Of course such solution would not be able to be used until these feature is properly specced and implemented, but I’m honestly in no hurry. :-)

-~-~-~-~-~-

In case you’re wondering about what is my use‐case for these nested pseudo‐elements, I was using them to add custom arrows to `::-webkit-inner-spin-button`. I’ll attach my CSS file in case you want to take a look. You can see they being use in line 223.

Deleted: style-input.css 13.0 KB

style-input.css 13.0 KB View Download

By the way, if you have no intention of reimplementing this, there is no point in keeping it opened.

Thanks for the report. As previously said, this was non-standard and unpredictable. Chrome won't re-add support for this without specification changes that mean it would (should) be supported on all browsers.

It really is the best thing to raise your use case at https://discourse.wicg.io/. If you do, please add a link to the discussion to this bug so anyone reading in the future knows where the discussion is continuing.

I could create another thread here asking for Chrome to allow `-webkit` properties to accept a rule list that will then be applied to the appropriate element inside its user‐agent shadow‐root. That would bring Chrome’s built‐in elements closer to regular custom elements. What do you think?

I am not sure I understand your idea. Perhaps some CSS (not SCSS) code example would help.

That supposedly is CSS. It makes use of Tab Atkins’ `@apply` rule proposal (https://tabatkins.github.io/specs/css-apply-rule/ https://bugs.chromium.org/p/chromium/issues/detail?id=586974) and of a “nesting” syntax suggested at https://github.com/w3c/webcomponents/issues/300 (and probably somewhere else before).

So regarding comment 13 - I would not bother asking adding features to prefixed features.

Why not? It seems that, besides resolving my problems, it’d make styling `-webkit` pseudo‐elements much more pleasing and regular, by — as I said — bringing Chrome’s built‐in elements closer to regular custom elements.

Because of the policy that says that Blink does not improve prefixed features anymore (if anything, it removes prefixed features).

And yes, there are exceptions (sprucing up the prefixed WebRTC APIs, for example), but they exist only because the migration cannot be done in a single step without hurting compatibility, interoperability and moving the standard web forward. This one does not merit an exception, so it will just be a waste of your time, honestly.