[09:00:21] <scott_gonzalez> arschmitz: fnagel gnarf jperrault jzaefferer kborchers mikesherov petersendidit rxaviers tj_vantoll
[09:00:24] <fnagel> Hey
[09:00:41] <jperrault> o/
[09:00:52] <kborchers> hey
[09:01:00] <rxaviers> Hello
[09:01:22] <arschmitz> Hi
[09:01:40] <scott_gonzalez> We still have one regression open from 1.11.1: http://bugs.jqueryui.com/ticket/10590
[09:01:58] <scott_gonzalez> mikesherov is assigned, but not sure if he's had any time to look into it yet.
[09:02:13] <scott_gonzalez> mikesherov did fix the regression from 1.11.2.
[09:02:31] <tj_vantoll> yo
[09:02:47] <jzaefferer> oi
[09:03:26] <scott_gonzalez> Thre's been some discussion going on around the AMD loading for tests.
[09:03:32] <scott_gonzalez> jburke has chimed in: https://github.com/jquery/jquery-ui/pull/1335#issuecomment-62188765
[09:04:15] <scott_gonzalez> So I'm guessing there's nothing to discuss about this right now. Is that corect, rxaviers?
[09:04:33] <rxaviers> By reading the discussion, I didnt understand what needs to be changed
[09:04:37] <rxaviers> Did you jzaefferer?
[09:05:31] <jzaefferer> We want to keep execution order without having to add two wrappers to all test files
[09:05:40] <rxaviers> How to accomplish that?
[09:05:41] <jzaefferer> using nested require seems to be good enough for now
[09:05:50] <rxaviers> ok
[09:06:37] <jzaefferer> so we should just give that a try, undoing some of the earlier changes, and applying the same changes to a second testsuite
[09:06:50] <jzaefferer> so see if we can abstract the require calls and reuse that abstraction
[09:07:40] <rxaviers> ok
[09:08:23] <rxaviers> About the demos to use AMD tests, lot has been discussed in the previous*2 meeting. But, nothing has been added to the PR.
[09:09:20] <jzaefferer> Can we finish using AMD in tests first? Or is there something in demos that needs discussion immediately?
[09:09:26] <jzaefferer> I don't remember the details of the previous discussions
[09:10:23] <tj_vantoll> They can happen independently.
[09:10:58] <rxaviers> no problem, I can get AMD in tests first
[09:11:38] <scott_gonzalez> tj_vantoll: Are you still stuck on removing the wrappers in minified files?
[09:12:09] <tj_vantoll> Yeah I gave up. I don't know how to do it without some hand holding.
[09:12:27] <scott_gonzalez> rxaviers: Can you help with that?
[09:12:36] <scott_gonzalez> This is in jquery-ui's Gruntfile.
[09:12:55] <rxaviers> absolutely, tj_vantoll please let me know what's going on in -dev after the meeting
[09:12:59] <tj_vantoll> Will do.
[09:13:02] <rxaviers> ;)
[09:13:43] <jzaefferer> One thing about AMD tests: Rafael wrote somewhere on that PR: "Considering test execution order doesn't matter, yeap it's better. Got the files updated accordingly."
[09:13:50] <jzaefferer> I'd like to discuss that point
[09:14:05] <rxaviers> that was before scott saying it matters
[09:14:08] <jzaefferer> We'd still have all modules grouped, but the order of modules would be arbitrary
[09:14:09] <rxaviers> that can be ignore
[09:14:12] <rxaviers> ignored*
[09:15:01] <jzaefferer> With the testId change in QUnit and the modules being ordered in the select (on the top right), the order technically doesn't matter
[09:15:48] <jzaefferer> But I guess for sanity its still better to have tests displayed in the same order on every run, which requirejs won't gurantee
[09:16:19] <jzaefferer> in my tests it looked like it was the same order on every run, but the order itself was arbitrary
[09:16:33] <jzaefferer> if we can live with that, we could just do a single require
[09:17:04] <scott_gonzalez> jzaefferer: Perhaps network latency will change your mind ;-)
[09:17:11] <rxaviers> As far as I remember, the problem that required tests to be in a sequential order was the execution of a certain test.
[09:17:26] <rxaviers> for example, selecting test #x.
[09:17:30] <jzaefferer> rxaviers: that was about testNumber, with the upcoming testId parameter that problem goes away
[09:17:38] <scott_gonzalez> You probably have consistently low overhead for every file, so order is likely based on number of chunks per file.
[09:18:11] <jzaefferer> scott_gonzalez: I ran the same suite a dozen times, the core module got run last every time, I think because it had a dependency on one additional module, compared to the other tests
[09:18:54] <jzaefferer> requirejs 1.0 had an order plugin, maybe we can rebuild that if the nested require calls turn out to suck
[09:20:25] <jzaefferer> http://requirejs.org/docs/release/1.0.5/comments/order.js
[09:21:54] <jzaefferer> anyway, let's try nested require calls for now
[09:22:03] <jzaefferer> arschmitz: update on classes?
[09:22:05] <rxaviers> So, with the testId fix in place, there's no technical reason to keep the same order except cosmetical.
[09:22:24] <arschmitz> Yea
[09:22:44] <arschmitz> jzaefferer: everything i know is fixed and working
[09:22:54] <arschmitz> jzaefferer: i added demos for removing corner classes
[09:23:13] <arschmitz> working on ones to use a different theme like bootstrap or foundation
[09:23:26] <jzaefferer> you added a demo for each widget?
[09:23:41] <arschmitz> jzaefferer: yes didnt know where else you would do it
[09:23:58] <arschmitz> seemed to make the most sense
[09:24:21] <arschmitz> some require extra too like selectmenu
[09:24:32] <jzaefferer> I was thinking of adding a second widget demo. Apparently I didn't mention that in my comment though
[09:25:10] <jzaefferer> I don't think having a demo for each widget is a good idea
[09:25:25] <jzaefferer> if you want to remove corners on a single page, you can also use CSS
[09:25:46] <jzaefferer> it gets interesting when you want to remove corners in just some specific widget or even in just part of a widget
[09:26:12] <arschmitz> jzaefferer: why dont we add it to the defult on each then
[09:26:16] <scott_gonzalez> Which only makes sense if you use an actual existing widget for the demo.
[09:26:19] <arschmitz> so that it shows one with and without
[09:26:26] <scott_gonzalez> I'm not sure adding a demo for this is the right thing to do.
[09:26:39] <arschmitz> scott_gonzalez: right thats kinda my point in doing it on each
[09:26:42] <scott_gonzalez> You really need this in the API docs or in a learn article.
[09:27:15] <tj_vantoll> Well it'll be an option in each widget's API docs right?
[09:27:24] <arschmitz> tj_vantoll: yes
[09:27:28] <tj_vantoll> learn article++ too
[09:27:36] <arschmitz> learn makes the most sense to me
[09:27:45] <jzaefferer> what happend to http://wiki.jqueryui.com/w/404/Classes%20Option ?
[09:27:48] <tj_vantoll> The API docs can link to a learn article that goes into detail.
[09:28:11] <jzaefferer> what about the demo showing custom theming in general?
[09:28:18] <arschmitz> same thing with something like adding a new theme
[09:28:18] <scott_gonzalez> jzaefferer: It got deleted with tons of other pages.
[09:28:33] <scott_gonzalez> Do you not remember when we did that?
[09:28:47] <arschmitz> jzaefferer: that seems like a demo that would accompany a learn article
[09:28:58] <arschmitz> thats somethign you would want to do for the whole page and every widget
[09:29:06] <jzaefferer> I do, I just didn't expect we'd delete a page that is linked to in the roadmap
[09:29:07] <arschmitz> and is kinda complicated and different
[09:30:04] <arschmitz> you would likely not want to just set the option
[09:30:15] <arschmitz> but overide the prototypes on all the widgets your using
[09:31:28] <jzaefferer> how about a demo or learn article or whatever that shows custom theming for datepicker? Not necessarily using the classes option, just show that you can replace our entire CSS
[09:32:08] <jzaefferer> The thing I want to address is that barely anyone seems to write custom themes (at least not publishing them), we can encourage that by actually demonstrating it
[09:32:09] <scott_gonzalez> That would be http://learn.jquery.com/jquery-ui/theming/write-a-theme/
[09:32:10] <arschmitz> thats very different
[09:32:27] <arschmitz> thats writing a new theme not using an existing one inplace of the ui one
[09:32:43] <arschmitz> like bootstrap or mobile or foundation
[09:33:42] <jzaefferer> do we link to that page anywhere from jqueryui.com?
[09:34:31] <scott_gonzalez> We link to it from api.jqueryui.com.
[09:34:35] <jzaefferer> we should have plenty of links and, on the page itself, an actual demo
[09:34:44] <jzaefferer> not just some abstract non-functional example
[09:34:49] <scott_gonzalez> jqueryui.com doesn't have anything about theming, because it's basically a demo and download site.
[09:34:59] <tj_vantoll> I think having a really good looking theme that exists would encourage new themes as much as an article.
[09:35:16] <tj_vantoll> jzaefferer: Exactly. It needs to be example driven and not abstract.
[09:35:24] <jzaefferer> so we added that widget demo to tell people that $.widget is a thing
[09:35:29] <scott_gonzalez> We should not concentrate our effort on that now. If we're going to spend time on that, it should be put into the new CSS framework.
[09:35:42] <arschmitz> also we are talking about classes option
[09:35:51] <arschmitz> which this has nothing to do with really
[09:36:05] <tj_vantoll> I think we should have a learn article on classes.
[09:36:13] <arschmitz> tj_vantoll: i agree
[09:36:14] <tj_vantoll> Theming could be one section of that article.
[09:36:24] <arschmitz> tj_vantoll: i agree
[09:36:42] <tj_vantoll> I can write that article once classes lands.
[09:36:48] <jzaefferer> sounds good to me.
[09:36:50] <arschmitz> tj_vantoll: awesome thank you
[09:37:04] <jzaefferer> can probably just that article now, maybe you'll notice some issues with the implementation while writing it
[09:37:09] <jzaefferer> *start now
[09:37:14] <jzaefferer> (or something)
[09:37:20] <tj_vantoll> Yeah that makes sense.
[09:37:23] <arschmitz> another classes thing
[09:37:24] <jzaefferer> anyway, arschmitz, can you revert the demo commits then?
[09:37:27] <arschmitz> destroy
[09:37:30] <jzaefferer> seems like we don't want those
[09:37:30] <arschmitz> jzaefferer: yup
[09:37:50] <jzaefferer> I didn't really expect you to add them immediately anyway, that was supposed to just start a discussion...
[09:38:02] <arschmitz> jzaefferer: it wasnt much
[09:38:14] <arschmitz> i just copyed the default and added the classes options
[09:38:27] <arschmitz> if had taken more then an hour i wouldnt have done it
[09:38:34] <tj_vantoll> On a somewhat related note I created a branch to start the 1.12 upgrade guide: https://github.com/jquery/jqueryui.com/commit/2a7f4ec2440aaaa3166daa9f11b101e3ba7abcc2
[09:38:53] <tj_vantoll> Per jzaefferer's request
[09:38:57] <arschmitz> ok so the automatic destroy i implemented it and i dont think its worth it at all
[09:39:12] <arschmitz> doing it in the entire library saved 9 lines of code
[09:39:27] <arschmitz> and adds substantial overhead
[09:40:05] <arschmitz> because in many widgets it saved nothing because we are calling removeClass to remove a class that does not go through the classes option
[09:40:12] <arschmitz> like icon classes or something
[09:41:15] <jzaefferer> well, let's not bother then
[09:41:19] <rxaviers> jzaefferer, https://github.com/jquery/download.jqueryui.com/pull/242 thanks for reviewing it. Should I land it now or closer to 1.12?
[09:41:43] <arschmitz> jzaefferer: that would be my recomendation
[09:42:55] <jzaefferer> rxaviers: actually, why would you change that in 1.10 or 1.11? This will only affect 1.12, not any existing versions
[09:43:43] <rxaviers> what do you mean why we I change that in 1.10 or 1.11? The change affects UI themeroller, which has no version control/switch
[09:43:44] <jzaefferer> arschmitz: alright, so you'll revert the demo commits and that's all for classes, right?
[09:43:50] <jzaefferer> anything on button?
[09:44:27] <rxaviers> + it affects the index.html that goes in the ZIP, which indeed would have to be versioned.
[09:44:30] <arschmitz> on button i do have a question
[09:45:03] <arschmitz> actuallly checkboxradio
[09:45:19] <arschmitz> should we have an icon postion option
[09:45:28] <scott_gonzalez> rxaviers: His point is that index.html in the zip for 1.10 and 1.11 needs to not change.
[09:45:39] <scott_gonzalez> Because those theme files have the incorrect spelling.
[09:46:05] <scott_gonzalez> arschmitz: Has anyone ever requested that?
[09:46:14] <arschmitz> scott_gonzalez: its an option on mobile
[09:46:22] <scott_gonzalez> oh
[09:46:34] <jzaefferer> arschmitz: are you suggesting removing iconPosition?
[09:46:59] <arschmitz> jzaefferer: in ui right now it does not have that option
[09:47:03] <arschmitz> jzaefferer: on checkboxradio
[09:47:06] <arschmitz> only on button
[09:47:27] <arschmitz> in mobile we have always had a position option on checkboxradio
[09:48:14] <rxaviers> Yeap, the ZIP files need to be properly versioned for 1.12. But, nothing can be done on that regard for TR.
[09:48:26] <rxaviers> thanks for checking that
[09:48:42] <arschmitz> jzaefferer: i have no strong opinion on it
[09:49:02] <arschmitz> just realized the difference when implementing the new ui one in mobile
[09:49:54] <tj_vantoll> I have to take off. I'm going to work on that article on classes next, probably early next week.
[09:50:15] <arschmitz> tj_vantoll: an opinion on icon position for checkboxradio before you go?
[09:50:26] <arschmitz> any*
[09:50:28] <jzaefferer> arschmitz: seems like we should have RTL support, but no option
[09:51:32] <arschmitz> jzaefferer: well you can do it very easily
[09:51:38] <arschmitz> jzaefferer: it uses the same options as button
[09:51:41] <arschmitz> i mean classes
[09:51:50] <arschmitz> so you can change one class to move the icon
[09:51:58] <arschmitz> same one as button
[09:52:06] <arschmitz> its just not an option in the widget
[09:52:21] <jzaefferer> do we even need iconPosition in button then?
[09:52:28] <jzaefferer> if you can achieve the same with classes?
[09:52:38] <jzaefferer> or even the icon option?
[09:52:53] <arschmitz> jzaefferer: well then why the button widget at all ?
[09:52:55] <jzaefferer> I guess icon option is required since we create an extra element?
[09:53:23] <arschmitz> jzaefferer: pretty much the only point of the button widget is icons  and managing them through options
[09:53:39] <arschmitz> other wise you have to use regexes
[09:53:49] <arschmitz> to know what class to remove before you add a new one
[09:53:58] <arschmitz> its not just a simple add remove class
[09:54:00] <jzaefferer> well, we don't want that
[09:54:18] <arschmitz> right thats why we havethe button widget
[09:54:19] <jzaefferer> so anything that isn't sane to do with classes should have an option then
[09:54:38] <jzaefferer> I'm not sure how that's different in checkboxradio though
[09:54:46] <arschmitz> jzaefferer: its not
[09:54:59] <arschmitz> the only question is should we support moving the icon at all
[09:55:05] <arschmitz> if yes it should be an option
[09:55:27] <scott_gonzalez> The question is do you ever seen styled checkboxes or radios where the icon is on the opposite side?
[09:55:27] <jzaefferer> is it trivial to introduce that option later?
[09:55:30] <arschmitz> position is also a little different then button
[09:55:38] <arschmitz> then icon i mean
[09:55:46] <arschmitz> because there are only 4 options
[09:55:52] <arschmitz> jzaefferer: yes extreamly trivial
[09:56:10] <arschmitz> its like 4 lines to add it
[09:58:31] <jzaefferer> Let's exclude it and if we find a compelling reason later, we can still add it?
[10:00:03] <arschmitz> works for me
[10:00:18] <arschmitz> i just wanted to decide before i finished backcompat for mobile
[10:01:29] <jzaefferer> okay
[10:01:38] <jzaefferer> no changes in the checkboxradio spec, right?
[10:03:10] <arschmitz> right