Needless to say, in changing these default rules please replace them with something existing. Proposals from WHATWG maintainer included new "display" property values, which would mean nothing if used just for this case, i.e. they probably wouldn't even be implemented.
It would be sufficient to state something like

br::after { content: '\A'; }
wbr::after { content: '\200B'; }

FWIW WHATWG HTML doesn't use 'content' for br/wbr anymore.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503
->
https://html5.org/r/8745

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26264#c2
->
https://html5.org/r/8798

Tab hasn't specified these in CSS yet I think.

I checked some of the "official" material about "display-outside" CSS property. I quoted the term "official" because we are talking about a working draft, so I don't know its completion status as of now.

…So you're saying that, in WHATWG opinion, <br> and <wbr> are to be rendered according to the value of a CSS3 property whose syntax is defined in a working draft, as of yet, and which is NOT supportedy by any browser. A CSS property whose syntax allows "display" as shorthand, but in a confused way because it has to ensure legacy compatibility for one of the most widespread CSS layout properties. A CSS property which also controls the layout of parent element.

This is not enough. WHATWG opinion is that  <br> and <wbr> should be rendered according to 2 brand-new values for this property, which aren't going to be used anywhere else (as I'm not aware of other elements breaking strings OR defininig "string-break opportunities").

…Am I the only one who find something weird in all of this?

(In reply to Andrea Rendine from comment #3)
> …Am I the only one who find something weird in all of this?

Yes.

(In reply to Tab Atkins Jr. from comment #4)
Can't tell you how much I love long replies. So, where's the CSS draft depicting these values ("break-opportunity" and "newline") for display-outside?

(In reply to Andrea Rendine from comment #5)
> (In reply to Tab Atkins Jr. from comment #4)
> Can't tell you how much I love long replies. So, where's the CSS draft
> depicting these values ("break-opportunity" and "newline") for
> display-outside?

I haven't written it yet, as comment #2 said.

I see. Yes, I found an IRC log from Feb 23 where you wrote the same. Is that true that display-outside is not supported by browsers yet, not even in for other values? And that <br> and <wbr> elements would be the only uses for display-outside values "newline" and "break-opportunity" respectively?
 
Anyway, apart from my previous reply, this doesn't apply to W3 HTML5.1 working draft, which still shows the old rendering rule (maybe it's just a matter of not being updated since last July). The problem is, both the display-outside and the element{content} are now impractical solutions, i.e. solutions based on currently un-standardized and unsupported CSS properties.
On the contrary, as I noticed above, a simple element::after{content} seems a base to solve the issue, using standard, supported rules. Is there a reason why this hasn't been proposed? (It's just a layman's request/idea/proposal)

(In reply to Andrea Rendine from comment #7)
> I see. Yes, I found an IRC log from Feb 23 where you wrote the same. Is that
> true that display-outside is not supported by browsers yet, not even in for
> other values? And that <br> and <wbr> elements would be the only uses for
> display-outside values "newline" and "break-opportunity" respectively?

Yes.  It's fine for specs to normatively describe behavior in terms of properties that aren't implemented yet; the browsers will match when they implement the behavior.

And yes, these are the only consumers of those values; the values are being added *for the purpose of describing these elements*.  Right now they're "magic" and do things that are impossible to describe with current styles.  (Or at least, difficult to describe, and sufficiently expensive that browsers won't implement them in the existing terms due to the ubiquity of the elements on the web.)

> Anyway, apart from my previous reply, this doesn't apply to W3 HTML5.1
> working draft, which still shows the old rendering rule (maybe it's just a
> matter of not being updated since last July). The problem is, both the
> display-outside and the element{content} are now impractical solutions, i.e.
> solutions based on currently un-standardized and unsupported CSS properties.
> On the contrary, as I noticed above, a simple element::after{content} seems
> a base to solve the issue, using standard, supported rules. Is there a
> reason why this hasn't been proposed? (It's just a layman's
> request/idea/proposal)

That only works for <br>, and we can't do it because it's possible today to have a "br::after {...}" rule in your page, and making <br> rely on that selector would break such pages.  Also, as I alluded to above, the use of 'content'/etc is actually rather slow and unoptimized; that's fine when you're doing it for a handful of things in your page, but not as acceptable for browsers to use for every <br>.

It doesn't work for <wbr> at all.

(In reply to Tab Atkins Jr. from comment #8)
> in terms of properties that aren't implemented yet
Nor present in official specifications, in this case.

> sufficiently expensive that browsers won't implement them in the existing terms
On <span> elements it is possible to simulate <br> elements. Internet Explorer and Mozilla Firefox also simulate <wbr> the same way. Of course if other browsers implement a UA stylesheet they will also implement this rendering.

> That only works for <br>
See above.

> it's possible today to have a "br::after {...}" rule in your page
Chrome, IE (all modern versions), FF and Opera don't allow rendering for br::after{}. Due to the "magic" of the element, probably, it doesn't allow pseudo-elements, so I don't think anybody has used it, as it'd be useless.

> the use of 'content'/etc is actually rather slow and unoptimized
Is it possible to predict that {display-outside} is implemented more efficiently? Only in that case this assumption is correct.

EC for previous reply
 b) Of course if other browsers decided to use element::after{content} in default UA stylesheet, then they would find a way to implement such rendering, the way IE and FF currently do.

 d) IE (all modern versions) don't allow br::after OR its legacy-compat equivalent br:after

(In reply to Andrea Rendine from comment #9)
> (In reply to Tab Atkins Jr. from comment #8)
> > in terms of properties that aren't implemented yet
> Nor present in official specifications, in this case.
> 
> > sufficiently expensive that browsers won't implement them in the existing terms
> On <span> elements it is possible to simulate <br> elements. Internet
> Explorer and Mozilla Firefox also simulate <wbr> the same way. Of course if
> other browsers implement a UA stylesheet they will also implement this
> rendering.
> 
> > That only works for <br>
> See above.

Ah, sorry, yeah, <wbr> is doable with 'content'.

> > it's possible today to have a "br::after {...}" rule in your page
> Chrome, IE (all modern versions), FF and Opera don't allow rendering for
> br::after{}. Due to the "magic" of the element, probably, it doesn't allow
> pseudo-elements, so I don't think anybody has used it, as it'd be useless.
> 
> > the use of 'content'/etc is actually rather slow and unoptimized
> Is it possible to predict that {display-outside} is implemented more
> efficiently? Only in that case this assumption is correct.

It's not just predictable, it's the explicit reason that browser vendors gave for why they'd prefer a 'display' value.

The rendering of <br> is actually handled specially, in the text rendering code, to make it fast.  Handling a U+000A character in a white-space:pre element is slower.  Thus, implementing <br> in terms of the latter, instead of with the special fast-path, would slow things down.

Implementing it with a special display value is slightly slower than just looking at the tagname, but it's much simpler overall - it's a single keyword on a non-inherited property that needs to be calculated early anyway.

Browsers could, with some difficulty, do more advanced detection, detect the particular combination of properties that <br> has, and use that to do the fast-path linebreak, but it's a lot of complexity for very little gain. Much easier to just add a new display value.

This does make sense somehow. A slow rendering means FOUC on heavy pages, so it's better to have something easy.
Just hope to see it fully specified and implemented soon.

One final request before this bug is closed: will the new display- rendering rule allow <br> and <wbr> to be styled differently? I mean, the spec explicitly says that an author could design a page so that <br> are rendered as "green dots", another could use <wbr> to represent (soft)hyphenated string- or word-break. Will display-outside behavior allow for such a design?

Thanks for the piece of info about vendors. It's the point I had missed.

(In reply to Andrea Rendine from comment #12)
> This does make sense somehow. A slow rendering means FOUC on heavy pages, so
> it's better to have something easy.
> Just hope to see it fully specified and implemented soon.
> 
> One final request before this bug is closed: will the new display- rendering
> rule allow <br> and <wbr> to be styled differently? I mean, the spec
> explicitly says that an author could design a page so that <br> are rendered
> as "green dots", another could use <wbr> to represent (soft)hyphenated
> string- or word-break. Will display-outside behavior allow for such a design?
> 
> Thanks for the piece of info about vendors. It's the point I had missed.

Yup, once you switch your rendering over to looking at the 'display' value rather than checking tagname, that means that if the author sets it to some *other* 'display' value, it'll render as a normal (empty) element with that 'display'.

I guess I'll go ahead and close this, then. ^_^