New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users

Issue metadata

Status: WontFix
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Pseudo-elements on input type="range" slider-thumb sub-elements don't render anymore

Reported by, Jan 29 2016 Back to list

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2633.3 Safari/537.36

Example URL:

Steps to reproduce the problem:
Visit a page with markup:

<input type="range" min="0" max="4" step="1">

and CSS:

input[type=range]::-webkit-slider-thumb:after {
		content: "Content Here Should Appear";

What is the expected behavior?
The text should appear.

What went wrong?
The inserted pseudo-element doesn't appear.

The Codepen link renders correctly in Safari, as expected. Out of curiosity, I tried the selector unprefixed (without "-webkit") but that doesn't work either.

This has broken a UI element in my app, and I'd really like to get it back.  It's a very useful styling hook for range inputs.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes This used to work in Chrome, I believe circa M45 or so.

Does this work in other browsers? Yes 

Chrome version: 50.0.2633.3  Channel: canary
OS Version: OS X 10.11.3
Flash Version: Shockwave Flash 20.0 r0

Comment 1 by, Jan 29 2016

Labels: -Cr-Blink Cr-Blink-Forms

Comment 2 by, Jan 29 2016

Labels: Needs-Bisect

Comment 3 by, Jan 29 2016

Labels: -Pri-2 -Type-Bug -OS-Mac -Needs-Bisect Pri-1 Type-Bug-Regression OS-All hasBisect M-49 ReleaseBlock-Stable
Status: Assigned
Able to reproduce this on the latest canary(50.0.2633.3) on Windows-7, Linux Ubuntu 14.04 and Mac OS 10.11.3 as well.

This is regression issue broken in M-49.

Last good build: 49.0.2622.0
First bad build: 49.0.2623.0

Change log:


rune@: Could you please take a look at this.

Thank you!

Comment 4 by, Jan 29 2016

Labels: -Cr-Blink-Forms Cr-Blink-CSS

Comment 5 by, Jan 29 2016

This was an intentional bug-fix to not allow anything but user action pseudo classes after pseudo elements in the selector parser, which is in line with the selectors spec.

Before that bug-fix, we would expose the internals of the UA shadow used to implement form inputs through selectors like "input[type="range" i]::-webkit-media-slider-container > div". These are now limited to UA stylesheets until we can get rid of it completely.

Now, I can have some sympathy for allowing to add pseudo elements on these webkit pseudo elements since the webkit ones are not truly pseudo elements but actual nodes in the light tree of the UA DOM. Yet, I think what the provided codepen example does looks pretty gross and something we should not allow.

I'll send a mail to blink-dev.

Comment 6 by, Jan 29 2016

Labels: Hotlist-Interop
Status: WontFix
Also, Gecko has ::-moz-range-thumb.

You can do:

::-moz-range-thumb { background: pink }
::-moz-range-thumb:hover { background: pink }

but, you cannot do:

::-moz-range-thumb::before { content: "pink" }

so this change makes us more interoperable with Gecko as well.

Tested ::-ms-thumb::before on which doesn't render in any IE versions tested there, either.

Comment 7 by, Jan 29 2016

Sent a mail to, not blink-dev.
Thanks for the quick response. I understand the point about needing to enforce the shadow boundary consistently.

There remain styling scenarios in which there is a requirement to add a design accent to a native input thumb. When you say "looks pretty gross" I assume you mean the selector, and not the design.

I understand that ::shadow and >>> are deprecated. Much of the advice from Bidelman here:

is now sadly already completely obsolete :/

I've tried numerous ways of styling pseudo elements on native input thumbs and none of them work. Please see the attached file. If there's a solution in place for this, can you please let me know what it is?
717 bytes View Download

Comment 9 by, Feb 1 2016

I think I meant "gross" in the sense that it relies on the shadow implementation of the range input. If the thumb was implemented as replaced content itself, ::before/::after would not have generated boxes.

The red alert in the MDN documentation for ::-moz-range-thumb is to the point, I think:

To answer your question about adding generated content to the UA shadow DOM for form inputs: that's not possible.

Comment 10 by, Feb 15 2016

We're also being hit by this regression.

E.g. Here's a more complete styling example for you:

This is used on one of my client projects, currently working across Safari (Mac & iOS), Firefox, Chrome (Mac, PC and Android), IE 10+, Edge.

In Chrome 49 (Beta) and Chrome 50 (Canary) we're losing the ability to style "::-webkit-slider-thumb:after" as previously mentioned above.

This is a pretty huge regression for us.

Can an alternative styling hook be provided before deprecating shadow selectors?

17.8 KB View Download

Comment 11 by, Feb 15 2016 by removing the :after pseudo element on the thumb styling, like you do for the moz rule, the thumbs started showing again for me.

AFAICT, there was no way to add generated content inside UA shadows in Gecko or IE, so I gathered the negative impact of fixing this bug would be very low.

Comment 12 by, Feb 15 2016 You're right at that, but…

Using :before and :after is already a hack for us.

Why? You'll see we're stuck using :after for the thumb and :before for the informative blue "progress fill" bar because Blink/Webkit provide nothing like to Firefox's "-moz-range-progress" or IE's -ms-fill-lower etc.

i.e. In Firefox & IE, we don't need to add generated content like we do for Webkit/Blink. The progress fill element is supported.

If shadow pseudo element support is being removed, is a progress-fill element on the way?

 Issue 594405  has been merged into this issue.
 Issue 595023  has been merged into this issue.
 Issue 594985  has been merged into this issue.
Range-thumb is not the only use of this feature.  An input type of search has the -webkit-search-cancel-button feature to clear the search value. This element offers very little control over appearance with no option to change the color of the "X" to something other than a blue gradient. Using -webkit-appearenc: none and -webkit-search-cancel-button:before I was able to render the cancel button using FontAwesome or potentially any glyph graphic. The background image option is still available on -webkit-search-cancel-button but it won't scale being a bitmap based rendering.

Adding back in the :before element would enable this use, but I would be equally satisfied with better control over the default "X" rendering.  If there is some other way of handling this type of graphic change, please let me know.
 Issue 596257  has been merged into this issue.

Comment 19 by, Mar 23 2016

 Issue 596920  has been merged into this issue.

Comment 20 by, Mar 23 2016

Wouldn't it be reasonable to remove this feature only when adding another way of doing it? It's going to break a lot of input ranges out there that uses this for the fill to the left/right of the slider thumb.

How about adding something like -ms-fill-upper / -moz-range-progress ?
This breaks styling of ranges in the Ionic framework.
It uses :before for the fill and :after to create a larger (non-visible) touchable region for fat fingers.

Since the site I'm working on is Ionic-based, this change breaks for me personally.

Given the lack of real standards, all range styling options are somewhat hacky.
Making any assumptions about how these elements are used seems like a bad idea.
As Aaron wrote, it's _not_ possible to duplicate Firefox or MS behaviour with these pseudoelements removed (no fill/progress pseudoelement), therefore I can't even work around the bug.
 Issue 611085  has been merged into this issue.

Comment 24 by, May 12 2016

from merged  issue 611085 :
this regression also breaks styling of cancel button on search forms
could you pls reconsider "wontFix" status

Sign in to add a comment