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.
(deleted), 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) (deleted) —
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. (deleted) —
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: