html
html copied to clipboard
whatwg
Specify br and wbr rendering as magic
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.
:boom: Error: Wattsi server error :boom:
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:
:rotating_light: Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
:link: 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.
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 https://github.com/whatwg/html/issues/2291#issuecomment-275245995 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. 😐
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.
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.
Line breaks in general have bidi implications. <br> specifically breaks the bidi “paragraph”. It was previously defined not to (in HTML4) but this was found to be Web-incompatible, IIRC.
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.
@Nadya678 points out that the display property is also supported, insofar as it can be set to none: https://github.com/w3c/csswg-drafts/issues/610#issuecomment-364315417
Wrt <wbr>, 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
More fun archaeology: https://bugzilla.mozilla.org/show_bug.cgi?id=6347#c29
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 <wbr>. 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 <wbr> 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 <wbr>.
From my tests, it seems like all browser engines honor display: none on <br> elements; and they will not render anything for display: contents, even if the <br> element has contents.
