Posted on June 18, 2014 by Chris Harrington
Shim to customize output strings for date inputs on mobile browsers
I’ve recently been playing around with the HTML 5 date input controls. They’re pretty robust, especially in the mobile space, as all of the major mobile players have excellent support for most HTML 5 tags. One of the downsides that I’ve come across, however, is that the date controls don’t support the placeholder tag, or any custom display strings. So if I want to show a date in a particular format, I’m out of luck, as I have to stick with the standard “yyyy-MM-dd” format that most browsers natively display the date in. For the most part, that’s ok, but I spent some time coming up with a solution that provides both placeholder and custom date format support to the input date control.
A note here: each browser handles the date controls a little differently. Chrome on the desktop, for example, shows a bunch of different options for setting the date, including typing the numbers for each of the year, month and date fields, while also providing an arrow which opens up a date picker. Mobile browsers all open up the date picker while tapping on the input, which is great for this solution. However, this solution won’t work for desktop browsers, as the date picker doesn’t show until the user clicks on the little arrow, which is invisible.
Posted on April 28, 2014 by Chris Harrington
Page change progress bar for jQuery-enabled single page applications
Leaf is a single page application, which means that only a portion of the page changes when navigating between pages. This has a number of benefits that I don’t want do delve into at the moment, but suffice to say it trades (optionally) longer initial page load time for speedier navigation and potentially fancier page transitions. One of the downsides, however, is that the developer has to build his or her own method of informing the user that a page change is taking place. I’ve noticed recently that YouTube does an excellent job of this. It puts a “line” progress bar at the top of the page that shows up when you click on a YouTube video to watch. The line behaves like Safari’s progress bar; it jumps a little at first to say, “hey, your page load progress is here!” and then completes as the new content loads. It’s slick and subtle and I like it, and I’m going to show you how you can do it yourself.
Posted on January 21, 2013 by Chris Harrington
jQuery, widths and hidden elements
I’ve recently been doing some front-end work which involves modifying widths of DOM elements using jQuery. The standard method of modifying the width of an element is as such:
$("some sort of fancy selector").width(100);
As of jQuery 1.8, users are now able to set the outer width, which is defined as the width of the element plus any padding and borders. An optional flag allows you to set the width including margins, too, but only for the getter.
If, however, you need to read the width of an element that’s hidden, jQuery will calculate the width of a hidden element to zero in every case. This makes sense, as the element is hidden and taking up no room on the page. It’s kind of a pain in the ass, though, as in my case, I needed the current width of the element to calculate what the width should be. A handy trick for solving this problem is to set the display’s opacity to some small amount, showing it, then measuring the width. Afterwards, the element can be hidden and its opacity restored to 100%.