936450 - Inline boxes containing only collapsed whitespace shouldn't have margins, borders and padding

Status: NEW

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

Description

[Khazar]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)
Build ID: 20131022185104

Steps to reproduce:

Visit https://gajim.org/index.php?lang=he

Notice second bar (cyan color).


Actual results:

The following menu
<div class="menu">
     <span>
     <a href="index.php?lang=he">בית</a>
     </span>
     <span>
     <a href="screenshots.php?lang=he">תמונות מסך</a>
     </span>
     <span>
     <a href="downloads.php?lang=he">הורדה</a>
     </span>
     <span>
     <a href="docs.php?lang=he">תיעוד</a>
     </span>
     <span>
     <a href="http://trac.gajim.org/wiki?lang=he">ויקי</a>
     </span>
     <span>
     <a href="dev.php?lang=he">פיתוח</a>
     </span>
   </div><!-- menu -->

Appeared like so:
 בית   תמונות   מסך   הורדה   תיעוד    ויקי פיתוח


Expected results:

That menu should appear like this:
 בית   תמונות   מסך   הורדה   תיעוד    ויקי   פיתוח

This menu appears properly with WebKit based browsers.  FF and MSIE do not display it properly.

Interestingly, MSIE 6 (no less!) DOES display this menu properly, just like WebKit does, as if Microsoft is now using Gecko as a rendering engine for advanced versions of MSIE! (busted?).

Comment 1

[Khazar]

Added '' to distinguish hyperlink items:

Actual results:
 'בית'   'תמונות מסך'   'הורדה'   'תיעוד'    'ויקי' 'פיתוח'


Expected results:
 'בית'   'תמונות מסך'   'הורדה'   'תיעוד'    'ויקי'   'פיתוח'

I stand corrected, "תמונות מסך" is a hyperlink, not two.

Comment 2

[Loic]

Where is the issue? The space between the words?

Could you make a screenshot of what you're seeing?

Comment 3

[Khazar]

Space between ויקי and פיתוח.

Comment 4

[Khazar]

Attachment: Good view with vimprobable2 (WebKitGTK) and IE6

Comment 5

[Khazar]

Attachment: Bad view with Firefox and MSIE (9 or 10)

Comment 6

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 7

[Loic]

Attachment: Testcase #2 (improved)

It's an issue with dir="ltr" and some spaces in the source code.

In the case #2, I have included a carriage return (enter) before each </span>.
With dir="ltr" (and "auto"), the margin-right of 40px is not displayed.
With dir=rtl", it is.

Comment 8

[Simon Montagu :smontagu]

Attachment: Testcase #1 with added punctuation

So first of all, the way to fix this is to add dir="rtl" to the <div class="menu"> on the site. This is not a workaround, it's the right thing to do: imagine for the sake of argument that each menu item began with "^" and ended with "$" as in this testcase. In that case even in Webkit the "$" after "פיתוח" jumps to the far right of the menu line, and that is where the margin-right of that span is too.

The open question is whether this should also happen with whitespace (as in Gecko) or not (as in Webkit).

Comment 9

[Simon Montagu :smontagu]

I can't find anything explicit in the spec, but what makes the most sense in my opinion is that after bidi reordering splits an inline element into multiple lineboxes, any linebox that contains only collapsed whitespace should be ignored when positioning the margin, borders and padding of the element.

Comment 10

[Boris Zbarsky [:bzbarsky]]

I'm not clear on the new summary. In this case:


  data:text/html,some<span style="margin: 20px; border: 5px solid blue"></span>text

the margin and border certainly need to show up, no?

Comment 11

[Simon Montagu :smontagu]

Suggestions for making the scope of the summary clearer but not too longwinded are welcome. http://www.w3.org/TR/CSS21/visuren.html#inline-formatting talks about "Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline"

Comment 12

[Boris Zbarsky [:bzbarsky]]

Are you talking about _line_ boxes or _inline_ boxes?  Those are two different things...

Comment 13

[Simon Montagu :smontagu]

inline

Comment 14

[Boris Zbarsky [:bzbarsky]]

Then how is the text in comment 11 relevant?

Comment 15

[Simon Montagu :smontagu]

i thought it was analogous.

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK, but we don't want to do this in all cases, as the testcase of comment 10 clearly shows..

So what cases _do_ we want to do it in?  Empty continuations created by bidi processing, basically?

Comment 17

[Simon Montagu :smontagu]

I don't know if this is only about continuations created by bidi processing or not. The summary of Bug 385649 sounds similar, but I don't understand its testcase.

Comment 18

[Simon Montagu :smontagu]

Correction to comment 17: The summary of bug 385469 sounds similar, but I don't understand its testcase