Develop Reference

$(window).width() not giving viewport width correctly

I have almost always used $(window).width() to check the viewport width. It normally works for both browsers and devices. But for a website on which I need to show a particular splash screen if viewport width is less than 768px, this is not working. It gives correct width upto a point but below that it keeps giving 980px howsoever narrow I make the browser. There are a few particular conditions for this site:
This site was responsive in beginning (using bootstrap) but then made non-responsive. For this we removed viewport meta tag and set following rule in css that overrides its responsive widths:
.container{ width: 1170px; }
If I resize the whole browser i.e. the window that contains all browser tabs, then it does give correct width (less than 980px also, which is the desired behaviour), but if I use development tools and use the mobile layouts from there then width is never reported to be below 980px.
It would not have mattered that it worked on resizing only the main browser window, but the issue is that it is not working in devices as well. I added an alert and on mobile devices, again width is never alerted to be less than 980px.
Can someone please suggest some solution for this or explain why it is not working as expected?

I can't seem to find any authoritative source, but there are many pages that mention smartphones assume a website is 980px wide unless told otherwise.
Apple's developer site for instance says
The majority of webpages fit nicely in the visible area with the viewport width set to 980 pixels in portrait orientation, as shown in Figure 3-4. If Safari on iOS did not set the viewport width to 980 pixels, then only the upper-left corner of the webpage, shown in gray, would be displayed. However, this default doesn’t work for all webpages, so you’ll want to use the viewport meta tag if your webpage is different. See Supported Meta Tags for more on viewport.
Figure 3-4 Comparison of 320 and 980 viewport widths
(Incidentally, it was the iPhone which first did this, but other phones soon followed.)
So the solution is either to put
<meta name="viewport" content="width=device-width">
into the head (in your case, back into the head), or, acknowledge that the site is now not-responsive, and will not perform optimally on a phone!

How to fix the height of an element to the "fold" height of the viewport?

I'm looking for a cross-browser (including IE => 10, 11) and cross-platform method to apply a specific height to an element with class="fold", where fold is defined in CSS like so:
.fold {
min-height: calc(100vh - 45px); /* 45px is the height of fixed header on the top */
max-width: 100vw;
}
Simple enough?, but there is jank!
What I wish to do here is simply apply the height of the fold i.e. the area above the fold and just below the fixed header to the element.
See it working here: https://bubbl.in/
The div containing the cat_image (background) will occupy the viewport height as expected, except on iOS Safari where the returned height is slightly bigger because it includes height of browser's url bar in it.
The issue(s):
(i) The .fold class works fine on desktop Chrome, Safari, Firefox, Opera, Yandex and Edge. It works okay-ish on IE11 but not so well on IE10 (though it does work sometimes on different installations of windows). Is there a way to getting more backwards support (like IE9/IE8) for this?
JavaScript is fine as long as it is performant.
(ii) The second issue is that the .fold class works fine on iOS Safari but is very very janky on iOS Chrome, Firefox and other few browsers like the UC browser from China. I'm sure that juddering is also there on stock Chrome/alternative browsers of Android phones. Will confirm this in a bit. Confirmed.
Here's my understanding of why it janks on iOS Chrome, for example:
This has something to do with how Chrome & Firefox calculate and return viewport height [See item number 11 in known issues] to the CSS rendering engine. The value of 100vh increases as the browser goes from normal to fullscreen mode as the user scrolls down a page. Try it on the iPad!
Since the "effective" viewport height increases, the said height of the .fold element goes up and the browser has to recalculate layout and repaint multiple times, causing some heavy FSLs on the page.
I'm wondering if there is a way to prevent this recalculation of height of the .fold element and fix its value to the viewport height when it first rendered? For once, I guess the known issue on iOS Safari is a rather desirable feature.
Edit: Demo page inserted on the top.

Document width calculated via Javascript is different in Firefox compared to other browsers

I have a problem with retrieving the current page document width from Mozilla Firefox. While the rest of the browsers report the correct width of the document, Firefox reports a smaller one (example: at screen resolution of 1920x1080 IE, Chrome and Safari reports 1920 while Firefox reports 1903).
I use document width in $(document).ready(function() { ... }); to reposition a div element. Funny this is that after using alert() inside this function, the element reposition correctly, though the document size is still smaller than other browsers.

As Salman already noted in the comments, this difference comes from the scroll bar. Depending on the browser (and probably also on whether quirks mode is enabled), the scrollbar might be considered "outside" the document (in which case its width won't be added to the document width) or part of the <html> element (then its width will be added to the document width). So document.documentElement.offsetWidth will return inconsistent results - sometimes with the scrollbar, sometimes without it. document.body.offsetWidth on the other hand seems consistent across browsers - scrollbar width isn't included.
If what you want to learn is viewport width, regardless of the contents, then window.innerWidth might be a better choice. I tested in Firefox, Chrome and MSIE 9.0 - it returns the full screen width for maximized windows in all of them.

Cannot scroll web page on iPad

On iPad I cannot scroll a web page. It works fine in Safari, Chrome and Firefox on OS X.
The page has an area in which content can be scrolled only horizontally. It consists of a container div which has width = 100% and height = (100% - 40px). I am setting the height by a JavaScipt function which is triggered by window resize events. Inside this container is another div with the width of the content (very wide, to avoid line breaks). Inside that is the content.
CSS properties of the container are:
overflow-x:scroll;
overflow-y:hidden;
white-space:nowrap;
See the page and full source code here: dcfoto.de
On iPad, scrolling is not possible. What am I doing wrong?
By the way: resizing also does not work properly on orientation change. Maybe that's connected.

Unfortunately a two-finger swipe needs to be performed, and even then it is not responsive (when compared to the default one finger swipe scroll).
There are quite many javascript solutions out there, (sencha touch and iscroll being the most promising and advanced)
I would recommend http://cubiq.org/iscroll-4 which is hands down the coolest touch-scroll script out there. It also works for android, but quite more sluggishly since the default android browser albeit webkit based doesnot support css3 3d accelerated properties as good as the mobile safari one.
If I were you I would check for the user agent of the user, and deploy that script for android and ipad/iphone users.

Javascript Window.Open Dimensions

I'm opening a new window from javascript using this code
window.open('index.htm', 'myWindow', 'width=1020,height=400');
However the window seems to be opening 10px too wide when measuring from outter border to outer border, I've only tested this on IE7 and IE8 so far. Does anyone know what could be causing this?

See the IE Blog for details on how Microsoft changed their window dimensions in IE7 (and beyond)
IE Blog: Why Does IE Resize My Dialogs?
Quotes:
IE6 gives web developers control over the frame size of dialogs (also known as the ‘chrome’). The frame includes visual elements such as the title bar, status bar, borders, etc. This is a problem for web developers because the dialog’s frame size varies according to whatever windows theme is applied (this is bad)...
In Windows XP Service Pack 2, IE’s security improvements added window restrictions that forced the status bar onto windows and dialogs (in certain security zones); developers adapted by subtracting the height of the status bar from their dialogs...
Before the guesswork for sizing the content area gets any worse for developers, we felt it was time to set things right by focusing on delivering HTML content area instead of total frame size.
Here’s how we changed it. In IE7, the meaning of window.dialogHeight and dialogWidth now refers to the content area. Essentially, the area (height/width) that you specify is what we try to deliver in the content area of the dialog (barring window restrictions on scriptable minimum sizes: 250px wide x 150px high*). It will no longer be necessary to calculate the area lost by components of a dialog’s frame.
Figure 3

window.onload=setTimeout(function(){window.open('http://www.w3schools.com', 'myWindow', 'width=920,height=400');},1000);