makeitresponsive

#23 Added testing infrastructure. It's time to flesh out the tests, get a coverage report, hook up Circle CI and ensure these stay updated.

Purpose:

Allow users to control whether any given date is selectable or not.

Implementation:

We could expose whitelist/blacklist or include/exclude options that accept an array of strings.

Noticed that even though I have a date in the future "selected", ca11y opens to the current month by default. Is this the desired behavior? It's kind of annoying, because if the date is next year and I want to move it by one day, I have to click 12 times to get to the month.

If my change makes sense (and it's not something I've just messed up on my end), I'll issue a PR.

Allow type="date" and only initialize datepicker if no system datepicker is available.

Related to #13

If this package goes the route of #13 and the DOM glue is left as an external concern then we don't need to worry about proxying handlers for things like onBlur, onFocus, etc. because that can be left to user-land code.

Purpose:

Allow users to tie their code into more of the internal events that Ca11y uses.

Could include some of the following events:
onPrevMonth()
onNextMonth()
onDaySelected()
onClose()
onOpen()

I think these callbacks should all be configured under options.

Or return a date object select, so devs can use and parse it however they see fit.

With #32, we have access to strftime date parsing. As a shortcut we should provide an option for users to provide a strftime compatible format string to be applied during the formatting phase.

With flexbox and some JS features, we're a little limited on browser support atm. Just worth a note.

Despite the title, I'm not convinced we need complete feature parity with any other specific datepicker libs.

Thoughts:

Referencing some other datepicker libraries to get a sense for the options they expose. I'm not certain about which of these we want to implement. Further discussion on the direction and philosophy behind Ca11y is required. Discussions in #13 and #20 seems to indicate that there is some interest in having Ca11y not be directly responsible for manipulating DOM outside it's own tree. It may also be nice to allow a user to control into which container the Ca11yndar markup get's rendered (option called render or container)?

Possible Options to Add:

container || render: per above, container could be a string selector or node. render would be a function
autoClose: auto hide the datepicker when a date is selected
clearButton: display a button that clears the selected date
disableTouchKeyboard: no keyboard will display on mobile (call blur on the input when the calendar is shown)

Links:

http://bootstrap-datepicker.readthedocs.org/en/stable/options.html

• all text on background color combinations
• all button color combinations
• all hover, focus, and active state color combinations
• ideally, sample page's input box would have better contrast too

Value probably makes more sense to be first.

Issue a warning if the user chooses colors that aren't accessible.

Sass warnings:
http://www.sitepoint.com/using-sass-error-warn-and-debug-directives/

Sass contrast checker:
https://gist.github.com/FStop/8959422

This is definitely in the "shoot for the moon" column, but thought I'd add it.

Cycling through months also selects the first day of the month. Probably not desirable. Lets leave the selected date alone on month change.

Do it.

Because the next and previous buttons are in the lower left corner, when switching between months that have a different number of week rows, the next and previous buttons shift up and down which makes it frustrating when navigating them with the mouse (clicking on next/prev repeatedly.)

For doing things like custom date parsing. We probably shouldn't even touch the date input... let the implementer do that in the callback. Ideally I'd like the setup to be something like:

import Ca11y  from 'ca11y'
import options from 'ca11y/defaults'
import parse   from 'ca11y/parse'

const someInput = document.querySelector('#some-input')

function callback(selectedDateObject) {
  someInput.value = parse(selectedDateObject, 'mm/dd/yyyy')
}

const datePicker = new Ca11y(options, callback)

To cut down on initialization boilerplate..

Safari 9.0.3, Firefox 44.0.2, probably others.

😞

Related to #13

Purpose:

Allow users to override the default date parsing and formatting that Ca11y does.

Implementation:

This could be entirely left to userland code as Dan outlined in #13.

import Ca11y     from 'ca11y'
import strftime  from 'strftime'

const myInput = document.querySelector('.input')

// user defines format/parse methods and is responsible for calling them
function format(date) {
  return strftime('%F %T', date) // simple e.g.
}

function parse(str) {
  const date = new Date(str) // simple e.g.

  return { 
    valid: !isNaN(date), // basic validation
    date: date
  }
}

function createChangeHandler(instance) {
  return function onChange(e) {
    const result = parse(e.target.value)

    if (result.valid) {
      instance.setDate(result.date)
    }
  }
}

const options = {
  // when a day is selected, propagate the change back to the input
  onDaySelected(date) {
    myInput.value = format(date)
  }
}

// create a new Ca11y instance, lib is responsible for merging defaults with options
const calendar = new Ca11y(options)

// tie changes to the input back to Ca11y
myInput.addEventListener('change', createChangeHandler(calendar), false)

Add test coverage.

Should the date input default to showing an error state when the input value is not in the YYYY-MM-DD format? I manually entered a value instead of using the picker here:

https://html.spec.whatwg.org/multipage/infrastructure.html#valid-date-string

If tabbing past the last date, focus should return to the prev/next month buttons

When an invalid input is entered, this error throws:

index.js:155 Uncaught TypeError: Cannot read property 'displayName' of undefined