Hi! I work on Brick. Yes, there are still rough edges on these components, and we're putting them out there in the hopes of getting feedback and bug reports- a traditional beta.
Cool. I see the date picker has been fixed - thanks muchly & thanks for putting this out there.
In terms of feedback :) I gave it a shot. The only one that had a native date picker component (on my setup) was Chrome. The polyfill version didn't seem fully operational (just an overflow list of the same date?).
The Chrome native suffers from the same UX snafu that so many Date Pickers do - it's fine for relative dates, but terrible for absolute ones. If you want to schedule an event in a week it's great. Or of you want to search for flights.
However, if you want to enter a Date of Birth, it's terrible. You have to scroll through hundreds of months to get to the year you want.
So maybe you fall back to typing? In the native picker in Chrome, you can muddle through the day/month piece, but you can't type a straight year. e.g. start by typing "19" for "1975" and it'll match "1909". This also makes it impossible to enter a date in the 2000's!
You do get a "spinner" that might let you set the year, but the buttons are so small I think it defies practical usability.
Bah! Interestingly the iOS version does not suffer from this gripe as has a slot-machine three drum date selector. It does default to today, but it's pretty easy to move +/-50 years in either direction.
Sorry, that was a genuine rant. I know this is not intrinsic to Brick, but for me a universal Date Picker is #1 bugbear that I'd like it to solve.
(* The Chrome one also defaulted to the wrong timezone. Clicking "today" selected the wrong date.)
I'm not having the freezing issue with Chrome (28). But I think there're some major usability issues. I cannot figure out how to input a date. If I input "8" then "16" it's current value is 08/16/yyyy with the "yyyy" part selected. If I continue to input "2" for the year part it changes to 1902. Inputting "20" will reset the date picker back to mm/dd/yyyy.
I believe you are describing the native datepicker, I am seeing the same weirdness. Be advised, the calendar polyfilled calendar is only active when a native implementation is not detected, or you force it to be used. This may be a bug in Chrome itself.
Yes you're correct. It's neat that it uses the native datepicker if available, but one area of concern is they use different date input formats. Native forces mm/dd/yyyy while the polyfill suggests yyyy-mm-dd (though it accepts the former format as well).
Given that the errors and ability to reproduce are so erratic (to the extent that people with the very same browser versions on the same platform are seeing different behavior), I have a feeling the issue may be something like this: https://github.com/eternicode/bootstrap-datepicker/issues/95...
Another thing about the date picker that was at least happening on my desktop: when it expands, it expands well beyond the bounds of the mobile phone container they're using in their example:
I'm also running Chrome 28 (Version 28.0.1500.95) on Windows, but everything is running fine. I'm wondering if Chrome itself is locking up, because the calendar demo is has only one demo of the polyfill picker, the rest are the native calendar that it uses when it detects it is available.
The one I was most interested in was the Date Picker, but locks up Chrome (28) and Safari (6) on my machine. http://mozilla.github.io/brick/component/datepicker/demo/ind...