New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have $(window).outerWidth() include the scrollbar width #1729

Closed
mgol opened this Issue Oct 20, 2014 · 38 comments

Comments

Projects
None yet
@mgol
Member

mgol commented Oct 20, 2014

Originally reported by antti@… at: http://bugs.jquery.com/ticket/14989

It is sometimes annoying that $(window).width() or $(window).outerWidth() do not include the scrollbar width in their value. Especially when trying to match the window width to the CSS media queries.

Currently e.g. if you have a media query in the CSS such as

@media screen and (max-width: 1600px) {
  body {background: red;}
}

When the red background is actually applied to the document by the browser, jQuery tells the window width is less than 1600px (1600 - scrollbar width).

This is annoying e.g. in cases where there are some mobile-specific stuff that needs to be done in both, CSS and JS. And they would need to be done at the exactly same width of the document/window.

However, plain JavaScript returns 1600 as the window width when asked at the point of the breakpoint as follows:

console.log(window.innerWidth);

Is it possible to get either $(window).width() or $(windor).outerWidth() working consistently with the browser's actual width? $(document).width() and $('body').width() will not return the same as "window.innerWidth" either, they return the same as $(window).width() and $(window).outerWidth().

Fixing this would greatly help making consistent code with the CSS media queries.

Possible workarounds currently are:

  • Using plain javascript, i.e. window.innerWidth
  • Checking $('...').is(':visible') for some element that is visible only in the target width

Here's an example of what I mean:  http://jsfiddle.net/aq5vb/

Issue reported for jQuery 2.1.0

@mgol mgol added this to the 3.0.0 milestone Oct 20, 2014

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: antti@…

And this applies to earlier versions of jQuery as well, I just reported it for the latest stable.

Member

mgol commented Oct 20, 2014

Comment author: antti@…

And this applies to earlier versions of jQuery as well, I just reported it for the latest stable.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: dmethvin

I'm very concerned about changing this, considering the compatibility implications; it's been this way forever. For $(window).width() we return document.documentElement.clientWidth which does not include the scrollbars as you've observed. We say that is "the width of the viewport".

 http://api.jquery.com/width/

Any other opinions on this? If people expect it to exclude scrollbars we would break a lot of code by changing it.

Member

mgol commented Oct 20, 2014

Comment author: dmethvin

I'm very concerned about changing this, considering the compatibility implications; it's been this way forever. For $(window).width() we return document.documentElement.clientWidth which does not include the scrollbars as you've observed. We say that is "the width of the viewport".

 http://api.jquery.com/width/

Any other opinions on this? If people expect it to exclude scrollbars we would break a lot of code by changing it.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: anonymous

I'm not sure if I articulated myself very clearly but what I actually meant was that the jQuery width in fact EXCLUDES the scroll bar from the width while the CSS media queries count it as part of the viewport.

Here's an image that might (or not) emphasize my point (see also the CSS that defines the breakpoint): http://i.imgur.com/2mtrjGw.jpg

If you say it's the "width of the viewport", shouldn't it be consistent with what the browser considers as the viewport width then?

I understand that it would might things but it just bothers me that it does not match the width that the CSS media queries are using, i.e. the width of the viewport. In fact, none of these do (you can test this by changing it in the jsFiddle above):

$(window).width();
$(window).innerWidth();
$(window).outerWidth();

Any possibility to get even ONE of these working consistently with the browser's viewport width?

Member

mgol commented Oct 20, 2014

Comment author: anonymous

I'm not sure if I articulated myself very clearly but what I actually meant was that the jQuery width in fact EXCLUDES the scroll bar from the width while the CSS media queries count it as part of the viewport.

Here's an image that might (or not) emphasize my point (see also the CSS that defines the breakpoint): http://i.imgur.com/2mtrjGw.jpg

If you say it's the "width of the viewport", shouldn't it be consistent with what the browser considers as the viewport width then?

I understand that it would might things but it just bothers me that it does not match the width that the CSS media queries are using, i.e. the width of the viewport. In fact, none of these do (you can test this by changing it in the jsFiddle above):

$(window).width();
$(window).innerWidth();
$(window).outerWidth();

Any possibility to get even ONE of these working consistently with the browser's viewport width?

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: dmethvin

Yes, you made yourself clear. My point was that as far as I can tell we have been doing it this way for a long time. If we change it there is a very good chance that we will break someone's code who expects the width to include only the client area. Still looking for feedback from others.

Member

mgol commented Oct 20, 2014

Comment author: dmethvin

Yes, you made yourself clear. My point was that as far as I can tell we have been doing it this way for a long time. If we change it there is a very good chance that we will break someone's code who expects the width to include only the client area. Still looking for feedback from others.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: scott.gonzalez

Please don't change this. Honestly, it's strange that the media queries include the scrollbars since developers are obviously using things like (max-width: 600px) based on actual usable space, and that excludes scrollbars.

I'd expect tons of broken sites if jQuery changed, but almost no broken sites if media queries changed. Just a thought...

Member

mgol commented Oct 20, 2014

Comment author: scott.gonzalez

Please don't change this. Honestly, it's strange that the media queries include the scrollbars since developers are obviously using things like (max-width: 600px) based on actual usable space, and that excludes scrollbars.

I'd expect tons of broken sites if jQuery changed, but almost no broken sites if media queries changed. Just a thought...

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: antti@…

I understand that changing $(window).width() would break things.

I don't think changing $(window).outerWidth() would break anything.

Member

mgol commented Oct 20, 2014

Comment author: antti@…

I understand that changing $(window).width() would break things.

I don't think changing $(window).outerWidth() would break anything.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: antti@…

And could someone also post me an example of a code that would break or behave strangely if this was changed? I'm not quite sure if I currently even see the risk as high as you guys.

Member

mgol commented Oct 20, 2014

Comment author: antti@…

And could someone also post me an example of a code that would break or behave strangely if this was changed? I'm not quite sure if I currently even see the risk as high as you guys.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: antti@…

And just adding to this, looking closer to the API documentation of .width().

It states the following:

// Returns width of browser viewport
$( window ).width();

// Returns width of HTML document
$( document ).width();

So, if $(window).width() currently returns document.documentElement.clientWidth, isn't this wrong regarding to the API documentation?

Member

mgol commented Oct 20, 2014

Comment author: antti@…

And just adding to this, looking closer to the API documentation of .width().

It states the following:

// Returns width of browser viewport
$( window ).width();

// Returns width of HTML document
$( document ).width();

So, if $(window).width() currently returns document.documentElement.clientWidth, isn't this wrong regarding to the API documentation?

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: scott.gonzalez

And could someone also post me an example of a code that would break or behave strangely if this was changed?

Anything that positions elements relative to the window, e.g., notifications. Positioning against the top right corner would overflow and cause a horizontal scrollbar.

Anything that sizes elements relative to the window, e.g., overlays. The overlay would be too large and would cause a horizontal scrollbar.

Anything that does bounds testing against the window, e.g., draggable elements contained to the window. The bounds would be slightly too wide and would cause a horizontal scrollbar at the right edge, increasing the size of the document and the bounds.

There are likely several other scenarios as well. Those are the generic cases that popped into my head right away.

Member

mgol commented Oct 20, 2014

Comment author: scott.gonzalez

And could someone also post me an example of a code that would break or behave strangely if this was changed?

Anything that positions elements relative to the window, e.g., notifications. Positioning against the top right corner would overflow and cause a horizontal scrollbar.

Anything that sizes elements relative to the window, e.g., overlays. The overlay would be too large and would cause a horizontal scrollbar.

Anything that does bounds testing against the window, e.g., draggable elements contained to the window. The bounds would be slightly too wide and would cause a horizontal scrollbar at the right edge, increasing the size of the document and the bounds.

There are likely several other scenarios as well. Those are the generic cases that popped into my head right away.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: antti@…

Does not sound something I would do with jQuery, I think all of these cases are handled by CSS in most occasions. But the bounds part, you're correct on that one.

But yeah, it might break such things because of which I was looking for actual references to existing code that I could test against (e.g. links to github projects).

Member

mgol commented Oct 20, 2014

Comment author: antti@…

Does not sound something I would do with jQuery, I think all of these cases are handled by CSS in most occasions. But the bounds part, you're correct on that one.

But yeah, it might break such things because of which I was looking for actual references to existing code that I could test against (e.g. links to github projects).

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: dmethvin

It seems highly unlikely that anyone would be using $(window).outerWidth() today so I'll mark this open for now and a potential change for 1.12/2.2.

Member

mgol commented Oct 20, 2014

Comment author: dmethvin

It seems highly unlikely that anyone would be using $(window).outerWidth() today so I'll mark this open for now and a potential change for 1.12/2.2.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: scott.gonzalez

Replying to dmethvin:

It seems highly unlikely that anyone would be using $(window).outerWidth() today so I'll mark this open for now and a potential change for 1.12/2.2.

#9434

Member

mgol commented Oct 20, 2014

Comment author: scott.gonzalez

Replying to dmethvin:

It seems highly unlikely that anyone would be using $(window).outerWidth() today so I'll mark this open for now and a potential change for 1.12/2.2.

#9434

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: dmethvin

Why do we have all 3 return the same value? I'm wondering about the use case that spawned #9434.

Member

mgol commented Oct 20, 2014

Comment author: dmethvin

Why do we have all 3 return the same value? I'm wondering about the use case that spawned #9434.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: scott.gonzalez

The use case is generic plugins that operate on elements, documents, and windows. For example, a plugin that centers x inside y would do something like:

x.css( "left", (y.outerWidth() - x.outerWidth()) / 2 );

The correct behavior would be achieved today even if y is a window. However, if the scrollbar width is included, x would be off-center by half the size of the scrollbar. To compensate for this, you would need to check for windows:

var yWidth = $.isWindow( y[ 0 ] ) ? y.width() : y.outerWidth();
x.css( "left", (yWidth - x.outerWidth()) / 2 );

Note that this extended logic is already required if you want to support jQuery <1.7 since that didn't support .outerWidth() on windows.

Member

mgol commented Oct 20, 2014

Comment author: scott.gonzalez

The use case is generic plugins that operate on elements, documents, and windows. For example, a plugin that centers x inside y would do something like:

x.css( "left", (y.outerWidth() - x.outerWidth()) / 2 );

The correct behavior would be achieved today even if y is a window. However, if the scrollbar width is included, x would be off-center by half the size of the scrollbar. To compensate for this, you would need to check for windows:

var yWidth = $.isWindow( y[ 0 ] ) ? y.width() : y.outerWidth();
x.css( "left", (yWidth - x.outerWidth()) / 2 );

Note that this extended logic is already required if you want to support jQuery <1.7 since that didn't support .outerWidth() on windows.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: scott.gonzalez

Here's the IRC discussion from three years ago:  http://irc.jquery.org/%23jquery-dev/%23jquery-dev_20110526.log.html#t07:35:33

Member

mgol commented Oct 20, 2014

Comment author: scott.gonzalez

Here's the IRC discussion from three years ago:  http://irc.jquery.org/%23jquery-dev/%23jquery-dev_20110526.log.html#t07:35:33

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Oct 20, 2014

Member

Comment author: emartel

Hi,

Sorry I don't have a strong web development background but I'm very interested in the topic and I thought one of the best way to learn more is to collaborate with existing projects.

I've given some thoughts about this problem, and I'm wondering if there wouldn't be a simple solution to it...

I'm not sure how "elegant" this solution is, but it might be a start to handle legacy code and new code that wants an outerWidth that takes scrollbars into account.

Would it be an option to add a "state" to the window jQuery object? By default, the state is legacy / no-scrollbar / a decent name that explains the behavior of calls made on this object. Using a function call such as $(window).sizeExcludesScrollbars(true/false), the state is altered and the state is persisted, making subsequent calls to width / height take scollbars into account or not?

I believe that such a change would give Antti what he wants while leaving existing code described by Scott functional.

What do you guys think?

Member

mgol commented Oct 20, 2014

Comment author: emartel

Hi,

Sorry I don't have a strong web development background but I'm very interested in the topic and I thought one of the best way to learn more is to collaborate with existing projects.

I've given some thoughts about this problem, and I'm wondering if there wouldn't be a simple solution to it...

I'm not sure how "elegant" this solution is, but it might be a start to handle legacy code and new code that wants an outerWidth that takes scrollbars into account.

Would it be an option to add a "state" to the window jQuery object? By default, the state is legacy / no-scrollbar / a decent name that explains the behavior of calls made on this object. Using a function call such as $(window).sizeExcludesScrollbars(true/false), the state is altered and the state is persisted, making subsequent calls to width / height take scollbars into account or not?

I believe that such a change would give Antti what he wants while leaving existing code described by Scott functional.

What do you guys think?

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Dec 5, 2014

Member

Per the comment above from @scottgonzalez it seems highly likely there is jQuery code that assumes inner/outer/upper/downer width/height is the same value, since his ticket asked for it to be that way. This change would break that code.

Is this a common enough need to create new width/height APIs and corresponding documentation? It can be done pretty simply with a plugin if it's needed, and it hasn't been previously requested although as the OP says it's useful for matching media queries.

Member

dmethvin commented Dec 5, 2014

Per the comment above from @scottgonzalez it seems highly likely there is jQuery code that assumes inner/outer/upper/downer width/height is the same value, since his ticket asked for it to be that way. This change would break that code.

Is this a common enough need to create new width/height APIs and corresponding documentation? It can be done pretty simply with a plugin if it's needed, and it hasn't been previously requested although as the OP says it's useful for matching media queries.

@gibson042

This comment has been minimized.

Show comment
Hide comment
@gibson042

gibson042 Dec 9, 2014

Member

Per the comment above from @scottgonzalez it seems highly likely there is jQuery code that assumes inner/outer/upper/downer width/height is the same value, since his ticket asked for it to be that way. This change would break that code.

On the other hand, 'tis the season for breaking changes, and a scrollbar-width is pretty mild. Our docs state that inner* and outer* don't even apply to windows. It would be nice to have consistency with media queries and with scrollbar-bearing elements, but I haven't even checked if they match each other. Throw in box-sizing and it really gets fun, but I could certainly see doing something if anyone has a defensible idea.

Member

gibson042 commented Dec 9, 2014

Per the comment above from @scottgonzalez it seems highly likely there is jQuery code that assumes inner/outer/upper/downer width/height is the same value, since his ticket asked for it to be that way. This change would break that code.

On the other hand, 'tis the season for breaking changes, and a scrollbar-width is pretty mild. Our docs state that inner* and outer* don't even apply to windows. It would be nice to have consistency with media queries and with scrollbar-bearing elements, but I haven't even checked if they match each other. Throw in box-sizing and it really gets fun, but I could certainly see doing something if anyone has a defensible idea.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Dec 9, 2014

Member

I agree it would be nice to expose this functionality, but I was assuming Scott knew of code that would break.

@scottgonzalez can you point to code in jQuery UI that depends on all of these APIs returning the same value?

Member

dmethvin commented Dec 9, 2014

I agree it would be nice to expose this functionality, but I was assuming Scott knew of code that would break.

@scottgonzalez can you point to code in jQuery UI that depends on all of these APIs returning the same value?

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Dec 9, 2014

Member

I don't think this will affect jQuery UI. The problem was just that null was being returned, which made generic logic like making two elements the same size, or dynamically aligning elements painful for plugin developers who accept elements, documents, and windows as input. As long as meaningful values are returned, there shouldn't be any problems, but it is possible that this will "break" existing code.

In jQuery UI, we have two cases I can think of that use dimensions like this.

  1. We try to match outer widths for generated elements like the menu on a select or autocomplete or an effect placeholder. Windows are never valid inputs in these cases, so the change won't affect this.
  2. We accept elements, documents, windows, and events for positioning logic in our .position() plugin. Including the scrollbar here would be undesirable, but we're already doing explicit checks for window and then using .width() and .height() because we have to support old versions of jQuery. If we had a different project lead, support for jQuery 1.6 would likely have been dropped a long time ago, this code would likely be reduced to not have the check, and then this change would break positioning within the window on the right edge.

The latter is the type of situation that I wanted to account for with the previous change. Note that making an element the size of the window via outer width matching will result in horizontal scrollbars if there is already a vertical scrollbar. See also the example in my previous comment. In the end, developers can just always include the window check, but that's what #9434 was about in the first place.

Member

scottgonzalez commented Dec 9, 2014

I don't think this will affect jQuery UI. The problem was just that null was being returned, which made generic logic like making two elements the same size, or dynamically aligning elements painful for plugin developers who accept elements, documents, and windows as input. As long as meaningful values are returned, there shouldn't be any problems, but it is possible that this will "break" existing code.

In jQuery UI, we have two cases I can think of that use dimensions like this.

  1. We try to match outer widths for generated elements like the menu on a select or autocomplete or an effect placeholder. Windows are never valid inputs in these cases, so the change won't affect this.
  2. We accept elements, documents, windows, and events for positioning logic in our .position() plugin. Including the scrollbar here would be undesirable, but we're already doing explicit checks for window and then using .width() and .height() because we have to support old versions of jQuery. If we had a different project lead, support for jQuery 1.6 would likely have been dropped a long time ago, this code would likely be reduced to not have the check, and then this change would break positioning within the window on the right edge.

The latter is the type of situation that I wanted to account for with the previous change. Note that making an element the size of the window via outer width matching will result in horizontal scrollbars if there is already a vertical scrollbar. See also the example in my previous comment. In the end, developers can just always include the window check, but that's what #9434 was about in the first place.

@dmethvin dmethvin added Dimensions and removed Needs review labels Dec 10, 2014

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Dec 10, 2014

Member

Okay. It's on.

Member

dmethvin commented Dec 10, 2014

Okay. It's on.

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Jan 30, 2015

Member

@dmethvin Just to sum up, is the idea here to leave .width(window) as-is, but add scroll bar width to .outerWidth(window)? Although, I think @scottgonzalez still makes a good case against it.

Member

timmywil commented Jan 30, 2015

@dmethvin Just to sum up, is the idea here to leave .width(window) as-is, but add scroll bar width to .outerWidth(window)? Although, I think @scottgonzalez still makes a good case against it.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jan 31, 2015

Member

Actually, I read the comment as, "it looks like doing this is okay." @scottgonzalez can you clarify? I agree it's possible this will break code somewhere . On the other hand, if we can't think of any and this is a 3.0 it would be nice to expose some way to get this dimension.

Member

dmethvin commented Jan 31, 2015

Actually, I read the comment as, "it looks like doing this is okay." @scottgonzalez can you clarify? I agree it's possible this will break code somewhere . On the other hand, if we can't think of any and this is a 3.0 it would be nice to expose some way to get this dimension.

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Feb 1, 2015

Member

Actually, I read the comment as, "it looks like doing this is okay." @scottgonzalez can you clarify?

I'll just repeat my summation from earlier:

As long as meaningful values are returned, there shouldn't be any problems, but it is possible that this will "break" existing code.

The reason I push break in quotes is because the more common cases of centering will only be off by a few pixels and will probably not be noticeable in most cases.

I agree it's possible this will break code somewhere . On the other hand, if we can't think of any and this is a 3.0 it would be nice to expose some way to get this dimension.

I've already provided examples of where this would actually break. See #1729 (comment)

Member

scottgonzalez commented Feb 1, 2015

Actually, I read the comment as, "it looks like doing this is okay." @scottgonzalez can you clarify?

I'll just repeat my summation from earlier:

As long as meaningful values are returned, there shouldn't be any problems, but it is possible that this will "break" existing code.

The reason I push break in quotes is because the more common cases of centering will only be off by a few pixels and will probably not be noticeable in most cases.

I agree it's possible this will break code somewhere . On the other hand, if we can't think of any and this is a 3.0 it would be nice to expose some way to get this dimension.

I've already provided examples of where this would actually break. See #1729 (comment)

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Feb 1, 2015

Member

@scottgonzalez Don't mean to annoy, but I'm still not clear on your position. It seems to me you've presented arguments for both sides. You said some breaks will barely be noticeable and then reminded Dave that you've listed multiple examples where this would break existing code. Are you for it, against it, or simply neutral?

Member

timmywil commented Feb 1, 2015

@scottgonzalez Don't mean to annoy, but I'm still not clear on your position. It seems to me you've presented arguments for both sides. You said some breaks will barely be noticeable and then reminded Dave that you've listed multiple examples where this would break existing code. Are you for it, against it, or simply neutral?

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Feb 1, 2015

Member

I'm neutral on it. If the change enables some reasonable use cases, I think it's ok to allow the breaking change in a major release. The userland fix for the breaking change is pretty simple.

Member

scottgonzalez commented Feb 1, 2015

I'm neutral on it. If the change enables some reasonable use cases, I think it's ok to allow the breaking change in a major release. The userland fix for the breaking change is pretty simple.

@AurelioDeRosa

This comment has been minimized.

Show comment
Hide comment
@AurelioDeRosa

AurelioDeRosa May 25, 2015

Member

What's the consensus here? Will you change the behavior in jQuery 3?

Member

AurelioDeRosa commented May 25, 2015

What's the consensus here? Will you change the behavior in jQuery 3?

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin May 26, 2015

Member

yes, it's on the list.

Member

dmethvin commented May 26, 2015

yes, it's on the list.

@aFarkas

This comment has been minimized.

Show comment
Hide comment
@aFarkas

aFarkas Jun 27, 2015

Contributor

Are you really sure, you want to change this? If a developer asks for $(window).width(), he really wants to know how much space is available.

This is actually also true for media queries. It's even possible, that the scrollbar is customized and much larger than 20.

The reason why media queries do include the scrollbar is because, media queries need to be calculable without knowing any styles and the document contents itself. (So they don't know, whether html, body {overflow: hidden} is applied or not for example).

So it is a necessary shortcoming of the mq API.

Changing the semantics of an existing API to match another less useful API isn't really great. Maybe add a new method, if you think this is so important.

At the end, I would even then always prefer to use matchMedia.matches and matchMedia.adListener (= the right API for this), if I want exact sync in time and semantics with CSS media queries.

Contributor

aFarkas commented Jun 27, 2015

Are you really sure, you want to change this? If a developer asks for $(window).width(), he really wants to know how much space is available.

This is actually also true for media queries. It's even possible, that the scrollbar is customized and much larger than 20.

The reason why media queries do include the scrollbar is because, media queries need to be calculable without knowing any styles and the document contents itself. (So they don't know, whether html, body {overflow: hidden} is applied or not for example).

So it is a necessary shortcoming of the mq API.

Changing the semantics of an existing API to match another less useful API isn't really great. Maybe add a new method, if you think this is so important.

At the end, I would even then always prefer to use matchMedia.matches and matchMedia.adListener (= the right API for this), if I want exact sync in time and semantics with CSS media queries.

@aFarkas

This comment has been minimized.

Show comment
Hide comment
@aFarkas

aFarkas Jun 28, 2015

Contributor

Don't take my comment to serious, in case your plan is to only change semantics of outerWidth/outerHeight and leave width/height as it is, like suggested here.

Contributor

aFarkas commented Jun 28, 2015

Don't take my comment to serious, in case your plan is to only change semantics of outerWidth/outerHeight and leave width/height as it is, like suggested here.

@akamustang

This comment has been minimized.

Show comment
Hide comment
@akamustang

akamustang Oct 23, 2015

There is already an includeMargin parameter, could another option be to add includeScrollbar?

There is already an includeMargin parameter, could another option be to add includeScrollbar?

@dmethvin dmethvin changed the title from $(window).width() AND $(window).outerWidth() excluding the scrollbar width to Have $(window).outerWidth() include the scrollbar width Nov 6, 2015

@thdoan

This comment has been minimized.

Show comment
Hide comment
@thdoan

thdoan Jun 22, 2016

Thanks for the patch, but we're left in an unfortunate situation where $(window).outerWidth() is equivalent to window.innerWidth, which can be confusing even though window.innerWidth itself is counter-intuitive (you would think "inner" leaves out the scrollbar).

thdoan commented Jun 22, 2016

Thanks for the patch, but we're left in an unfortunate situation where $(window).outerWidth() is equivalent to window.innerWidth, which can be confusing even though window.innerWidth itself is counter-intuitive (you would think "inner" leaves out the scrollbar).

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jun 22, 2016

Member

How is that a problem? Can you not get the information you need from jQuery's API?

Member

dmethvin commented Jun 22, 2016

How is that a problem? Can you not get the information you need from jQuery's API?

@thdoan

This comment has been minimized.

Show comment
Hide comment
@thdoan

thdoan Jun 23, 2016

There's not a problem, just a little bit of potential confusion because jQuery and native use opposite terms ("outer" and "inner", respectively).

thdoan commented Jun 23, 2016

There's not a problem, just a little bit of potential confusion because jQuery and native use opposite terms ("outer" and "inner", respectively).

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jun 23, 2016

Member

Imagine how much more confusing it would be if jQuery's .innerWidth() was larger than its .width()!

Member

dmethvin commented Jun 23, 2016

Imagine how much more confusing it would be if jQuery's .innerWidth() was larger than its .width()!

@thdoan

This comment has been minimized.

Show comment
Hide comment
@thdoan

thdoan Jun 23, 2016

:) Yeah, that's why I mentioned it's an "unfortunate situation" -- native's innerWidth property is counter-intuitive to begin with.

No issues if people stay within the jQuery API to get the window dimensions; it's only when they mix native and jQuery when they see "inner" and "outer" flying around meaning the same thing. Anyway, I was just commenting...no new issues here.

thdoan commented Jun 23, 2016

:) Yeah, that's why I mentioned it's an "unfortunate situation" -- native's innerWidth property is counter-intuitive to begin with.

No issues if people stay within the jQuery API to get the window dimensions; it's only when they mix native and jQuery when they see "inner" and "outer" flying around meaning the same thing. Anyway, I was just commenting...no new issues here.

@yitwail

This comment has been minimized.

Show comment
Hide comment
@yitwail

yitwail Jul 24, 2016

I'm working on a WordPress site, and the version of jQuery it uses returns the same value excluding scrollbar for width(), innerWidth() and outerWidth(), so I just used this workaround:
Math.max(window.outerWidth, $(window).width())

yitwail commented Jul 24, 2016

I'm working on a WordPress site, and the version of jQuery it uses returns the same value excluding scrollbar for width(), innerWidth() and outerWidth(), so I just used this workaround:
Math.max(window.outerWidth, $(window).width())

@acjbizar

This comment has been minimized.

Show comment
Hide comment
@acjbizar

acjbizar Aug 3, 2016

window.outerWidth != $(window).outerWidth simply makes no sense. Never has, and never will. Yes, changing it now probably breaks some existing code, but it’s bad design to begin with, so I’d say the sooner, the better. Chances are much of the existing code that uses $(window).outerWidth doesn’t work as expected anyway, because it doesn’t match window.outerWidth (as one would expect). Also, there’s an easy fix if you do want the sans-scrollbar width: just use $(window).width().

acjbizar commented Aug 3, 2016

window.outerWidth != $(window).outerWidth simply makes no sense. Never has, and never will. Yes, changing it now probably breaks some existing code, but it’s bad design to begin with, so I’d say the sooner, the better. Chances are much of the existing code that uses $(window).outerWidth doesn’t work as expected anyway, because it doesn’t match window.outerWidth (as one would expect). Also, there’s an easy fix if you do want the sans-scrollbar width: just use $(window).width().

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.