Here's mine[1]. I need to button it up for an actual release, and improve the demo to show more options... it's pretty flexible and the modal is entirely standalone, with no external dependencies on the built version.
You could write a pretty thin shim for wiring up date inputs. I didn't write an actual date input component as I wanted it to be able to tie to whatever input component/method one wanted... but have a nice full-modal picker.
Also, as you resize the screen it will handle reflows/sizing as well as vertical scrolling when the window is too small, many modal templates won't do that properly. The size min+gz is about 20kb, using preact, preact-compat and redux... I'll probably refactor to separate the actual date-picker component from the modal, and make it more friendly for use inside react (and preact-compat) projects, without the bundling.
edit: the demo doesn't always seem to gzip the js, it's about 60k non-gzipped, but can shrink a bit with gzip level 5-9 compression.
[1] http://tracker1.github.io/md-datepicker/
Indeed, but without dependencies it's a lot more work. Anyway, moment is great for date management so IMO it's a dependency in lots of projects dealing with dates.
About the polyfill, with dpicker:
;[].slice.call(document.querySelectorAll('input[type="date"]')).forEach((e, i) => new DPicker(e))
Maybe you can use rollup or similar to bundle moment inside this lib and use tree-shaking to reduce the final size ?
About the polyfill, of course it is more complicated than that. There's no test of support, the value formatting is different, the optional HTML attributes are not handled etc. This would imply major changes in your library to mimic the standard.
I've introduced the type="date" attributes support (eg: min, max) and added format to the input attributes. This way, it can almost be a full polyfill, it'll still replace the type attribute with `text` so that the browser doesn't interfere with handled events/value.
Thank you, I appreciate the effort and the documentation. If you want to propose a full-polyfill behaviour, you could make a new module for that. Then you won't have to worry about the code size when adding the missing parts of the standard like valueAsDate: https://gist.github.com/sylvainpolletvillard/0aa9df9c180cd007e5e1
Indeed but it's an interesting idea. Anyway, you'll have to change type=date to type=text, at least programatically to ditch the navigator behavior...
Thanks about the bundle idea, I'll think about that. Thing is, if you're handling dates with javascript, you probably already use momentjs. IMO it's easier to let the end developper bundle everything his way.
Not really, you've seen how many lines of code "rome" has? 2253 sloc in the standalone version, even with comments dpicker is 578 sloc, and I've lot of comments compared to rome.
Also, I count 4 dependencies, where dpicker has only 2.
I don't speak about maintenance either (38 issues, 14 PR, not updated since a year). A date picker is supposed to be simple and straightforward. Btw rome is almost not commented.
> Also, I count 4 dependencies, where dpicker has only 2.
I wouldn't count 3 of them, since they're packages by Bevacqua himself. The other is moment.js, which dpicker depends on too.
Rome *is* larger, though.
ok i was simply drawing comparison.. however it seems like you took to the offensive stance. When i saw your link it just reminded me of Rome by ponyfoo thats all. No harm no foul.
Sorry 'bout that, those were only facts didn't meant to be offensive. Thing is there are many date picker implementations and I always have the feeling that those are too heavy...
Indeed, but without dependencies it's a lot more work. Anyway, moment is great for date management so IMO it's a dependency in lots of projects dealing with dates. About the polyfill, with dpicker: ;[].slice.call(document.querySelectorAll('input[type="date"]')).forEach((e, i) => new DPicker(e))