[11:05:16] agcolom: gabriel_schulhof: jasperdegroot: cgack: sfrisk: lisa_del_: Meeting time [11:05:28] howdy [11:05:29] hi! [11:05:29] hi all [11:05:32] allo [11:05:38] Hey! [11:05:52] hey :-) [11:07:35] agenda https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdG5nSmZiSUhjYm4ya29CdjhLZmJwSWc&usp=drive_web#gid=56 [11:08:46] Ok lets get started with classes [11:08:56] since thats the big hold up on 1.5 [11:09:41] *drumroll* [11:09:44] We had a skype call this morning with scott_gonzalez and jzaefferer and we came to i "think" a finial decision [11:10:06] we will be doing auto destory of classes [11:10:39] and we will be doing _add/_removeClass [11:11:03] Nice! [11:11:06] the signiture will be _addClass( elements, classeskeys, extra ); [11:11:23] we will also have _toggleClass [11:11:31] So "extra" won't be tracked? [11:11:38] extra will be tracked [11:11:42] OK. [11:11:50] Nice. That makes it a complete solution. [11:12:05] excellent [11:12:06] toggle class will require a boolean final param [11:12:23] _toggleClass( elements, classeskeys, extra, bool ); [11:12:38] and unlike core you MUST pass the bool option [11:12:47] param i mean [11:13:20] there is one more big change [11:13:29] which is we will no longer define null nested options [11:13:39] Hmmm? [11:13:51] so you wont have like classes: { "ui-button": "" } [11:14:02] Oh, OK. [11:14:02] you just wont define ui-button at all [11:14:13] this is for all widget options not just classes [11:14:32] ok to be clear that example WAS NOT NULL [11:14:51] but we are switching back to null for classes values that are empty [11:14:53] Right, so, null, or falsy? [11:14:58] Oh, OK. [11:14:59] which means they wont be defined [11:15:00] GOtcha. [11:15:24] So, "" is OK, false is OK, but null and undefined are, well, gonna be absent. [11:15:26] the concatenation idea didn't really work in practice [11:15:48] because you needed to hit the prototype to get it to concant to anyway at which point it makes little difference [11:16:44] gabriel_schulhof: right [11:16:54] but thats only for nested options [11:17:14] ... of which we don't have too many in mobile, IIRC. [11:17:15] so where its an object [11:17:25] there are not a ton in ui either [11:18:19] ok so thats the classes news [11:19:37] on other 1.5 stuff gabriel_schulhofi started reviewing the test fixes i have some questions but we can talk about that after [11:19:49] OK. [11:20:05] it looks mostly fine though nothing big [11:20:39] jasperdegroot: any update on the css? [11:20:42] It's gonna get quicke a knockin' once we actually start moving up to the new classes implementation :) [11:20:51] arschmitz: yeah, the CSS is done [11:21:26] excellent so you would say its ready for review and merge into ui-1-12 [11:21:34] I know this is waaay preliminary but is there any sense when we'll be Chassis-compliant? [11:21:35] I haven't finished updating the button and checkboxradio demo pages though [11:22:00] jasperdegroot: how long do you think that will take just want to decide if we should wait on that or not [11:22:01] '? [11:22:06] that had also to do with me not knowing how certain data- attributes are supposed to work in 1.5 [11:22:24] did i answer that ? [11:22:52] arschmitz: I think there are some issues with the backcompat [11:23:13] like data-type="vertical" on a controlgroup doesn't work [11:23:29] i thought we talked about that already? [11:23:32] that wasn't a problem, because I update the demos to use data-direction which works [11:23:47] arschmitz: yeah, you said that should work [11:23:52] Right, but how are we gonna handle that in 1.5.0? [11:24:02] ok gotcha i remember now [11:24:03] Are we gonna make an extension that just aliases the option? [11:24:11] yes [11:24:13] we have to [11:24:14] OK. [11:24:18] Just checking. [11:24:19] but things like data-theme also don't work [11:24:28] theme should work [11:24:46] arschmitz: Right, you added that widget extension for the theme option. [11:24:46] but dont worry about that stuff for now [11:25:18] lets just get the css in place and that makes it possible to actually see whats broken a lot easier and fix it [11:25:44] arschmitz: well, I don't feel like updating those demo pages twice so I am just wondering if I am doing it wrong or if something is not working (yet) [11:25:59] right thats fine ill answer any questions as far as that [11:26:08] arschmitz: ok, then let's merge 1.5-button-css-and-demos in ui-1-12 [11:26:19] ok [11:26:46] so once the updates come down the line from ui ill pull in the css and update ui-1-12 [11:26:48] maybe we should add a functional test page for button, controlgroup and checkboxradio [11:27:12] jasperdegroot: we will be adding a bunch of tests for those both visiual and unit [11:27:16] to test backcompat [11:27:17] I have one for button-markup ... [11:27:21] ok [11:27:26] ... may still be useful. [11:27:30] jasperdegroot: yeah we will have full test coverage [11:27:45] for anything we change from the ui widget including backcompat [11:27:55] we just wont duplicate ui's tests [11:27:57] great [11:28:27] our coverage will actually likely be much more complete then it was [11:29:27] speaking of which [11:29:42] QUnit 1.16 was released this week [11:29:49] which changes the api quite a bit [11:30:10] we will need to update ALL of our tests before 2.0 when the current api is going to be dropped [11:30:45] since we have some pretty substantial other problems in the tests [11:30:58] we should address this all at once [11:31:12] Yeah ... our init tests, for example ... [11:31:22] one big advantage [11:31:27] They have require() calls in the _core.js [11:31:30] is tests now return a promise [11:31:49] so for nav tests we can use that directly instead of a time out in some places [11:31:57] Oooh! Nice! [11:32:12] so this should remove some flake from out tests too [11:32:28] but its going to be a ton of work [11:32:38] we should probably aim for 1.6 or 1.7 on this [11:32:55] because we also need to get them passing on all supported devices [11:33:31] right now we assume certain things are supported in our tests [11:33:54] meaning its not possible for them to pass on some devices which we support [11:34:16] does not mean the library is broke just that we have bad tests [11:34:50] No updates on pointer events this week [11:35:08] The CSS Framework has a name [11:35:11] Chassis [11:35:45] We confirmed that we will be using SVG for icons [11:36:54] sfrisk: and i are meeting with Yandex next week [11:37:06] yuuup [11:37:08] They are the russian company that created BEM [11:37:40] cool [11:37:43] Oleg works for them they are basically the russian google with some pretty amazing devs [11:38:32] sfrisk: i think thats about it this week right? [11:39:26] I believe so - I think everything else was decided last week and was probably already announced here [11:39:35] yeah i think so [11:39:52] ok last thing i see on the agenda is popup on android [11:40:15] Yeah. I wrote a fix that checks whether the popup is on screen, before initiating the repositioning insanity. [11:40:36] ... and it is insanity if a virtual keyboard is present at the time. [11:40:43] gabriel_schulhof: would using ui's position utility make any of this more sane? [11:41:07] I doubt it. It's not about the calculated position being wrong, but about the fact that we need to hide/show the popup. [11:41:32] ... in fact, it may not even be that. I tried to not hide/show the popup, but simply reposition it and it was just as bad. [11:41:46] I think the bottom line is that the repositioning code needs to be rethought. [11:42:07] yeah it seems like we are doing this all wrong and there is a better way to handle it [11:42:08] This was at some point a plan, but now we've veered far from that course. [11:42:30] Looking into this has also made me a bit concerned about replacing popup with dialog. [11:42:37] Dialog is a very different beast. [11:42:52] ... and much slower because of all the extra features. [11:43:12] ... but I'm not sure if we should discuss this during the meeting. I'm good with talking about it in -dev afterwards. [11:43:17] that seems like something that could potentially addressed in ui [11:43:59] The question is one of use cases though. [11:44:12] ok [11:44:30] If popups are mostly used for creating dialogs, then dialog is the way to go - after we've factored resizable and draggable into a separate extension. [11:44:50] resizable and draggable are their own extensions? [11:45:03] Not right now, but if we're gonna use UI dialog, they should be. [11:45:12] you can use dialog with out either of them [11:45:17] they are completely optional [11:45:33] arschmitz: Yes, you can turn it off, but it still AMD-depends on the draggable and resizable module. [11:45:47] it shouldnt [11:45:54] they are optional always have been [11:46:22] Yeah, it's kinda weird. It AMD-depends on the module but then it turns around and checks whether $.fn.draggable is present. [11:46:26] https://github.com/jquery/jquery-ui/blob/master/ui/dialog.js#L128 [11:46:28] So, that's kind of a contradition. [11:46:36] yeah thats not correct [11:46:37] contradiction, even. [11:46:58] scott_gonzalez: you around? [11:47:37] guess not [11:47:47] but we can address that on our own as is [11:47:52] Well, anyway ... I just wanna make sure that if we do grab dialog, then we do not unjustifiedly pay a perf penalty. [11:48:07] draggable and resizable are non issues [11:48:18] because we can shim the amd [11:48:20] on our side [11:48:31] Hey, that's a good point! [11:48:36] to make sure they are actually optional [11:49:20] OK. I have a nice test setup at http://jsperf.com/dialog-vs-popup/, so I can test various scenarios. [11:49:44] but does that include draggable and resizable? [11:49:55] it does [11:50:04] arschmitz: It does now, but I can turn it off and see how it influences performance. [11:50:13] i would like to see that [11:50:45] Doing it now ... [11:50:58] Should be as simply as passing draggable: false, resizable: false to the options. [11:51:07] gabriel_schulhof: not even [11:51:11] just take out the script tags [11:51:25] we cant even use them right now they only work on mouse [11:51:37] Aaah, true! [11:51:50] they are also going to be re-written [11:52:00] and ours does not do that [11:53:11] Dialog is 20% slower when the popup also has a header. [11:53:31] That's not bad. [11:53:41] nope [11:53:47] and im sure we could do some optimization [11:54:01] if we work with the ui folk [11:54:02] arschmitz: Yeah, and we may want to short circuit title bar creation. [11:54:08] ... with an extension. [11:54:49] we can also work with them to isolate dom manip in create so we can add enhanced [11:54:52] Oh, and we'll also need to update the positioning, and the modal overlay does not resize to the height of the document on some platforms. [11:55:22] these are all really minor things we either add by extension or work with ui on [11:55:28] Yeah. [11:55:31] It's gonna be fun. [11:55:40] so since it seems like perf is not an issue any more are there any other major concerns [11:55:41] But it's good do keep performance in mind. [11:56:04] yes but 20% before any optimization is not bad [11:56:16] i can live with that [11:56:34] espically if we can push of some from create->open [11:56:35] No ... no ... and I'm hoping to bring it up to par with an extension that eliminates the title bar. [11:57:49] So, that's about it re: popup [11:58:20] ok cool [11:58:38] anyone have anything else or anything from the community? [12:01:45] ok thanks everyone see everyone on -dev [12:01:49] L8R [12:02:03] later [12:02:09] adios