In my original comment, I said:
I don't think this is possible as content within the progress
element is never displayed if the browser can already draw the progress bar, similarly to content within an object
or iframe
.
To put it another way, this classifies progress
as a replaced element. Just as with the traditional input
and other form elements that are replaced elements, as well as img
, CSS2.1 doesn't have much to say about using generated content with it:
Note. This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in a future specification.
It's well-established that Gecko-based browsers choose not to support generated content for replaced elements, whereas WebKit-based browsers allow it to some extent, at least for form elements that are replaced elements. (Interestingly, progress::before
and progress::after
do not work in any browser.) So if you're asking if it's possible to do this cross-browser, the answer is no, and has always been no.
As for why WebKit browsers can insert strings and not attr()
values, I'm not certain. Both CSS2.1 and CSS3 Units and Values state that attr()
should take values from attributes of the actual element generating those pseudo-elements, since pseudo-elements can't have attributes themselves anyway. This is where I'm stumped.
Perhaps the browser is incorrectly trying to take the data-value
attribute from ::-webkit-progress-bar
and ::-webkit-progress-value
and not the progress
element, which is why content
is failing when using attr()
but working when using a string.
Perhaps the root of the problem lies in the very fact that you're trying to add generated content to other pseudo-elements, which again seems to work in WebKit browsers for whatever bizarre reason. Unlike the above issue with generated content within replaced elements, the current Selectors 3 spec and the upcoming Selectors 4 spec are both very clear on this: you are not supposed to have more than one pseudo-element per complex selector. Of course, WebKit has infamously flouted various rules when it comes to implementing pseudo-elements, so in hindsight it does not surprise me to see WebKit mess up doing so.
Either way, the real conclusion is that the implementation of CSS generated content is extremely poor beyond the scope of the current standard of CSS2.1 + Selectors, by which I mean generated content for replaced elements such as input
and progress
, and nesting of pseudo-elements in a single selector.