342531 - Block replaced element margin is overlapped by float

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Paul Armstrong]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/418 (KHTML, like Gecko) Safari/417.9.3
Build Identifier: Gecko/20060508

"display: block" is not being applied to SELECT elements that have the attribute multiple="multiple", though the correct behavior is applied without the multiple attribute.

Reproducible: Always

Steps to Reproduce:
1. create a left floating element with a width X
2. create a multiple select box immediately after that has the attribute multiple="multiple"
3. set the display of the select box to block, with a left-margin of X+10px (10 is arbitrary)

Actual Results:  
The select box is placed X+10px to the right of the floating element

Expected Results:  
The select box should be placed X+10px from the edge of its container (in this case, the FORM), not the right edge of the floating box (in this case, LABEL)

Comment 1

[Brian Polidoro]

Attachment: testcase

I see the behavior described above in this testcase.  It seems like a bug to me.

Comment 2

[Brian Polidoro]

I could not find an existing bug.  Confirming.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060622 Minefield/3.0a1 ID:2006062204 [cairo]

Comment 3

[Mats Palmgren (inactive)]

Attachment: wip1

This "fixes" the reported problem, however I don't think this is the
correct layout...

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 5

[Mats Palmgren (inactive)]

CSS2.1 "9.5 Floats" says that
"The margin box of a [...] block-level replaced element [...] must not
overlap any floats in the same block formatting context [...]" 
http://www.w3.org/TR/CSS21/visuren.html#floats

So it seems to me that the current placement of form control elements
with display:block is wrong.

Comment 6

[Mats Palmgren (inactive)]

Attachment: wip2

I think this patch makes us implement what CSS2.1 says.
All the (non-float) elements line up in the "right column" except the
1st (non-replaced block) and the "LABEL block".
(This patch regresses bug 18445.)

Comment 7

[Paul Armstrong]

@Mats Palmgren (on the CSS definition):

Please see the spec for Block Formatting Contexts 
http://www.w3.org/TR/CSS21/visuren.html#block-formatting

"In a block formatting context, each box's left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box's line boxes may shrink due to the floats), unless the box establishes a new block formatting context (in which case the box itself may become narrower due to the floats)."

Comment 8

[Boris Zbarsky [:bzbarsky]]

Paul, the text you quoted doesn't apply unless form controls are block formatting context roots (which they are not, since they're replaced elements).

Comment 9

[Paul Armstrong]

(In reply to comment #8)
> Paul, the text you quoted doesn't apply unless form controls are block
> formatting context roots (which they are not, since they're replaced elements).
> 

A replaced element means that it is replaced by the Operating System and thus are not allowed to be styled at all. In the Gecko rendering engine, however, this is not the case (as will be with WebKit soon). Gecko draws its own form elements based on the styles provided for them. Therefore, when a style is applied to "display: block" on a form element, it enteres into the block formatting context.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> A replaced element means that it is replaced by the Operating System 

No.  That's not what it means; please read the CSS spec.  For example, <img> is replaced, and there is no "Operating System" involved there.

All being a "replaced element" means is that the internal structure does not necessarily use the CSS box model and that from the box model's point of view the box just has an intrinsic size.  This is the case for <img>, and in Gecko it's the case for form controls.

Now one could try to create a form control implementation in which they are not replaced elements (or at least one could try this for listboxes).  But that's not what Gecko does.

> it enteres into the block formatting context.

I'm really not sure what you mean by that.  The element is in a block formatting context no matter whether it's replaced or not.  The context is rooted at some block formatting context root that's an ancestor of the element.  The part of the spec you quoted would apply if there were a new block formatting context _inside_ the element, but since it's a replaced element there is no "inside" as far as CSS is concerned -- it's just a box with an intrinsic size.

Comment 11

[Paul Armstrong]

(In reply to comment #10)

Maybe I'm lost, but where are you getting this information from? I'm not seeing how what you are trying to say is different than what I'm saying, other than you think that the element should not "necessarily use the CSS box-model." How do you mean "necessarily"? I see no actual recommendations on this activity and would love if you could point me to them.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Maybe I'm lost, but where are you getting this information from?

The Gecko code.

> other than you think that the element should not "necessarily use the CSS
> box-model."

This is because its default behavior cannot be described with said box model.  This applies to pretty much all the form controls.

Comment 13

[Paul Armstrong]

(In reply to comment #12)
> > Maybe I'm lost, but where are you getting this information from?
> 
> The Gecko code.
> 
> > other than you think that the element should not "necessarily use the CSS
> > box-model."
> 
> This is because its default behavior cannot be described with said box model. 
> This applies to pretty much all the form controls.

So you are saying that Gecko does not strive to be in conformance with the W3C recommendations?
I would really like some actual documentation on this... 

I went looking, and apparently the W3C says that CSS2.1 should not be able to change the "intrinsic dimensions" of a replaced element... So we should not be able to change the width and height of any form element, image, etc???

Comment 14

[Boris Zbarsky [:bzbarsky]]

> So you are saying that Gecko does not strive to be in conformance with the W3C
> recommendations?

No, I am saying that the W3C recommendations are insufficient to describe form controls.  This is well documented in the www-style mailing list archives.

Please don't confuse intrinsic dimensions and used dimensions; they're not the same thing.

Comment 15

[Jesse Mullan]

Don't 18445 and 23412 give full justifications for this bug?

All block-level elements, whether replaced or non-replaced, should be positioned as if floats don't exist.  See the relevant section of CSS:
http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-float

Comment 16

[Boris Zbarsky [:bzbarsky]]

> All block-level elements, whether replaced or non-replaced, should be
> positioned as if floats don't exist

Jesse, this isn't actually true in CSS2.1.  In particular, it's false for block formatting context roots and replaced elements (see CSS2.1 section 9.4.1 paragraph 3 last sentence second clause and see also secton 9.5 paragraph 5).  Bug 23412 and bug 18445 were filed based on CSS2; this part of the spec has changed from CSS2 to CSS2.1.

Paul, I'm not sure quite what we're worrying about in our back-and-forth.  The rendering of <select multiple> in Gecko is correct no matter whether it's a replaced element (since if it's not, it clearly doesn't have overflow:visible)...  We do have a bug in the rendering of <select> without multiple (which is clearly a replaced element, since its rendering cannot be described by the CSS box model at all).

Comment 17

[Boris Zbarsky [:bzbarsky]]

Mats, I believe regressing bug 18445 is fine (since it's only a bug per CSS2, assuming a text input is a replaced element), but please mail hixie to verify?  Certainly the current renderings on that testcase don't make very much sense for text inputs...

Comment 18

[Paul Armstrong]

(In reply to comment #16)
> > All block-level elements, whether replaced or non-replaced, should be
> > positioned as if floats don't exist
> 
> Jesse, this isn't actually true in CSS2.1.  In particular, it's false for block
> formatting context roots and replaced elements (see CSS2.1 section 9.4.1
> paragraph 3 last sentence second clause and see also secton 9.5 paragraph 5). 
> Bug 23412 and bug 18445 were filed based on CSS2; this part of the spec has
> changed from CSS2 to CSS2.1.


Thank you for finally pointing out an actual specification. I missed that and admit that I am wrong. However, it appears in light of this that every browser has implemented this incorrectly (Gecko is halfway there). In all honesty, I think the specification by the W3C is just wonky.

Comment 19

[Boris Zbarsky [:bzbarsky]]

There's actually pretty good interoperability for block formatting context roots; not sure about replaced block-level elements.

Please raise specification issues on [e-mail]; if the spec needs changing it's better to say so now rather than later!

Comment 20

[Mats Palmgren (inactive)]

(In reply to comment #17)
Ian confirms that our interpretation of the spec is correct and that
bug 18445 is now invalid. He also added regarded the testcase:
"<label> isn't replaced, right. Neither should <isindex>, actually. 
<fieldset> should be in the right, not because it is replaced but because 
it is a formatting context root."

Comment 21

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

With this patch we render all elements in the right column except:
"non-replaced block", "LABEL block" and "ISINDEX block".

The patch makes <isindex> non-replaced.
(I also verified that <fieldset> is already non-replaced.)

Comment 22

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

I think ISINDEX should probably stay as-is.  It's basically just a block (except for slightly broken intrinsic width behavior); one of the things inside it is replaced, though.

There's no need to add an additional column of indentation to those comments.

Note that XUL boxes also claim to be replaced, but since they probably should be considered BFC roots, this makes sense for them too.

Other than that this looks fine.

Comment 23

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

Comment on attachment 227921 [details] [diff] [review]
Patch rev. 1

Oh, I read your isindex change backwards.  So this looks fine, other than the comment indentation.  r+sr=dbaron

Comment 24

[Mats Palmgren (inactive)]

Fixed the comment indentation. Checked in to trunk at 2006-07-04 20:53 PDT

-> FIXED

Comment 25

[Mats Palmgren (inactive)]

I have added "Testcase #2" to the layout regression test suite on trunk.
layout/html/tests/formctls/bugs/bug342531.html

Comment 26

[Martijn Wargers (dead)]

Attachment: testcase3

This seems to have caused the text inputs and select to not be on one line anymore at:
http://dotnet22099.combell.net/RIS.Web/login.aspx?ReturnUrl=%2fRIS.Web%2fdefault.aspx
Opera9.20 and IE7 do show this all at the same vertical position.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Indeed.  That's exactly this case: form controls with margin and variable-width floats on the left.

That said does IE7 even get the same content?  I rather doubt it, since the page gives us XHTML with the XHTML MIME type.

Comment 28

[Boris Zbarsky [:bzbarsky]]

Note that Opera's behavior on Mats' testcase indicates that it just doesn't implement this part of CSS2.1, for either replaced elements or block formatting context roots.

Comment 29

[Martijn Wargers (dead)]

(In reply to comment #27)
> That said does IE7 even get the same content?  I rather doubt it, since the
> page gives us XHTML with the XHTML MIME type.

I've compared the source between IE7 and Mozilla, they are virtually the same (apart from some trivial differences).
I've read http://www.w3.org/TR/CSS21/visuren.html#block-formatting and
http://www.w3.org/TR/CSS21/visuren.html#floats
I guess I can see sorta that current behavior is correct (although it sucks to be incompatible with IE).

Comment 30

[Martijn Wargers (dead)]

Someone sent me this testcase:
http://pieterhoste.be/firefox_bugs/floating_labels_in_combination_with_display_block_input_fields.html
He mentioned that it works fine in Firefox2, IE6, IE7, Safari3 and Opera9.23.
It doesn't work fine for him in Firefox3b and Opera9.5alpha.