Re: <wbr> rendering

>> In the spec, <wbr> is meant to be a line break opportunity.
> That’s a good informal description, but rather unsatisfactory as a
definition.
It comes from the spec:
http://www.w3.org/TR/html51/text-level-semantics.html#the-wbr-element .

>Such a convention is far less universal than you might think
Never meant it to be universal. I meant that it could help wherever it is
needed.

> It’s more like allowed break in a string.
It should allow authors to break strings according to language and context
typographical conventions.

> The soft hyphen has been with us for many years ... though support to it
has been surprisingly limited.
I saw it doing its job in modern browsers. Do you mean older visual UAs?

>  It is all OK for plain text to contain soft hyphens. If you paste text
in an environment where e.g. soft hyphens or other invisible characters
might cause problems, you just need to deal with it.
Authors and users alike have to deal with several problems. I'm just asking
why a feature which has become part of the standard (and not just
"supported") cannot be used in such scenarios.
I'm quite sure that there are other HTML elements meant to deal with old
problems already solved. If something works, something else could still
work better.

>> an author could style such element so that its rendering fits to the
purpose. For instance, <wbr> inside <code> could be rendered as zero width
space, while <wbr> in paragraphs could become a soft hyphen.
> I cannot see where you got that idea, but in any case, <wbr> is not meant
to become a soft hyphen.
http://www.w3.org/TR/html51/rendering.html#phrasing-content-0
I thought that according to this section, <wbr> is meant to work as if a
CSS rule placed a zero-width space as its content. According to this,
there's nothing bad for an author to specify a CSS rule overriding this
standard in order to make <wbr> fit other cases of "string break". Exactly
as "a style sheet or user agent would be ... justified in causing line
breaks to be rendered in a different manner, for instance as green dots, or
as extra spacing" (this is the case for <br /> line break).

> There are no specifications on such things either, and there has not been
work on the issue for many years, as far as I can see.
Then it's just a matter of misused words: I should have said "working
drafts". Here's the last (though quite old) about "content" property
applied to elements:
http://www.w3.org/TR/css3-content/#inserting3
Specs and documentation currently state that "content" is not to be used on
elements. Which is what I saw, too. But then, why relying upon this in
order to define the rendering for this element?

>> It breaks words, right,
> No, it just declares a permitted line breaking point in a string.
This is definitely a matter of terms, then. It declares a permitted line
break in a string. Which means that, if the string is a word and the line
break occurrance condition occurs, it does break the word. Or, which is the
same, as it declares points where a line break can occur in a string, it
should allow authors to define how the string should be broken. I'm not
going against the use cases, or the purpose of the element itself.

>> empty span element would do the trick.
> No, empty spans do not do such things; foo<span></span>bar acts as foobar
as far as layout is considered
foo<span></span> bar breaks in Google Chrome, old versions of Safari (can't
test on newer). I think it was the same with the previous Opera engine, but
I can't be sure.

It's just my conclusion: now that <wbr> is part of the standard, its
rendering whould not rely upon defining CSS "content" on the element itself
It is theoretically a poor choice, as currently it can be applied only to
pseudo-elements. And it prevents users to change its behavior, in case a
string break can be represented differently. These are possible solutions:
1. define default rendering for <wbr> as wbr::after{content:'\200B';}
2. avoid mentioning it in rendering at all, and state that its working is
unrelated with CSS (i.e. it relies on UA interpretation).