[css-text-3] Line breaking with <br> handled differently.

[faceless2]

I thought by now I had the humble <br> element pretty well understood, but apparently not. Please take a look at https://jsbin.com/jupalic/edit?html,css,output

I'm adding a forced line break (a preserved newline character) after an inline that has already overflowed the line - the question is, do I get one line break or two?

It seems that the <br> element has some special properties I can't reproduce with any other element, as implemented in Chrome/Firefox/Safari anyway. If I follow the overflowing content with a <span>, it will begin on a new line (as it should), and I get two line breaks. But if I follow the overflowing content with a <br>, it is not moved to a new line before being applied, and I get one line break.

The behaviour of <br> should be entirely determined by CSS according to #610, so I think this is an issue. It might be there is some special HTML rule here that I've missed, although I tested with XHTML and got the same result.

Note test B gives different results in Gecko and Blink - the difference appears to be whether the break opportunity before an item of zero width (the left edge of the span) is taken.

EDIT:

For clarification, I'm aware that <br> is known to have magical properties - the point of this issue is that those magical properties cannot be duplicated with regular CSS, against the resolution in #610: RESOLVED: keep <br> and <wbr> magic, but add an explainer about how to mimic the results

[faceless2]

Oh sorry! Thanks @frivoal.

[Loirooriol]

those magical properties cannot be duplicated with regular CSS

But isn't that the point of being magic? If the behavior could be explained with regular CSS, it wouldn't be magic.

[faceless2]

After reading #610 I believe the intention of the magic was performance - the magic means you can't give a BR content, or change it's display, but the functionality itself could be defined in CSS and - as the resolution said - you should be able to "mimic the results".

Fantasai gave a definition in CSS of how to do that, but this issue shows that's incomplete. Without being able to mimic it, any non-HTML XML syntax that uses CSS for layout is going to be unable to reproduce the functionality of BR, which doesn't seem right.

Edit: another key quote from 610: "...their behavior can be adequately explained by existing CSS rules such as those listed in the above discussion". I don't think that's the case.

[faceless2]

After some more testing, the behaviour of <br> can be fully defined by the existing CSS rules from issue 610 plus one additional rule - a break before a <br> element is not allowed.

I don't know how much appetite there is for this, but - if fully defining the behaviour of <br> in CSS is desirable - can I suggest a new property:

inline-break-before: avoid | auto

which would determine if a break opportunity exists before the inline element it's applied on.

Setting this to "avoid" on a <br> would fully define the current behaviour. I know single-purpose properties are not wanted, but this would also be useful for several other situations:

• Currently a break opportunity exists between two replaced inlines or inline-blocks. This property, perhaps with a corresponding inline-break-after, would suppress the break opportunity without having to use additional markup to wrap the two elements with a white-space: nowrap.

• There are situations where generated content must be kept with the previous text, no matter what. I'm specifically thinking of footnote call in GCPM, but I'm sure there are others. As the content is generated, it won't always be practical to require markup that wraps both the content and its previous sibling with white-space: nowrap.

[faceless2]

Have just been pointed towards https://drafts.csswg.org/css-text-4/#wrap-before - which does exactly what I was suggesting. A default rule on "br" of wrap-before: avoid would fix this, so I am closing this issue.