98621 - 100% width div causes horizontal scroll bar to appear

Status: RESOLVED DUPLICATE of bug 98617

(Core :: Layout, defect)

Description

[shelby]

1. Horizontal scroll bar should not appear.  For some reason the 100% width 
<DIV> is made to extend beyond the right edge of window.  See the horizontal 
bar at topmost edge of the following web site for example of 
the problem:

http://downloadfast.com/bugzilla.php

2. window.innerHeight is returning a value that assumes the horizontal scroll 
bar is not displayed.  You can verify this by navigating the dhtml menu "All 
Categories -> Engineering -> Programming -> Language" and notice that the last 
menu item is chopped by the horizontal scroll bar.  The chopped off menu is 
positioned according to window.innerHeight.

I think this probably depends and is caused by Bug#: 98617

I was not sure whether to classify this as Layout or HTML Element.

Comment 1

[Andreas M. "Clarence" Schneider]

Cannot reproduce with 2001-09-06-03, Win NT.
But note: 100% + 2 x 1px border > 100%.

Comment 2

[shelby]

Are you saying the horizontal scroll bar does not appear 2001-09-06-03, Win NT?

Did you have the browser full screen at 800x600?

I can reproduce on WinMe.

Also the border and margins MUST be included in a 100% width style, else there 
would be no way to set a 1 pixel border on a 100% width box.  What do you 
propose 98% width + 1% border?  1% != 1px

If that is not stated explicity in CSS2 then it HAS to be implied, else it 
should be considered a bug in CSS2.  Unless I am mistaken, CSS2 does not allow 
arithmetically specified lengths, e.g. {width:100%-2px;} is not valid.

Comment 3

[shelby]

I am cross-referencing to Bug#98617, because the second example mentioned there:

http://downloadfast.com/bugzilla2.php

illustrates another case where width:100% is not honored on same DIV.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Also the border and margins MUST be included in a 100% width style

No, they must NOT (nor should padding).  Please see: 

http://www.w3.org/TR/REC-CSS2/box.html#box-dimensions
and
http://www.w3.org/TR/REC-CSS2/visudet.html#the-width-property

> else there would be no way to set a 1 pixel border on a 100% width box.  What
> do you propose 98% width + 1% border?  1% != 1px

#mybox { border-width: 1px; display: block; margin-left: 0; margin-right: 0;
         padding-left: 0; padding-right: 0; width: auto }

Very simple.  Will give us a box that has the same width as the content area of
the parent from left edge of left border to right edge of right border (which is
what you seem to want).

Setting QA to hixie; I believe this is invalid.

As for window.innerHeight, that sounds like it may be a bug.  Please file a
separate bug on just that one issue on the DOM Mozilla Extensions component.

Comment 5

[Andreas M. "Clarence" Schneider]

> Are you saying the horizontal scroll bar does not appear 2001-09-06-03, Win NT?

Now it appears. Probably there was an external script missing because of some
network problem.

Comment 6

[shelby]

Thank you, Boris Zbarsky 2001-09-07 06:50, for giving me the theoretically 
correct CSS2 to achieve 100% width box with px length border and padding.  
Before we can say this aspect of this bug report is invalid, I need to test 
your suggested CSS2, as I will do shortly and report back here.

However, I believe the original part #1 of bug report is still valid in the 
inverse logic.  The DIV was specified as width:100%, yet the width of the DIV 
is not 100% of the contain block (it just barely extended past edge of 
window).  You might argue that the containing block is reduced by the 
float:left image, but CSS2 says display:block elements are unaffected by floats:


  "Since a float is not in the flow, non-positioned block boxes created before
  and after the float box flow vertically as if the float didn't exist.
  However, line boxes created next to the float are shortened to make room for
  the floated box."

The other problem with your suggested CSS2 is that width:auto will be taken as 
0 for all but display:block.  Thus I see no way to achieve the image on the 
left because as I understand display:block will, if implemented according to 
CSS2 spec, place the box on the next line.

Also I want to suggest that instead of closing this bug and opening a new one 
for window.innerHeight and lose all this context, just re-assign this bug 
should it be proven that part #1 is invalid.

Lastly, standards are great thing to shoot for, especially when they work.  So 
far Mozilla doesn't work and IE does.  If it takes this much work to get 
something to work, and you are going against IE's 95% installed base, one has 
to question the wisdom of such.  Luckily I am very persistant to try to help 
Mozilla stay in the game (which is commercially silly and I do run very 
profitable internet business...imagine that!).

I want to pursue this until we find out definitively the variables, not be so 
quick to dismiss it as invalid because we think that the CSS2 spec is holy 
grail.  Mozilla has to be proven to work wholely as the spec says first.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> The DIV was specified as width:100%, yet the width of the DIV 
> is not 100% of the contain block

width:100% means the content area of the div is 100% of the content area of the
containing block per CSS2.  The width of the div on the page is margin + border
+ padding + content.  So a div with width:100% and borders would overflow its
containing block as you saw.  This is correct behavior per spec.

> The other problem with your suggested CSS2 is that width:auto will be taken as 
> 0 for all but display:block.

Sure...  Why would you not be using display:block?

> Thus I see no way to achieve the image on the left because as I understand 
> display:block will, if implemented according to CSS2 spec, place the box on
> the next line.

Not unless you set the "clear" property on the block box.  That whole business
about floats being out of normal flow means that block boxes are laid out as if
the float were completely not there.

> Also I want to suggest that instead of closing this bug and opening a new one 
> for window.innerHeight and lose all this context, just re-assign this bug 
> should it be proven that part #1 is invalid.

That would make it very difficult to read this bug and determine what it's
about.  That would make verifying its fix when it's fixed painful for QA. 
Please do not mutate bugs.

> So far Mozilla doesn't work and IE does.

I'm sorry, but Mozilla is not working in your case due to what I perceive as
some fundamental misunderstandings of CSS on your part...  This is not meant as
criticism as much as letting you see my point of view on the issue.

> Mozilla has to be proven to work wholely as the spec says first.

That's why I set QA to hixie.  He's the standards-compliance guy.  :)

Comment 8

[shelby]

Boris beat me to the conclusion, I was just about to say that I realized that 
Mozilla was using 100% of the entire window for the original bugzilla.php case, 
and I did not realize it (because I couldn't not see how much of the box was 
obscured by the image).  However, after doing the bugzilla4.php case as 
mentioned in the cross-referenced Bug#98617, this became apparent to me.

Once again (as mentioned in bug#98617) I really do not appreciate when you 
personalize the facts.  You said you weren't going to do that any more.  Stop 
trying to characterize it as me having a big personal misunderstanding with 
the "correct" CSS2.  As the discussion in Bug#98617 shows, I am thinking about 
many different cases and have raised some serious concerns about CSS2 and 
Mozilla's implementation.  For one the issue of the float being completely 
removed for block boxes, makes it impossible to specify block box which would 
be 50% of the remaining content area, at least in Mozilla's implementation.  
This for one thing illuminates the need to either be able to specify % width on 
inline boxes, or some other solution....

Any way, I am not going to try to completely restate the discussion going on in 
Bug#98617 here.  I just think our discussion would be more productive if you'd 
avoid the occassional underhand slander.

I came here to say that I know agree that the scroll bar was appearing in this 
case, because the width exceeded the window size and this was correct.  Now 
whether the width should be exceeding the window size is another issue, but I 
think the discussion in Bug#98617 is already headed into more detail about 
that, so this bug should be closed asduplicate of bug #98617.  Then let's carry 
on the discussion there.

In particular I want to see what you have to say about the apparent 
inconsistencies I've raised there.

If someone wants to refile the window.innerHeight bug as separate bug, be my 
guest.  I am not interested in pursuing that bug as it seems to consume quite a 
lot of effort to defends one's bugs here in this system and I want to stick 
with what I think are the make or break issues for Mozilla.

Comment 9

[shelby]

Trying to mark as duplicate bug.  Don't know if I have permission.

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