This is an update to the console.log wrapper; see this blog post for background and a more detailed discussion of the problems with console logging.
While logging the console can be useful during development, some browser consoles do not display logged data in a readable, useful format. These primitive consoles do not expand arrays, do not link DOM elements to the source code, print objects as
[object Object] rather than listing their properties, etc.
The viewport is a direct window into what the user sees, and a lot can be learned by watching it. In my previous post I introduced Within Viewport and I want to discuss how, particularly through my Twitter app Signal~Noise, I’ve found it useful in making interfaces respond sensibly to user behavior.
A common solution for developers looking to increase their site’s performance is to load data on demand, for example using Infinite Scroll. But sometimes the scroll position isn’t enough — you need to know about the content on screen.
Within Viewport indicates whether an element is entirely within the viewport. It also allows you to specify your site’s effective viewport (eg, to account for fixed header and navigation bars) and provides a few handy shortcut notations.
It’s quite simply to use:
var elem = document.getElementById("myElem"); // Returns true if it's completely visible withinviewport(elem); // Same as above, but using the jQuery plugin $(elem).is(":within-viewport"); // Run some function on all visible divs $("div").withinviewport().myFunction();
Update: I’ve made a significant update to this project which is targeted at primitive consoles (IE, Opera 11 and older, iOS 5 and older, and more). A separate blog post has more details or you can jump right to the updated Github repo. The original post below still applies.
Many front-end web developers make use of the wonderful browser consoles that have matured in the past few years. While the tried-and-true
console.log() often does the trick, its lack of support (particularly in IE) has led to the use of proxy functions, such as Paul Irish’s console.log wrapper and Ben Alman’s Debug() which prevent unsupportive browsers from throwing errors.
I had a need for logging data in every browser, not just ones that natively support
console.log(). So I forked Paul’s function and expanded it to work with every browser I could test — IE6-9, Firefox 3.6 & 4+, Chrome 10+, Safari 5+, and Opera 11+.
This will be exhaustive, so you may want to jump directly to:
But what if a very popular site, one that nearly everyone would hit before reaching your site, loaded those libraries? I imagine the number of users running cached libraries would increase dramatically.
Twitter recently unveiled a new interface for their mobile site located at mobile.twitter.com loaded with the features you’re accustomed to having on the desktop version of the site. However, when you browse to Twitter or follow a link from an email on your mobile phone you’re still shown the older, far less useful interface by default.
To automatically view any page in the new interface, just use the bookmarklet below. If you’re currently on a Twitter page you’ll be redirected to the same page on mobile.twitter.com; or, if you’re anywhere else at all, you’ll simply go to the mobile home page.
The bookmarklet: Mobile Twitter
Or, to install it on an iPhone, follow these steps.
- Click here, and bookmark the resulting page once it loads by clicking the + icon at the bottom of Mobile Safari. (It will look just like the page you’re on.) Call it something like “Mobile Safari”.
- Tap the bookmarks icon to open your bookmarks, then click Edit
- Tap on the bookmark you just made. Then tap on the second line, containing the URL, to edit it.
And that’s it. To use it, just open your bookmarks and tap on your new Mobile Twitter bookmarklet while you’re viewing any page.