[09:00:00] <scott_gonzalez> jzaefferer: arschmitz gnarf kborchers mikesherov tj_vantoll
[09:00:11] <arschmitz> here
[09:00:12] <kborchers> yo
[09:00:47] <scott_gonzalez> New agenda doc: https://docs.google.com/spreadsheet/ccc?key=0AgyHrN8YnS0IdER6clpleEd6WnBrRTgybnhUSTVMRUE
[09:00:51] <tj_vantoll> hey
[09:01:45] <scott_gonzalez> rxaviers isn't back yet, so probably no updates for AMD or CLDR this week.
[09:02:05] <scott_gonzalez> It looks like we have consensus to use full AMD in the tests though.
[09:02:24] <scott_gonzalez> Dylan's PR for tooltip a11y improvements landed.
[09:02:44] <scott_gonzalez> He's looking into autocomplete now since it needs a similar hack for the live region.
[09:03:28] <scott_gonzalez> arschmitz: Any update for button or have you been busy with Mobile stuffs?
[09:04:28] <arschmitz> not really mobile has kept me busy last couple weeks
[09:04:57] <arschmitz> one thing though is i want to talk to kristoph about spans vs :after when we talk to him with jasper
[09:05:42] <arschmitz> for anyone that does not know he is the main man behind Topcoat
[09:06:00] <scott_gonzalez> Sounds good.
[09:06:20] <scott_gonzalez> _isDivider() was added to menu to handle optgroups in selectmenu.
[09:07:06] <jzaefferer> Those commits look like there should've been a PR
[09:07:45] <scott_gonzalez> Which commits?
[09:08:11] <jzaefferer> For adding _isDivider(), and using it in Selectmenu; I see commits in master, but can't find a closed PR for that
[09:08:29] <tj_vantoll> https://github.com/jquery/jquery-ui/commits/master (the four commits on Dec 18th)
[09:08:46] <tj_vantoll> I can't remember the GitHub convention for URLs with commit ranges.
[09:09:15] <jzaefferer> Looks like your var-declaration comment didn't get addressed either...
[09:09:45] <scott_gonzalez> :-/
[09:09:49] <jzaefferer> This one: https://github.com/jquery/jquery-ui/commit/a6806ab17a9a5b332dc7d0c947a0a7a512dc2579#commitcomment-4896745
[09:11:12] <jzaefferer> How is this? https://gist.github.com/jzaefferer/edaea75821be062ce57d
[09:11:36] <scott_gonzalez> Needs a blank line above 31
[09:12:01] <tj_vantoll> looks good
[09:13:08] <scott_gonzalez> There's an open ticket + PR for disabled items in autocomplete.
[09:13:09] <jzaefferer> (please add line numbers to pretty-diff! 31 isn't anywhere in the actual code)
[09:13:40] <scott_gonzalez> Well, adding them to pretty-diff isn't going to help with gist-diff :-P
[09:14:24] <jzaefferer> Anyway, like this? https://gist.github.com/jzaefferer/28e8a001c7df69ad95b6
[09:14:38] <scott_gonzalez> yup
[09:14:40] <jzaefferer> Blank line as the first line in a method is odd
[09:14:56] <scott_gonzalez> We have a few methods like that.
[09:15:36] <scott_gonzalez> So, back to autocomplete.
[09:15:44] <scott_gonzalez> I've never seen an autocomplete with disabled items before.
[09:15:50] <scott_gonzalez> I think the whole idea is a bit strange.
[09:16:24] <scott_gonzalez> https://github.com/jquery/jquery-ui/pull/1163
[09:16:51] <scott_gonzalez> I'm going to try to implement this as an extension without modifying the plugin to see if we can just close this.
[09:17:15] <scott_gonzalez> Any objection to that resolution if it works?
[09:17:40] <tj_vantoll> I agree it's an edge case. I'm fine with not modifying the core widget.
[09:17:43] <jzaefferer> No, that seems fine
[09:18:03] <jzaefferer> You can put it in a demo and maintain it forever :p
[09:18:17] <scott_gonzalez> haha
[09:18:26] <scott_gonzalez> Here's how you do something we think is bad...
[09:18:41] <tj_vantoll> If you *can* implement it without duplicating code then the issue and PR are fine to close.
[09:18:44] <scott_gonzalez> While I'm at it, I can make a demo for busted tabs with <base>.
[09:18:47] <tj_vantoll> imo
[09:18:48] <tj_vantoll> :)
[09:19:19] <scott_gonzalez> tj_vantoll: Any update on datepicker?
[09:19:54] <tj_vantoll> I have most of the old tests running now. I still have a little more work there.
[09:20:05] <tj_vantoll> I implemented value(), valueAsDate(), and isValid().
[09:20:29] <tj_vantoll> I want to implement min and max since a lot of the old tests use those options.
[09:21:02] <tj_vantoll> My question is, what formats should min and max take? The existing options take a Date, Number, and String: http://api.jqueryui.com/datepicker/#option-minDate
[09:22:15] <tj_vantoll> The Date and formatting String (e.g. "1/8/14") make sense, but should we support things like "+1m" or 2?
[09:23:07] <scott_gonzalez> We might want to simplify the datepicker API and just delegate to Globalize.
[09:23:32] <scott_gonzalez> Or we might decide that all strings require the use of Globalize and we just pass it along.
[09:23:43] <scott_gonzalez> Let's wait till rxaviers is back to see what he thinks about that.
[09:24:08] <scott_gonzalez> If we support `"+2d"` I don't think supporting `2` is necessary.
[09:24:32] <scott_gonzalez> I think supporting numbers just adds confusion.
[09:24:41] <tj_vantoll> Ok. For now I think I'll just implement the Date objects and we can talk about strings with rxaviers.
[09:24:47] <scott_gonzalez> If I saw a date method that said it accepted numbers, my first thought would be it's a timestamp.
[09:24:50] <scott_gonzalez> Not a relative number of days.
[09:24:55] <scott_gonzalez> Sounds good.
[09:25:00] <tj_vantoll> I agree that Number APIs are confusing.
[09:25:15] <tj_vantoll> *these* Number APIs that is
[09:25:18] <scott_gonzalez> And we don't lose any functionality if we're keeping support for "+2d"
[09:25:19] <arschmitz> scott_gonzalez: i agree also i would assume timestamp
[09:25:48] <jzaefferer> > support for "+2d"
[09:25:56] <jzaefferer> where is this currently implemented?
[09:26:08] <jzaefferer> wait, that's a silly question. Everything is stuffed into datepicker...
[09:26:45] <scott_gonzalez> :-)
[09:26:52] <jzaefferer> I've here and there talked with Rafael about delegating to moment for manipulating date objects. In that regard, we could only support Date objects (or strings that we pass off to Globalize)
[09:27:25] <jzaefferer> And have users use Moment to build Date objects where needed, which would then do "+2d" or moment.startOf("week") and fun stuff like that
[09:28:02] <scott_gonzalez> Yeah, that's along the lines of what I was thinking.
[09:28:55] <tj_vantoll> Yeah I think we should support Strings that can be directly passed to Globalize (e.g. 1/8/14). I'm fine abandoning the relative date strings.
[09:29:18] <tj_vantoll> btw those string are currently parsed in here: https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.datepicker.js#L1299
[09:30:45] <scott_gonzalez> tj_vantoll: parser-lib was released yesterday.
[09:30:52] <tj_vantoll> ah cool
[09:31:16] <jzaefferer> What's parser-lib?
[09:31:44] <jzaefferer> Apart from being a candidate for most ambiguous name...
[09:31:50] <tj_vantoll> https://github.com/nzakas/parser-lib/pull/98
[09:31:54] <scott_gonzalez> The CSS parser used by csslint.
[09:32:01] <scott_gonzalez> Which is in turn used by grunt-contribut-csslint.
[09:32:05] <scott_gonzalez> Which is used by us :-)
[09:32:11] <tj_vantoll> So now we need a new version of https://github.com/gruntjs/grunt-contrib-csslint.
[09:32:25] <scott_gonzalez> Since grunt-contrib-csslint and csslint both use version ranges, we should be good to go.
[09:32:40] <tj_vantoll> Oh cool. I'll update my PR then.
[09:32:40] <jzaefferer> tj_vantoll: that method doesn't even seem to deal with relative date values like +2d
[09:33:17] <scott_gonzalez> tj_vantoll: You might not to force an update of grunt-contrib-csslint.
[09:33:26] <jzaefferer> I have write access to all grunt-contrib repos; if you ever need a new release in any of them, let me know
[09:33:28] <scott_gonzalez> This is the really annoying thing about version ranges.
[09:33:42] <scott_gonzalez> We might get failures for people who already have this installed.
[09:33:48] <scott_gonzalez> Because our dependency isn't changing.
[09:33:53] <scott_gonzalez> But the nested dependencies are.
[09:34:00] <jzaefferer> Yeah, that sucks
[09:34:37] <arschmitz> its bit us in mobile twice
[09:35:02] <arschmitz> and broken out tests
[09:35:04] <arschmitz> our
[09:35:11] <jzaefferer> Maybe we should start using npm-shrinkwrap to tackle this? Would have to try if it would actually help here. -> https://npmjs.org/doc/shrinkwrap.html
[09:35:38] <tj_vantoll_phone> I just lost power o_O
[09:35:50] <jzaefferer> Once we start depending on a nested dependency, run `npm shrinkwrap` and commit the updated npm-shrinkwrap.json
[09:36:46] <scott_gonzalez> Well, let's see what happens.
[09:37:21] <scott_gonzalez> Looks like `npm install` isn't enough, but `npm update` is.
[09:37:32] <tj_vantoll1> Power seems to have been restored. I'll try to update that PR right after the meeting.
[09:37:50] <jzaefferer> But that's pretty random - how would anyone know that they have to run `npm update`?
[09:38:41] <scott_gonzalez> You could just do a release of grunt-contrib-csslint and the problem would go away :-P
[09:40:24] <tj_vantoll1> scott_gonzalez: After the meeting you'll have to tell me what you did. I'm getting errors but I haven't forced updated anything.
[09:40:46] <scott_gonzalez> ok
[09:40:57] <scott_gonzalez> Does anyone have anything else to discuss today?
[09:44:05] <scott_gonzalez> Ok, see everyone back in -dev.
[09:44:06] <scott_gonzalez> Thanks.