Initial state affects viewport method detection

[rhelms]

I have some functionality in a page where I want to set the width of a list of menu items manually, however, I also want to detect when a 767px break point has been reached, and remove the manually set list.

Currently, I have this

function update() {
        if (window.innerWidth > 767) {
            $("nav.main ul li").width($("nav.main ul").width() / 5 - 11);
        } else {
            $("nav.main ul li").css('width', '');
        }
    };
    update();
    $(window).on("resize", update);

I did try replacing window.innerWidth with $.viewportW(), but noticed that the reported value of $.viewportW() was not matching up with the width displayed in the top corner of Chrome (30.0.1599.101 m). That is, $.viewportW() would report 767 when Chrome is reporting 784.

With regards to the 767px breakpoint, I have a media query that uses max-width, as this is what the Unsemantic CSS Framework is using. i.e. @media screen and (max-width: 767px).

Using the Chrome debug tools, when Chrome reports 767px, and the media query kicks in for max-width: 767px, I can see the following: $.viewportW() : 750 window.innerWidth : 767 window.outerWidth : 783 $(window).outerWidth() : 750, as well as outWidth(true) and innerWidth()

I can't quite tell if the 17px difference between viewportW() and window.innerWidth has anything to do with scrollbars, or if there is simply an issue because I'm using max-width in my media query.

[rhelms]

Actually, I think this might be something specific with my page, because if I view http://ryanve.com/lab/dimensions/ with the same size window, it correctly reports verge.viewportW() as 767, but only reports my page as 750.

I'll need to dig a little further into how verge.viewportW() is calculated, to see why it is different between the two pages, when they have the exact same window.innerWidth value.

[rhelms]

I was having a bit more of a look.

When the makeViewportGetter first runs for the viewportW, docElem[client] and win[inner] both match at whatever the window appears to be at (which I'd set to be 768 for the debugging). Due to this, it will return a function always returning docElem[client].

However, on subsequent calls docElem[client] is no longer matching win[inner], in fact, it's less than, but because viewportW has been set to a function that will always return docElem[client], I'll never get a viewportW that matchs what Chrome will break on. The same thing happens in FF and IE as well.

I think if the initial comparison checked docElem[client] <= win[inner], this would result in win[inner] being returned, which is the desired result (for me, anyway).

[ryanve]

@rhelms I was testing something else and came to a similar conclusion. I renamed the issue because initial zoom seems to be the cause. As mentioned the current detection uses matchMedia to test if window.innerWidth is correct. But window.innerWidth can be 1px off the @media breakpoint if the page has an initial zoom. I suspect this is due to rounding in either native. I think you are right that a simple comparison will suffice.