[11:02:02] agcolom: cgack: gabriel_schulhof: ianmaffett: jasperdegroot: sfrisk: Meeting Time! [11:02:14] yo [11:02:18] hi all [11:02:27] howdy [11:02:39] hello [11:03:20] new agenda https://docs.google.com/spreadsheets/d/1xGEVtftLDEHAA37YYlA23J_EZwIRyMUaseBY790byPM/edit#gid=0 [11:03:37] howdy [11:03:46] lisa_deluca: sorry [11:03:49] Hi! [11:03:56] arschmitz: no problemo [11:03:57] btw, don’t forget to update the agenda on meetings.jquery.org :-) [11:04:15] lisa_deluca: glad you were paying attention [11:04:19] arthurvr: already on it [11:06:14] ok so lets get started [11:06:41] Next round of updates have landed for Classes and Button [11:07:27] Looks like once again the api has stabilized. So iv pulled the changes into ui-1-12 and am currently merging in jasperdegroot css updates [11:07:38] cool [11:07:57] I will look into the demo pages that need attention after you've merged [11:08:06] jasperdegroot: sounds good [11:09:20] So that means gabriel_schulhof and cgack we can start on the classes pr's again [11:09:36] Sorry I'm late! [11:09:44] \o/ [11:09:52] *whew* [11:11:50] gabriel_schulhof: ok so i was saying updates have landed upstream in ui [11:12:08] Yeah. Read that. The "*whew*" was for that :) [11:12:40] awesome [11:12:52] Can't wait to get started on that. [11:13:06] one thing to be mindful of i ran into [11:13:21] never do toggleClass on the same element twice in a row [11:13:32] even with different arguments [11:13:37] ... because? [11:13:46] you must always remove classesthen add them [11:13:57] or if someone sets the same value for a classes on both keys [11:14:05] you will remove the theme class after you add it [11:15:20] Another thing not sure if this is an issue anywhere in mobile [11:15:42] arschmitz: So, what separation is required between two subsequent toggleClass calls? I mean, what if two option values change at the same time and they both affect the same element? [11:16:30] gabriel_schulhof: its up to you to ensure you dont remove classes that should be there [11:16:43] its just the nature of having a classes hash [11:17:07] Well, OK, but if the new API works in non-obvious ways, that could lead to bugs. [11:17:36] I guess we'll see it in action soon enough. [11:17:41] we should have tests checking the effects of classes changes [11:18:00] This has only come up in one place in all of ui and tests caught it instantly [11:18:08] Oh, boy! Should we ever. That'll be a d00zy of a task getting all those tests in. [11:18:44] * gabriel_schulhof cracks his knuckles ... [11:18:51] classes it self you dont need to test [11:19:01] just test setting the other options [11:19:28] and make sure the classes on the element are correct after each option change [11:19:42] there was some talk of making an automated test for this in ui this morning [11:19:55] I assume we'll just check out your changes in UI to figure out the new api, or is there a doc/issue we can read through? [11:20:06] Well, we need to make sure that this._(add|remove|toggle)Class gets called at all the right times. That's up to the widget. [11:20:28] cgack: I think it's a lot like ._on() and ._off() [11:20:33] cgack: you can check out the pr or just ask me [11:20:48] cgack: Only the second argument is classes, not handlers. [11:20:48] Ill be doing a pr for the api docs shortly [11:21:05] the api is [11:21:20] cool, sounds good [11:21:22] Right, the API, sorry. [11:21:29] this._addClass( elements, keys, extra ) [11:21:42] this._removeClass( elements, keys, extra ) [11:21:55] this._toggleClass( elements, keys, extra, bool ) [11:22:02] elements is optional in all 3 [11:22:08] and defaults to this.element [11:22:36] keys is not optional if you are not passing any pass null [11:22:46] extra is only optional in add and remove [11:22:52] its required in toggle and so is bool [11:23:49] another thing to be mindful of [11:24:00] is we now cant change classes on one widget from another [11:24:17] with out going through that widgets classes option [11:24:47] you can also get an instance and use the methods on that [11:25:04] but we want to avoid this unless its the same widget tyoe [11:25:12] We don't have a lot of that ... custom select at most, I guess ... [11:25:13] like panel on another panel or something [11:25:22] Yeah im hoping we dont [11:25:30] the only cases in ui were radio buttons [11:25:46] and controlgroup does lots of classes option setting [11:26:27] How fortunate then that we get all that free from UI :) [11:27:59] ok unless there is something else related to classes / button lets move on [11:28:06] how about slider and rangeslider? [11:28:14] re: changing classes on another widget [11:28:41] jasperdegroot: they will have to do that [11:29:49] I just hope this isn't going to bring startup performance waaay down :/ [11:30:03] I suppose people can always pre-render. [11:30:21] it should not make a real difference [11:30:36] browsers cache re-flows [11:30:51] unless you query something requireing the dom to be re-rendered [11:31:53] and the function call overhead is minimal since we should be saving instances and its just some array itteration basicly [11:32:32] gabriel_schulhof: if you recall when the college did the tests on enhanced option it didnt make nearly as much difference as expected [11:33:17] arschmitz: It made a pretty big difference in the demos when I pre-remdered all the collapsibles in the main menu. [11:34:05] So, it starts to add up when you have, like, 30-40 widgets. [11:34:24] gabriel_schulhof: our demos are a terrible example [11:34:43] you should never be making individual pages so complex and with some many widgets on a single page in real practice [11:35:41] if you put enough of anything on a page its going to start adding up [11:36:25] arschmitz: Right, but there aren't too many ways of doing a two-level tree structure other than a UL + collapsibles, and ULs can get large fast. [11:36:36] But yeah, generally, I totally agree. [11:36:46] like our search in the demos is TERRIBLE that should be querying remote data not rending the whole thing in the dom and just hining elements [11:37:20] I guess we should make an issue, because our demos are never expected to run without Ajax, right? [11:37:33] gabriel_schulhof: as far as multi level tree structures http://jqueryui.com/menu/ [11:37:48] single widget [11:38:20] gabriel_schulhof: I think it shows a warning when you run demos without Ajax [11:39:15] gabriel_schulhof: and menu is on our list of widgets to merge next [11:39:21] because its used by selectmenu [11:40:04] ... and speaking of which: Did you get my message? It's super-easy to make UI's selectmenu alternately show a native/non-native menu! [11:40:14] gabriel_schulhof: we can switch to remote data for the search and if Ajax isn't working you won't have autocomplete but search still works [11:40:18] gabriel_schulhof: theres already a branch of that [11:40:37] gabriel_schulhof: but there are many accessability issues that are yet to be solved [11:40:40] you should look at that [11:41:18] Oh, is there? In what repo? I did a git remote update origin and I haven't found any branches that seem related. [11:41:19] The issue has never been making it "work" its making it work correctly [11:41:34] its probably on fnagles fork [11:41:41] Aaaah, OK. [11:43:18] ok lets move on to RTL [11:43:27] this has come up over and over and over again [11:43:28] arschmitz: Even if we do it in mobile to continue to support native/non-native it's gonna be at least as good as what we have now. [11:43:33] in both ui and movile [11:44:08] Right. RTL. [11:44:19] most recently its been brought up by some folks at IBM and by Ariya in chicago [11:44:21] I know: clearButton! [11:44:34] gabriel_schulhof: huh? [11:44:36] That's an RTL-sensitive widget. [11:44:43] we have many of them [11:44:48] but we dont support it at all [11:44:58] same thing in jQuery UI [11:45:05] right [11:45:14] How does one write CSS conditional on whether the locale is RTL or LTR? [11:45:20] the main problem with support in both cases is we dont have a native speaker or anyone who actually uses it [11:45:28] dir="rtl" [11:45:30] gabriel_schulhof: there is a built in css prop [11:45:38] as well as an html attribute [11:46:12] some of the works is done auto magicly by the browser when you do these [11:46:20] arschmitz: Do we actually need a native speaker? I mean, to actually implement RTL? You can just launch LANG=il_IL firefox http://localhost/path/to/jquery-mobile/demos/ & [11:46:38] but some things in widgets need to be handled [11:46:51] gabriel_schulhof: yes becaue we dont know the common issues [11:47:02] have you ever actually used rtl ? [11:47:07] Do we have any open issues? [11:47:20] no they have all been closed as feature requests [11:47:31] anyway [11:47:40] so we are going to be organizing a call [11:47:51] with people who actually use and are familier with the issues involved [11:48:03] we have pinged a few people and are waiting on responses [11:48:45] http://www.intlaqa.com/jquery-mobile-rtl/ from https://github.com/jquery/jquery-mobile/issues/5167 [11:49:08] That's from the 1.1.0 era. [11:49:27] they updated as recently as 1.4.0 [11:49:35] but there is no saying they are actually doing it right [11:49:51] but we should ping them [11:51:49] I push a branch of the enhancer module [11:52:14] its working in the demos but i need to fix some tests that look for deprecated code which is removed [11:52:27] Very, very cool! [11:53:00] https://github.com/jquery/jquery-mobile/blob/enhancer/js/widgets/enhancer.js [11:53:37] Biggest things to see here from previous gist is addition of a hooks prop [11:53:43] Oooh, do we update all our AMD modules to do that little if ( typeof define === "function" ... thing? [11:53:50] yes we do [11:53:52] OK. [11:54:09] That should render js/jquery.mobile.define.js useless. [11:54:10] that will make it so individual files can be included via script tag as well [11:54:17] yup thats the idea [11:54:17] ... or rather unnecessary. [11:55:07] so a little work needed there but you can play with it its working [11:55:44] pretty neat overall i think [11:55:58] no updates on removing the data-attribute namespace [11:56:10] Pointer events [11:56:25] Will be having our first call since the transfer next week [11:56:29] and deciding on a team lead [11:57:25] hopefully soon we will be able to pull into mobile [11:57:30] likely 1.6 [11:57:48] chassis work is continueing well lots of discussion [11:57:52] Are there any major outstanding issues with pointer-events? [11:57:59] adding tests [11:58:07] removing the polymer build system [11:58:16] *whew* [11:58:21] removing es5 stuff [11:58:38] updating the jQuery wrapper once the polyfill it self is stable [11:58:59] you can see it working in mobile already though ( ie10+ ) [11:59:05] in the polymer branch [12:00:36] ok i think we are down to things gabriel_schulhof added want to run through them? [12:01:31] Yeah, so I guess it boils down to two things. [12:02:16] If we get rid of blur-upon-change from select, we lose fixed toolbar reappearance, but we gain better support for navigating forms on iOS (#6028) [12:02:21] I mean, re-gain, [12:02:56] native or custom? [12:02:58] ... and we can also claim to have fixes https://github.com/jquery/jquery-mobile/issues/3184 (better keyboard navigation for select), because there's no way we can get type-letter-to-select-option for custom select. [12:03:05] did we already discuss deprecating hideDuringfocus? [12:03:15] arschmitz: Native. [12:03:33] jasperdegroot: we did a month or so ago [12:03:50] and decided to drop it for at least selects since its not actually possible [12:03:50] arschmitz: ... That is, the blur-upon-change is in the native select, but of course, the custom select also uses it by extension. [12:03:58] Yeah. [12:03:59] right [12:04:22] So, I made two fixes. [12:05:02] One (#7902) fixes the way the fixed toolbar implements hide() and show(), because they can interfere with each other, if one animation is started before the other completes. [12:05:18] The other fix (#7903) remove the blur-upon-change. [12:06:02] removes [12:06:44] So, I guess https://github.com/jquery/jquery-mobile/issues/7903 removes support for hideDuringFocus in the case of a select. [12:06:48] gabriel_schulhof: the blur upon change whats the original motivitaiton? [12:07:01] arschmitz: To inform the fixed toolbar that it is time to show itself again. [12:07:18] arschmitz: It was assumed that, if the select has changed, the user was done interacting with it. [12:07:20] ok yeah that does not seem like a valid use at all [12:07:26] arschmitz: Which is, of course, not true in the case of multiple selects. [12:07:58] yup [12:08:07] ... and if you recall, the blur-upon-change also uncovered that nasty iOS crash :) [12:08:08] Yeah that logic is not correct for sure [12:08:13] yup [12:08:21] gabriel_schulhof: ok so this makes sense [12:08:30] Yep. [12:08:31] i did have some comments on those pr's already i believe [12:08:48] mostly about there being no tests i think [12:09:20] Right. I guess I have to add some. [12:09:34] gabriel_schulhof: i reviewed all but one of your pr's [12:09:40] the build one i didnt get to [12:10:12] arschmitz: I'm not sure what I can test with the blur-upon-focus removal. I mean, should I test that the select continues to have the focus? [12:10:30] gabriel_schulhof: comment on the pr and il lthink about it [12:10:41] anyone have anything else to discuss? [12:10:47] we are running late [12:11:29] we could consider using a media query to make a fixed toolbar position absolute when the viewport is less than a certain amount of pixels [12:11:56] jasperdegroot: pretty sure the keyboard does not change the view port size [12:11:59] when the keyboard pops up the viewport height changes [12:12:05] on Android it does [12:12:16] but we can look into this and discuss another time [12:12:20] ok on ios i dont"think" it does but could be wrong [12:12:31] I am not sure about iOS either [12:12:46] arschmitz: Actually, the appearance of the keyboard does cause resize events. [12:12:58] arschmitz: It used to be only on iOS, but now it's happening on Android too. [12:13:03] ok [12:13:16] It's throwing the popup repositioning logic out of whack when a popup contains a textinput. [12:13:37] this actually might make more sense for hiding logic [12:13:39] And the worst is, it resizes from x times y to x times y :/ [12:13:47] yeah [12:13:52] we could listen for throtteled resize [12:14:00] arschmitz: Doesn't help. I've tried. [12:14:04] and if the viewport has changed based on some heuristic [12:14:11] hide [12:14:22] like if the width has not changed [12:14:22] arschmitz: There can be a huge break between two resize events, because the browser is busy re-rendering :( [12:14:32] arschmitz: I'm already doing that. [12:14:42] arschmitz: Sometimes it changes by one pixel. [12:14:45] It's terrible. [12:14:55] and the hight gets smaller by > 100px hide toolbar [12:15:07] if it gets bigger show toolbar [12:15:35] gabriel_schulhof: thoughts? then we dont listen for focus or blur at all [12:15:42] I suppose we could study the problem ad nauseam and come up with a good heuristic ... and then the next version of breaks it again. [12:16:01] gabriel_schulhof: well we just need to find the smallest popup keyboard we can [12:16:10] and make it like 30 px smaller for the change amoutnt [12:16:24] arschmitz: Well, sometimes the virtual keyboard does not cause a resize, because it appears "above" the browser window. Yet the area that's effectively visible is much smaller. [12:16:48] gabriel_schulhof: thats what i asked about you said that the viewport changes? [12:17:07] arschmitz: It appears to change, but the difference is at most, like 1px of height. [12:17:18] arschmitz: The browser fires unnecessary resize events. [12:17:24] ok well thats nor actually getting smaller [12:17:31] Yes, exactly. [12:17:35] i was asking if the view port actually gets smaller by the size of the keyboard [12:17:52] No. [12:17:55] ok [12:18:07] arschmitz: OK. To be clear. [12:18:10] then thats not usefull [12:18:23] The user sees a substantially smaller portion of the window when the keyboard is up. [12:18:30] However, the window is not actually resized. [12:18:32] right im not concenred with what they see [12:18:38] im concenred with the viewport sizr [12:18:40] size [12:18:51] That does not change. [12:18:52] ( not guranteed to be the same ) [12:19:00] ok [12:19:07] lets move this to the issue [12:19:25] but personally im inclined to remove all hide on focus logic [12:19:28] regardless of the element [12:19:45] and maybe show how to add yourself for your specific use case [12:20:02] That does not change. [12:20:10] WTF?! [12:20:14] That's not what I wrote. [12:20:17] Weird. [12:20:19] lol [12:20:26] huh? [12:20:30] I meant to say +1, because it should be done per-application. [12:20:46] ITs very possible to do right depending on your use case [12:20:47] arschmitz: I accidentally pasted an earlier response of mine: "That does not change." [12:20:51] but its not possible in general [12:20:55] oh ok [12:20:56] Exactly. [12:21:14] these are cases we should just not support [12:21:25] as a library if we cant make it work consistent we should not do it [12:21:30] arschmitz: Do you want me to yank the hideDuringFocus logic? [12:21:41] arschmitz: We can keep the option around but it will have no effect. [12:21:44] put it in the issue and let it sit a few days [12:21:48] see if any one freaks out [12:21:58] OK. [12:22:17] Well, wait a sec ... which issue? [12:22:32] https://github.com/jquery/jquery-mobile/issues/6028 is about the select losing focus in iOS. [12:22:39] ... and https://github.com/jquery/jquery-mobile/issues/3184 is also about the select. [12:22:54] I have another call... later all [12:23:09] OK. I'll re-open https://github.com/jquery/jquery-mobile/issues/5514 and I'll put it there, and the fix will be to remove the logic. [12:23:27] gabriel_schulhof: that souns good [12:23:34] jasperdegroot: ok thanks i think we are done anyway [12:25:22] anything from the community? [12:26:52] ok see everyone back in -dev