[08:35:38] <JamesMGreene> thanks, arschmitz
[08:35:48] <arschmitz> no problem
[08:35:57] <JamesMGreene> jzaefferer Krinkle leobalter scott_gonzalez gibson042 et al: QUnit meeting time!
[08:36:43] <JamesMGreene> Anyone have something they'd like to start with or should we just talk through issues blocking v1.16?
[08:37:54] <jzaefferer> here now
[08:37:56] <JamesMGreene> Moreover, are any of you present? :-P   jzaefferer Krinkle leobalter gibson042
[08:38:23] <gibson042> I have no special topic to raise
[08:38:26] <jzaefferer> I spend time yesterday on commitplease, just finished that and update QUnit to use the newest release, 1.11.0
[08:38:34] <gibson042> or throw, if that's your preferred terminology ;)
[08:38:53] <jzaefferer> this now allows us to specify valid components
[08:39:06] <gibson042> hooray!
[08:39:08] <JamesMGreene> What does that mean?
[08:39:18] <jzaefferer> This is the list I came up with so far: "Build", "Core", "Test", "Tests", "HTML Reporter", "Assert", "Dump", "CSS"
[08:39:28] <JamesMGreene> Oh, nice
[08:39:48] <gibson042> what's the difference between "Test" and "Tests"?
[08:39:52] <JamesMGreene> I would like to use "Reporter" instead of "HTML Reporter", personally
[08:40:12] <jzaefferer> gibson042: there's src/test.js and test/*
[08:40:25] <JamesMGreene> I'd assume "Test" = QUnit.test  and "Tests" = unit tests, right?
[08:41:02] <jzaefferer> almost, really Test is `Test`, while core.js defines QUnit.test
[08:41:21] <JamesMGreene> Oh, yeah
[08:41:57] <JamesMGreene> I think of them as generally the same but I suppose that's true
[08:42:10] <jzaefferer> There's also the idea to provide a template for commit messages, which could use this list: https://github.com/jzaefferer/commitplease/issues/25
[08:42:10] <JamesMGreene> So if we changed something in QUnit.test but not Test, we'd mark it as "Core"?
[08:42:47] <jzaefferer> JamesMGreene: I've been mostly using the file names as component names, so yes
[08:43:00] <JamesMGreene> k
[08:44:07] <JamesMGreene> I've been waylaid, so no real progress on my part other than some discussions
[08:44:18] <jzaefferer> Okay
[08:44:27] <jzaefferer> Any idea how it'll look like in the next two weeks?
[08:44:38] <jzaefferer> I guess Leo is busy since he's moving to Boston now
[08:44:39] <JamesMGreene> Here's the list of "jquery/qunit" issues/PRs that are supposedly holding up v1.16: https://github.com/jquery/qunit/milestones/pre-2.0
[08:44:44] <JamesMGreene> Are they all truly blockers?
[08:45:20] <jzaefferer> No, but might as well address them
[08:45:21] <JamesMGreene> Should get some time relief soon, maybe in a week. Just extra busy at work right now
[08:45:41] <jzaefferer> I'm going to review Mislav's two PRs soon, now that the CLA is signed and the commitplease stuff is mostly done
[08:46:14] <jzaefferer> I hope that Leo can work on that HTML reporter regression
[08:46:30] <jzaefferer> There's still https://github.com/jquery/qunit/issues/665
[08:46:48] <jzaefferer> gibson042: have you looked at https://github.com/jquery/qunit/issues/665 ? Any opinion? Would you use that feature at all?
[08:47:06] <gibson042> looking now...
[08:48:40] <gibson042> I prefer them as functions, but am not sure it would matter just yet
[08:49:15] <JamesMGreene> Making them setters just seems like `QUnit.done = fn` all over again to me
[08:49:23] <JamesMGreene> very limiting
[08:49:56] <gibson042> functions are likely to have much better symmetry with 2.0 changes, as JamesMGreene points out in the PR
[08:50:01] <JamesMGreene> Yes, ideally there will only be one callback for a global beforeEach/afterEach
[08:50:16] <JamesMGreene> gibson042: That's assuming they let me eventually merge a nested suites concept :-P
[08:51:48] <jzaefferer> Well
[08:52:18] <gibson042> there is nothing harder to stop than that who's time has come to pass :)
[08:52:19] <jzaefferer> I don't want to think about nested suites, yet. This feature is very marginal and I've seen very few testsuites where it helps a little bit
[08:52:42] <jzaefferer> I still tend towards ripping it out for now and revisiting together with nested suites
[08:52:49] <jzaefferer> It makes more sense in that context
[08:53:14] <gibson042> I like that approach too, provided it doesn't come with compatibility issues
[08:53:20] <gibson042> (I don't think it does)
[08:54:23] <jzaefferer> We're just removing something that we added in master a while ago, it wasn't released
[08:55:31] <JamesMGreene> \o/
[08:56:03] <jzaefferer> So JamesMGreene, what do you think about dropping it for now?
[08:56:31] <JamesMGreene> I guess it would be OK since Ember already has their custom wrapped workaround for this functionality
[08:57:37] <jzaefferer> Yeah. The one other time I would've used this, I ended up with the same workaround
[08:58:55] <jzaefferer> Okay, so I'll comment on the issue to drop it for now
[09:00:27] <jzaefferer> I made notes https://docs.google.com/document/d/13FbWhiFQ9gWQvB1Tm4QM_OC4me-ha2ujDWH5sdF7ueo/edit - guess that's all for today
[09:00:55] <scott_gonzalez> arschmitz gnarf kborchers mikesherov petersendidit rxaviers tj_vantoll
[09:01:07] <tj_vantoll> yo
[09:01:11] <arschmitz> Hi
[09:01:36] <kborchers> have to sit this one out but ping me if there is anything specific for me
[09:03:05] <scott_gonzalez> Let's start with button/checkboxradio/controlgroup
[09:03:40] <arschmitz> Ok i updated the wiki with info on backcompat
[09:04:22] <arschmitz> and have started implementing some of the basic option proxies and will finish the rest
[09:04:56] <arschmitz> im almost done with a PR to update the classes option which will change the controlgroup implementation a little bit
[09:05:27] <jzaefferer> arschmitz: apart from multiple icons, what's there that can't be mapped, if anything?
[09:05:27] <arschmitz> and im also just about done fixing everything from jzaefferer last review
[09:05:40] <arschmitz> nothing really
[09:06:25] <jzaefferer> "Need to figure out how to handle multiple icons in new button." - new button only supports one icon, right?
[09:06:32] <arschmitz> yup
[09:06:46] <arschmitz> but old button supported 2
[09:07:24] <arschmitz> its possible to do the back compat its just ugly need a bunch of additional css and logic to do it
[09:07:53] <scott_gonzalez> I think it's ok to just say "sorry, there's no deprecation period for two icons"
[09:08:02] <scott_gonzalez> There's no upgrade path for it anyway.
[09:08:03] <arschmitz> that works for me
[09:08:19] <jzaefferer> We can still map one of the two, right?
[09:08:20] <scott_gonzalez> So it's not like they just need to change how they're doing it, they have to change the design of their button if they want to use future versions.
[09:08:24] <arschmitz> yeah
[09:08:33] <arschmitz> its simple to support both of them one at a time
[09:08:39] <arschmitz> just not both at same time
[09:09:14] <arschmitz> and for when they specify 2 we will just use primary
[09:09:23] <arschmitz> since its well the PRIMARY one lol
[09:09:28] <scott_gonzalez> yup
[09:09:35] <tj_vantoll> sounds good
[09:10:19] * rxaviers is late, but he's here now
[09:11:30] <jzaefferer> Yeah, that works. Let's put that into the wiki page as well
[09:11:40] <arschmitz> will do
[09:11:59] <jzaefferer> Reminds me that we should start writing the upgrade guide for this asap
[09:12:07] <arschmitz> yup
[09:12:30] <arschmitz> there are a lot of changes
[09:12:41] <jzaefferer> Checkboxradio - Icons on by default?
[09:13:01] <arschmitz> yeah i think we should change the default to true
[09:13:02] <jzaefferer> the backcompat turns them off, but checkboxradio has them enabled?
[09:13:07] <jzaefferer> Seems good to me
[09:13:28] <scott_gonzalez> Yeah, since the semantics of the widget have changed from button to checkbox/radio, it makes sense for the icons to be on.
[09:13:39] <scott_gonzalez> You're no longer saying "represent this as a button"
[09:14:15] <arschmitz> its also very different what the icon option does
[09:14:20] <arschmitz> its now a bool
[09:14:25] <arschmitz> and toggles with the state
[09:14:40] <arschmitz> there were not even icons possible before
[09:14:42] <scott_gonzalez> right
[09:15:01] <scott_gonzalez> Because now it's actually a checkbox or radio button representation as opposed to a toggle button representation.
[09:15:08] <scott_gonzalez> You can get the toggle button representation by turning off icons.
[09:15:13] <arschmitz> yup
[09:15:36] <jzaefferer> arschmitz: do you have a plan for making controlgroup extensible?
[09:16:06] <arschmitz> jzaefferer: yeah im working on something similar to what you commented
[09:16:30] <arschmitz> but im also updating it based on classes so i need to finish that first
[09:16:45] <jzaefferer> okay, let me know if you run into issues with that
[09:16:52] <arschmitz> jzaefferer: will do
[09:17:10] <jzaefferer> Looks like Felix isn't here
[09:17:35] <jzaefferer> Scott reviewed the current datepicker PR, but nothing else has yet happened
[09:17:56] <jzaefferer> rxaviers: has anything happened to Globalize since last week?
[09:18:06] <scott_gonzalez> Yeah, my last review sat for a few days, but then he worked through everything really quickly (in a few hours).
[09:18:15] <scott_gonzalez> I expect he'll do the same this time.
[09:18:32] <scott_gonzalez> Does anyone know why the option() method is proxied though?
[09:18:49] <tj_vantoll> In datepicker?
[09:18:52] <scott_gonzalez> yeah
[09:18:55] <scott_gonzalez> For the value option.
[09:18:59] <scott_gonzalez> Well, in calendar.
[09:18:59] <jzaefferer> Something about value option?
[09:19:10] <scott_gonzalez> I don't understand why the value option isn't always correct.
[09:19:26] <scott_gonzalez> I keep asking about it, but I never seem to get a solid answer.
[09:20:30] <rxaviers> On Globalize this week, we had a meeting with Dojo and IBM about having ibm-js/ecma402 to adopt our cldr-data and cldr.js baseline.
[09:20:39] <scott_gonzalez> No response in the last review: https://github.com/fnagel/jquery-ui/commit/0f431a683968e9e9d30120eb3bf09a3f13da8814#commitcomment-7922977
[09:21:04] <tj_vantoll> scott_gonzalez: I confused by this as well.
[09:21:40] <scott_gonzalez> Here's a non-answer: https://github.com/fnagel/jquery-ui/commit/73a3d4e2915840306a826c4b47d03807f9de67b8#commitcomment-7174788
[09:21:51] <tj_vantoll> this.inline isn't a thing anymore
[09:21:57] <scott_gonzalez> How is it ever invalid?
[09:22:45] <scott_gonzalez> And he says it's changed in later versions, but it's still there in the most recent PR.
[09:22:53] <scott_gonzalez> Ok, we'll just keep waiting for an answer on that.
[09:23:18] <tj_vantoll> I'm guessing it's leftover from datepicker, where maybe the user explicitly change an <input>'s value? I'm just guessing though.
[09:23:31] <scott_gonzalez> The default datepicker demo doesn't even work right now with the current PR.
[09:23:37] <jzaefferer> There's a section called "Proposed functionality of the value method / option" on http://wiki.jqueryui.com/w/page/12137778/Datepicker
[09:23:46] <scott_gonzalez> It wouldn't be left over from datepicker, there was no value option.
[09:23:48] <scott_gonzalez> It's new in calendar.
[09:24:03] <jzaefferer> "value option -> getter returns" might be relevant here
[09:24:06] <tj_vantoll> https://github.com/fnagel/jquery-ui/blob/calendar-value-pr2/ui/calendar.js
[09:24:11] <tj_vantoll> ^ The most recent version
[09:24:26] <tj_vantoll> I think the proxy can just go away personally.
[09:24:48] <scott_gonzalez> What's documented doesn't make sense.
[09:25:06] <scott_gonzalez> The option can only become invalid via setting, in which case it should be discarded.
[09:25:25] <scott_gonzalez> It shouldn't be normalized in the getter.
[09:26:56] <jzaefferer> what's the relation between the input value and the datepicker value option?
[09:27:21] <jzaefferer> This says there should be a close relation, which seems the problem here
[09:27:35] <scott_gonzalez> Datepicker doesn't have a value option.
[09:27:50] <scott_gonzalez> The input is the value.
[09:28:03] <scott_gonzalez> Only calendar has a value option.
[09:28:24] <scott_gonzalez> Which is a bit awkward since datepicker builds on top of calendar, but that shouldn't affect how calendar manages the value option.
[09:28:27] <jzaefferer> so that is just outdated?
[09:28:40] <jzaefferer> because this talks about input + value option
[09:28:51] <jzaefferer> you're saying that doesn't exist, so let's kill it
[09:29:00] <jzaefferer> after giving Felix a chance to comment on it anyway...
[09:29:55] <tj_vantoll> Current datepicker has value() and valueAsDate() https://github.com/fnagel/jquery-ui/blob/calendar-value-pr2/ui/datepicker.js#L270
[09:31:24] <tj_vantoll> We can chat about this when Felix is around.
[09:31:50] <scott_gonzalez> yeah
[09:32:46] <scott_gonzalez> rxaviers: Ok, back to Globalize :-)
[09:32:53] <rxaviers> :)
[09:33:01] <scott_gonzalez> Did the meeting result in any concrete decisions or actions?
[09:33:31] <rxaviers> It did:
[09:33:49] <rxaviers>     John to work with Rafael to integrate the cldr-data module
[09:33:49] <rxaviers>     Rafael and Jörn to check out the i18n requirejs plugin
[09:33:49] <rxaviers>     Rafael/John to schedule a follow-up meeting once there’s some progress to look at
[09:34:26] <scott_gonzalez> Great.
[09:34:30] <rxaviers> This week, I've basically did some preliminary work to facilitate their adoption
[09:34:41] <jzaefferer> So mostly for them to integrate cldr-data, at least they intend to do that
[09:34:55] <rxaviers> https://github.com/jquery/globalize/pull/268
[09:35:02] <jzaefferer> John's boss Steven was there as well and approved that, that's something
[09:35:03] <rxaviers> whops
[09:35:09] <rxaviers> https://github.com/ibm-js/ecma402/pull/68
[09:36:07] <jzaefferer> Finding missing files shouldn't be hard, since John is the one who puts the zip files together that we use
[09:36:08] <rxaviers> But, basically, that's what happened
[09:36:23] <rxaviers> Exactly ;)
[09:38:38] <scott_gonzalez> arschmitz: You said you started work on _setOptions() support for classes, right?
[09:38:44] <arschmitz> yes
[09:38:48] <scott_gonzalez> I assume that's all there is to discuss for classes right now.
[09:38:56] <arschmitz> all i know about
[09:39:00] <scott_gonzalez> Ok
[09:39:06] <scott_gonzalez> For 1.11.2, we're back down to one issue.
[09:39:36] <scott_gonzalez> There are two listed in the agenda, but one is ready to merge, got the green light from Jörn (pending one style issue fix) this morning.
[09:39:58] <scott_gonzalez> And that last issue is the one thing on the agenda for menu.
[09:39:58] <jzaefferer> is this supposed to be under 1.11.2 in the agenda? http://bugs.jqueryui.com/ticket/10162
[09:39:58] <scott_gonzalez> http://bugs.jqueryui.com/ticket/10162
[09:40:07] <jzaefferer> That's 1.12
[09:40:15] <scott_gonzalez> hmm...
[09:40:28] <scott_gonzalez> Must've copied the wrong URL.
[09:40:30] <scott_gonzalez> Hold on a sec.
[09:40:50] <scott_gonzalez> I originally pasted in the wrong section, so I probably just grabbed the wrong URLs as the end.
[09:40:52] <jzaefferer> http://bugs.jqueryui.com/ticket/10639
[09:40:56] <jzaefferer> this one?
[09:40:58] <scott_gonzalez> yup
[09:41:15] <scott_gonzalez> So not the menu issue :-P
[09:43:41] <jzaefferer> Original issue was "Maintaining the selection is necessary if you want to use the dropdown to apply actions to a selection in a contenteditable div." - looking at the fiddle ( http://jsfiddle.net/TdLvC/ ), what's the problem?
[09:43:57] <jzaefferer> oh, this is using ui-git.js
[09:44:04] <jzaefferer> that's why its working now
[09:44:10] <scott_gonzalez> I'm going to look into this today.
[09:45:50] <scott_gonzalez> tj_vantoll: There's one issue left for hte menu PR, right?
[09:46:07] <scott_gonzalez> But that's for 1.12, so it's not as urgent.
[09:47:05] <scott_gonzalez> Ok, anyone have anything else to discuss today?
[09:47:27] <jzaefferer> Nope
[09:47:48] <scott_gonzalez> Thanks everyone. See you back in -dev.