<nobr> is non-conforming for authors but it is still required to be supported by browsers.

The 'content' property is intended to apply to elements in future levels of CSS.

I find it appropriate to discuss it here, although the bug is marked as "resolved". The previous bug reports about the <wbr> argument are too old and in my opinion a point has gone missing.

(In reply to Ian 'Hixie' Hickson from comment #1)
>The 'content' property is intended to apply to elements in future levels of CSS.
It isn't now, however. I must report here that the current rendering suggestion leaves the space to the usual "magick" in browsers behavior with uncommon, unknown elements. I am about to explain:
I tested its behavior by myself on the 5 major user agent and I noticed that none of them applies rules like 
wbr{content:'\00200B';}
Which is obvious, as no prersent-day browser could respect it on any element. As far as this level of CSS is in place, {content} has effect only on pseudo-elements, and it is worth noting that Opera 12, which was the only UA to apply this property on proper element, has discarded this behavior with version 17. I personally think that using this property would bring to a conflict with proper content. But apart from this, we can agree that a WBR is an inline element (is it?) which has the same behavior than a zero-width space (with the difference that <wbr> is not part of the text) and that using it as an inline-block is unreliable. Now, today <wbr> works just because an unknown element dividing text breaks it naturally and behaves as an inline element. It seems that not all the UAs know if they can style it or not. I would propose a rendering for the element as follows:
wbr:after{content:'\00200B';}
but a *specific mention* on what CSS properties can be applied to <wbr> is required, for it is unclear now, as I said. If it comes out that it can also accept a {content}, it will have effect when user agents allow it. We all know how much time is required for style rules implementation.
This would not only bring a solution immediately available, but would also allow authors to exploit the :after pseudo-element with something like
wbr:after{content:'\0000AD'} 
thus solving the problem of soft hyphen.
Thank you.

The HTML spec attempts to be the spec for tomorrow's implementations, not yesterday's. As such, it attempts to describe the world we're converging on. That's why it uses features that aren't implemented yet.

It would be worse for us to keep changing how 'wbr' is implemented, than for us to describe the future and encourage browsers to get there, IMHO.

(In reply to Ian 'Hixie' Hickson from comment #1)
> <nobr> is non-conforming for authors but it is still required to be supported by browsers.

HTML still cares about support for <nobr> elements and it cannot take into account simpler things like this? It isn't about inventing new things. The fact is, can authors wait for slow user agents to respect still-developing features when the solution is at arm's length? The spec also has to stick to reality that CSS implementation is slower in some cases.
Besides, which elements will {content} be available on? I saw the Opera12 early implementation and it was able to overwrite all the content.

> HTML still cares about support for <nobr> elements and it cannot take into
> account simpler things like this?

I'm not really sure what "simpler things" you mean here.


> The fact is, can authors wait for slow user agents to respect still-developing
> features when the solution is at arm's length?

Why would authors have to wait? I don't understand what you mean here.


> The spec also has to stick to reality that CSS implementation is slower
> in some cases.

How does this affect what browsers will eventually converge on?


> Besides, which elements will {content} be available on? I saw the Opera12
> early implementation and it was able to overwrite all the content.

Yes, the idea is that 'content' will apply to all elements.

Please re-open if you respond to comment 5. Thanks.