Author: Andrew Duthie

Over the past few months, I’ve published a numberofNodemodules aimed at implementing a very minimal and focused set of features. In doing so, I’ve made a point to take special care in keeping the size of the code as small as possible; ideally a kilobyte or less in size when minified. Not only does this force me to think of the simplest solution, it importantly reduces the burden on applications in using it, especially when it’s bundled to be served on the web. There are a number of techniques I’ve employed toward this goal, and for the purpose of this post I’ll focus on the module bundler: Rollup.

Regimen is a side-project I’ve been building off-and-on for the past few months. It’s a web app that I’d originally created for myself out of frustration for the lack of options in helping me plan my workouts. Specifically, most weightlifting routines offer some form of downloadable Excel spreadsheet, but these are cumbersome to work with when at the gym. I found myself either fumbling with the Google Sheets app on my phone, or printing a paper copy of the spreadsheet – neither was a great solution.

Tonight, I presented on the topic of “Responsive Web” to our local WordPress meetup group based in Cincinnati. Below is the abstract and slides:

What is responsive web design, and why should you care? As a developer or when otherwise modifying an existing theme, how do you go about making elements on a page responsive? At December’s meeting, we’ll seek to answer these questions and others.

Some items that we’ll expect to cover include:

Motivations behind responsive web design

Tools for testing your a theme or page in a variety of contexts

Building your site to work on all types of displays, be it desktop, phone, tablet, or other

Imagine yourself building a web app that supports image uploads by simply capturing your computer’s paste keyboard shortcut. Sites like imgur.com already support this behavior and it adds an extra level of convenience for what would otherwise require several additional button clicks.

The paste event has been supported in major browsers for some time now, but interestingly Firefox doesn’t trigger the event unless the user’s cursor is currently focussed in an editable region. This seems to be contradictory to the specification itself, which states:

The paste event has no default action in a non-editable context, but the event fires regardless.

There is an open ticket on Bugzilla related to this behavior, while others have resorted to tricks to move the user’s cursor when detecting that a combination of the “control” and “v” keys are pressed.

In my testing, however, I found that the mere presence of a contenteditable element at the root of the page was sufficient in allowing the paste event to trigger normally in Firefox, even if the element is hidden using display: none; styles.

Check it out in the demo below:

In Firefox (v40.0.3 as of today), you’ll find that the paste event is captured so long as the contenteditable attribute is assigned. When toggling the contenteditable off, thereby removing the attribute, the paste is no longer captured. Admittedly, it’s a nuisance to include this unused element, but it’s certainly an improvement over redirecting or otherwise faking the paste interaction using one of the aforementioned tricks.

While there are many other browser inconsistencies to account for when working with the paste event, I was surprised to find that despite what I had read, it was easier than I had anticipated to capture page-wide pastes in Firefox.