1502610 - Unnecessary line break when using negative margins on an inline-child of an inline-block element

Status: NEW

(Core :: Layout: Block and Inline, defect, P3)

Description

[Markus Stange [:mstange]]

Attachment: screenshot from Respec specification

I don't know if this behavior is per spec, but it differs from Chrome.

Steps to reproduce:
 1. Load this testcase: data:text/html,<span style="display:inline-block"><span style="margin-right:-1px">Two words</span></span>

Expected results:
The text "Two words" should be within one line.

Actual results:
There is a line break between "Two" and "words"

Chrome has no line break.


I encountered this issue on https://w3c.github.io/navigation-timing/#issue-container-generatedID-3 where Respec's default styling hits this bug on certain types of references.

Comment 1

[Markus Stange [:mstange]]

Attachment: testcase

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: further testcase

I haven't dug through the spec, but experimenting a bit further I'd say Chrome's behavior (shared by Safari, FWIW) seems pretty weird. Try gradually increasing the negative right margin using the slider in this example, and watch how the second testcase (with spaces in "w o r d s") behaves... makes no sense, afaict.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Edge never breaks, but never shrinks the inline-block either.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

I wonder what Chrome's new engine does. If somebody has Canary around (I tested edge via browserstack) it can be turned on from the chrome://flags page.

If it does something different it'd be wonderful :-)

Comment 5

[Mats Palmgren (inactive)]

Chrome's LayoutNG does a line break.

Comment 7

[Mats Palmgren (inactive)]

Fwiw, I re-tested this in the latest Canary with LayoutNG enabled
and it's still compatible with Firefox, so hopefully they'll ship
that soon :-)

Comment 8

[Marcos Caceres [:marcosc]]

Indeed, Chrome LayoutNG works like us... I filed a bug on the W3C to fix their stylesheet. It feels like we are doing the right thing here (bug in Safari then ;) ).

Comment 9

[fantasai]

It feels like we are doing the right thing here

Um. I'm pretty sure the testcase here should pass. The point of shrink-to-fit sizing is to size the box to fit its content exactly without triggering any unforced line breaks. We're sizing to fit the content, we're just failing to fit the content into the resulting custom-fitted size... I'm guessing because the "extra space" created by the negative margin isn't accounted for when we're placing the text.

Comment 10

[Marcos Caceres [:marcosc]]

I'm not able to reproduce this via the following anymore in Nightly (web render enabled):
https://w3c.github.io/navigation-timing/#issue-container-generatedID-3

Maybe it got fixed by something else?

Comment 11

[Jonathan Kew [:jfkthame]]

Not sure what's changed about the example at https://w3c.github.io/navigation-timing/#issue-container-generatedID-3, but Markus' testcase here (attachment 9020527 [details]) still fails on Nightly for me.

Comment 12

[Markus Stange [:mstange]]

(In reply to Jonathan Kew (:jfkthame) from comment #11)

Not sure what's changed about the example at https://w3c.github.io/navigation-timing/#issue-container-generatedID-3

The content was updated so that respec is no longer "offended" by the element, and it was also regenerated with a version that includes the following workaround for this very issue:

/* TODO: Remove once https://github.com/w3c/tr-design/pull/176 is merged. */
.respec-offending-element a[href] {
  margin: 0;
}

Comment 13

[Jonathan Kew [:jfkthame]]

While it's nice that the original site has been modified to work around the issue, the underlying bug in Gecko (as per comment 9) is still present. We should fix this.

Comment 14

[Daniel Holbert [:dholbert]]

This bug has been filed several times. I think bug 871224 may be the original bug, but it's got some word-wrap: break-word fanciness which may make it its own thing, so for now I'll dupe this to the more-recent bug 1406116 (which is a bit simpler).

Comment 15

[Daniel Holbert [:dholbert]]

Actually, yeah, bug 871224 is definitely the same bug. Adjusting dupe target to bug 871224.

Comment 17

[Daniel Holbert [:dholbert]]

Sorry, my mistake -- per bug 871224 comment 27, it turns out Chrome has changed behavior and matches us on that bug's testcases now. So this is not a dupe of that bug after all.

I'll dupe this family of bugs (which have unexpectedly-linewrapped text, with intrinsic sizing & margin-right & padding-right) to this bug here.

Comment 20

[Kaspar Etter]

Both Chrome and Firefox break the words with data:text/html,<span style="display:inline-block"><span style="margin-right:-1px">Two words</span></span>, while Safari doesn't.

However, if you use data:text/html,<span style="display:inline-block"><span style="padding-right:1px;margin-right:-1px">Two words</span></span>, only Firefox breaks the words.

This is a problem for me at https://explained-from-first-principles.com/email/tools/#dkim-record. Please fix! 🙂

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 23

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 24

[Robert Bryer]

I've noticed this bug affecting the subtitles on the BBC website — I'm going to work around it by removing the negative margins from the subtitles, but I think this bug is still causing problems in the wild.

Comment 25

[Robert Bryer]

Attachment: Subtitles breaking on BBC

Comment 26

[nigel.megitt]

I've been looking at this with Robert Bryer and agree that this bug is causing us a significant subtitle and caption rendering issue, only on Firefox.

Additional observation: the unwanted line break happens with a negative margin only on the edge that the direction is pointing to, i.e. margin-right for direction: ltr and margin-left for direction:rtl.

If we do what he suggests and remove the negative margin, then we will not be able to render conformant to the subtitle spec (see EBU-TT-D Annex D) on any browser unless we try to detect the presence of this bug. If we leave it as is, then it will be conformant on other browsers, but unusably broken on Firefox. I would back the request to increase the severity of this bug.

Comment 27

[nigel.megitt]

Further observation: merely moving the last character on the line into a separate <span> and shifting the negative margin to that <span> causes the behaviour to look normal, i.e. it avoids the line wrap. That inconsistency also looks like a bug!