Csswg-drafts: [css-display] Display values for <br> and <wbr>

[AndySky21]

display-outside values

<br> and <wbr> elements were originally meant to be rendered according to a content property. That was first changed for <br>, probably because content is not optimized for performance. Nor was that property usable with ::after for legacy reasons: it could break those pages using br::after, because authors' rule would override the line break instead of adding something to it. The pseudo-element could have been used for <wbr>, though.

On September 2014, when <br> had been turned into display-outside: newline since at least two months, it was decided that <wbr> could become something similar: and thus display-outside: break-opportunity was born.

Two years have passed and still there's no trace of either display value. Googling it out, I noticed that it was discussed briefly on Feb 23, 2015 (one year and a half ago), when performance considerations were the only obstacle to reverting both elements back to the content scenario (and as of now content apparently applies to real elements only with image and URL values - which is not sure either).

Now I'd like to ask you a couple of questions:

1. Was the display-outside solution deemed not viable, despite the fact that browser vendors would have preferred such a solution? What are the considerations against it?
2. In case it cannot be used, how likely is it that content: <string> applies to at least a subset of HTML elements and how bad would the performance impact be?
3. Will either of the scenarios above be compatible with HTML spec concept of styling <br> (and possibly <wbr>)?

Related issue: https://github.com/w3c/html/issues/586

[fantasai]

Further discussion at https://lists.w3.org/Archives/Public/www-style/2016Mar/0378.html and https://lists.w3.org/Archives/Public/www-style/2016Mar/0379.html

Note that the Web platform specs have had a longstanding tradition that the behavior in a spec is required, but the specific algorithms used to implement it are not. It is entirely possible for the CSS and HTML specs to describe <br> and <wbr> in terms of existing 'content' and 'display' constructs, but for an implementation to treat them specially internally for optimization. Imho it would be better to go this route than to create one-off display types that may then have to be maintained indefinitely once they are no longer needed by contemporary implementations.

[fantasai]

The CSSWG concluded that we are not adding new display types for <br> and <wbr> as their behavior can be adequately explained by existing CSS rules such as those listed in the above discussion, and a new display type is an unnecessary burden to carry over in the Web platform forever. Engine optimization of this implementation is of course already allowed, and to simplify this the spec can specify all: unset !important; for the UA style sheet to prevent any author modification. Thus

br { all: unset !important; display: contents !important; content: "\a" !important; white-space: pre !important; }
wbr { all: unset !important; display: contents !important; content: "\200B" !important; }

should be enough to implement this in the HTML spec.

[frivoal]

As mentioned in https://github.com/w3c/csswg-drafts/issues/610#issue-183231355, a remaining issue is that the content property does not normally apply to elements; it only works on pseudo elements. However, the suggested UA stylesheet uses that. So how does it work?

[dbaron]

I don't think https://github.com/w3c/csswg-drafts/issues/610#issuecomment-274911199 is an accurate reflection of the WG discussion, key excerpts of which were:

dbaron: what's the use case of authors customizing this stuff?
TabAtkins: none
dbaron: do we want to do this then at substantial cost?
dbaron: if you want to do "it's this CSS thing and we exlpain it this way but you can optimize" then we have to write code for every <br> we ned to check to see if the stars align, 50 different checks, which may defeat the optimization in the first place
dbaron: we survived for 20 years with it being magic and we can survive another 20
fantasai: we should spec behavior, unspec author's behavior potential changes
fantasai: or like the UA stylesheet has !important and can't be change
astearns: what's the value?
fantasai: then authors know what it means and have expectations
TabAtkins: we could say <br> and <wbr> are magic, but you can reproduce with this: ______________
...
astearns: RESOLVED: keep <br> and <wbr> magic, but add an explainer about how to mimic the results

(Yes, @fantasai proposed an alternative in the [...] bit, but I don't think we accepted that in the resolution.)

[dbaron]

Er, I guess I got confused -- I suppose it is basically equivalent, although the description above is much less clear that implementations are allowed (perhaps even expected) to have a different implementation. However, it only works under the assumption that it's actually true that no CSS properties apply -- except I'm not sure it is.

[fantasai]

@frivoal The content property applies to elements in Level 3, no?

[frivoal]

It does for now, but that spec “is a very rough draft, and is not ready for implementation” (cf its status section). By the time it matures, I expect it will no longer allow it, at least not without some syntax shenanigans, because of a major web compat problem.

The problem is that lots of sites who meant to write this something like this

.clearfix::after {
     content: ".";
     visibility: hidden;
     display: block;
     clear: both;
     height: 0;
}

would instead write:

.clearfix {
     content: ".";
     visibility: hidden;
     display: block;
     clear: both;
     height: 0;
}

Same thing without the ::after pseudo. Of course, that does not work, but that does not prevent people from leaving it behind in their stylesheets. Some other part of the cascade overrides the visibility/height or whichever part of their variant of clearfix would break the site, but nothing stands in the way of the content property.

If we were to make content apply to elements, a non negligible part of the web would be replaced by "." or " " or ""...

I believe presto-based opera actually tried, and rolled it back because of that. I have not checked recently if that was still true, but I would be surprised if it had gone away. That would be a good surprise, but a surprise still.

[tabatkins]

By the time it matures, I expect it will no longer allow it, at least not without some syntax shenanigans, because of a major web compat problem.

We actually explicitly resolved to not allow content: <string>; on ordinary elements. As you say, there's a web-compat issue, and also it was considered to not have any real use-cases.

[Crissov]

content: attr(alt); does have use-cases and attr(alt) isn’t really different from <string>. → #729

[tabatkins]

attr(alt) is a specific instance of <string>, yes.

[fantasai]

Here.

br, wbr { all: unset !important; display: contents !important; white-space: pre !important; }
br::before { all: unset !important; content: "\a" !important; }
wbr::before { all: unset !important; content: "\200B" !important; }

Any further problems?

[frivoal]

Given that existing browsers do not let authors set the content property on br::before or wbr::before, this will not conflict with existing pages (and the !important part actually explains why authors cannot override it), so it seems safe.

I guess the only potentially observable differences between this and and “br and wbr are magic” is what happens when you inspect their styles via the OM. Which I don't think is something people do a lot for these elements, if at all.

[zcorpan]

Further problem is that all: unset !important is wrong. There's also something about bidi paragraph break and br that should be preserved when changing how this is defined...

https://github.com/whatwg/html/issues/2291#issuecomment-275245995
https://github.com/whatwg/html/pull/2298

[AndySky21]

wbr::before { all: unset !important; content: "\200B" !important; }
This means that it won't be possible to style wbr with symbols like soft hyphenation and use it as a standard-text syllable word break opportunity, right?

[tabatkins]

Correct, it's rendered "magically" with equivalent effects to that code.

Use ­ to get soft-hyphen symbols when appropriate.

[AndySky21]

As I said above, the problem with soft hyphen is that it behaves erratically when text is copypasted. It might be turned into a hyphen, or generate a mojibake. That's why I hoped wbr could be an alternative.

[tabatkins]

The technique will still work if you use an element other than <wbr> (such as a <span class=wbr>, or a custom element with a shorter, easier name). You just can't use <wbr> itself if you want to customize its styling, because of the magic rendering.

[Nadya678]

display: contents !important;

... so it seems safe.

No, it cannot be used. I use for three years br{display:none} to stop break lines. br{display:inline /* or block */ } starts to break lines. It works in IE, EDGE, Cr, Moz and other browsers. It is sometimes helpful for smartphones.
display: contents; /*without important*/ can be used.

Before write an official definition of stylesheet of <br/> and <wbr/> please test IE/EDGE, Moz and Cr behaviour. Part of styles is applicable. For example display and... are used. All "!imprtant" cause them to stop work.

BTW. <br clear="all"/>? Also !important? Style clear:both also overriden by unset !important???

https://stackoverflow.com/questions/7596647/ignore-br-with-css
https://stackoverflow.com/questions/34876140/a-css-way-of-using-br-clear-all-on-divs-without-heights

[BananaAcid]

wbr::before and the same for br, does not work for me in Chrome. As it does not work for img.