Skip to content

[css-text] Should <wbr> create a break opportunity in nowrap? #3562

Closed

Description

@kojiishi
<style>
div {
  width: 10ch;
}
.nowrap {
  white-space: nowrap;
}
</style>
<div class="nowrap">1234567<wbr>7654321</div>

Should this create two lines? Blink/WebKit create two lines, while Edge/Gecko do not.

Activity

  1. fantasai commented on Jan 28, 2019

    @fantasai
    Collaborator

    I seem to recall that WBR was historically used to provide breaks inside a NOBR. I imagine there's a lot of pre-CSS pages that rely on this, I'm not sure what the modern compat requirements are. Some interesting discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=656960 and https://bugzilla.mozilla.org/show_bug.cgi?id=6347 I think this is technically a question for HTML, though.

  2. upsuper commented on Jan 29, 2019

    @upsuper
    Member

    It's worth considering what it means for inlinization if we allow it to break lines in ruby.

    Although it is technically a question for HTML, it can still interact with CSS features like inlinization, so ideally we should be able to map it with some CSS mechanism.

  3. fantasai commented on Jan 29, 2019

    @fantasai
    Collaborator

    WBR is a breaking opportunity, not a break. I don't think it causes any problem with ruby. :)

  4. frivoal commented on Jan 30, 2019

    @frivoal
    Collaborator
    • Doing what Blink does is certainly web compatible (and follows the historic precendent that @fantasai mentioned)
    • if you want the alternative behavior despite that markup, you can display: none the <wbr>, so authors are not stuck.
    • Given that the white-space property applies to inlines, and <wbr> with that behavior is reasonably described as something like <span style=white-space:normal>​` (or the same on its ::before or ::after), so no particular magic needs to be involved
    • The same logic applies with white-space: pre instead of white-space: nowrap
    • Relatedly <wbr> introduces a word break even with word-break: keep-all (and that also works in Firefox)

    I agree with @fantasai that no change is needed in css-text to support the existence of an element that behave like that. A clarification in the HTML spec seems like the right place. The right bug to discuss this is probably: whatwg/html#2291

  5. fantasai commented on Dec 14, 2020

    @fantasai
    Collaborator

    Filed whatwg/html#6227 as a follow-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions