Cloud Four Blog

Technical notes, War stories and anecdotes

What’s New in hideShowPassword 2

Last June, we released our hideShowPassword plugin for improving the experience of password-entry (particularly on mobile devices). As of this writing, it’s our most-starred and most-forked project on GitHub.

We’ve released a handful of incremental and bug-fix updates since then, but today we’re shipping a full-fledged Version 2 with several noteworthy improvements.

Simpler Usage

The plugin’s “inner toggle” feature tended to steal the show, yet its syntax was verbose:

$(selector).hideShowPassword(true, { innerToggle: true });

We now support a simpler, shorthand syntax for enabling the inner toggle:

$(selector).hideShowPassword(true, true);
 
// enable toggle but hide till input focus:
$(selector).hideShowPassword(true, 'focus');
 
// using shorthand method:
$(selector).showPassword('focus');

Improved Accessibility

My personal favorite feature is the improved accessibility of the inner toggle button. Some changes we made based on real-world feedback:

  • The toggle button element is now a <button> by default (it was previously a <div>).

  • Several accessibility attributes have been added to better communicate the purpose and state of the button to assistive devices.

  • The toggle should now be keyboard-accessible, with space and enter key events attached where necessary.

We understand every project’s different, and you may need to tweak some of these new properties. Luckily, Version 2 also includes…

Overhauled Options

Just about anything we could make an option, we have. There are so many new options, we had to re-organize the options object to accommodate them all. See the full list here.

Built For jQuery and Zepto

Version 1 of hideShowPassword supported Zepto, but we’ve decided to simplify the plugin’s dependencies by only supporting jQuery from here on out. This makes sense to us for a few reasons:

  • Zepto’s data module was required, necessitating a custom build of Zepto to work at all.

  • The plugin’s inner toggle features could be unpredictable given Zepto’s simpler width and height calculation methods.

  • Zepto does not support AMD, and likely never will. We introduced AMD support to hideShowPassword in our first minor update based on developer feedback.

  • While Zepto’s modest file size remains an attractive feature, its performance once loaded may not be so competitive.

Get It Now!

All the aforementioned improvements (plus more fixes and tweaks) are available right now on GitHub (which is also a great place to report issues or request features). Check out the live demo if you remain unconvinced.

If you use the plugin in a project, please drop us a line and let us know. We’d love to hear about it!

Invisible Webfont Issues in Chrome (and a fix)

A few weeks back, we started hearing from Chrome users about a rather bizarre problem. They’d visit our site, only to find that the text was completely invisible:

Screenshot of blog.cloudfour.com with webfont issue

(Poor Jason, all alone, no content to keep him company…)

It turns out that Chrome 32 and 33 have some bugs when it comes to webfonts. Typekit wrote about the problem in a February post and again in a March update.

We’re sure the Google folks will fix the issue in a future update, but in the meantime it’s a significant obstacle for our users. So we rigged up a temporary hack based on a solution offered in Chrome’s issue tracker that seems to remedy things:

Our hack uses browser detection (yuck) to avoid unnecessary repaints, but if that turns your stomach there’s also a CSS-only solution. Let’s hope either measure is an extremely temporary one!

SimpleSlideView: Controlling Flow With JavaScript

In July we released SimpleSlideView, a jQuery and Zepto plugin for simple, responsive sliding views (here’s a demo). In the last few months, I’ve noticed an uptick in developers emailing to ask a variation of this question:

How do I change or stop a view transition based on user input?

It’s a great question, and one that may not be immediately apparent from the demo alone.

When using SimpleSlideView, there are two ways to navigate between views. The simplest way is with HTML, which is great for predictable, non-dynamic interactions or prototyping:

<button data-pushview="#result">See Result</button>

The straightforwardness of this technique is a double-edged sword. It’s easy to use, but it’s also kind of static. What if we want to change the destination? Or prevent the transition altogether? For that, we’ll want to use JavaScript instead.

We can remove the data-pushview attribute from the button, but we’ll need some way to select it via JS, so let’s give it an ID:

<button id="result-btn">See Result</button>

And here’s the scripty part:

// Save the simpleSlideView instance to a variable
var slideView = $('#container').simpleSlideView();
// Add a click event handler to the button
$('#result-btn').click(function(){
  // On click, push the view with an ID of 'result'
  slideView.pushView('#result');
});

Right now this probably feels like a step backward. It’s more verbose. But we’ve gained the freedom to define the sliding-view behavior any way we like.

Suppose you only want to transition when certain criteria are met:

if (isValid) {
  slideView.pushView('#thanks');
} else {
  alert('Oops! Something seems off.');
}

Or maybe you’d like the next view to depend on the value of something else:

if (age < 21) {
  slideView.pushView('#soda');
} else {
  slideView.pushView('#beer');
}

Here’s a working example that uses Moment.js and your browser to determine the weekday of a date you provide. The result is populated before the view transitions, and only if Moment.isValid() returns true:

See the Pen Weekday (SimpleSlideView Demo) by Tyler Sticka (@tylersticka) on CodePen.

For more info on what you can do with SimpleSlideView and JavaScript, refer to the documentation on GitHub. If you’re using SimpleSlideView in your own projects, we’d love to hear about it!

Retooling

GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).

Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.

We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.

It’s a complicated relationship.

 Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.

Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.

We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.

In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!

Icon Fonts: Mind the Baseline

Earlier this week, I made my first custom icon font using IcoMoon (implemented with Filament Group’s “bulletproof” technique).

I set my grid sizes and exported, but all the icons felt a little higher than I wanted them to be in relation to their surrounding elements. I did some finagling in CSS, but found the results varied (sometimes wildly) between platforms.

After some fruitless Googling, I trudged through the font’s preferences and found the culprit: A rather diminutive baseline height value. In IcoMoon, this is under Preferences, then Font Metrics.

Here’s a quick example at the default height (6.25%):

Here are the same elements and icons, but with a larger baseline height (18.75%):

Lesson learned: If the icon font’s vertical alignment is off, adjust its baseline height before resorting to CSS tweaks.

The more you know…