There are many developers who love using jQuery because it makes things so much easier. However, just like anything else in life, the real work comes in looking for and noticing the details that you wouldn’t have thought would be a problem until they are. Always better to fix it before you launch, than fix it after, right? I’m sure your client would agree wholeheartedly with this sentiment. 

I would like to present you with one of these situations today, that came down to debugging before I realized that there was a slight issue.

While using Windows, I used a CSS breakpoint set to 768px for some media queries. The project I worked on also needed some classes to be changed from jQuery when I got below this breakpoint. I thought, this shouldn’t be too difficult, I will compare $(window).width() to 768 and that is it, problem solved!

Not… exactly...

Everything looked good until I started testing my code… and I’m really glad I did. When I resized the window during testing, I paid more attention when the browser was showing that I was getting close to my breakpoint and noticed that the CSS was taking action as it should but the classes were not changing when I got from 767px to 768px. That’s a problem, something I would not have wanted to launch.

So of course, I started debugging and digging in further. I very quickly noticed that the value $(window).width() returned was different from the one that CSS used for its media queries. That’s when I realised the importance of window.matchMedia and window.innerWidth, something I hadn’t considered before I started testing.

These values are the ones I will use from now on because they match the width that the CSS media queries react to, and I want the users that see the pages I create from Windows to have the same experience with the ones that have browsers that don’t have a fixed scrollbar…. Because… drumroll please… the presence of the scrollbar was the reason why $(window).width() didn’t have the result I expected.

To wrap up, always be aware of the differences in operating systems, not just from a code perspective, but also from a UI perspective, and never EVER take shortcuts in testing and debugging… you might just miss a very important detail that completely alters your user experience.