Specify br and wbr rendering as magic #2298

domenic · 2017-01-25T20:51:34Z

Closes #2291.

Marked "do not merge" as we try to work on the following questions.

Editorial questions:

Does this belong in the Widgets section, or the Replaced elements section? Both seem rather similar.
Did I use "used style" correctly? Should it be "computed" instead? I always get these confused.

Normative questions:

What are the "bidi implications" that I deleted about? Do we need to add those back somehow?
"No CSS properties affect this element's rendering." This is not true across browsers. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4837 shows line-height affecting br in different ways in Edge and in Blink (no effect in Gecko), and wbr seems to be styled as a red box in Edge and a box in Gecko. Should we hold this as an ideal and submit some reftests, perhaps? In the intersection, none of the tested CSS properties appear to apply reliably.

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 7:57 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Parsing MDN data...
Parsing...

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

zcorpan · 2017-01-25T22:12:04Z

Does this belong in the Widgets section, or the Replaced elements section? Both seem rather similar.

Neither? Can't it stay in the phrasing content section?

Did I use "used style" correctly? Should it be "computed" instead? I always get these confused.

I guess you mean, whatever is returned by getComputedStyle? In CSSOM that is called "resolved style", which can be used style or computed style depending on the property... but it's not clear to me it's a good idea to include these rules in the first place.

What are the "bidi implications" that I deleted about? Do we need to add those back somehow?

I think what is considered a bidi paragraph, and yeah, we need to be careful not to break that here. Can check in more detail later.

In the intersection, none of the tested CSS properties appear to apply reliably.

Per #2291 (comment) results are different if you apply only line-height (without display:block). I don't want to assume that the Web doesn't depend on this. 😐

zcorpan · 2017-02-02T12:26:20Z

I think we need to do more testing to inform what to do here.

tabatkins · 2017-02-03T00:12:26Z

What are the "bidi implications" that I deleted about? Do we need to add those back somehow?

Actually, that note is about setting the 'content' property on those elements. Assuming that property simply doesn't work on these, then there are no bidi implications, and the line was safe to remove.

zcorpan · 2017-02-03T07:08:33Z

Well it depends on whether the "bidi implications" were an unimportant side-effect or if it was deliberate. I remember something about br and bidi, but need to look up what happened there.

fantasai · 2017-02-16T18:07:20Z

Line breaks in general have bidi implications.   specifically breaks the bidi “paragraph”. It was previously defined not to (in HTML4) but this was found to be Web-incompatible, IIRC.

tabatkins · 2017-03-14T20:57:04Z

source

+   <p>However, this is not part of the user agent stylesheet rules, as inspecting the used style
+   of <code>br</code> and <code>wbr</code> elements does not give any of the above values.</p>
+
+   <p>(Note also that this depends on the as-of-yet unimplemented ability to specify the


You can just move the 'content' declaration to a ::before pseudo; there's no real need for it to be specified on the element itself.

tabatkins · 2017-03-14T20:57:18Z

source

+  <p>No CSS properties are expected to affect the rendering of these elements.</p>
+
+  <div class="note">
+   <p>The following CSS snippet reproduces the above expectations:</p>


Say it "approximately" reproduces?

Given that things like line-height work probably the best thing to do is to just remove this approximation.

fantasai · 2017-03-14T21:06:06Z

source

+}</pre>
+
+   <p>However, this is not part of the user agent stylesheet rules, as inspecting the used style
+   of <code>br</code> and <code>wbr</code> elements does not give any of the above values.</p>


There are in fact use cases for allowing more CSS control over these elements (see @AndySky21's comments in w3c/csswg-drafts#610). So I would suggest allowing a UA to implement it with CSS rules, even if that's neither required nor expected atm. In which case, the note shouldn't say that these styles are necessarily undetectable. (This is very unlikely to be or become a Web-compat issue.)

When we have multi-implementer interest in implementing these in a way that detectably shows up in getComputedStyle, we'll allow (or enforce) that in the standard, but until then it's best to spec the interoperable reality that they do not.

fantasai · 2017-03-14T21:06:12Z

source

+  <h4>The <code>br</code> and <code>wbr</code> elements</h4>
+
+  <p>The <code>br</code> element is expected to render as a line break, ignoring the effect of the
+  <span>'white-space'</span> property.</p>


... expected to render as a forced line (and bidi paragraph) break.

“line break” is ambiguous, because the Unicode Line Separator (U+2028) breaks a line but doesn't break the bidi paragraph.

fantasai · 2017-03-14T21:06:14Z

source

+
+  <p>The <code>wbr</code> element is expected to render as a line break opportunity.</p>
+
+  <p>No CSS properties are expected to affect the rendering of these elements.</p>


@zcorpan points out that line-height and font-size are honored, so these should be listed as exceptions.

Closes #2291.

domenic · 2017-03-14T21:18:39Z

OK, I posted a new version of this that omits the CSS equivalent, hopefully talks properly about bidi line breaks, and has a vague paragraph about what properties apply. The text ends up being:

The br element is expected to render as a forced line (and bidi paragraph) break, ignoring the effect of the 'white-space' property.

The wbr element is expected to render as a line break opportunity.

Most CSS properties do not affect the rendering of these elements; however, some such as 'line-height' and 'font-size' seem to do so under some circumstances. The exact specification for which properties apply is still being determined.

Thoughts and help appreciated; the last paragraph in particular could probably be better.

fantasai · 2018-03-20T22:53:18Z

@Nadya678 points out that the display property is also supported, insofar as it can be set to none: w3c/csswg-drafts#610 (comment)

Wrt , it looks like Webkit/Blink-based browsers override an inherited white-space: nowrap and create a line-break opportunity anyway, but Edge/IE/Gecko do not. I want to run this test on Netscape 4 now... see http://fantasai.tripod.com/FHQR/HTML/misc.htm#NOBR which dates from like 2000 or so. More ancient references can be found with https://www.google.com/search?q=netscape+nobr+wbr

fantasai · 2018-03-20T23:01:32Z

More fun archaeology: https://bugzilla.mozilla.org/show_bug.cgi?id=6347#c29

frivoal · 2018-08-20T15:25:19Z

another nuance in "Most CSS properties do not affect the rendering of these elements; however, some [...] seem to do so under some circumstances":

In Firefox (but not Chrome), the margin property applies to . This can be useful for a (somewhat rough) solution to wakachi-gaki, a practice often found in Japanese books (including textbooks) for children and language learners which consists of putting half an em or an em worth of whitespace between words. Japanese does not normally have interword spaces, but marking word boundaries with  is a semantically reasonable thing to do, which then allows wbr {margin-right: 1em;}, possibly combined with word-break: keep-all, to enable word-by-word line breaking, rather than the usual character-by-character line breaking.

I don't think this is gives a perfect rendition of wakachi-gaki, but it's a useful approximation.

TL;DR: I wouldn't ban the margin property from applying to .

Further reading on this issue: - w3c/csswg-drafts#610 - whatwg/html#2298 - https://stackoverflow.com/a/45143493/4633524 To test the native behavior of in and out of a flexbox: https://jsfiddle.net/jko4fh9y/

andreubotella · 2022-09-19T12:54:33Z

From my tests, it seems like all browser engines honor display: none on   elements; and they will not render anything for display: contents, even if the   element has contents.

mtrootyy · 2024-09-27T09:12:34Z

When will this pull request be merged?
Shouldn't even only removing of br { display-outside: newline; } and wbr { display-outside: break-opportunity; } be preceded?

domenic added do not merge yet Pull request must not be merged per rationale in comment topic: rendering labels Jan 25, 2017

domenic requested a review from zcorpan January 25, 2017 20:51

domenic mentioned this pull request Jan 25, 2017

UA style for and #2291

Open

zcorpan added the needs tests Moving the issue forward requires someone to write tests label Feb 2, 2017

zcorpan mentioned this pull request Feb 15, 2017

[css-display] Display values for and w3c/csswg-drafts#610

Closed

tabatkins reviewed Mar 14, 2017

View reviewed changes

fantasai suggested changes Mar 14, 2017

View reviewed changes

Specify br and wbr rendering as magic

304931b

Closes #2291.

domenic force-pushed the br-wbr branch from f566047 to 304931b Compare March 14, 2017 21:17

domenic mentioned this pull request Apr 20, 2017

Test computed styles from user agent stylesheet? web-platform-tests/wpt#5625

Open

zcorpan mentioned this pull request Jun 15, 2017

BR and WBR style refers to "display-outside" which is no longer present in CSS Display Module #2749

Closed

domenic mentioned this pull request Oct 20, 2017

Specify br and wbr rendering as magic #3145

Closed

domenic mentioned this pull request Oct 21, 2018

The CSS rules for wbr/br uses a display-outside property which no longer exist. #4110

Closed

jdm mentioned this pull request May 7, 2020

Rendering CSS for br/wbr uses nonexistent property display-outside #5521

Closed

frivoal mentioned this pull request Jul 31, 2020

codepen.io - Text is wrapped webcompat/web-bugs#56012

Closed

domenic mentioned this pull request Dec 15, 2020

wbr should cut through nowrap unconditionally #6227

Open

Base automatically changed from master to main January 15, 2021 07:56

Zynton mentioned this pull request Mar 22, 2021

[FIX] ensure is never identified as a block odoo-dev/odoo-editor#165

Merged

domenic force-pushed the main branch from 0947339 to 1b5099f Compare July 27, 2021 17:07

zcorpan mentioned this pull request Apr 7, 2022

add a test for br { content: "" } web-platform-tests/wpt#33555

Merged

r12a added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Sep 21, 2022

w3cbot mentioned this pull request Sep 22, 2022

Specify br and wbr rendering as magic w3c/i18n-activity#1594

Open

myfonj mentioned this pull request Apr 4, 2024

codepen.io - Floating line break rendering mismatch (Firefox vs Chrome) webcompat/web-bugs#135460

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Specify br and wbr rendering as magic #2298

Specify br and wbr rendering as magic #2298

domenic commented Jan 25, 2017 •

edited by pr-preview bot

Loading

zcorpan commented Jan 25, 2017

zcorpan commented Feb 2, 2017

tabatkins commented Feb 3, 2017

zcorpan commented Feb 3, 2017

fantasai commented Feb 16, 2017

tabatkins Mar 14, 2017

tabatkins Mar 14, 2017

domenic Mar 14, 2017

fantasai Mar 14, 2017

domenic Mar 14, 2017

fantasai Mar 14, 2017

fantasai Mar 14, 2017

domenic commented Mar 14, 2017

fantasai commented Mar 20, 2018 •

edited

Loading

fantasai commented Mar 20, 2018

frivoal commented Aug 20, 2018

andreubotella commented Sep 19, 2022

mtrootyy commented Sep 27, 2024


		<p>The <code>wbr</code> element is expected to render as a line break opportunity.</p>

		<p>No CSS properties are expected to affect the rendering of these elements.</p>

Specify br and wbr rendering as magic #2298

Are you sure you want to change the base?

Specify br and wbr rendering as magic #2298

Conversation

domenic commented Jan 25, 2017 • edited by pr-preview bot Loading

💥 Error: Wattsi server error 💥

zcorpan commented Jan 25, 2017

zcorpan commented Feb 2, 2017

tabatkins commented Feb 3, 2017

zcorpan commented Feb 3, 2017

fantasai commented Feb 16, 2017

tabatkins Mar 14, 2017

Choose a reason for hiding this comment

tabatkins Mar 14, 2017

Choose a reason for hiding this comment

domenic Mar 14, 2017

Choose a reason for hiding this comment

fantasai Mar 14, 2017

Choose a reason for hiding this comment

domenic Mar 14, 2017

Choose a reason for hiding this comment

fantasai Mar 14, 2017

Choose a reason for hiding this comment

fantasai Mar 14, 2017

Choose a reason for hiding this comment

domenic commented Mar 14, 2017

fantasai commented Mar 20, 2018 • edited Loading

fantasai commented Mar 20, 2018

frivoal commented Aug 20, 2018

andreubotella commented Sep 19, 2022

mtrootyy commented Sep 27, 2024

domenic commented Jan 25, 2017 •

edited by pr-preview bot

Loading

fantasai commented Mar 20, 2018 •

edited

Loading