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.
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)
The select box is placed X+10px to the right of the floating element
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)
Created attachment 226824 [details]
I see the behavior described above in this testcase. It seems like a bug to me.
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]
Created attachment 226952 [details] [diff] [review]
This "fixes" the reported problem, however I don't think this is the
Created attachment 226953 [details]
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 [...]"
So it seems to me that the current placement of form control elements
with display:block is wrong.
Created attachment 226954 [details] [diff] [review]
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.)
@Mats Palmgren (on the CSS definition):
Please see the spec for Block Formatting Contexts
"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)."
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).
(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.
> 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.
(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.
> 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
This is because its default behavior cannot be described with said box model. This applies to pretty much all the form controls.
(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???
> So you are saying that Gecko does not strive to be in conformance with the W3C
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.
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:
> 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).
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...
(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.
There's actually pretty good interoperability for block formatting context roots; not sure about replaced block-level elements.
Please raise specification issues on firstname.lastname@example.org; if the spec needs changing it's better to say so now rather than later!
(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."
Created attachment 227921 [details] [diff] [review]
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.)
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 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
Fixed the comment indentation. Checked in to trunk at 2006-07-04 20:53 PDT
I have added "Testcase #2" to the layout regression test suite on trunk.
Created attachment 274935 [details]
This seems to have caused the text inputs and select to not be on one line anymore at:
Opera9.20 and IE7 do show this all at the same vertical position.
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.
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.
(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
I guess I can see sorta that current behavior is correct (although it sucks to be incompatible with IE).
Someone sent me this testcase:
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.