Using only Month and Year in jQueryUI Datepickers

User interface components in general are built with an expected user behavior.
We used the jQuery-UI datepicker, to save time, but in an unusual way, which
cost us a lot of time discovering what we’d missed. We re-learned a key insight,
namely, month and year are navigation, not selection controls.

The rest of this post describes the implications we worked out. Short version
of the code is at the bottom of this post. There are other files attached in a gist version of this post at


Recently (November 2016) we ran into a design requirement that a dashboard report should cover a time period, with start and end dates and that the report should update when users change a month or a year in either the start or end datepicker.


In the interest of saving time, rather than roll our own control for that, we
chose to use the JQueryUI datepicker for each of these, but with an unusual
approach that we would not show the calendar control (the table with all the
clickable date links).

Of course, that unexpected approach led to unexpected and undesired behavior.


In our implementation, we used changeMonth: true and changeYear: true in the
datepicker(options) argument, in order to display the month and year “
elements, and set let the datepicker display “inline” (i.e., always, without a
dialog – see

We also set the defaultDate to the current year and month, and use 1 as the
day, so that we’re always comparing the first of any month.

We also needed to keep the two datepickers synchronized, such that a user could
not set the start date to something greater than the end date. We do that in the
onChangeMonthYear handler, re-setting either start’s maxDate or end’s
minDate after a change to the end or the start date, respectively.


The prev and next arrows worked just fine, as they are decrement/increment
handlers only. But we noticed that sometimes the onChangeMonthYear handler
was called multiple times when we changed a date by using the month and year
select elements. For example, we’d change the start year, then change the
end year. On that second change, we’d see the update to the start date’s
maxDate – which seemed to trigger a onChangeMonthYear call to the start
datepicker again, even though the start element had not been touched.
The result was that date ranges became unpredictable, even un-navigable.


It turns out the onChangeMonthYear event results only in re-drawing the
calendar – it does not calculate a new date selection.

Translation: month and year are navigation controls; the calendar’s date links are the selection controls.

The expected behavior in the datepicker is that users select a date link inside
the calendar. Because we are not using the calendar, we have to re-set the date,
in code, on the datepicker for which the onChangeMonthYear handler is called –
every time.

You can see most of the code fragments necessary to make the whole thing go by
looking at the other files posted in this gist. Here’s the condensed version of
the JavaScript we used:

onChangeMonthYear: function (year, month, instance) {

  // Build a new Date from the display date, decrementing the display
  // month by 1 for use in JavaScript's built-in Date().
  var newDate = new Date(year, Number(month) - 1, 1);

  // This one line prevents the buggy behavior noted above.
  $(instance.input.context).datepicker('setDate', newDate);


This took quite a bit of time to reason out, but that’s all there was to it.

Pseudo-Comments in CSS (Or, How Browsers Parse Styles)

The CSS spec does not mention it, but you can mimic C-style and/or unix-style line comments in CSS files (with some caveats). Others have written about them before (see in particular, SitePoint’s Web Foundations post covering CSS Comments). The present post examines them in further detail.

[Note: Thanks to Louis Lazaris and Web Tools Weekly, this post was originally published on October 21, 2015, at It is actually a follow-up (slightly modified) to my earlier post on CSS line rule comments. ]

Continue reading

Constructor Inheritance in JavaScript

[ originally posted 12 Feb 2013 ]

Note: this post acts as justification for my Constructor kata on github. It’s really a re-post for posterity, as 1) I thought it worth preserving a specimen of my former thinking, because 2) I think far less often in the constructor/super inheritance pattern in JavaScript than I did even a year ago (i.e, summer of 2014).

Continue reading

3rd-party code still needs tests

[ original gist 28 March 2013 ]

“If there are no tests, it does not work,” a former colleague said, who could have added, “whether your code or someone else’s.”

I’m not the first to say it but it needs re-stating: 3rd-party libraries are no guarantee that your code continues to behave as expected.

If one of the duties of your work is making sure you’re not introducing bloat or cruft or inefficiencies or bugs or unexpected behavior, then you’re cutting corners if you don’t have tests, whether you use 3rd-party code or not.

Continue reading