Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Block replaced element margin is overlapped by float

RESOLVED FIXED

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: Paul Armstrong, Assigned: Mats Palmgren (vacation - back in August))

Tracking

({css2, testcase})

Trunk
css2, testcase
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

11 years ago
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

11 years ago
Created attachment 226824 [details]
testcase

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

Comment 2

11 years ago
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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
Created attachment 226952 [details] [diff] [review]
wip1

This "fixes" the reported problem, however I don't think this is the
correct layout...
Created attachment 226953 [details]
Testcase #2
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.
Keywords: css2
Created attachment 226954 [details] [diff] [review]
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.)
(Reporter)

Comment 7

11 years ago
@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

11 years ago
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).
(Reporter)

Comment 9

11 years ago
(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

11 years ago
> 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.
(Reporter)

Comment 11

11 years ago
(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

11 years ago
> 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.
(Reporter)

Comment 13

11 years ago
(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

11 years ago
> 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

11 years ago
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

11 years ago
> 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

11 years ago
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...
(Reporter)

Comment 18

11 years ago
(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

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

Please raise specification issues on www-style@w3.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."
Assignee: nobody → mats.palmgren
Summary: The correct behavior for display: block is not applied to SELECT elements that have the attribute 'multiple="multiple"' → Block replaced element margin is overlapped by float
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.)
Attachment #226952 - Attachment is obsolete: true
Attachment #226954 - Attachment is obsolete: true
Attachment #227921 - Flags: superreview?(bzbarsky)
Attachment #227921 - Flags: review?(bzbarsky)
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
Attachment #227921 - Flags: superreview?(bzbarsky)
Attachment #227921 - Flags: superreview+
Attachment #227921 - Flags: review?(bzbarsky)
Attachment #227921 - Flags: review+
Fixed the comment indentation. Checked in to trunk at 2006-07-04 20:53 PDT

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
I have added "Testcase #2" to the layout regression test suite on trunk.
layout/html/tests/formctls/bugs/bug342531.html
Created attachment 274935 [details]
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

10 years ago
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.
Flags: in-testsuite?

Comment 28

10 years ago
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
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).

Updated

10 years ago
Blocks: 385858
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.
You need to log in before you can comment on or make changes to this bug.