CSS content: attr() on HTML5 progress doesn't work

Question

HTML

<progress max="100" value="80" data-value="5"></progress> 

CSS

progress { margin: 50px; width:250px; border:0; } 

CSS (Attempt 1)

progress:before, progress:after { content: attr(data-value); } 

CSS (Attempt 2)

progress::-webkit-progress-bar:before, progress::-webkit-progress-bar:after { content: attr(data-value); }  progress::-moz-progress-bar:before, progress::-moz-progress-bar:after { content: attr(data-value); } 

CSS (Attempt 3)

progress::-webkit-progress-value:before, progress::-webkit-progress-value:after { content: attr(data-value); }  progress::-moz-progress-value:before, progress::-moz-progress-value:after { content: attr(data-value); } 

None of the above attempts succeeded. Also tried each of the above versions with different CSS code blocks, for :before and :after.

OBJECTIVE

To inject CSS generated content before and after the HTML5 <progress> element. Is this possible?

JsFiddle Demo

http://jsfiddle.net/pankajparashar/MNL2C/

UPDATE

When I use the following CSS it works.

progress::-webkit-progress-bar:before, progress::-webkit-progress-bar:after { content: '123'; }     

CONCLUSION

Apparently when we inject static content in the CSS, it works. But if we use the content from data-* it doesn't.

Answer 1

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.