333472 - element width calculation broken (both internally and exposed via offsetWidth) when using CSS width=100% and padding-{left,right}>0px.

Status: RESOLVED DUPLICATE of bug 308687

(Core :: Layout, defect)

Description

[Molle Bestefich]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

The width of any container element (tested with DIV and TABLE->TR->TD) is not taking into account the padding in the container's subelements when subelements are 'width: 100%'.

It makes our web menu render *really* screwy, because stuff like borders on the containers are half-rendered (some of it falls behind the subelements, stuff like that).  It also messes up javascript dynamic width calculations by giving wrong offsetWidth values.


Reproducible: Always

Steps to Reproduce:
Open the HTML file (which I'll attach in one moment) in these browsers:
 * IE
 * Opera
 * FireFox

Actual Results:  
IE:
 TD is 97 pixels, A is 97 pixels, dialog shows "Phew, same size."

Opera:
 TD is 67 pixels, A is 67 pixels, dialog shows "Phew, same size."

FireFox:
 TD is 97 pixels, A is 127 pixels, dialog shows "A element is larger than containing element!"


Expected Results:  
Size of TD should take into account size of contained A element in FireFox.


Workarounds:
Haven't found any that will work cross-browser :-(.

Comment 1

[Molle Bestefich]

Attachment: Test case for bug 333472

Comment 2

[Gérard Talbot]

Molle, You're using a very old Firefox build. "be sure that you've reproduced your bug using a build released within the past three days. Our development process moves at lightning speed, and the bug you've found may already have been fixed."
Bug Writing Guidelines
http://www.mozilla.org/quality/bug-writing-guidelines.html

The testcase you submitted has a lot of css declarations which could be removed.
What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

Your testcase also is also over-declaring, over-defining and is over-constraining the table.


This is the css rule for the link:
			a.menuItem {
				white-space: nowrap;
				display: block;
				text-align: left;
				width: 100%;
				padding-left: 15px;
				padding-right: 15px;
				text-decoration: none;
			}

Now, the document will trigger backward compliant rendering mode in MSIE 6 and MSIE 7 beta 2. That means that IE uses the broken CSS box model.
With a compliant CSS box model, we end up with a box width of 15px + 100% of available space from parent + 15px. That's why there is a 30px difference.

I'm 99% sure this is INVALID.

Comment 3

[Molle Bestefich]

Thanks for the prompt reply :).

> Our development process moves at lightning speed

Honestly, for the last year and a half of using Firefox, it doesn't seem like anything has happened.  Simple bugs, like that annoying sound that BLAST out of my speakers when I search for "quadzxcv" with CTRL-F, that for the love of God CANNOT be turned off, hasn't been fixed.  As far as visible changes go, all that has changed for me since the 0.9 days is that the 'Settings' dialog has become more obscure.  Sorry =).

> Bug Writing Guidelines
> http://www.mozilla.org/quality/bug-writing-guidelines.html

Sorry about that.  I can't reach www.mozilla.org from here for some reason?
I googled "nightly firefox build" and found
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/.

Using the apr10 nightly aka. "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060410 Firefox/3.0a1", these are the results:

TD width 97
A width 127
"Damn, A element is larger then the TD it is placed in!"

So this issue is still present in today's Firefox.

> What is a Simplified Test Case, and How Do I Make One?
> http://www.mozilla.org/newlayout/bugathon.html#testcase

Honestly, I've spent _a lot_ of time simplifying this test case.
I could remove the comments and whitespace (~ 50 lines) and some more CSS.

But that would completely pull the bug out of context, and you guys would have *no* idea why I'm trying to do what I do, so I can't really see how that is a helpful thing to do.

That said, if you really want me to, I can make the test case less explanatory.

> Now, the document will trigger backward compliant rendering mode in MSIE 6
> and MSIE 7 beta 2. That means that IE uses the broken CSS box model.

Hmm, so should FireFox, I imagine?

> With a compliant CSS box model, we end up with a box width of 15px + 100%
> of available space from parent + 15px. That's why there is a 30px difference.

Yes.  I've done more experiments trying to find a way.  Today I tried to workaround Firefox's behaviour by locating the largest A element and resizing the container TD element to the A element's size when rendering in Gecko.

But when I resize the TD, Gecko resolutely resizes the A to again be 30 pixels larger than it's container.

Is there any way to make Gecko render in the non-compliant mode, as a way of making padding + full width possible?

> I'm 99% sure this is INVALID.

With Firefox, there is no way to do this:
 * Have an element fill the entire width of it's parent
 * and (at the same time) use padding on this element to give some space around the text.

Is this correct?

If so, that's really broken from a usability point of view.  Regardless of whether it's INVALID with respect to some arbitrary rendering model.

I hope we can agree on that much..

Thanks again for the prompt reply, looking forward to your response.

Comment 4

[Steve England [:stevee]]

[ As an aside, you can stop the farting sound when searching by changing accessibility.typeaheadfind.enablesound to false in about:config -- also, the anoying sound has been replaced with a system ding in bug 193923 for windows ]

Comment 5

[Molle Bestefich]

Hmm, while I'm waiting for your no doubt enlightened response,
I'd like to reiterate another point :).

Consider the simple setup:
 * A containing element with some amount of border defined
 * An element inside of it with width set to 100% and padding-{right,left} set to a couple of pixels.

Same case as before, we'd like the inside elements to fill the container, the text in the inside elements to be padded a bit, and we'd like the container to have a border.

Firefox actually renders half of the container's border, and the other half is missing - presumably rendered behind the inside elements.

Does it not seem very wrong that the browser breaks in this very simple setup?

> accessibility.typeaheadfind.enablesound

Thanks!!  Wauw!
I'm having a hard time getting my arms down - whee :D!
(And sorry for the bugnoise.)

Comment 6

[Gérard Talbot]

> So this issue is still present in today's Firefox.

Molle, I believe you get in Firefox exactly and accurately what your code is requesting.

> > What is a Simplified Test Case, and How Do I Make One?
> > http://www.mozilla.org/newlayout/bugathon.html#testcase
>
> Honestly, I've spent _a lot_ of time simplifying this test case.

I don't question that.

> I could remove the comments and whitespace (~ 50 lines) and some more CSS.

No, no, that's not it. The wrapping div is absolutely positioned, and has all kinds of weird css declarations like width of 1px and height of 1px, overflow: hidden, etc.. What has all of this to do with your element inside a table cell? What has all of this to do with the summary and description of this bugreport?


			.invisiContainer {
				position: absolute;
				left:0px;
				top:0px;
				overflow: hidden;
				width: 1px;
				height: 1px;
			}

Also your a element is not inline; it is declared as a block level element...

			a.menuItem {
				display: block;

...presumably to make the link clickable, hoverable/reachable/reactive even in the padding area.


> But that would completely pull the bug out of context, and you guys would have
> *no* idea why I'm trying to do what I do,

Molle, the correct thing to do to allow others to see/examine/investigate a possible bug within a webpage context and to show what you're trying to do is to provide the URL of the original webpage. So that we could see the "whole picture".

Over-coding, over-declaring and over-constraining is the first cause/reason why people have layout problems and rendering problems to begin with.

> so I can't really see how that is a
> helpful thing to do.

I can not see how your testcase shows me something. I see a blank page and get 2 alerts; that's it.

You want a cell to expand when its content overflows its requested dimensions. But that's not what your code is really, accurately requesting. Width dimension and overflow (or no overflow) of its content are 2 distinct, separate issues.

You want the link's width to be using 100% of the available width of its wrapping cell and, at the same time, to have the *link* have its own 30px paddding. The logic here is that if the link honors those 2 requirements, then it will by force and by definition be wider (offsetWidth) than its containing cell. CSS width *_does not_* include the padding and that is by definition.

> That said, if you really want me to, I can make the test case less explanatory.

Reduced. Not more explanatory. Simplified. The previously mentioned link explains how to do this.

> But when I resize the TD, Gecko resolutely resizes the A to again be 30 pixels
> larger than it's container.

Molle, that is exactly what your code is asking, requesting too. Resize the cell to be "x" wide and the link will be "x": that's the CSS width. Then, add it + 30px for padding. Again, *_very important_* css width does not include css padding.

> Is there any way to make Gecko render in the non-compliant mode, as a way of
> making padding + full width possible?

full width of what? When you set the link's width to 100%, you're asking the browser to allocate 100%, precisely 100% (not more, not less) of its parent's available width. So, the cell is already filled at that time (assuming you've removed padding and borders of the cell and you did that in your testcase code). Now, if you're adding an horizontal 30px padding on top of that for that link, then the link's offsetWidth will and should exceed the cell dimension, whatever the cell's width is.

> With Firefox, there is no way to do this:
>  * Have an element fill the entire width of it's parent
>  * and (at the same time) use padding on this element to give some space around
> the text.

It will exceed the cell width, just as requested. Read carefully your 2 steps up here. And such dimensioning does not happen "at the same time".

----
Ask yourself what do you want exactly?

link width is cell CSS width - 30px
or
link width is cell CSS width + 30px

and then ask yourself what is your code demanding exactly?

Comment 7

[Gérard Talbot]

Molle, I've created 2 testcases showing the wrong code and corrected code for your needs:

http://www.gtalbot.org/BugzillaSection/Bug333472_3.html

http://www.gtalbot.org/BugzillaSection/Bug333472_4.html

Resolving as DUPLICATE of bug 308687

*** This bug has been marked as a duplicate of 308687 ***

Comment 8

[Molle Bestefich]

Hi

First of all, thank you very much Mr. Talbot for your reply and your work with the test cases!  And for pointing me to bug 308687!


> I believe you get in Firefox exactly and
> accurately what your code is requesting.

According to the W3C box model, yes.

Since my code has no DOCTYPE, Firefox should (and does) render in Quirks mode.
Quirks mode, as I understand it, primarily means "render using the IE5 box model".

Correct?

This does not happen.
To acknowledge this for yourself,
 * Take Bug333472_3.html and remove the DOCTYPE,
 * Compare IE and Firefox.

It doesn't render the same, even though FF is in Quirks mode.

So, Quirks mode bug in Gecko, right?

I'll reopen this issue based on the idea that it's a bug.  I apologize that it took me so long to get to the actual core of the problem - thank you for your help in getting here.

(Test case coming up in a moment.)


> The correct thing to do to allow others to see/examine/investigate a
> possible bug within a webpage context and to show what you're trying
> to do is to provide the URL of the original webpage.

The entire reason that I'm knee deep in this code is that I am doing a major cleanup of a web site (read: trying my best!) before we launch the next version.  This means redoing an old, really screwy Javascript menu with CSS.  Which is why the code is not available online... yet ;-).

I'd be happy to post the JS and CSS that I've conjured up so far, if that's of any help.


> You want the link's width to be using 100% of the available width of its
> wrapping cell and, at the same time, to have the *link* have its own 30px
> paddding. The logic here is that if the link honors those 2 requirements,
> then it will by force and by definition be wider (offsetWidth) than its
> containing cell. CSS width *_does not_* include the padding and that is by
> definition.

I've understood the W3C "width" definition by now (thanks).

The W3C definition being as it is however does not change the fact that we NEED to set the spacing (left/right padding) to some value that is proportional to the font size and not to the browser window width.  That equals saying "fixed pixel padding".


In your example you propose that we use width:auto as a method of getting full width and fixed-pixel padding to play together.

That does not work as a real world solution!  To see why, add a second, small link row to your example.  It will have a large portion inside the menu area (on it's right side) that we need to be clickable, but it's not clickable in IE6 in Standards Compliance mode!

(Test case coming up in a moment.)

Comment 9

[Molle Bestefich]

Attachment: Demonstrating 'width:auto' with multiple menu items

Here's a test case showing why width:auto is not a solution when more than 1 menu item is needed.

(Hope the colors did not have any significance..)

Comment 10

[Molle Bestefich]

Attachment: Demonstration to the effect that display:block breaks FF out of quirks mode

Here's a test case showing that FF does not render using IE5 box model when in Quirks mode.

(Just found out: it seems like it's the display:block that breaks FF..)

Comment 11

[Lee Glasgow]

I am running into the same problem.  I have a div that is set at 100% and if I put padding on it, it gets calculated 100% + the padding. Thus making the div go off the page and make a scrollbar at the bottom of the window.  Looks like width: auto; may fix the issue but it shouldn't have to in the first place.

Comment 12

[Daniel.S]

(In reply to comment #8)
> Since my code has no DOCTYPE, Firefox should (and does) render in Quirks mode.
> Quirks mode, as I understand it, primarily means "render using the IE5 box
> model".
> 
> Correct?

No. In quirks mode, we (as well as Opera and Safari) apply certain quirks to the rendering. That enables us to view more websites that were originally designed for Netscape or older Internet Explorer versions.

We do not try to completly emulate those browsers. Experience tells us that this would be unnecessary.

> The entire reason that I'm knee deep in this code is that I am doing a major
> cleanup of a web site (read: trying my best!) before we launch the next
> version.

Using a doctype is the future-proof way of doing relaunches :)

Anyway, the W3C recognized the need for a box model that is IE5-like, but as far as I know, the methods planned aren't yet deploey wide enough.

> In your example you propose that we use width:auto as a method of getting full
> width and fixed-pixel padding to play together.

Giving that element any height should fix that. See http://www.satzansatz.de/cssd/onhavinglayout.html for some great details on how to cope with IE6 and 7.