Specify br and wbr rendering as magic #2298
Conversation
domenic
added
do not merge yet
Neither? Can't it stay in the phrasing content section?
I guess you mean, whatever is returned by
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.
Per #2291 (comment) results are different if you apply only |
zcorpan
added
the
needs tests
|
I think we need to do more testing to inform what to do here. |
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 |
|
Line breaks in general have bidi implications. |
source
Outdated
| <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 |
There was a problem hiding this comment.
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.
source
Outdated
| <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> |
There was a problem hiding this comment.
Say it "approximately" reproduces?
There was a problem hiding this comment.
Given that things like line-height work probably the best thing to do is to just remove this approximation.
source
Outdated
| }</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 was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
source
Outdated
| <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> |
There was a problem hiding this comment.
... 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.
source
Outdated
|
|
||
| <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> |
There was a problem hiding this comment.
@zcorpan points out that line-height and font-size are honored, so these should be listed as exceptions.
|
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:
Thoughts and help appreciated; the last paragraph in particular could probably be better. |
|
@Nadya678 points out that the Wrt |
|
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 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 |
Further reading on this issue: - w3c/csswg-drafts#610 - whatwg/html#2298 - https://stackoverflow.com/a/45143493/4633524 To test the native behavior of <br> in and out of a flexbox: https://jsfiddle.net/jko4fh9y/
Further reading on this issue: - w3c/csswg-drafts#610 - whatwg/html#2298 - https://stackoverflow.com/a/45143493/4633524 To test the native behavior of <br> in and out of a flexbox: https://jsfiddle.net/jko4fh9y/
|
From my tests, it seems like all browser engines honor |
r12a
added
the
i18n-tracker
Closes #2291.
Marked "do not merge" as we try to work on the following questions.
Editorial questions:
Normative questions:
💥 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
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.