46217 - {ib}border don't show with inline specified + some tags [INLINE]

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Vincent Jaubert]

with this style sheet:
div.a {display: inline;border-style: solid}

div.b {display: block;border-style: solid}

and this code:
<div class="a"><p>block a</p></div>
<div class="b">block b</div>

the border of the block a don't show.
this bug doesn't happen when the display:inline is removed (but it's still the 
default), or when the <p></p> tags are removed. It works also with others tags 
like <div> or perhaps other (i havn't made furthers tests)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

One could argue that it's correct that it doesn't show - the CSS spec isn't
clear on this.  The question comes down to whether you should generate block
frames for inlines that contain blocks, to contain the blocks.  I'd need to
think about it, and maybe ask www-style (not that I'd expect an answer...).

However, I don't like the current layout of the example - the inline border is
being shown on the line below the paragraph.  Why?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: the testcase

Comment 3

[Hixie (not reading bugmail)]

That *is* strange -- it should either appear both before and after the <p>, or
it should not appear at all. I would go with the first, due to empty inline
considerations. But the second makes sense too.

Having said that... Future? We have much bigger fish to fry...

Comment 4

[Greg K.]

I guess I reconfirm this using FizzillaCFM/2002070913. In block a, a border is
drawn around an empty inline box, while the "block a" text is down on a line by
itself quite outside the border. Setting All/All.

Was it ever decided if inline boxes can contain block boxes and what that means?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that now the border appears only before the <p>.

The reason for that is that we don't create the second inline of an ib split
unless it's actually needed, and it's not needed in this case....

Changing that would be easy, but do we want to?

Comment 6

[Boris Zbarsky [:bzbarsky]]

The issue from comment 5 got fixed in bug 480323.  Is there anything left here?  Our behavior looks correct per current CSS2.1 spec now...

Comment 7

[Mats Palmgren (inactive)]

FWIW, our current layout for the testcase is compatible with Chrome.
Comment 6 suggests this layout is spec compliant.
Please file a new bug if there is a newer CSS spec that says otherwise.