[11:01:19] agcolom: jasperdegroot: gabriel_schulhof: cgack: lisa_deluca: sfrisk: Meeting Time [11:01:32] hi all [11:01:33] allo [11:01:38] howdy! [11:01:57] Hey! [11:02:11] hi :-) [11:02:16] ianmaffett: Welcome [11:03:02] agenda: https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdG5nSmZiSUhjYm4ya29CdjhLZmJwSWc&usp=drive_web#gid=55 [11:03:10] howdy [11:03:49] Ok so gabriel_schulhof tracked down the perf regression we saw [11:04:03] apparently widget :pseudo selectors are terrible [11:04:22] Yes, but also because we were doing $( ":mobile-toolbar" ) [11:04:24] we should go through the rest of the code base and make sure we are not using them anywhere [11:04:29] That searches the whole document. [11:04:43] Or, I mean :mobile-pagecontainer [11:05:01] gabriel_schulhof: see my comment about avoiding that completely on your pr [11:05:03] Doing this.element.closest( ":mobile-pagecontainer" ) examines at most 2-3 elements. [11:05:05] and using a class [11:05:21] Yeah, I guess ui-mobile-viewport. [11:06:04] gabriel_schulhof: then we also need to answer the queston at some point is what about toolbars outside any page container [11:06:35] arschmitz: Well, then the selector will return an empty set *shrug( [11:06:37] * [11:06:45] right but is that correct [11:06:50] Up to toolbar to handle that case. [11:07:00] We don't currently support that, do we? [11:07:04] anyway this is a simple fix for now [11:07:09] gabriel_schulhof: we never say [11:07:21] arschmitz: :) Pagecontainer is the new page :) [11:07:31] We need to add support for widgets outside the pagecontainer. [11:07:35] we allow you to use something besides body [11:07:43] and say to put toolbar in body for external [11:07:48] which would imply you can [11:08:01] Right. We should say put it in the pagecontainer for external. [11:08:18] im not sure i would agree with that [11:08:37] but thats something for another time [11:08:47] Right. [11:08:57] perf wise lets go with just using ui-mobile-viewport [11:09:04] and only doing for fixed [11:09:08] Oh, absolutely! [11:09:11] * jasperdegroot noticed 40 matches for ":mobile-" (in ui-1-12 branch) [11:09:34] ok so lets get those sorted out though i suspect many may be in demos [11:10:05] yes and in tests [11:10:24] also some in widgets (collapsible set, selectmenu, loader) [11:10:26] 14 in the lib. [11:10:32] those are fine ( though cant hurt to see if something better is easy ) [11:10:45] collapsible set we dont need to worry about [11:10:51] right [11:10:58] anything else though we want to remove [11:11:46] ok so moving on [11:12:05] things with classes and button are very much in flux at the moment [11:12:14] _classes is not going to happen any more [11:12:15] that performance regression wasn't a 1.4.6 need was it, or just additional to 1.5? [11:12:24] nope [11:12:28] just for 1.5 [11:12:40] k [11:12:41] and we will be using some form of _addClass and _removeClass [11:12:53] but there are 2 competeing apis right now [11:13:18] _addClass( elements, classes, extra ); and _addClass( elements, classes ); [11:13:43] It looks like we will likely ( maybe? ) end up with auto destroy for all classes [11:13:50] There's also the whole tracking issue. [11:13:55] Right. [11:14:03] Both of those APIs accommodate tracking. [11:14:11] yes [11:14:19] there is no tracking issue [11:14:33] The main issues are which api [11:14:38] and if it will include autodestroy [11:14:49] the first one who knows the second ond is likely yes [11:14:59] this means like _on and _off [11:15:06] if you use _AddClass and _removeClass [11:15:09] "if it will include autodestroy" is what I refer to as the tracking issue. [11:15:21] you will never have to remove any class in destroy [11:15:27] is there a good metric we could use to compare the api differences? [11:15:28] It would be cool. [11:15:42] cgack: yes just a sec [11:15:59] cgack: https://github.com/jquery/jquery-ui/pull/1394 [11:16:15] that shows the difference moving from one to the other [11:16:50] arschmitz: What if you add a parameter to _addClass() indicating that classes need not be removed upon destroy? [11:17:04] gabriel_schulhof: that is not part of the issue at all [11:17:11] arschmitz: Like, it's basically the widget telling _addClass() that it can safely skip this element at destroy. [11:17:23] arschmitz: Nono. I just had this idea. [11:17:27] that would be fairly pointles [11:17:30] arschmitz: Then you needn't worry about optimisation. [11:17:34] because the main use is for set options [11:17:47] and as scott_gonzalez pointed out yesterday there is no need for optimization [11:18:02] Well, OK. [11:18:31] 60000 elements per second is not going to be an issue [11:18:46] and on things like removing pages [11:18:50] On what hardware? [11:18:54] the solution is elsewhere [11:19:15] like _remove() [11:19:27] which will skip destroy entirely [11:20:02] Right, yeah, but that's a whole new feature. I'm not sure if we should tackle that for 1.5.0/1.12.0 [11:20:16] There're already way too many things in flux. [11:20:36] gabriel_schulhof: well we are not going to add an optimization liek that for a single version with no proof its actually needed [11:20:51] it changes the api [11:21:00] Yeah, sorry! I dropped the idea as soon as you reminded me of _remove() [11:21:44] ok so anyway there is not much point in doing any updates related to 1.12 until this is ironed out [11:21:45] arschmitz: So, if we're gonna use _addClass() mostly for _setOptions(), I think we should go with the three-param version. [11:22:11] so lets try to concentrate on things not effected by this [11:22:22] gabriel_schulhof: put it in the PR [11:22:39] OK. [11:23:09] gabriel_schulhof: and remember the three param version makes no difference to autodestroy or anything under the hood [11:23:19] its just if you think the classes should be mixed or not [11:23:42] the factory will sort out if its a classes key or not [11:24:09] Ok so i reviewed i think all of the PR's which are not based of ui-1-12 [11:24:11] arschmitz: Right, I guess that's what I'm concerned with. Are we going to track non-key classes? I don't believe we've established one way or the other. [11:24:27] if we do auto destory yes if we dont no [11:24:34] that has nothing to do with which api we use [11:24:50] they can be tracked weather its 2 params or 3 [11:25:58] there are lots of PR's that are just waiting to land [11:26:32] so if you had ( non ui-1-12 ) PR's waiting please check them when you get a chance they should be reviewed [11:27:03] Nice! [11:27:16] do table & navbar review apply here? [11:27:37] i can review them [11:27:51] but they need to be incorperated into classes before we can really do anything with them [11:27:53] I dunno how they jive with classes though. [11:27:58] Right. [11:28:04] so it would be more a general function review [11:28:08] then a real code review [11:28:19] yeah, but can we reduce a rebase by reviewing them into a branch now? [11:28:22] which im happy to do its up to the two of you [11:28:37] arschmitz: What about the tests for ui-1-12? can you look at those? [11:28:38] cgack: evntually they will need to be in a single branch [11:28:46] arschmitz: That would help us keep ui-1-12 clean. [11:28:52] gabriel_schulhof: sure that way its ready [11:29:08] arschmitz: https://github.com/jquery/jquery-mobile/pull/7738 [11:29:48] ill go through after the meeting [11:30:14] *sigh* ... I get the nagging suspicion that our tests will become completely unhinged from all these changes. We're gonna end up using them mostly for reference (to see what things we were testing - conceptually) rather than as actual tests. [11:30:49] But it's just a nagging suspicion. We might be able to power through them and update the assumptions. [11:30:55] gabriel_schulhof: not sure what you mean? [11:31:35] arschmitz: When I was fixing the tests very often I had to re-write one or two. Conceptually, /what/ the test was testing continued to be valid, but /how/ it was testing it was completely off. [11:31:59] right assumptions have changed [11:32:40] Yeah, but we've "encoded" many regressions and bug fixes as tests. Those continue to be things for which we need to ensure correctness. [11:32:41] gabriel_schulhof: like icons [11:33:05] Otherwise old bugs will re-surface. [11:33:20] gabriel_schulhof: yes and now sadly we are bad about documenting platforms [11:33:21] but as gabriel_schulhof we at least have reference to what needs testing [11:33:27] Anyway ... all this is pretty clear, and we'll just have to keep trying to keep tests green in ui-1-12. [11:33:40] cgack: Exactly! [11:33:54] cgack: That's probably the most valuable information stored in the tests. [11:34:17] gabriel_schulhof: the reality is though any test that is for button checkboxradio or controlgroup [11:34:31] gabriel_schulhof: indeed! [11:34:32] arschmitz: Oh yeah. Raze those with extreme prejudice :) [11:34:46] is likely either already covered in ui, is not really a bug, or should be in ui not mobile [11:34:54] Absolutely. [11:35:15] the only test for those that should be in mobile are for backcompat or things we change [11:35:33] BTW: checkboxradio looks completely native right now. I'm assuming that's because the CSS hasn't yet caught up with the JS in ui-1-12, right? [11:35:50] yes [11:35:58] OK. That's cool! [11:36:17] jasperdegroot: you were asking questions before the meeting any progress there [11:36:19] gabriel_schulhof: I am working on that in 1.5-button-css-and-demos branch [11:36:29] Awesome! [11:36:30] thats the one thing that wont be effected by the ui changes coming [11:36:33] arschmitz: yeah, made some good progress [11:36:46] execlent [11:36:53] I think I can finish PR 1.5-button-css-and-demos this weekend [11:36:59] execlent [11:37:15] would like to get that merged asap even if you have to do seperate prs after to fix up some things [11:37:43] ok [11:37:54] I haven't had time to look into "Update widgets that use icons to generate spans instead of adding icon class to the element + update the "Enhanced" examples on demo pages" [11:37:58] Let's please release 1.5.0 during a major conference so we can go and hose ourselves afterwards :) [11:38:09] so that's probably something we can do after merging into ui-1-12 [11:38:13] jasperdegroot: generating spans can be part of classes prs [11:38:21] ok [11:38:27] one question [11:38:33] what's the plan with selectmenu [11:38:43] its not going to change in 1.5 [11:38:55] they are still broken inside controlgroups in my branch [11:38:56] other then getting classes and probably enhanced [11:38:58] What about announcements as to its deprecation? [11:39:20] gabriel_schulhof: cant get rid of something until we have the replacment ready [11:39:22] ... and dialog is still hanging in there solely because of selectmenu :/ [11:39:26] ui is no where near usable yet [11:39:30] Yeah ... *sigh* ... [11:39:32] gabriel_schulhof: yeah sadly [11:40:05] jasperdegroot: we wont be able to make selectmenu work in controlgroup until it recieves the classes option [11:40:13] arschmitz: what I need to know is if the outer div gets class ui-button next to ui-select or not [11:40:22] both [11:40:27] arschmitz: ok clear [11:40:35] than I am not gonna fix it with CSS [11:40:45] one other thing [11:40:45] jasperdegroot: look at how checkboxradio works with classes [11:41:01] it get ui-button but also a checkboxradio class [11:41:10] that just has no styles connected to it [11:41:14] after switching to accordion only listview will be using our addFirstLast classes method [11:41:43] yeah we can probably just roll that into listview at that point [11:42:01] arschmitz: ok, I will just see how selectmenu looks after classes option has been added [11:42:26] jasperdegroot: yeah not much you can do with select menu until then with regards to controlgroups [11:42:35] arschmitz: yes, and it should add ui-corner-top/bottom classes [11:42:59] jasperdegroot: it does but through classes option [11:43:05] so it fails completely with that missing [11:43:30] How does accordion deal with the first collapsible being hidden? [11:43:46] Or the last one, for that matter. [11:43:57] gabriel_schulhof: what do you mean? [11:44:22] http://jqueryui.com/accordion/ [11:44:23] he means if the 2nd button gets the corners classes [11:44:25] arschmitz: Well, we added addFirstLast precisely because CSS doesn't have a :first-visible-child selector nor a :last-visible-child selector. [11:45:00] gabriel_schulhof: there is no need of a first last there [11:45:05] Oh, right. UI accordion rounds all accordions. [11:45:21] gabriel_schulhof: and we can make it look however we want [11:45:24] arschmitz: OK, so are we gonna drop our integrated look-and-feel in mobile? [11:45:37] gabriel_schulhof: thats more or less up to sfrisk shes doing the implementation there [11:45:48] we will want it to fit with the rest of mobile overall look [11:46:03] but the exact look can be whatever we want [11:46:13] arschmitz: Right, but she won't have the tools to implement the overall-rounded look, because she needs to know the first /visible/ and last /visible/ child. [11:46:28] right so we probably wont do that :) [11:46:43] or we keep our method [11:46:45] *makes notes* [11:46:59] jasperdegroot: ... but that would have to be an extension to accordion. [11:47:10] gabriel_schulhof: yes [11:47:20] i really dont think adding in the extra logic all based on corners is a good decision [11:47:28] not saying that we should do it [11:47:37] agreed [11:47:38] but im open to others opinions [11:47:48] sfrisk: since your working on this whats your thought? [11:47:51] nothing wrong with changing a look from time to time [11:48:05] and this is a whole new widget [11:48:17] in mobile so we are not restricted by collapsible / set [11:48:31] arschmitz: Well, it's really an extension to CSS itself. I'm not advocating keeping the extension, just curious. [11:48:41] about rounded corners vs not rounded corners? [11:49:02] sfrisk: About rounded top corners on the topmost collapsible and rounded bottom corners on the bottom-most. [11:49:14] sfrisk: The problem is if the first is hidden, you need to add the rounding to the second. [11:49:19] well about if it should be like this http://demos.jquerymobile.com/1.4.5/collapsibleset/ [11:49:30] or if it should be like http://jqueryui.com/accordion/ [11:49:34] sfrisk: currently our collapsible set looks like listview with all collapsibles on top of eachother [11:49:55] UI's accordion is a set of single collapsibles [11:50:13] Wait a sec! controlgroup definitely needs the first-last rounding, right? [11:50:15] my opinion is if we are introducing a new look and feel, nobody will miss it, and if they do, we can perhaps come up with an overly complicated workaround and add it to the demos [11:50:18] I mean, if you had a class that was applied to the visible ones, it should actually be doable I would think [11:50:25] gabriel_schulhof: yes but its baked in from ui [11:50:26] gabriel_schulhof: the widget adds the corner classes [11:50:46] jasperdegroot: Aaah, OK, so the widget can check which is the first visible child. [11:50:47] maybe . . thinking it through [11:50:49] I didn't test with hidden buttons in it, though [11:51:05] arschmitz: So, basically, it duplicates what our extension does. [11:51:13] gabriel_schulhof: not sure [11:51:18] gabriel_schulhof: some what [11:51:28] I can test now [11:51:32] it does [11:51:36] i wrote it lol [11:51:36] I suppose it's simple enough that it can be coded inline for each case where it's necessary. [11:51:52] theres an option just like no [11:51:57] excludeInvisibles [11:52:12] ah nice :) [11:52:16] nice! [11:52:31] arschmitz: what are invisibles in this case? [11:52:37] arschmitz: we used "ui-screen-hidden" [11:52:38] :visible [11:52:41] ah ok [11:52:46] its the actual true visible [11:52:57] That's hard to establish during page load. [11:53:01] not sure what CSS we used for ui-screen-hidden [11:53:13] display: none !important, IIRC. [11:53:13] gabriel_schulhof: thats why it binds to pagebeforshow [11:53:18] if it's display none the class could still be used [11:53:26] and refreshes [11:53:56] arschmitz: What about outside pages? I guess it's the user's responsibility to refresh in that case. [11:54:09] if its outside a page its not hidden [11:55:08] That's true, and in this case we don't need to perform computations that may be affected by whether the style has been applied or not. Cool! [11:55:44] also iv been thinking [11:55:50] why do we display none [11:56:05] why dont we just throw up a absolute white div covering the screen [11:56:27] then everything would be visible according to a selector [11:57:08] I don't get it. [11:57:10] jasperdegroot: gabriel_schulhof: any idea? [11:57:13] neither do I [11:57:22] right now we do display:none [11:57:27] to hide everything durring loading [11:57:35] ah [11:57:38] Oh, during loading. [11:57:44] thought we were talking about buttons [11:57:46] But that's to avoid FOUC. [11:57:46] why dont we append a div thats 100% width 100% height and white [11:58:16] we could do the same for transitions [11:58:25] all but slide go to a white page at a point [11:58:29] using display none [11:58:56] instead make them visible behind a full div and avoid all this hidden durring init nonsense [11:59:36] a white page between transitions? [11:59:56] yes all our current transitions execpt slide go to a blank white page [12:00:00] to hide scrollong [12:00:02] scrolling [12:00:24] or black if theme b [12:00:40] ah ok [12:00:50] now I remember [12:01:06] thought you meant it was actually white [12:01:10] rather then using display none if we hid content with a solid div :visible would work [12:01:42] arschmitz: So, when the page gets attached to the DOM after Ajax everything's visible? [12:01:50] arschmitz: That would be cool. [12:02:04] thats the idea just not 100% sure we can make it work [12:02:06] Oh, and most importantly, before we instantiate widgets. [12:02:16] gabriel_schulhof: yes exactly [12:02:22] so lets just think about this [12:02:34] could even transition the opacity so contents fade in [12:02:43] ok we are out of time [12:02:52] so lets just run through last few things real fast [12:02:59] pointer events still waiting on lawyers [12:03:03] Yeah, I mean our viewport has overflow-x: hidden, so there should not be a scrollbar if we plant the page to the right of the visible page before the transition. [12:03:27] css-framework had first official meeting this week [12:03:34] Nice! [12:03:37] cool [12:03:40] they are tuesdays at 1pm eastern right here [12:03:43] all are welcome [12:03:56] sfrisk: is the official new team lead on that project [12:04:02] arschmitz: is there a link to see the chat history? [12:04:06] *clap* *clap* *clap* *clap* *clap* [12:04:16] Having people at meetings would be awesome :-) [12:04:35] lisa_deluca: all channels are logged here [12:04:36] Also we're voting on a css project name, it's a race between Draft and Chassis [12:04:47] I'll get the links [12:04:52] yeah I saw that in the minutes [12:04:56] lisa_deluca: http://irc.jquery.org/ [12:04:58] where can we vote? [12:05:11] sfrisk: oh yeah can you post the link in the issue for that [12:05:12] agenda from tuesday -> https://docs.google.com/spreadsheets/d/1FUdRcAq2d8njs8KAcfQmEyoZL74SXLsLp1rtc7E9z_I/edit?usp=sharing [12:05:16] to vote [12:05:29] voting link -> https://www.surveymonkey.com/s/VPM2WCN [12:05:31] that way anyone watching the repo will get it [12:05:41] gabriel_schulhof: thanks [12:05:54] lisa_deluca: you can get transcripts of all channels any time there [12:06:25] lisa_deluca: It just sucks that it isn't indexed by Google - you can't search the archives :/ [12:06:42] lisa_deluca: I guess it's to reduce load on the server. [12:06:42] gabriel_schulhof: probably best its not [12:06:47] lol [12:06:57] gabriel_schulhof: not sure we want every conversation searchable [12:07:00] :-) [12:07:04] will the new css framework have device specific styles... like an ios style and an android style? [12:07:12] lisa_deluca: no [12:07:27] :( [12:07:40] lisa_deluca: its a combination of a markup and class structure standard and a single implementation of that standard [12:07:43] I suppose it should be easily themeable in that direction though, right? [12:07:53] lisa_deluca: the community often develops platforms specific themes [12:07:54] lisa_deluca: we dont have the man power to maintain multiple themes [12:08:17] its just not realistic that the idea though behind the standard aspect [12:08:19] lisa_deluca: Yeah, people have written Android themes for jQM before. [12:08:23] for JQM there is a theme available for every platform [12:08:34] understandable, seems to be the biggest complaint with customers about going to jQuery though. They want it to "feel" native [12:08:36] it will make it possible to have completely interchangable themes across many js toolkits and css theme frameworks [12:08:39] gabriel_schulhof: Android, iOS, Windows Phone, Blackberry 10 [12:08:53] Right, true. [12:09:01] yeah we have themes written by 3rd parties for every major platform already [12:09:12] and this is a step to encourage more of that [12:09:12] yup [12:09:20] I mean, it's possible someone could theme the css-framework to mimic iOs/Android [12:09:39] sfrisk: yeah i mean that the whole point behind the standard aspect of the project [12:09:52] Yeah, and all of a sudden your theme would work with any and all projects that support the css-framework. [12:09:54] to have people make lots of themes based on it like that [12:09:56] so the new css framework will be easier to extend with different themes than it is today? cool [12:10:22] lisa_deluca: it will be an independant project designed around the idea of a markup standard for widgets and components [12:10:32] lisa_deluca: Well, your theme should gain wider impact if it's for the css-framework. [12:11:00] so the ones today will have to be rewritten? the 3rd party ones? [12:11:06] so like right now Zurb foundation, famo.us, caridnal css, cascade css, intel app framework, topcoat, and others have all commited to help [12:11:29] lisa_deluca: Those themes need to be updated for each new version of jQM anyway. [12:11:40] so if all of those stick any of those alone with the one create by the actuall css framework will all be 100% interchangable [12:11:45] lisa_deluca: This time, the update will gain them css-framework compatibility. [12:12:15] it requires a lot of updating anyway [12:12:17] nice, and exciting! [12:12:24] lisa_deluca: Meaning that the updated theme should, in theory all of a sudden be useable on all frameworks arschmitz mentioned. [12:12:26] https://github.com/jquery/css-framework/ [12:12:31] also because the platform look changes [12:12:40] now everyone want Material Design theme :) [12:12:43] gives a brief outline of the goals [12:13:17] jasperdegroot: Everyone on Android, presumably ... [12:13:20] lisa_deluca: also feel free to ask sfrisk or myself any questions about it [12:13:21] I've been looking into Material Design, I really like it [12:13:29] sfrisk: me too [12:13:41] sfrisk: jasperdegroot me three [12:13:55] i like the vast majority of the concepts in it [12:14:00] I also kinda like it. [12:14:04] though have reservations about a few things [12:14:21] OTOH, AFAIK it's the only explicit design concept to be released into the public. [12:14:26] there is an open issue on the css framework about design direction people can feel free to weigh in there [12:14:32] Usually design concepts are closely guarded secrets. [12:14:55] gabriel_schulhof: not sure [12:15:04] gabriel_schulhof: all the platforms want apps in the app store [12:15:10] It's interesting to see a style guide document about how animations work too [12:15:21] so they also teach how to make an with the platform look [12:15:39] sfrisk: yeah [12:15:51] jasperdegroot: Yes, that's right, but they won't tell you what the unifying concept behind the look and feel of their platform was. You mostly end up immitating the various details you see. [12:16:14] anyone who knows anyone potentially interested in the framework feel free to point them in the direction of the repo, sfrisk, or myself also we are always looking for help getting this going [12:16:18] gabriel_schulhof: yeah, that's true. Google gives more insights [12:16:31] jasperdegroot: Exactly! And AFAIK, they're the first to do that. [12:18:02] jasperdegroot: I wish we'd get more design concepts expressed publically. [12:18:11] me too [12:18:33] yeah design is something that tends to be pretty closely guarded [12:18:34] jasperdegroot: So your app could not only benefit from a theme and a framework, but a design concept as well. [12:18:36] yeah [12:18:58] As a developer who has been learning design slowly, I appreciate transparency explaining why things are done [12:19:02] I learned a lot from that Google Material Design document [12:19:04] and what the trends are [12:19:07] Well, I'm preaching to the choir here, no doubt, but I'm glad I find kindred spirits :) [12:20:06] :) [12:20:23] Anyway ... we've philosofied about this in Chicago a bit, so this can easily segue into a long discussion :) [12:20:45] right now things on the framework are still kinda slow [12:20:53] but we will really ramp up once we have a name [12:21:09] a LOT of the current tasks are waiting on that [12:21:37] Is the vote a secret vote? [12:21:59] sfrisk: ^^ [12:22:12] yeah [12:22:16] I have no idea who voted what [12:22:33] the last vote was me ;) [12:22:34] lol [12:22:38]