[11:01:57] Hi Everyone! [11:02:00] <_|Nix|_> Yo ho ho and a barrel of grog! [11:02:02] hey gseguin [11:02:09] hey all [11:02:13] hi [11:02:18] hi [11:03:18] The jQuery Mobile team meeting is starting up [11:03:23] agenda: https://docs.google.com/document/d/1mv2TYnavN_pehG802dso46T3Ww0t_qb5IDvPDfcxFBU/edit# [11:03:39] 1.3.1 released yesterday with close to 50 fixes and improvements - http://jquerymobile.com/blog/2013/04/10/announcing-jquery-mobile-1-3-1/ [11:03:42] w00t [11:03:51] focused on 1.4 now [11:04:17] Team is focused on 1.4.0: re-factoring, performance, theming [11:04:24] <_|Nix|_> Niceness! [11:04:36] yep [11:05:16] how goes on the widget perf front - _|Nix|_ and arschmitz [11:05:34] really good! [11:05:54] we found some places to make some big gain on widget nit speed [11:06:24] that's great [11:06:51] _|Nix|_'s change is already in [11:06:58] and mine will be after the meeting [11:07:02] saw that, cool [11:07:25] can't wait to see how much faster we can get things [11:07:32] for sure! [11:07:42] <_|Nix|_> toddmparker: I think pages like the form widgets page will see a big boost. [11:07:56] for folks who are still going to use attr config, do you think we can speed that up even more? [11:08:04] _|Nix|_: great [11:08:07] things for the last week have been very focused around optiosn [11:08:12] <_|Nix|_> toddmparker: I'm trying to write a util for creating a new window repeatedly and loading a given page therein, and then recording window.performance.timing data. [11:08:22] nice [11:08:37] well _|Nix|_ change already speeds that up by ~70% [11:08:46] arschmitz: can you edit the agenda doc? [11:08:52] holy [11:08:53] here! [11:08:55] no i cant get to it for some reason [11:09:24] <_|Nix|_> uGoMobi: Yeah, .jqmData was really hurting us in _getCreateOptions in $.mobile.widget ... [11:09:47] arschmitz, _|Nix|_: how are you guys profiling widget init and such? [11:09:58] <_|Nix|_> paul_irish: jsperf.com [11:10:16] paul_irish: we have a perf branch with benchmark.js setup in there [11:10:16] <_|Nix|_> paul_irish: We can create a custom build of the lib containing only the widget. [11:10:29] paul_irish: but it's not merged [11:10:45] kay. i could walk through a few of the instantiations with you in devtools timeline.. it would reveal if we have layout thrashing or heavy recalc styles [11:10:52] _|Nix|_: arschmitz: should I merge that so we can keep track of perf tests as tests? [11:10:53] <_|Nix|_> paul_irish: Then, copy the improved widget definition and call that something else, like mobile.widgetname2 [11:10:57] things that jsperf may not be telling you :) [11:11:01] that would be great paul_irish [11:11:04] nice [11:11:12] paul_irish: yes please [11:11:17] yeah would love to [11:11:26] just name a time [11:12:34] yeah ill make my self available any time [11:13:15] we're really focused on perf for 1.4 so that would be great [11:13:31] arschmitz: i can paste stuff into the agenda [11:14:37] ok, sounds like good headway on that stuff arschmitz and _|Nix|_ [11:14:52] gseguin: what are you up to? [11:15:05] Fixing all the things [11:15:07] there is one options related change we want to discuss in here today whenever too [11:15:22] ok arschmitz [11:15:24] I fixed the builder crash [11:15:31] nice [11:15:46] gseguin - What can we do to prevent all those issues with the Demo Center in the zip and on view [11:15:49] but there is still something going on [11:15:55] now that we have more time [11:16:56] toddmparker: when we test we need to test against the build version [11:17:11] true [11:17:13] so you `grunt dist` and then point your browser at dist [11:17:36] ok, good call [11:18:01] so yeah will be looking into the builder hang later today [11:18:07] I linted all the files [11:18:18] to comply with the new .jshintrc [11:18:24] cool, so you added that? [11:18:42] not yet I was running the tests and got a couple failures [11:18:50] gseguin: but how come that 1.3.0 has .php files on .view but 1.3.1 has .html files? [11:18:55] will look into them then fix and push [11:19:20] uGoMobi: because the 1.3.0/index.php probably does not redirect to dist [11:19:58] I added a meta refresh in 1.3.1/index.php to redirect to 1.3.1/dist/ [11:20:13] why do we need that? [11:20:15] we need to find a way to automate that [11:20:30] uGoMobi: because otherwise it opens the dev version [11:21:23] when we push a semver tag, view checks out that tag into the directory of the same name and runs `grunt` [11:21:48] problem is that AJAX nav doesn't work in dist [11:21:54] example: http://view.jquerymobile.com/1.3.1/dist/demos/examples/swipe/newyork.html [11:22:13] right [11:22:18] how come? [11:22:29] gseguin: file:// [11:22:31] seems like we need to review the build stuff [11:23:18] I can look into that next [11:23:25] ok, thanks gseguin [11:23:40] now that we're not under the gun, be good to figure that out [11:23:52] last thing is after I push the lint changes [11:24:04] I'll add lint to test target [11:24:14] so CI build will fail for lint problems [11:24:23] great [11:24:37] nice [11:24:54] we still need to fix the unstable tests [11:25:01] that's it for me [11:25:09] thanks [11:25:23] arschmitz: if your question something we should discuss here or on dev? [11:25:29] here [11:25:34] ok, shoot [11:25:47] _|Nix|_ and i were discussing options [11:26:07] and we want to move the initSelector out of options and directly onto the widget prototype [11:26:23] because its not an option it cant be changed per widget or within the life of a widget [11:26:36] it can only be set via the prototype durring mobile init [11:27:18] hmm [11:27:27] there was a branch for that aready, right? [11:27:34] not that i know of [11:27:42] _|Nix|_: arschmitz: why isn't it an option? [11:27:51] changing it wont do anything [11:27:53] https://github.com/jquery/jquery-mobile/tree/4974-move-non-option-constants-to-defaults-object [11:27:53] <_|Nix|_> johnbender: It's useless as an option. [11:28:01] its only refrenced in the autoinit [11:28:17] <_|Nix|_> johnbender: You cannot affect an instance of a widget by changing the initSelector. [11:28:19] arschmitz: doesn't it determine which dom elements are enhanced for the widget? [11:28:23] yes [11:28:34] but that will only do anything durring mobile init [11:28:40] right [11:28:43] <_|Nix|_> johnbender: Yes, but when it's part of the prototype, it gets copied over to every instance. [11:28:43] otherwise its too late [11:28:45] that's the convention the library follows [11:28:47] <_|Nix|_> johnbender: What good is that? [11:29:05] if we put it directly on the widgetprototype it makes more sense [11:29:23] arschmitz: I'm asking why though [11:29:32] <_|Nix|_> arschmitz: Actually, let's be clear: I prefer $.mobile.widgetname.initSelector, not $.mobile.widgetname.prototype.initSelector. [11:29:32] it would still work the same just be widgetname.initSelector instead of widgetname.options.initselector [11:29:37] namespacing it provides semantic informaiton [11:29:53] <_|Nix|_> johnbender: We keep the namespace: $.mobile.widgetname.initSelector. [11:30:05] _|Nix|_: I meant .options [11:30:12] johnbender because options are suposed to be things you can change to effect the widget [11:30:21] although looking at it there makes sense to me [11:30:33] changing initselector via options wont ever do anuthing [11:30:37] <_|Nix|_> johnbender: There is absolutely no point copying the value of initSelector from widget to widget to widget, because it will never be set on any widget instance. [11:30:38] arschmitz: how is initSelector not something that you change to affect the widget o.O [11:30:53] <_|Nix|_> johnbender: It doesn't affect the widget at all. [11:30:56] because initselector effect what becomes a widget [11:30:57] _|Nix|_: I'm not sure what that means [11:30:59] not the widget itself [11:31:24] <_|Nix|_> initSelector is a class-level configuration setting, not an instance-level setting. [11:31:31] arschmitz: agree [11:31:31] if you do widgetname("option","initselector","newname") what exactly would that do? [11:31:33] <_|Nix|_> Therefore it has no place in the instance. [11:31:53] it should do anything because the widget already exists [11:31:57] <_|Nix|_> initSelector is class metadata. [11:32:43] i can see that argument [11:32:49] <_|Nix|_> If you have 59 buttons on a page, they each get a copy of initSelector, because it's in the prototype. It will never, ever be modified except in one place: the prototype. [11:32:55] _|Nix|_: arschmitz: it sounds like this is something we need to do for more than just initSelector [11:33:10] <_|Nix|_> johnbender: Yes. Defaults. [11:33:15] https://docs.google.com/document/d/1n7ozvhQTLhBj6sPR-LYxuev3p8kcbHjlAM8EBMlQ8GE/edit [11:33:27] _|Nix|_: arschmitz: how do UI handle it? Defaults? [11:33:38] it's really info that we need for triggering the auto enhancement via markup, not and option you can set each time you call the widget [11:33:55] <_|Nix|_> toddmparker: Exactly. Class metadata. [11:33:58] UI may not, they don't offer markup config [11:33:59] in the widget factory ui does not do auto enhancement [11:34:13] but i'm sure scott_gonzalez would have a solid perspective on this [11:34:34] toddmparker: good idea [11:34:37] arschmitz: right but I'm curious if they have a segregation between the widget config/ instance config [11:34:44] <_|Nix|_> I believe in the beginning we were far to liberal with the things we put in options. Now we suffer the consequences. [11:34:49] which is what you guys are proposing [11:35:07] im not sure they handle widget config in that way anywhere that i know of [11:35:12] <_|Nix|_> johnbender: They don't have much class config. [11:35:44] <_|Nix|_> johnbender: They merely declare a widget class with $.widget and it's up to you to call the corresponding jQuery plugin to instantiate a widget whenever you want. [11:35:56] _|Nix|_: they have defaults don [11:35:59] 't they? [11:36:10] <_|Nix|_> johnbender: I don't think so. They only have options. [11:36:39] they have defaults for each option [11:36:40] _|Nix|_: arschmitz: seems to make sense, do we document initSelector? [11:36:54] cause we'll need to deprecate / default [11:36:55] <_|Nix|_> johnbender: Extensively, I believe. [11:37:04] otherwise seems sound to me [11:37:08] yeah we will need to document that its being moved [11:37:10] right, the API breakage is an important factor [11:37:18] <_|Nix|_> I have a tricky proposition. [11:37:34] <_|Nix|_> It doesn't work on OldIE, but it will work everywhere else. [11:37:41] ?? [11:38:03] <_|Nix|_> We could create a pair of accessors that basically get/set initSelector from the new location when one attempts to access initSelector at its old location. [11:38:09] <_|Nix|_> It's kinda like a symlink. [11:38:29] <_|Nix|_> ln -s $.mobile.widgetname.initSelector $.mobile.widgetname.prototype.options.initSelector [11:39:07] if we do this, might be an interesting idea [11:39:43] my question is whether this offers much upside vs. other thing we could do for 1.4, even if we agree that an option may not be ideal [11:40:03] along these same lines we talked about moving things that are able to be set per widget but that cant be changed durring the life of a widget [11:40:10] <_|Nix|_> toddmparker: We have to do it at some point, and it will never offer too much of an upside. [11:40:15] i'd suggest we log this as a dev task for a future release [11:40:18] toddmparker this is more just about logical organization [11:40:25] sure, i get that [11:40:29] its almost no effort [11:40:41] it involves chaning two lines in each widget [11:41:00] <_|Nix|_> Let's not forget that initSelector is getting copied to every single instance of a widget on a page, for absolutely no reason. [11:41:56] <_|Nix|_> Now, in reality that may not be a big memory penalty, because the underlying JS engine is almost certainly copy-on-write, and initSelector will never be overwritten once copied. [11:42:21] if you guys want to try and hit this for 1.4, fine with me. be good to discuss this with scott_gonzalez to make sure that if we make this move, it aligns with UI's thinking too [11:42:35] for sure [11:42:42] and to make sure johnbender et. al don't disagree [11:42:47] i already reached out to him hes not around right this sec though [11:42:53] think we can discuss more in -dev [11:42:59] thanks [11:43:04] <_|Nix|_> arschmitz: One thing to check with UI is how they feel about adding stuff to the widget's constructor. [11:43:19] +1 [11:43:23] yeah they do it in a bunch of their widgets [11:43:28] I'm for it if the overhead is so low [11:43:28] but still good to check [11:43:30] <_|Nix|_> arschmitz: OK, good. [11:43:56] <_|Nix|_> I dunno how we'd handle the deprecation process. [11:44:13] <_|Nix|_> I suppose we could add a check for both locations for one version. [11:44:21] that was my thought [11:44:29] <_|Nix|_> Although they would get out of sync ... [11:44:32] add a comment remove in 1.5 [11:44:55] or create a PR for 1.5 right away [11:44:59] <_|Nix|_> arschmitz: I think prototype should take precedence over constructor, because that's an indication that someone has modified it using legacy code. [11:45:15] i agree [11:45:18] <_|Nix|_> arschmitz: ... at least for the deprecation period. [11:45:27] yes that was what i was thinking also [11:45:54] <_|Nix|_> OK. I'm good with this plan. [11:46:18] cool [11:46:39] johnbender: anything to discuss? [11:46:58] saw you landed static base tag [11:47:01] woot [11:47:21] toddmparker: nope, just keep an eye on that [11:47:36] it's minor code wise but it could cause ugly issues [11:47:55] yep, good to live with it for a while [11:48:36] ok, if that's it uGoMobi - yours [11:48:58] have been hacking on theming [11:49:05] created branch "next" [11:49:12] yeah, i want to do a hangout right after this to review [11:49:16] https://github.com/jquery/jquery-mobile/commits/next [11:49:34] reduced default theme to 2 swatches, set all options “*theme” to “a”, pseudo classes for button states, active and focus state themeable, etc. as a starting point [11:50:00] also created a few basic test pages so we can see what we broke :) [11:50:22] yeah, good to do a hangout [11:50:47] we have to make decisions about how theme inheritance should work and what we do with icons [11:51:09] <_|Nix|_> uGoMobi: How close are we to dropping the H-bomb on buttonMarkup? [11:51:31] _|Nix|_: I didn't touch buttonMarkup itself much [11:51:46] first I made theme.css independent from it [11:52:01] <_|Nix|_> uGoMobi: I'm just asking if you have a sense of how much we need to do in JS. [11:52:10] so we still at button state classes but don't use them in theme CSS and they are ready for removal [11:52:29] <_|Nix|_> uGoMobi: Nice! [11:52:35] next step would be going to all widgets and remove calls to buttonMarkup [11:52:41] then you can drop the bomb :) [11:52:49] s/to/thru/ [11:53:17] <_|Nix|_> uGoMobi: We can $.fn.buttonMarkup = $.noop ... [11:53:21] <_|Nix|_> uGoMobi: To test ... [11:53:48] _|Nix|_: as soon a we don't wrap in ui-btn-inner and -test anymore all widgets will be broken at once [11:53:51] yeah, we can remove a fair amount of markup stuff [11:53:56] see how far we can go [11:54:25] so I thought it might be better to just remove calls to buttonMarkup each widget at the time [11:54:52] right [11:55:11] remove the need to use buttonMarkup one step at a time [11:55:19] yes [11:55:33] <_|Nix|_> uGoMobi: Actually, I looked at the code and we don't select for .ui-btn-inner and .ui-btn-text in a lot of places. [11:55:35] +1 [11:55:44] ok, so we can talk about that stuff in a few [11:55:56] <_|Nix|_> I'll probably listen in as well. [11:56:04] ok [11:56:07] _|Nix|_: all buttons have ui-btn-onner [11:56:11] inner* [11:56:13] i'll post a hangout link [11:56:17] okay [11:56:26] one more thing [11:56:30] sure [11:56:35] tj_vantoll asked us to give feedback on Widget Factory Classes option: http://wiki.jqueryui.com/w/page/65050459/Classes%20Option [11:56:47] yeah, let's discuss that too [11:57:03] ok that's it [11:57:06] Hey guess, you have questions for me? [11:57:20] hey scott_gonzalez [11:57:53] yeah scott_gonzalez - we want to pick your brain on dev in a bit if that's ok [11:58:08] sure [11:58:13] cool [11:58:16] <_|Nix|_> Thanks! [11:58:26] anyone else have an update or questions? [11:59:07] <_|Nix|_> An observation: If we get rid of the inner buttonMarkup divs, a lot of people's code will break. [11:59:25] <_|Nix|_> Although we never promised them .ui-btn-inner and .ui-btn-text ... [11:59:34] i think that's the big debate - can we progress without making huge breaking changes [11:59:52] at what point does this need to be a 2.0 [12:00:03] <_|Nix|_> Alright. Let's save some of that for the hangout. [12:00:10] feel like inner stuff is less scary [12:00:12] yeah [12:00:36] ok, any Q's from the community before we wrap? [12:01:50] [ crickets ] [12:01:56] ok, thanks everyone. [12:01:59] <_|Nix|_> *tumbleweeds* [12:02:13] <_|Nix|_> L8R [12:02:19] later [12:05:05] by a all