[11:01:57] agcolom: gabriel_schulhof: cgack: sfrisk: arthurvr: Meeting time [11:02:04] allo [11:02:08] Hey! [11:02:08] hello! [11:02:08] Hi! [11:02:16] howdy [11:04:39] hi all [11:05:33] ah agenda is freaking out [11:05:39] keeps saying unavailable and reloading [11:06:19] can anyone else get to it? [11:06:25] arschmitz: I don't see it in my Google Drive [11:06:35] was about to ask for the link [11:06:38] I can access it [11:06:42] https://docs.google.com/spreadsheets/d/1xGEVtftLDEHAA37YYlA23J_EZwIRyMUaseBY790byPM/edit#gid=2059624658 [11:07:13] weird guess its just me [11:07:23] agcolom: can you get to it you normally update it anyway? [11:07:27] I'm good with it too. [11:07:51] I'm good. I'd be happy if Gabriel can update the more technical stuff though [11:08:11] Sure anyone who can feel free to update based on what w talk about [11:08:17] and once i can get it ill check everything [11:08:24] sounds goof [11:08:28] good ^ [11:08:36] * agcolom can't type! [11:08:56] I've added a few items. [11:09:27] Shall I copy the items into the channel? [11:09:32] One-by-one. [11:09:34] I mean. [11:09:43] why dont we go through what i know [11:09:57] and then anyone that has anything we can add do those after i dont have much [11:10:00] OK. I can keep an eye on the agenda. [11:10:07] gabriel_schulhof: thank you [11:10:11] Ok so 1.5 [11:10:15] classes [11:10:35] the last update was pulling deps from wrong branch [11:10:40] so it did not have new api [11:11:04] thats been fixed in both the ui-1-12 and test fix branches [11:11:43] that explains a lot ;) [11:15:18] so in other 1.5 stuff [11:15:39] we have had a steady flow of fixes for old bugs from gabriel_schulhof [11:15:55] which is nice to iron out some old wrinkles [11:16:22] Yeah, my JS-fu has certainly improved over time, so now I have a better handle on these things. [11:17:38] gabriel_schulhof: any thing to discuss on those? [11:18:24] Lemme check ... [11:18:43] animationComplete could use a remove method. [11:19:07] Right now we do some juggling to render a stale .animationComplete() handler $.noop. [11:19:17] This would not be necessary if we could just remove the handler. [11:19:33] We can do this with $.data( "mobile-events" ) like we do with the swipe event. [11:19:51] do you have a link to the juggleing? [11:19:56] Maybe something like .animationComplete( callback, type, fallbackTime, remove ) [11:20:06] Yeah, jussec ... [11:20:43] https://github.com/jquery/jquery-mobile/pull/7902/files#diff-d08fdc724bcb00aacb41795a7921fbafR194 [11:21:22] ... and in popup: https://github.com/jquery/jquery-mobile/blob/31cc90ddc8c051cb01db46e270478c12be9685bb/js/widgets/popup.js#L519 [11:21:48] The bottom line is that inside the .animationComplete() handler you need to check whether this handler is still relevant. [11:22:13] ... because a second animation can be started before the first one has a chance of completing. [11:22:38] ... and when the first one finally gets called, it may end up clobbering the final state you want to achieve. [11:23:04] gotcha [11:23:15] ok so yes we need a way to remove it [11:23:43] What do you think about the API? A forth boolean parameter which, if true, will remove the callback? [11:24:45] TBH, this is beginning to look more and more like a case for $.event.special.animationcomplete ... [11:25:08] gabriel_schulhof: i would not add another argument [11:25:12] it should be another function [11:25:25] removeAnimationComplete(); [11:25:30] like on and off [11:25:45] OK, so $.fn.removeAnimationComplete( callback )? [11:25:52] yeah [11:25:57] OK. [11:26:11] I'll file an issue. [11:26:19] sounds good [11:26:51] The other issue I have is: Should I add tests to make sure the library is built properly? [11:27:00] Like I did in that one PR. [11:27:03] no [11:27:15] this is in the process of being addressed in ui already [11:27:23] once its setteled there we will adopt [11:27:31] OK. [11:27:41] basicly we should be running the full test suite on an amd build [11:27:41] Then I'll remove that test. [11:27:44] and a regular build [11:27:52] Oh, OK. [11:28:08] and if the tests pass on both we are good [11:28:13] and if they dont there is an issue [11:28:16] When you say amd, do you mean just the modules that are needed for the test? [11:28:39] gabriel_schulhof: https://github.com/jquery/jquery-ui/pull/1335 [11:28:44] that should also take care about some issues we had with the Download Builder because different order of CSS [11:29:04] well, take care, make us aware I mean [11:29:34] jasperdegroot: under the hood when we switch builders it will also start using amd for the css [11:29:52] we will still use comments to define the amd for the css [11:30:12] but they will be parsed into amd defines in the builder [11:30:13] yes [11:30:48] so then it will always be the same [11:31:23] that's great [11:32:45] gabriel_schulhof: could you please check my note in C14? [11:33:04] OK. [11:33:47] agcolom: ✓ [11:34:00] thx :-) I love that tick! [11:34:09] :) [11:35:28] ok next [11:35:35] anything else? [11:36:14] Checking ... [11:36:27] RTL ... autoinit ... [11:36:37] data- attribute name space [11:36:53] I guess pointer events should be removed until they become relevant to us. [11:36:56] RTL a call is being organized [11:37:05] ... and Chassis too, right? [11:37:06] nothing new [11:37:12] yeah we already decided that [11:37:14] gabriel_schulhof: yes we discussed that last week [11:37:19] (re: PEP and Chassis) [11:37:22] OK. [11:37:24] I'll remove it. [11:37:29] them both, I mean. [11:37:37] ok [11:37:56] *wipe hands* [11:38:08] Ok something not for mobile yet [11:38:16] but that will be coming out way [11:38:22] is rendering performance testing [11:38:32] im working on this for chassis right now [11:38:54] http://104.236.81.132:5984/css-perf/_design/site/index.html#/page-select [11:38:57] Oooh! Nice! [11:39:19] that compares the rendering performance of the css for buttons [11:39:31] in ui mobile bootstrap and foundation [11:39:45] certainly nice [11:39:56] was only looking for any easy way to compare [11:40:23] jasperdegroot: https://github.com/axemclion/perfjankie/issues/19 [11:40:38] :) [11:41:05] the creator has expressed an intreset in working with us several time [11:41:11] great [11:41:13] so im hopeful he will address the issues i filed [11:41:51] this also does profiling of things like event handers [11:41:55] and other js stuff [11:42:04] so it will be very useful in general [11:42:27] We also need commit-to-commit performance comparisons [11:42:30] for example this would have caught the perf regression from fixed toolbars [11:42:35] gabriel_schulhof: it has that [11:42:39] arschmitz: is it very different from the way Topcoat was doing telemetry tests? [11:42:42] Oh, sweet! [11:42:51] Where does it store the data? [11:42:55] look at any test you will see a graph over time [11:42:59] it uses a couchdb [11:43:56] the pages in that link are 1000 buttons [11:44:06] with every possible combination of options [11:44:41] the test pages are all auto generated [11:44:42] Oh, the runs at the bottom, I guess that correlates to commit ids. [11:44:55] gabriel_schulhof: no it doesnt [11:45:00] but in a ci setup it coud [11:45:26] it wont be able to use travis though [11:45:34] we will need to use jankins probably [11:46:16] perfJankie Jenkins? ... *sigh* [11:46:25] lol [11:46:35] its because its VERRY VERY enviroment dependant [11:46:51] :) [11:46:53] if i run it on an external monitor vs built in even makes a difference [11:46:58] Oh, I figured as much ... the achilles' heel of perf testing is the platform dependence. [11:47:22] which means i dont think we can rely on like browserstack or saucelabs either [11:47:32] You have to keep it consistent with time. [11:47:47] because those have load variences [11:48:05] Yeah. You need a dedicated server doing nothing else. [11:48:13] which we can do with jenkins [11:48:35] so i just wanted to mention this here [11:48:44] we wont be doing anything until chassis irons things out [11:48:55] * agcolom gotta run... catch you later [11:48:59] Who's gonna provide the infra? [11:49:02] agcolom: K L8R [11:49:14] gabriel_schulhof: well chassis is a foundation project [11:49:17] so its all the same [11:49:33] I already have a server set up hosting the couchdb app [11:49:56] OK, so the machine will be owned by the Foundation. Cool! [11:50:24] gabriel_schulhof: yes we already have a jenkins server [11:50:41] and the couchdb app is on a new server because debian and couch dont play nice [11:51:12] but we dont need to worry about any of this [11:51:25] Naw, just curious. [11:51:29] chassis / i will deal with all of that for that [11:51:36] and we will jsut plug in when its ready lol [11:51:45] same with ui [11:52:08] there is talk of making a seperate project just for doing project comparision benchmarks [11:52:25] not sure yet though [11:52:37] What are "project comparison benchmarks"? [11:52:52] like the page i posted [11:53:03] comparing component implementations from different frameworks [11:53:29] Oh, I see ... [11:53:38] like the perf for ui selectmenu vs bootstrap selectmenu vs foundation selectmenu [11:53:41] same as the button [11:53:49] for both the css and js [11:54:06] for example sizzle already does this [11:54:14] for different selector engines [11:55:03] ok last thing i have [11:55:08] tests [11:55:27] In the past we have written mostly functional tests with some unit tests [11:55:41] UI writes essentially entirely functional tests [11:56:21] I would like to see us focus on functional tests as i think they best suite the type of product we are creating [11:56:34] Yeah, I'm also more of a fan of functional tests rather than unit tests, because unit tests are too easily tripped up by code changes. [11:56:35] The important thing we want to be testing is that a problem is actually fixed [11:56:49] Yeah. [11:56:50] not that some function is no longer called [11:57:14] So going forward when we are working on tests lets focus on functional tests [11:57:44] also related to how we are writing out tests [11:58:01] With the classes work in ui [11:58:18] there has been a lot of debate on the proper way to check the presence of classes [11:58:29] you can do a whole bunch of .hasClass checks [11:58:47] you can do .attr( "class" ) [11:59:00] you can do .is( ) [11:59:07] I vote hasClass. [11:59:11] hasClass is ugly because it makes a bunch [11:59:20] but ti has the best output for failures [11:59:47] and its not going to be broken by things like the order of classes being changed like .attr() [11:59:57] Exactly. [12:00:03] or by adding an addition class in the markup [12:00:05] If .hasClass() get ugly you can use .is() [12:00:09] which is perfectly valid to do [12:00:16] gabriel_schulhof: the problem with .is [12:00:23] is the failure output is useless [12:00:33] you have no idea if there is one missing [12:00:34] or all [12:00:37] or 2 [12:00:43] or which ones [12:01:04] You can put the .attr() in the third parameter to deepEqual() [12:01:31] after a couple weeks of debate jzaefferer scott_gonzalez and i all agreed on many .hasClass [12:01:41] anything left on the agenda? I have to go [12:02:04] Nope. [12:02:07] so id like to see the same here as we add tests for classes [12:02:15] OK. [12:02:18] these are tests so being a bit verbose is ok [12:02:23] and file size does not matter [12:02:37] Exactly. We have a pile of ok()s in our tests. [12:02:37] hasClass it is [12:02:49] Unearthing them as I revisit old bugs. [12:03:02] yeah those should be avoided too [12:03:32] thats the end of our time [12:03:37] any one have anything else? [12:03:47] I'm done. [12:04:17] ok see everyone back on -dev [12:04:17] i'm good [12:04:21] K L8R