[08:30:25] <jzaefferer> there
[08:30:33] <leobalter> o/
[08:30:36] <JamesMGreene> \o
[08:30:38] <jzaefferer> JamesMGreene leobalter Krinkle|detached gibson042
[08:30:57] <leobalter> I'm finally online
[08:31:02] <JamesMGreene> scott_gonzalez ?
[08:31:05] <jzaefferer> so as far as I can tell, we can release 1.16
[08:31:10] <gibson042> here, but not at all caught up on qunit developments
[08:31:31] <JamesMGreene> Thanks for picking up my slack, jzaefferer and leobalter
[08:31:36] <jzaefferer> I did the necessary preparations: bumping version number, updating history.md, updating authors.md
[08:31:42] <jzaefferer> And did a test release once
[08:31:59] <jzaefferer> JamesMGreene: do you have anything last minute to include in 1.16?
[08:32:35] <JamesMGreene> I don't think so
[08:33:25] <leobalter> post 1.16, I believe we should work to land https://github.com/jquery/qunit/pull/670, right?
[08:34:08] <leobalter> at least in the pre-2.0
[08:34:20] <leobalter> or: the 2.0 batch
[08:34:47] <jzaefferer> this wouldn't replace anything, right? So it shouldn't really matter where we land it
[08:34:51] <JamesMGreene> Yeah, definitely post 1.16 though
[08:34:57] <jzaefferer> 1.x would be better, easier to adopt
[08:35:06] <JamesMGreene> Well, the way I implemented it now wouldn't replace anything
[08:35:27] <jzaefferer> Generally speaking, James, any estimate what your availability is going to be?
[08:35:28] <JamesMGreene> we could theoretically merge "suite" and "module" into a single construct if we wanted, though
[08:35:42] <jzaefferer> Between this and jsreporters we should could use your mindshare
[08:35:53] <jzaefferer> *sure could use
[08:36:15] <JamesMGreene> Sorry, been busy with work and suffering at home a family death, and then 4 illnesses in a row (and my wife and daughter have both also been sick :()
[08:36:36] <JamesMGreene> Hoping to get back into it now for at least a few hours per week to keep up with responding to issues and discussions
[08:36:48] <JamesMGreene> *to at least keep up with
[08:36:56] <JamesMGreene> (well, whatever)
[08:37:25] <JamesMGreene> plus it's winter now >_<
[08:37:31] <jzaefferer> Sounds like you had a pretty bad time
[08:37:32] <JamesMGreene> longer commute, shoveling, etc.
[08:37:39] <JamesMGreene> Yeah, November was an awful month
[08:37:40] <JamesMGreene> lol
[08:37:43] <leobalter> JamesMGreene my condolences
[08:37:49] <JamesMGreene> Thanks, leobalter
[08:38:08] <JamesMGreene> It was my grandma, so I know you can empathize well
[08:38:17] <leobalter> :(
[08:38:41] <leobalter> Mine is still at the intensive unit, but that's only suffering for her
[08:39:50] <leobalter> well, getting back to the meeting, we should set a path for what's next
[08:40:10] <jzaefferer> Well, it'll be good to have James chime in here and there :-)
[08:40:20] <jzaefferer> I hope we can revive the jsreporter project, so far no one seemed to have looked at my PR
[08:40:39] <jzaefferer> I'd like to land that, then work out the event data
[08:41:01] <jzaefferer> then we could update the event emitter PR based on that
[08:41:23] <jzaefferer> try to get at least one other project to do the same
[08:41:34] <JamesMGreene> yep
[08:41:51] <JamesMGreene> Are we all set on documentation needs for 1.16?  https://github.com/jquery/qunitjs.com/milestones/1.16 https://github.com/jquery/api.qunitjs.com/milestones/1.16
[08:42:03] <jzaefferer> I think the nested suite PR had some discussion that could use James' input
[08:42:23] <jzaefferer> docs should be fine, I'll merge those after the new version is up on site and CDN
[08:42:32] <jzaefferer> I can fix anything that we may have missed
[08:42:50] <jzaefferer> one thing I'd like to get in 1.x is better diffs
[08:42:59] <jzaefferer> there are several open issues, some overlapping
[08:43:03] <JamesMGreene> Yeah, I noticed lots of issues labeled as `diff`
[08:43:28] <jzaefferer> maybe something for leobalter to dig into?
[08:44:31] <leobalter> diffs are hard to work at, I can try
[08:45:02] <jzaefferer> Maybe we'll do a Skype call or so to go through the diff-labeled issues together and discuss where to start?
[08:46:30] <gibson042> for the record, are there any backwards compatibility concerns with diff output?
[08:46:41] <gibson042> or is it "anything goes, as long as the result is useful"?
[08:46:47] <gibson042> (to humans)
[08:47:21] <jzaefferer> It should only affect the html reporter output, so yeah, anything goes
[08:49:51] <jzaefferer> leobalter: do you have time in the next days to sit down and review diff issues?
[08:50:12] <leobalter> there'll be backwards compatibility issues only with css skins, maybe
[08:50:24] <JamesMGreene> Is the diff for grunt-contrib-qunit different then?  That diff needs some improvement too
[08:50:48] <jzaefferer> That has a diff?
[08:50:54] <JamesMGreene> Yeah
[08:51:02] <JamesMGreene> if the tests fail :-P
[08:51:14] <jzaefferer> I don't know
[08:51:31] <jzaefferer> Since QUnit.diff is outputting html, it probably has its own thing
[08:51:43] <JamesMGreene> Probably
[08:51:56] <JamesMGreene> When displaying objects, it tends to display some properties twice in a row, e.g.   {
[08:51:58] <JamesMGreene> name: "blah"
[08:52:01] <JamesMGreene> name: "blah"
[08:52:05] <JamesMGreene> otherProp: "foo"
[08:52:05] <JamesMGreene> }
[08:52:19] <JamesMGreene> plus commas ;)
[08:52:35] <jzaefferer> https://github.com/gruntjs/grunt-contrib-qunit/search?utf8=%E2%9C%93&q=diff
[08:52:41] <jzaefferer> the only "diff" reference in that repo
[08:53:37] <JamesMGreene> Perhaps it's not a diff, then
[08:53:42] <JamesMGreene> just a display of actual vs expected
[08:54:00] <JamesMGreene> i.e. https://github.com/gruntjs/grunt-contrib-qunit/blob/master/tasks/qunit.js#L50-L53
[08:54:08] <jzaefferer> no diffing here either: https://github.com/gruntjs/grunt-contrib-qunit/blob/master/tasks/qunit.js#L44-L59
[08:54:42] <jzaefferer> well, a proper console reporter could also do diffs...
[08:55:17] <JamesMGreene> absolutely
[08:56:20] <JamesMGreene> Their `formatMessage` function looks pretty naive
[08:57:39] <JamesMGreene> Or else the `actual` and `expected` were converted to a string elsewhere ahead of time
[08:58:52] <JamesMGreene> Hmm
[08:59:00] <JamesMGreene> It is using jsDump.parse
[08:59:01] <JamesMGreene> https://github.com/gruntjs/grunt-contrib-qunit/blob/master/phantomjs/bridge.js#L32-L35
[09:00:08] <jzaefferer> that's independent of diffing though
[09:00:15] <JamesMGreene> sure
[09:00:22] <jzaefferer> Well, I'll talk to Leo later and finish the 1.16 release
[09:00:25] <JamesMGreene> but apparently broken :-P
[09:01:34] <JamesMGreene> sounds good, jzaefferer
[09:01:54] <jzaefferer> JamesMGreene: looking for your input on jsreporter
[09:02:18] <JamesMGreene> OK, I'll prioritize it
[09:02:46] <scott_gonzalez> arschmitz fnagel gnarf jperrault kborchers mikesherov rxaviers tj_vantoll1
[09:02:51] <rxaviers> Hello
[09:02:53] <scott_gonzalez> Let's kick these jerks out :-P
[09:03:03] <kborchers> hey
[09:03:28] <fnagel> hey
[09:04:16] <arschmitz> hi
[09:05:10] <scott_gonzalez> rxaviers: Any update on AMD loading for tests and demos?
[09:06:02] <rxaviers> Nope
[09:07:30] <JamesMGreene> scott_gonzalez  (╯°□°）╯︵ ┻━┻  ;)
[09:08:45] <tj_vantoll1> here now
[09:08:53] <scott_gonzalez> Did anyone get a chance to look at the new classes PR?
[09:09:16] <tj_vantoll1> The one with _addClass() and _removeClass()?
[09:09:21] <scott_gonzalez> Yeah.
[09:09:23] <scott_gonzalez> https://github.com/jquery/jquery-ui/pull/1392
[09:09:52] <rxaviers> scott_gonzalez, I have looked into http://bugs.jqueryui.com/ticket/10674 though
[09:10:02] <tj_vantoll1> I did, but it seems that arschmitz has added some commits recently.
[09:10:05] <rxaviers> I've added two comments there
[09:10:26] <arschmitz> yes i finished it in the rest of the widgets
[09:10:49] <tj_vantoll1> I'm a fan. It makes it so much easier to explain how to use the option in your own widgets.
[09:10:59] <scott_gonzalez> rxaviers: The first comment doesn't seem related. We're not talking about monolith builds.
[09:11:11] <scott_gonzalez> The second comment is a bit misguided.
[09:11:22] <scott_gonzalez> #2 and #3 are the same thing. There is no dist folder in the tags.
[09:11:25] <rxaviers> my first comment is related to "Use comments like Mobile?"
[09:11:29] <rxaviers> there's no mobile approach
[09:11:55] <arschmitz> I also added this PR https://github.com/jquery/jquery-ui/pull/1394
[09:12:01] <scott_gonzalez> That was just about how the wrappers are removed.
[09:12:08] <scott_gonzalez> Not about what the output of the build is.
[09:12:32] <scott_gonzalez> There is a mobile approach, they're removing the wrappers during the build.
[09:12:34] <scott_gonzalez> We're not.
[09:12:39] <rxaviers> we remove the wrappers on our build.
[09:12:47] <rxaviers> we're talking about two different things
[09:12:50] <scott_gonzalez> We're not talkinga bout download builder.
[09:13:03] <tj_vantoll1> I started an article (https://github.com/jquery/learn.jquery.com/pull/574) and had to stop at adding to your own widgets because I'm waiting for a decision on _addClass() and _removeClass().
[09:13:08] <scott_gonzalez> We're talking about the minify task which the bower module uses.
[09:13:50] <rxaviers> Why do they run the minify task?
[09:14:01] <rxaviers> Do we want people to get stuff using minify?
[09:14:15] <scott_gonzalez> You'd have to ask whoever manages the bower repo.
[09:14:15] <rxaviers> The question is around what do we want people to use as distriutables
[09:15:15] <rxaviers> The problem is not about the minifieds. Because, there's no official minified files. Right?
[09:15:27] <rxaviers> All we distribute are bundles just like Mobile.
[09:15:33] <scott_gonzalez> Stop thinking about distribution.
[09:15:34] <rxaviers> People are welcome to fetch the sources as well.
[09:15:46] <scott_gonzalez> We have a task that we maintain which generates files which don't work with AMD.
[09:15:56] <rxaviers> If bower module has broken minifieds, they should not include minifieds.
[09:16:33] <rxaviers> That's my point, I'd like to know what we think about those minified files.
[09:16:47] <scott_gonzalez> Ok, I really need to not get into this. I'm sticking to my stance of not discussing things related to AMD anymore.
[09:16:52] <scott_gonzalez> Someone else can chime in.
[09:17:12] <arschmitz> ok just want to make sure i understand correctly
[09:17:32] <arschmitz> this is about the jquery.ui.min.js file generate by grunt tasks correct?
[09:17:35] <rxaviers> I'd like to solve that issue. But, I can't unless I understand what the goal of that stuff is.
[09:17:58] <rxaviers> arschmitz, yes
[09:18:09] <rxaviers> not jquery.ui.min.js, but the components.
[09:18:13] <scott_gonzalez> no
[09:18:24] <scott_gonzalez> It's about the individual minified files.
[09:18:27] <arschmitz> ok
[09:18:29] <scott_gonzalez> generated by `grunt uglify`
[09:18:47] <arschmitz> and those currently do not work with amd
[09:18:55] <rxaviers> there's no problem with jquery-ui.min.js we have in our download packages (as far as I know)
[09:19:03] <tj_vantoll1> Right
[09:19:28] <arschmitz> hmm
[09:19:34] <tj_vantoll1> This is generated by our uglify task: https://github.com/components/jqueryui/blob/master/ui/minified/accordion.min.js#L4
[09:19:55] <rxaviers> but, the main question is: what's the purpose of those minified files?
[09:20:10] <arschmitz> ok i see thats bad
[09:20:18] <arschmitz> the amd should either work or not be there
[09:20:42] <tj_vantoll1> We decided that they should not be there in the minified files.
[09:20:53] <arschmitz> ok
[09:20:54] <rxaviers> We only use the minify task, correct me if Im wrong, to feed compare-size task in.
[09:21:12] <tj_vantoll1> Correct to my knowledge
[09:21:26] <rxaviers> So, no one should use that in any module distributing jQuery UI
[09:21:41] <arschmitz> then it seems like we just need to parse out the amd wrapper as part of this task
[09:22:00] <scott_gonzalez> That's all *we* use it for. There's a separate question of how much support we want to provide to whoever is maintaining the bower module.
[09:22:12] <scott_gonzalez> My opinion from day 1 has been no support.
[09:22:40] <rxaviers> We should let them know they should fetch jQuery UI from our stable download link?
[09:23:15] <arschmitz> to me it seems like if we have a task that generates filesthey should be usable files
[09:23:25] <arschmitz> regardless of if they only feed into compare size
[09:23:37] <tj_vantoll1> That is my thought as well.
[09:23:56] <scott_gonzalez> rxaviers: That doesn't help. You don't get individual files then.
[09:24:16] <arschmitz> regardless of support for bower or other ways to get files
[09:24:23] <rxaviers> Developers only want a way to consume jQuery UI
[09:24:29] <arschmitz> we should not generate non usable files
[09:24:39] <rxaviers> It happens that this is actually broken
[09:24:52] <scott_gonzalez> FWIW, my suggestion was to just rename the files.
[09:25:09] <tj_vantoll1> I'm cool with that.
[09:25:14] <arschmitz> i really dont care too much with how we fix it
[09:25:28] <arschmitz> but they should work
[09:25:57] <scott_gonzalez> I'm not sure why you'd use AMD + minified files instead of using AMD + source + r.js build.
[09:26:19] <rxaviers> arschmitz, the minified files are not meant to be used. Are they?
[09:26:25] <scott_gonzalez> But maybe that's because I never use AMD.
[09:26:43] <tj_vantoll1> scott_gonzalez: No you're right. It's a stupid thing to do.
[09:27:00] <arschmitz> my only opinion on all of this is if we have a task that generates files they SHOULD BE usable in what ever for the are spit out
[09:27:04] <tj_vantoll1> The point is more that we are generating something broken.
[09:27:06] <scott_gonzalez> Which is why removing the wrapper seems like the better option.
[09:27:14] <tj_vantoll1> And they are being used.
[09:27:14] <scott_gonzalez> Renaming is the simple solution.
[09:28:08] <tj_vantoll1> I'm fine with the simple solution because this isn't important.
[09:29:03] <rxaviers> tj_vantoll1, arschmitz, are you chiming in then?
[09:29:07] <scott_gonzalez> It's been five weeks and the OP never responded to jzaefferer's question of "what's the motivation for loading minified files using AMD?"
[09:29:18] <rxaviers> I can help any of you if you have questions with the AMD part
[09:30:33] <rxaviers> scott_gonzalez, feel free to move on then
[09:31:11] <scott_gonzalez> ok, back to classes...
[09:31:38] <arschmitz> so i finished implementing _addClass and _removeClass
[09:31:53] <arschmitz> i also added a pr with a slightly different API for those
[09:32:43] <arschmitz> rather then this._addClass( elements, classes, extra );
[09:32:57] <arschmitz> just this._addClass( elements, classes );
[09:33:08] <arschmitz> and classes can be any class in classes option or not
[09:33:44] <arschmitz> then it also auto removes all classes that go through _addClass on destroy which saves a few lines in most widgets
[09:33:58] <arschmitz> https://github.com/jquery/jquery-ui/pull/1394
[09:35:20] <arschmitz> things like tabs you save a bunch of lines
[09:35:41] <tj_vantoll1> Interesting. So it'll only remove classes that were actually added.
[09:35:43] <arschmitz> makes it more like _on and _off too
[09:35:47] <arschmitz> yup
[09:36:08] <arschmitz> in that you never need to call _off in destroy its all automatic
[09:37:01] <gabriel_schulhof> arschmitz: So what you were talking about earlier was an optimization whereby you forego calling _removeClass() on those tracked elements which have become detached?
[09:37:03] <tj_vantoll1> Yeah I see a bunch of red in _destroy()s
[09:37:16] <arschmitz> gabriel_schulhof: yes
[09:37:23] <arschmitz> tj_vantoll1: yup
[09:38:22] <gabriel_schulhof> arschmitz: The problem then is that any given widget implementation can pass an element to _addClass() that remains in the DOM after the widget is destroyed. For example, filterable.
[09:38:27] <gabriel_schulhof> .. in mobile.
[09:39:02] <arschmitz> gabriel_schulhof: ok? im not sure i see the issue?
[09:39:28] <arschmitz> the worst thing that can ever happen is removeClass is called on a detached node?
[09:39:37] <arschmitz> instead of being skipped
[09:40:48] <gabriel_schulhof> arschmitz: Well, for safety's sake you should call _removeClass() on all nodes. The determination as to whether you can skip any one node is too complicated to make, I think. Better to (uselessly) call _removeClass() on a detached node, than to accidentally skip over a node that remains attached after destruction.
[09:41:22] <gabriel_schulhof> arschmitz: ... I mean, if you don't want to use $.contains.
[09:41:39] <arschmitz> gabriel_schulhof: it can only skip if its detched?
[09:41:40] <scott_gonzalez> We definitely should not be trying to check if elements still exist.
[09:41:46] <scott_gonzalez> If they're in the object, we touch them.
[09:42:06] <scott_gonzalez> If they're detached, the widget should have already cleared them out.
[09:42:08] <gabriel_schulhof> arschmitz: Yes, otherwise you have to leave the DOM the way you found it.
[09:42:48] <arschmitz> ok wait all this does for optimization is if the element to have a class removed has no parents it does not remove the class because its not in the dom any longer
[09:43:18] <arschmitz> and this is after _destroy has completed
[09:43:21] <scott_gonzalez> Do you know what kind of perf optimization that actually is?
[09:43:26] <arschmitz> es
[09:43:28] <arschmitz> yes
[09:43:41] <arschmitz> let me check i have a jsperf of it
[09:43:46] <gabriel_schulhof> So which is more expensive? Determining whether it's detached, or calling _removeClass()?
[09:44:06] <arschmitz> calling remove class by far
[09:44:17] <gabriel_schulhof> arschmitz: Is that true for detached nodes?
[09:44:29] <arschmitz> gabriel_schulhof: yes
[09:44:30] <scott_gonzalez> I don't care which is faster.
[09:44:35] <scott_gonzalez> I care about the actual performance metrics.
[09:44:45] <arschmitz> scott_gonzalez: im getting that just a sec
[09:45:08] <tj_vantoll1> To take a step back, regardless of this potential optimization, do we have a consensus to move forward with _addClass() and _removeClass() in general? If so I'll add it to my article and hit the code a little more.
[09:45:30] <arschmitz> http://jsperf.com/contains-depth
[09:46:04] <arschmitz> oops that does not have removeClass on the detached node
[09:47:51] <jzaefferer> tj_vantoll1: I have no objections
[09:47:52] <gabriel_schulhof> I don't believe we can claim that !target.parentNode || !target.parentNode.parentNode will always return the same result as $.contains() for all tracked elements.
[09:47:53] <arschmitz> http://jsperf.com/contains-depth/2
[09:48:05] <arschmitz> gabriel_schulhof: it does not need to
[09:48:20] <arschmitz> again the worst that happens is we call removeClass on a detached node
[09:49:18] <gabriel_schulhof> arschmitz: So is the extra expense of the $.contains() check not worth the potential expense of unnecessary calls to removeClass()?
[09:49:37] <arschmitz> gabriel_schulhof: since in UI it will always be the same no
[09:49:48] <scott_gonzalez> So, first of all, we're talking about .00035ms per element.
[09:49:54] <scott_gonzalez> for .removeClass()
[09:50:31] <gabriel_schulhof> arschmitz: Was that on a desktop?
[09:50:41] <arschmitz> yes
[09:50:44] <scott_gonzalez> .001ms for the slowest browser on there.
[09:50:59] <scott_gonzalez> So you could handle 1000 detached elements in 1ms.
[09:51:22] <scott_gonzalez> I can't even imagine getting into that situation.
[09:51:34] <gabriel_schulhof> For sure! List of emails.
[09:51:48] <arschmitz> scott_gonzalez: well in mobile whole pages get .removed();
[09:52:05] <scott_gonzalez> There's a much much much better optimization for that.
[09:52:15] <scott_gonzalez> Which is finally implementing _remove()
[09:52:26] <scott_gonzalez> You don't need to do any cleanup at all for .remove()
[09:52:30] <arschmitz> actually thats very true
[09:52:32] <gabriel_schulhof> That's true.
[09:52:49] <gabriel_schulhof> _destroy() cannot distinguish between remove and restore-to-initial-state.
[09:52:59] <arschmitz> ok then ditch the check and add _remove ?
[09:53:29] <gabriel_schulhof> +1 for what my vote is worh.
[09:53:45] <arschmitz> i guess the bigger question is do we want to go with this new api or the original one to begin with?
[09:54:47] <arschmitz> i like that its more similar to how _on works and auto destory of classes is nice
[09:55:11] <gabriel_schulhof> It saves a bunch of explicit ._removeClass() calls.
[09:55:33] <arschmitz> also saves all regular .removeClass() calls in destroy too
[09:55:58] <scott_gonzalez> I don't think we're ready to make a final decision yet.
[09:56:26] <scott_gonzalez> I don't think too many people have looked at the implementation yet.
[09:56:44] <gabriel_schulhof> arschmitz: Wait a sec ... if classes contains both keys and random classes, you have to parse the value to determine whether to track the element or not.
[09:56:55] <arschmitz> no
[09:57:13] <gabriel_schulhof> No?
[09:57:14] <arschmitz> because you want to track them regardless to make destroy work
[09:57:33] <arschmitz> this handles removal of all classes not just those that go through classes
[09:57:38] <tj_vantoll1> I want _addClass() and _removeClass() but I don't know enough to take a stance on any of the implementation details.
[09:57:47] <gabriel_schulhof> Well ... hmmm ... this scope is starting to creep.
[09:58:02] <gabriel_schulhof> Our original reason for tracking at all was to handle changes to the value of the option, right?
[09:58:21] <gabriel_schulhof> That is, to make _setOption() work for classes.
[09:58:33] <scott_gonzalez> To make it work automatically.
[09:58:38] <scott_gonzalez> Not to make it work.
[09:58:39] <gabriel_schulhof> Yeah, exactly.
[09:58:47] <scott_gonzalez> This is just extending what happens automatically.
[09:58:51] <gabriel_schulhof> scott_gonzalez: Well, to make it work without elementsFromClassKey()
[09:59:07] <scott_gonzalez> That's not automatic.
[09:59:12] <gabriel_schulhof> No, right.
[09:59:23] <gabriel_schulhof> But now you're talking about tracking for other reasons, too.
[09:59:36] <scott_gonzalez> To automate work.
[10:00:04] <scott_gonzalez> And thereby reduce the code needed per widget and the chances of a mistake in a widget.
[10:00:17] <gabriel_schulhof> GOod reasons.
[10:00:21] <scott_gonzalez> arschmitz' extension to that follows the exact same goals.
[10:00:54] <scott_gonzalez> But I'm not a fan of the fact that it makes non-classes option classes work with the classes optin.
[10:01:06] <scott_gonzalez> It makes it much easier for users to fall into using non-public API.
[10:01:22] <scott_gonzalez> That's an implementation detail that can be avoided though.
[10:01:23] <arschmitz> scott_gonzalez: i could add a circut breaker to stop that
[10:01:45] <gabriel_schulhof> Wait a sec ... _addClass() and _removeClass() will be available to implementors of widgets, right?
[10:01:45] <arschmitz> the simple solution was to not differentiate and just never tell any one thats possible
[10:02:22] <scott_gonzalez> gabriel_schulhof: Yes, it's public API for widget developers.
[10:02:34] <gabriel_schulhof> OK, so what non-public API were you referring to?
[10:02:43] <scott_gonzalez> arschmitz: It's public API, we have to indirectly tell people.
[10:02:57] <arschmitz> hat you could add your own keys to the classes option and this would make them work
[10:03:04] <scott_gonzalez> this._addClass( elem, key, extra ) vs this._addClass( elem, key + " " extra )
[10:03:07] <gabriel_schulhof> Oh. The usage.
[10:03:09] <arschmitz> so you could "ui-icon": "foo"
[10:03:18] <scott_gonzalez> The latter makes all extra classes go through the classes option.
[10:03:36] <gabriel_schulhof> :)
[10:03:52] <gabriel_schulhof> We could implement the original idea, but if the third parameter is empty, random classes will also be tracked.
[10:03:55] <arschmitz> but we would not want people to actually do such things
[10:04:12] <gabriel_schulhof> It's like, ._addClass( element, classesToTrack, classesNotToTrack )
[10:04:24] <gabriel_schulhof> Right.
[10:04:26] <arschmitz> gabriel_schulhof: that would make destroy not work any more
[10:04:38] <arschmitz> because if you dont track them they wont be removed
[10:04:47] <scott_gonzalez> It's not about whether we track, it's about whether it goes through the option.
[10:04:51] <arschmitz> they need to be tracked in some form no matter what
[10:04:56] <gabriel_schulhof> arschmitz: Well, but it takes a conscious effort to put things into the third parameter.
[10:05:06] <arschmitz> thats not the issue though
[10:05:11] <gabriel_schulhof> I understand.
[10:05:29] <arschmitz> the issue is giving people the abilit to essentially create their own classes options on the fly
[10:05:36] <gabriel_schulhof> I'm just saying, that we could implement it and an astute observer will see from our code that ._addClass() can, in fact, handle random classes.
[10:05:53] <gabriel_schulhof> But we document no such thing.
[10:05:55] <scott_gonzalez> gabriel_schulhof: That doesn't matter. Obviously it handles random classes.
[10:06:11] <scott_gonzalez> The only thing that matters is what WE pass.
[10:06:50] <scott_gonzalez> Anyway, this has gone on too long.
[10:06:56] <scott_gonzalez> We're past our one hour mark.
[10:07:08] <arschmitz> yeah if anyone has an opinion put it in the pr
[10:07:19] <arschmitz> im going to remove the garbge collect though
[10:07:22] <scott_gonzalez> I'll just wrap up by saying that mikesherov has updated the effects rewrite PR based on my review.
[10:07:32] <scott_gonzalez> I believe we're just waiting for jzaefferer to get a chance to review.
[10:07:36] <tj_vantoll1> Yeah I've got to go. I'm going to play with arschmitz's original PR to finish my article. I'll comment if I see any issues.
[10:07:37] <arschmitz> since we agree on that
[10:07:59] <tj_vantoll1> I'll also be completely out next week on vacation.
[10:08:01] <arschmitz> tj_vantoll1: ok just be aware the actually function sig may change :)
[10:08:08] <tj_vantoll1> No worries
[10:08:14] <gabriel_schulhof> It's good to do it in stages, and we're not preventing ourselves from continuing to move in arschmitz's direction.
[10:08:17] <jzaefferer> yeah, reviewing effects is still on my list
[10:08:32] <jzaefferer> got QUnit 1.16 out today, that was blocking a few things
[10:08:50] <scott_gonzalez> woohoo
[10:08:59] <scott_gonzalez> Ok, thanks everyone.
[10:09:09] <scott_gonzalez> If you have anything else to discuss, just bring it to -dev.