Closed Bug 48634 Opened 24 years ago Closed 13 years ago

window.innerWidth should not include scrollbar space

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: chris, Unassigned)

References

(
URL
)

Details

(Keywords: dom0, Whiteboard: see comment 51 for the gist of the bug)

Attachments

(1 file, 4 obsolete files)

Testcase. Finally.
915 bytes, text/html
Details 
It is impossible to consistently center dynamically positioned content.  When
the vertical scrollbar appears, it moves the content of the page to the left by
half the scrollbar's width.  Not only is it visually jarring when a page's
content expands vertically to force the creation of a scrollbar, and tables and
such set to fill the width of the browser jump, but the failure of
window.innerWidth to account for the scrollbar makes it impossible to accurately
position dropdown menu layers over a centered page, for example.

Keeping the scrollbar on the screen at all times and greying it out when not
needed may in fact be the only way to keep content centered accurately in all
cases.  Otherwise, by the time the page is parsed to determine whether a
scrollbar is needed, dynamic positioning has already occurred and cannot account
for a scrollbar.  See testcase:

<html>
<head>
</head>
<body>
<div align="center">These sentences should line up.</div>
<div id="Layer1" style="position:absolute; left: 0px; top: 30px">These sentences
should line up.</div>
<script language="JavaScript">
document.getElementById("Layer1").style.left=Math.floor(window.innerWidth/2)-94;
</script>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>They do when there is no scrollbar (hit refresh).</p>
<p>But not with a scrollbar (make your browser window smaller and refresh
again).</p>
<p>This is not a problem in IE or NN4!</p>
<p>&nbsp;</p>
</body>
</html>

    
    

    
  
(Note. If a web page is doing its dynamic positioning only once, onload, then
it is badly designed. Scrollbars are the least of your problems -- what about
resizing the window? This does not affect the validity of this bug, however.)

Chris -- you were looking at something similar to this yesterday, no?

    
    

    
  
I believe this one belongs to danm, reassigning.
Assignee: jst → danm

    
    

    
  
You ask for the simplest possible test case, so that is what I gave you.  I 
could not agree more that "if a web page is doing its dynamic positioning only 
once, onload, then it is badly designed," which is why in an actual site I use 
the onResize event to reposition layers whenever the browser is resized.  
This repositioning would work perfectly if this bug were fixed, so at this point 
scrollbars are, in fact, my only problem.

    
    

    
  
confirming using the 2000081508 nightly on win2k
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
cc evaughan, jrgm

    
    

    
  
->future
Target Milestone: --- → Future
Keywords: dom0

    
    

    
  
The Mozilla "bouncing scrollbars" feature creates an insolvable problem in some 
existing e-commerce site designs.

The problem worked around because of the combination of 2 "features":
1) the width of a page cannot be calculated by any means
   (even the browser does not know it until the page is fully loaded)
2) FRAME: "scrolling = yes not implemented: forced scrollbars don't show up"

The "bouncing scrollbars" breaks frames designs that are as basic as having 2 
rows with proportionally aligned content.
Proportional alignment is a necessity wherever a window is resizable or the 
screen size is not fixed, both of which are fundamental boundary conditions on 
the web.

As commercial e-commerce site providers, we are extremely disappointed that some 
misguided Mozilla designers are prepared to break compatibility with all other 
browsers in the market (Priority: 3, Target Milestone: Future).
We are also disappointed that such a basic arithmetic failure can get beyond the 
design stage.

We recognise and appreciate the efforts of the Mozilla team in the area of DOM 
and CSS standards compliance.

However, for us, these CSS and DOM related improvements are overshadowed by more 
basic issues such as this.

    
    

    
  
This is a DOM level 0 bug that I think should be fixed by mozilla1.0.  Who's
against me?  Let's argue.  How hard is it?  Maybe there are others who can help,
so that danm doesn't have to do all the work.

/be
Keywords: mozilla1.0

    
    

    
  
How exactly does vertical scrollbars break window.innerWidth? I don't see
window.innerWidth behaving any differently in mozilla vs NS 4x, or is the
problem simply that you can't force scrollbars to always show up in a frame with
scrolling=yes? If so, a bug summary change would be in order since this doesn't
really have anything to do with window.innerHeight, unless I missed something
obvious.

    
    

    
  
Lack of scrolling=yes support is bug 44306.

/be

    
    

    
  
I'm confused. Then this bug is about what?

    
    

    
  

      
      
      
      

        Attached file
          
        modified testcase; (obsolete)
        — 
      

    


  
The behaviour of 'innerWidth' is identical in Nav4.x and mozilla: it returns
the width of the viewport independent of the presence of a vertical scrollbar.
In other words, the presence or absence of a scrollbar does not change the
value returned from window.innerWidth for a given window size.

The issue in the testcase, where the two blocks of text line up when no
scrollbar is present, but don't line up when the vertical scrollbar is present
is actually because the interpretation of '<div align="center">' differs
between Nav4.x and mozilla: in Nav4.x, "centering" was done based on the same
width that innerWidth would return (i.e., the text was placed in the same
screen horizontal position independent of the presence of a scrollbar); in
mozilla, the centering takes the presence of the vertical scrollbar into
account (i.e., it center's the text on the visible canvas of the browser).

Internet Explorer avoids the whole issue with its "always-on" vertical
scrollbar. [Personally, I'm not averse to mozilla changing over to use an
"always-on" vertical scrollbar, but that is outside the scope of this bug].

    
    

    
  
"always on" vertical scrollbars is bug 72540.
Depends on: 72540

    
    

    
  
So this is really a layout bug then isn't it? Maybe we could have a quirk mode
dependent positioning algorithm for "center" stuff that could take care of this?

    
    

    
  
Changing summary (someone fix it better if I didn't).  Who should get this bug?

/be
Summary: Vertical scrollbar breaks window.innerWidth → Vertical scrollbar breaks align=center

    
    

    
  
ahh, John, after reading comment 13, is this the problem I see in bug 104012?

    
    

    
  
<center> layout problem, over to Layout.
Assignee: danm → attinasi
Component: DOM Level 0 → Layout
QA Contact: desale → petersen
Target Milestone: Future → ---
Target Milestone: --- → mozilla1.0

    
    

    
  
Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla1.0 → mozilla1.1

    
    

    
  
If bug 62536 fixes a IE compatible 'clientWidth' that would be a solution?
Depends on: 62536
No longer depends on: 72540

    
    

    
  
This is still a problem in 1.1alpha.  This is a real pain for my pages which use
a centered table.  This page: http://www.chem.ucdavis.edu/chemclub/ has a
scrollbar, and this page:
http://www.chem.ucdavis.edu/chemclub/PicnicDay/index.htm does not.  And they are
not centered the same...even though, in my mind at least, they definitely should be.

The appearance or lack thereof of a scrollbar should not affect the presentation
of the page in any way.  For example, changing screen resolutions could add or
remove a scrollbar on the page...and this would change the centering of the
table on the page...something that needs to be fixed.

    
    

    
  
Re: Comment #21
I went to http://www.chem.ucdavis.edu/chemclub/ and I saw a ... huh... not so
well designed page. For very little content, 4 levels of nested tables are used
(mostly for formatting and positioning), 3 functions all named refresh(),
align="center" and <center> is used at least 20 times, <font> and all sorts of
old coding manners, MacroMedia cross-browser functions,etc.etc. This is what
anyone can see when viewing the source code:
                        </u></span></div>
                    </td>
                  </tr>
                </table>
              </td>
            </tr>
          </table>
        </center>
      </td>
    </tr>
  </table>
</center>
<center>

This bugzilla place is not a newsgroup forum to get help in order to code
properly, this is not a newsgroup or some kind of place where one can complain.
I checked the code of that chem.ucdavis.edu page: I removed all the javascript
functions and reloaded the page and no horizontal scroll bar at all. So the
problem has to be in the use of these functions.

This bugzilla place is about identifying real bugs by getting first a clear and
precise explanation of the problem, creating good and clear test cases and
solving bugs. It seems clear to me (after reading comment #13 and examining
attachment 62036 [details]) that this bug 48634 was and is invalid.

    
    

    
  
Re: Comment #22

Regardless of the beauty of the html on those pages (and they meet the W3C's
HTML 4.01 standard), the problem is not with the horizontal scrollbar, nor is it
with the vertical scrollbar.  You obviously did not take the time to actually
read what I had written.

The problem is with the centering on those two pages.  Technically, the main
table on each page should be centered EXACTLY the same.  However, since one page
has a vertical scrollbar (as there is more content than can be shown
vertically), the table is shifted over.  This is MOST DEFINITELY a bug.

I don't need you to lecture me about the use of bugzilla.  I am perfectly aware
of how to use it, and I was in no way asking for your advice.  This remains a bug.


    
    

    
  
Re: Comment #22
The main issue of this bug has been made sufficiently clear by now.

It is genarally invalid and unacceptable practice to conclude from debatable
side issues that the main issue is not valid. 

The comment #22 is right in that "This bugzilla place is not a newsgroup forum"
where these things usually happen. Please apply to self.

    
    

    
  
Doug, I was expecting a demo, a solid test case, you know, something clearly
demonstrating the bug. You pointed out 2 pages at your chemclub. Nowhere do you
indicate to use a high resolution for both pages (even at 1024x768, I didn't see
your problem). Geez.. your problem appears in a particular context and IMO has
nothing comparable to crashes, which are "a real pain".

Most people here won't work on long and complex pages trying to figure out
what/where is the bug, etc... for many reasons. They'll first design a good
solid test case enlightening the problem and work on it from there. Is that
reasonable, sensible?

When you say "The appearance or lack thereof of a scrollbar should not affect
the presentation of the page in any way.", you seem to suggest, if I understood
you right, that you want centering to be within the client area, not within the
window.innerWidth (browser's viewport), which is what Mozilla already does.

Any element which is absolutely positioned is taken out of normal flow, that
means removed from the body element: therefore, the dimensions of the root
element could increase (depending on many factors) while body element dimensions
will decrease. That's just 1 example among many subtilities involved with DHTML,
scrollbars, positioning, repaint,etc.

Read J. Morrison's excellent comment: innerWidth has nothing to do with presence
or absence of scrollbars. innerWidth returns "the width of the (browser)
viewport independent of the presence of a vertical scrollbar. In other words,
the presence or absence of a scrollbar does not change the value returned from
window.innerWidth for (any) given window size." On top of that, one can even
figure out what's the size of this browser viewport before even loading any
document because window.inner* properties have nothing to do per se with the
loaded or to-be-loaded documents. That was true in NS 4.x and that is still true
for the latest Mozilla/NS versions.
In NS 4.x, centering is done in the browser viewport, innerWidth/Height, which
is *independent* of the presence or absence of scrollbars. In Mozilla/NS6+, the
centering is done in the client area, in the content area without scrollbars if
present. 

All of this means that the problem can be worked around. And this also means
that Mozilla's way of centering elements is correct as it centers elements
within the client area, not the browser viewport. And that means NS 4.x had the
bug (just imagine for a second that vertical scrollbar would be 200px wide:
elements would be perfectly centered within the content area in Mozilla, NS 7
while elements would not look centered at all within the content area in NS 4).

A demo case is coming.

    
    

    
  


  
Resize/Maximize your browser to generate/remove vertical scroll bar when trying
the demo. Observe the 7th line which is repositioning within the client area,
line up vertically with all the others. To better view the lining up, highlight
all 7 lines and then resize your browser. Tested with Mozilla 1.1alpha on
Windows XP, with different video monitor screen resolutions, different text
sizes (View/Text Zoom), standards compliant mode (strict 4.01 DTD).

Fair enough?

    
    

    
  
Re: Comment #26
Thank you.  Your testcase just revalidated my point.  When you resize the
browser window to add or remove the vertical scrollbar, the text shifts.  This
should not be happening.  The presence or absence of the scrollbar should not
affect where the text is centered, yet it does.

My point with the chemclub pages was to show that, when you compared the two
pages, one with a scrollbar and one without (at least at my resolution of
1280x1024), the table is centered differently.

I still feel that this is a bug.

    
    

    
  
If you need more discussion about what I am talking about, see bug 72540 and bug
76197.  Both are very closely related to what I'm talking about here.

This DOES need to be fixed.

    
    

    
  
How does this depend on bug 62536?

I believe this should depend on (or is a duplicate of) bug 72540. That bug has
been resolved INVALID (after much debate), meaning this one should be resolved
INVALID, too.


    
    

    
  
Bug 72540 was resolved as WONTFIX, on the premise that bug 76197 would be fixed
in its place.

    
    

    
  
WONTFIX, INVALID, whatever. My point stands: I believe we do not need this bug
to remain open.


    
    

    
  
Doug, you said "When you resize the browser window to add or remove the vertical
scrollbar, the text shifts. This should not be happening." All 7 lines shift
because the client area (width) is changing due to the appearance or
disappearance of the vertical scroll bar: 6 of them are repositioned *in real
time, continuously* thanks to normal flow layout or due to css, the 7th one
thanks to javascript event handling where the onresize is fired only on mouseup
(see bug 114649). I'm convinced repositioning could be achieved in real time,
continuously by using css (need a demo case? I might have one).

I tried to understand what exactly you mean with "The presence or absence of the
scrollbar should not affect where the text is centered, yet it does." (I think
your wish is closely related to the way your pages work.) Elements are centered
or not depending on a related/referenced system of coordinates: it could be
centered within their nearest parent element, within their offsetParent node,
halfway inside the whole width of the body (often referred as page or canvas),
halfway inside the width of the root element (referred as the document), within
the browser viewport (client area, rendering area, viewing area, content area,
innerWidth/Height, browser window, etc.. are loose synonyms used often) or even
within the user's video display monitor screen. When people say "I want this
element to be centered", I often wonder "centered within what exactly?",
"content or element itself within another containing element?",etc.. I can
create pages where the body element will have a scroll bar while the html
element won't but will have asymetrical margins and padding: again, the question
will be how this or that element should be centered, in relation to which
referenced coordinates system.

Doug, definitively less than 10% of all people use a resolution of
1280x1024resolution of
1280x1024. And your problem will only shift elements left or right of a distance
equivalent to half the width of the vertical scroll bar, which is 8 pixels
within Mozilla-based browsers. Just compare to the people who crash... Besides,
I'm sure your page could be rebuild to work around this problem.

Bug 62536 is about elements, not the root element: AFAIK (anyone who wants to
correct me, go ahead), there are no plans for now to implement
clientWidth/Height for the root element. Anyway, I believe one doesn't even need
to have access to this property if one can figure out in a reliable manner if
there is a scrollbar (or not) in the rendered viewport and what are the margins
and padding values for the html and body elements.

    
    

    
  
RE: Comment 32

Ok...let me clarify.  I believe, and many comments in the other bugs that I've
mentioned support my belief, that the centering should be happening in the
browser viewport.

Let me quote from comment 35 of bug 72540:
"Lets assume a family of pages where the content is centered in a constant-width
table.  The length of the table depends on the content to be displayed.  Some
pages have enouh content to force a scrollbar, most do not.  There are graphical
elements placed at the top and bottom of each table for navigation.

When the scroll bar is present, the entire document (which is centered and
constant-width) shifts over by half the width of the scroll bar.  This means
that the navigation elements have now moved, and if the visitor is rapidly
clicking through a series of these pages, the mouse cursor may no longer be over
the nav graphic (or worse, over a different graphic, such as jump-to-last-page).

There is no way to fix this problem in Mozilla, at least no way that I can think
of.  IE does not have this issue because of the permenant vertical scroll; NS4
and Opera reserve the scroll space, making the table appear slightly off-center
but at least its position is fixed.  Mozilla causes the table to jitter between
pages, and this is unacceptable for me.

It is my opinion as a web designer that there should be a CSS rule or BODY tag
that reserves vertical-scrollbar space.  Whether or not it should be *default*
behavior is not my concern."

Ok...I hope that clarifies my concern.  This bug has nothing to do with
resolutions or dynamic repositioning.

    
    

    
  
> It is my opinion as a web designer that there should be a CSS rule or BODY tag
> that reserves vertical-scrollbar space.

Since there is already such a thing (the value "-moz-scrollbars-vertical" for
"overflow"), I believe this should be resolved INVALID.

No longer depends on: 62536

    
    

    
  
Ok...so could you point me to where this (-moz-scrollbars-vertical) is
explained?  Or explain it?

Thanks.

    
    

    
  
That would be an appropriate thing to ask on the newsgroups.

You could always experiment with it.


    
    

    
  
After experimenting around with "-moz-scrollbars-vertical", I still think that
this is not a valid workaround.  The fact of the matter remains that mozilla's
innerWidth fails to account for the scrollbar space...and this causes the
problem...I still think that this, and/or bug 76197 are valid.

    
    

    
  
This will be my last comment on this bug. I just won't repeat myself over and
over. The basic arithmetic "failure" has been implemented in the demo case I
submitted. So, it's up to people to proceed accordingly with that. <center> and
the align="center" attribute are deprecated (except for sub-table elements).
Even frames started to be "deprecated" as soon as strict 4.01 (target attribute
is no longer supported for the a element).

As far as I'm concerned, the main issue of the problem involved as been clearly
explained as soon as J. Morrison brought in comment #13.

And yes, the browser's inner window dimensions (that includes margins, borders,
padding on the root element and on the body of a document to be loaded - plus
scrollbars if they show up) can be determined before any document gets loaded.

As far as I'm concerned, the content area, the client area can be determined in
real time without problems regardless of what happens with bug 62536 and
regardless if Mozilla intends to support
document.documentElement.clientHeight/Width. I even have several demos on all this.

IMO, this bug should be resolved INVALID.

    
    

    
  
Changing summary to zero in on what appears to be the only potentially valid
issue here.

OS: Windows 2000 → All
Summary: Vertical scrollbar breaks align=center → window.innerWidth should not include scrollbar space

    
    

    
  
so... the testcase worksforme.  Once I stop resizing, the lines all line up. 
With or without the scrollbar.  This suggests that window.innerWidth is indeed
not including the scrollbar space...  Am I missing something?

    
    

    
  
RE: Comment 40
The problem is not with the testcase by itself.  The problem is that when you
compare the same testcase:

1) Without a vertical scrollbar
and
2) Resized with a vertical scrollbar

the text shifts over half the width of the scrollbar.  The problem occurs when
you compare the two pages.

    
    

    
  
No, that's bug 72540 / bug 76197.  What's the innerWidth problem this bug is
referring to?

    
    

    
  
RE: Comment 40
Also...as comment 13 points out, and after further review, I don't believe the
problem is with window.innerWidth, but rather, Mozilla's implementation of
"centering":

"in Nav4.x, "centering" was done based on the same width that innerWidth would
return (i.e., the text was placed in the same screen horizontal position
independent of the presence of a scrollbar); in mozilla, the centering takes the
presence of the vertical scrollbar into account (i.e., it center's the text on
the visible canvas of the browser)."

    
    

    
  
Re: Comment 42

OK...I think this bug should just be marked a duplicate of bug 76197.

As far as I can tell window.innerWidth has no problem.  Bug 76197 should take
care of the problems that I am seeing, as long as it gets fixed.

Can someone assure us that bug 76197 will get fixed if this bug is closed?
Depends on: 76197

    
    

    
  
I think this bug is more similar to bug 72540 than to bug 76197.

    
    

    
  
So, if there is no problem with window.innerWidth, what is this bug about?

    
    

    
  


  
One small minor correction to comment #38. 

The content area, the client area can be determined in
real time without problems regardless of what happens with bug 62536 and
regardless if Mozilla intends to support
document.documentElement.clientHeight/Width. That's still true.

IMO, bug 48634, as re-summarized, is still INVALID.
Document.body.clientWidth/Height does the trick and solves everything.

Demo case includes possible values of margins, borders and paddings for the
root node and body node.

    
    

    
  
Yeah this is a significant problem for me as well, and it would seem every other
web developer on the planet since they all unfortunately have to use the same
technique to get around it, and that is to left justify websites that rely on
perfectly centered content [such as things like drop down menus as in our own
little “test case”: http://www.pixelcarve.com/testcase/ (notice the menu not
lining up properly without a scrollbar)]. If we’re missing something and there
really is a way of lining that up, I would LOVE to know about it.

Left justified websites usually don't look nearly as nice (aesthetically
speaking) as sites that are centered since there is too much consistent blank
space on higher screen resolutions (which are becoming more and more common).
When sites such as Alias|Wavefront’s, with their enormous access to brilliant
programming talent, have to shift their entire website from the center over to
the left just on pages with drop down menus just to conform to cross-browser
compatibility, this indicates to me that we aren't simply missing something, and
that there is most definitely a bug here that needs to be addressed.

As my head programmer said when he was laughing his way through some of the
ridiculous responses in this thread: “I'm surprised they are debating this so
much.  Doesn't it just make sense to have the innerwidth take into account the
scroll bar? Or at least let us set scrollbars = yes so things wouldn’t jump
around from one page to the next.”

This *is* a bug and it needs to be fixed very soon before more generations of
browsers ship without it and websites are stuck justified to the left for many
years to come. I am very disappointed that this wasn’t fixed by the time
Netscape 7 was released, and I fear this message now will be in vein as the
damage has already been done, but I honestly am tired of pulling my hair out
every time something doesn’t line up properly in Mozilla and just had to say
something.

Although truth be told, the stats we keep on the usage of the websites we make
put NS4 at about 2% and NS6/7 at about 3%, so since so many more people use IE a
lot of designers have just given up on the headache of conforming to Mozilla’s
“standards” and let people using it deal with the things that don’t show up
right. Unfortunately I have a hard time doing that due to my strong Netscape
roots, but even I am finding myself compromising Mozilla/Netscape out of the
equation when they just become impossible to work with, especially when most of
our clients want their websites centered and want drop down menus – and the
client is always right.

    
    

    
  
Curtis, I can't shake the feeling you're talking about a different bug (bug
76197 to be exact)...  The "jumping around" that happens as the scrollbar
appears and disappears has nothing to do with window.innerWidth.

Again, I have yet to see anyone produce a testcase that shows that _this_ bug
exists.  When I asked for one in comment 40, I was given a response that clearly
indicated that people are confusing this bug with bug 76197 (comment 42 through
comment 45).  I've spent hours writing testcases for this bug now, and I have
yet to reproduce the problem as "originally reported" (note that comment 0 is
_very_ clearly talking about bug 76197).

Given all that, I'm marking this worksforme.  If I missed something and
window.innerWidth _is_ buggy, please reopen and attach something that shows it.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Many of the posts in http://bugzilla.mozilla.org/show_bug.cgi?id=76197 seem
somewhat convoluted, so I’m not really sure if it is also a cause to the problem
we’re experiencing, although I suppose it could be.

I may be reporting this in the wrong bug, but from what I’ve read in this thread
it is the same problem (although it causes a couple of different issues). Here’s
what happens, as our test case shows: http://www.pixelcarve.com/testcase/

In Mozilla/Netscape6/7, the horizontal menu is offset to the left a bit when
there is no scrollbar present. When you minimize the window and force the
scrollbar to appear, the menu gets lined up properly, the way it’s supposed to
be and the way it appears in IE. This definitely seems to be a window.innerWidth
bug to me, as the way the menu is centered is to calculate the
window.innerWidth, and then mathematically use that number to center the
Javascript menu. However Mozilla seems to ignore whether or not the scrollbar is
present, so the math can never be perfect and the menu can never be centered
properly.

My particular bug isn’t the “jumping around” issue, however I understand that
the “jumping around” is also a problem, so the solution I may want implemented
to correct my problem (making window.innerWidth include the scrollbar) wouldn’t
correct the “jumping around” issue (in fact it would make it worse), so the only
alternative I can see is to let us force the scrollbar like it does in IE.

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase.  Finally.
        — 
      

    


  
OK.  So here's a clear testcase that shows what's up.  And indeed, the
innerWidth does not include the scrollbar width in it...  Best part is, I
tested in NS4 and that is also the case there.	Of course the difference (per
bug 76197) is that NS4 does not use that scrollbar space to render even when
there's no scrollbar.

In both Mozilla and NS4 window.innerWidth is always the width of the content
area.  Looking at the JS at http://www.pixelcarve.com/testcase/, there's a "-
16px" hack to account for this fact (16px is the width of the NS4 scrollbar
and, as it happens, also the width of the Mozilla scrollbar).

So it's a matter of what's more important -- knowing the width of the window
(window.innerWidth) or knowing the width of the rendering area
(window.innerWidth - 16) in NS4, depends on scrollbars in Mozilla.

Curtis, for your site in particular, I'd just use document.body.clientWidth for
Mozilla just like you do for IE.  It will work correctly (I just tested on a
local copy of that page) and you will not have to do odd 16px subtractions...

        Attachment #12760 -
        Attachment is obsolete: true

        Attachment #62036 -
        Attachment is obsolete: true

        Attachment #90383 -
        Attachment is obsolete: true

        Attachment #91257 -
        Attachment is obsolete: true

    
    

    
  
Reopening; we need to answer that "what is more important" question (while
keeping in mind that the _correct_ width of the rendering area in Mozilla can be
gotten by looking at document.body.clientWidth just like in IE.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
And to something like the right component.  This is jst's call as DOM module
owner when he gets back from vacation (in 2.5 weeks, iirc).
Assignee: attinasi → jst
Status: REOPENED → NEW
Component: Layout → DOM Level 0
Priority: P3 → --
QA Contact: petersen → desale
Whiteboard: see comment 51 for the gist of the bug
Target Milestone: mozilla1.1alpha → ---

    
    

    
  
To clarify, by "the width of the content area" I mean "from left edge of content
area to right edge of scrollbar, if any".  This is what innerWidth is in NS4 and
Mozilla.

    
    

    
  
Ok excellent thanks we'll try using document.body.clientWidth like we do for IE.
We weren't aware that variable existed in Mozilla, is that something newly
added? Will this work for Mozilla builds as old as Netscape 6?

    
    

    
  
That's been in the tree since Oct 16, 2001...  So it'll work in NS7.0, but
almost certainly not in NS 6.x for any x (including 6.2).

    
    

    
  
*** Bug 131029 has been marked as a duplicate of this bug. ***

    
    

    
  
Uhhhh ok, unless we are doing something really wrong, using
document.body.clientWidth for Netscape7/Mozilla1.x also doesn't take into
account the scrollbar, and goes off center if the scrollbar appears.

http://www.pixelcarve.com/testcase/

    
    

    
  
Your JS is running before any of the content has come in, so at that point there
is no scrollbar yet and the body's width is the window width.  Try putting
alerts for document.pgW and document.body.clientWidth in both your code and the
onload handler.

    
    

    
  
Ok thanks. That's a somewhat major rewriting of the code though so we'll have to
try it a bit later when we have more time.

It's a shame though that these very odd problems with Mozilla weren't discovered
earlier so they could have been fixed before Netscape 6/7 was released, since if
this works we'll be forced to go and edit the HTML source of every single page
this menu has ever been applied to :-(  This all just works perfectly in IE. I
know many designers who completely avoid designing the much more aesthetically
pleasing centered websites or using drop down menus at all simply because of the
bugs in Netscape.

    
    

    
  
The reporter thinks that window.innerWidth should not include scrollbar space. 
He finds it impossible to consistently center dynamically positioned content.


If this were pre 1.0 still, I'd completely agree with Brendan. It's the right
way to do it. This should have been fixed a long time ago.

I propose adding a read-only property. This will make it easier to center
content, right position elements, write tooltip/menu/animation scripts. It
should not be too hard to implement that.


// fictitious example of window.clientWidth
// returns window.innerWidth, excluding any scrollbar space.
var realWidth = window.clientWidth;


    
    

    
  
*** Bug 107172 has been marked as a duplicate of this bug. ***

    
    

    
  
see bug 189112

    
    

    
  
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

    
    

    
  
*** Bug 26793 has been marked as a duplicate of this bug. ***

    
    

    
  
I just ran into a related issue when trying to dynamically keep a bar at the bottom of the window. (I'm not using position:fixed b/c I want it animated.)

Basically it comes down to:
element.top = (window.innerHeight + window.pageYOffset) - element.offsetHeight

In other browsers, it's fine whether or not a horizontal scrollbar is present. In FF (using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071216 Firefox/2.0.0.11) if a horizontal scrollbar is present, the bar will stop behind it, obscuring ~20px of it.
Assignee: general → nobody
QA Contact: desale → general

    
    

    
  
> The innerWidth attribute must return the viewport width including the size
> of a rendered scroll bar (if any).

http://dev.w3.org/csswg/cssom-view/#dom-window-innerwidth
Status: NEW → RESOLVED
Closed: 22 years ago → 13 years ago
Resolution: --- → INVALID

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: