[11:01:49] I bid y'all good "${PART_OF_DAY}"! [11:01:57] agcolom: cgack: gabriel_schulhof: ianmaffett: sfrisk: Meeting time [11:02:10] jasperdegroot: [11:02:17] howdy [11:02:25] hello [11:02:27] at board meeting, so cannot join today [11:02:31] howdy [11:02:46] agcolom: thats fine i was just doing it for completeness [11:04:17] we can use https://coloma.users.ecs.westminster.ac.uk/jqueryStats/mobileIssues.php to track open issues (issues + PRs) in all jQM-related repos (tracking only since sunday) [11:04:44] agenda https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdG5nSmZiSUhjYm4ya29CdjhLZmJwSWc&usp=drive_web#gid=57 [11:04:57] agcolom: Login required [11:05:13] shame sorry [11:05:28] I thought that got opened up [11:06:02] i'll need to reach out to the work infra guys [11:06:08] I saw it the other day [11:06:10] its pretty awesome [11:08:43] Ok so 1.5 [11:08:51] classes continues [11:09:26] implementation on new api is about 3/4 done but found some issues that had to be addressed [11:09:40] nothing major just took some time [11:10:21] Also sfrisk chimed in on button agreeing on floats for controlgroups vs inline block and i have no opinion so will be changing that [11:10:37] chimed in agreeing with jasperdegroot that is [11:11:08] arschmitz: you can pick the CSS from 1.5-button-css-and-demos [11:11:34] jasperdegroot: we wil lstil ldo double border [11:11:48] arschmitz: ok, then you have to delete that part :) [11:11:50] just switching to floats [11:12:28] i think thats it on the ui side of things [11:12:28] So, cgack will take over exactly what? [11:12:36] huh? [11:12:43] oh thats old i have not hcnaged it yet [11:12:48] gabriel_schulhof: that was from ages ago [11:12:49] its just from the cheet i copied [11:13:13] Oh, OK. Was just wondering. [11:14:14] Well, "all updates from ui pulled in" is also out-of-date, right? [11:14:21] yes fixing right now [11:14:23] OK. [11:15:42] ok anything else about updates for 1.5 i know we are kinda stalled there waiting on ui [11:15:58] arschmitz: shall we pull https://github.com/jquery/jquery-mobile/pull/7846 into ui-1-12 branch/ [11:15:59] ? [11:16:18] jasperdegroot: im going to do it when i pull in the ui updates i think [11:16:28] arschmitz: ok, sounds good [11:16:39] arschmitz: I guess the touch events split-up? [11:16:40] so i can properly rebase everything easily [11:16:45] I suppose that'll go into 1.5.0. [11:16:51] gabriel_schulhof: yes [11:16:56] I'm working on that. [11:17:08] I've made good progress, but I'd like to separate out the tests. [11:17:13] ok want to add that [11:17:24] ... and I may need a place to put shared code, like triggerCustomEvent() [11:17:35] I can't use $.mobile, because events are independent of the mobile ns. [11:17:42] I'll add it. [11:17:42] yup [11:17:59] ok is there anything to discuss on that or your just working on it? [11:18:25] Well, I could use some ideas as to where to put stuff that's common. [11:18:34] $.event._privateStuff? [11:18:42] $.event._mobilePrivateStuff? [11:18:43] why dont you work on a pr so its easier to see what your talking about [11:18:45] I dunno. [11:18:51] arschmitz: OK. [11:18:55] I'll do a PR. [11:18:59] and once we have code to look at its easier to put in context for a discussion [11:19:31] speaking of touch [11:19:51] the pointer events poly fill is officially now home with the jQuery foundation [11:20:06] https://github.com/jquery/PointerEvents [11:20:37] cool [11:20:50] and in related news PointerEvents became a Proposed Recommendation at the W3C yesterday. [11:21:08] about time! [11:21:11] * gabriel_schulhof queues marching band music [11:21:22] well not yesterday tuesday but close enough [11:21:24] Ha! Despite Google, I guess. [11:21:45] they never said it should not be a spec [11:21:50] in fact they helped draft it [11:22:03] and they didnt pull out of the working group [11:22:13] they just chose not to implement [11:22:22] Riiiight ... O_o [11:23:08] So 1.6 we will hopefully be using pointer events!! [11:23:32] awesome [11:23:35] I also finally got back to autoinit this week [11:23:41] *whew* ... will we ship the polyfill inline? [11:23:47] gabriel_schulhof: yes [11:24:03] it will be a hard dependency like core [11:24:11] arschmitz: Ummm ... what about making it download-builder-excludable? [11:24:12] will more like ui-core [11:24:33] I guess it short-circuits itself if there's a native implementation, right? Still, the size ... [11:24:37] yeah we will have a way to do that [11:25:01] but since almost no enviroment can exclude it [11:25:15] only ie has pointer events and only mobile or 10+ [11:25:22] Right. Nice :) [11:25:43] so its pretty much required lol [11:26:02] arschmitz: Do you know what Mozilla's gonna do about it? [11:26:12] they are implementing [11:26:14] 100% [11:26:30] they implementation fully passes the wc3 test squite already [11:26:36] but its not in most builds right now [11:26:45] Cool! [11:27:08] microsoft open tech contributed most of it [11:27:30] Wow! That's ... just ... wow! [11:27:47] Must've been all those cakes the Mozilla guys sent the IE guys :) [11:27:59] :) [11:28:15] so auto init related things [11:28:23] nojs is not documented at all [11:28:31] so its going to be removed [11:28:43] its pointless [11:28:53] Yeah, we already have a mechanism for that. [11:29:09] since we never documented and its exactly the same as data-role none execpt it also makes it display none [11:29:21] by adding ui-nojs [11:29:29] which you could still do your self [11:29:55] since this is crazy and undocumented i think we just remove it [11:30:28] on the lines of crazy [11:30:46] does anyone think we should actually have degradeinputs any more? [11:31:17] Well, we need something for slider, otherwise we'll have a native slider next to a bunch of divs that look (much better) like a slider. [11:31:29] Same for search input, IIRC. [11:31:36] no just tell people to use input type=number [11:31:40] or type=text [11:31:57] OK, but what about backcompat? [11:32:01] replacing an element is very destructive [11:32:11] Yeah, agreed. It's a very bad way of doing it. [11:32:45] I suppose it's OK for backcompat to have a native slider next to a non-native one. [11:32:46] backcompat we just deprecate it and remove the next version? [11:32:48] I mean, it works. [11:32:58] ... and it provides a **strong** incentive to move forward :) [11:33:00] there is no backcompat issue? [11:33:06] gabriel_schulhof: that would never happen? [11:33:20] how would you get that case? [11:33:32] arschmitz: By having an input type range turn into a jQM slider. [11:33:49] input type range gets rendered natively as a slider, but now it has a jQM slider next to it. [11:33:52] right for 1.5 we wuld still have degrade inputs [11:33:57] so there is backcompat there [11:34:12] Yeah, OK. Just declare it as deprecated. [11:34:25] and in 1.6 that could happen happen but you would then not be following the published api [11:35:22] for 1.5 we can factor this out into a wrapper on enhance [11:35:31] which is also how we will handle popup links [11:36:22] arschmitz: Right, but please make the enhancer itself such that it doesn't unconditionally assign $.fn.enhance [11:36:38] gabriel_schulhof: yes that wont be an issue [11:36:41] OK. Good. [11:36:51] last auto init thing is keepNative [11:36:59] we already talked about deprecating this [11:37:07] just want to confirm everyone is ok with that [11:37:14] +1 [11:37:45] between setting individual initselectors and the ability to create an initselector generator i see no need for this [11:37:50] OK, so modifying initSelectors is the future way of preventing unwanted widget init, right? [11:38:00] yes [11:38:09] the one and only way [11:38:12] arschmitz: ... and people can shim the enhancer, because they can control the load order for their project. [11:38:17] deprecate all others [11:38:31] arschmitz: ... but we need not endorse this latter approach. [11:38:41] gabriel_schulhof: there is also an initselector generator in the enhancer [11:39:44] gabriel_schulhof: https://gist.github.com/arschmitz/47610f7fd7bf2d9fb2d5#file-enhancer-js-L31 [11:40:45] Aaah, OK, so we no longer inflict initSelectors on unsuspecting widgets upon definition, right? [11:41:01] no of course we do [11:41:07] autoinit would not work if we didnt [11:41:41] Well, no. We do not set initSelector, but we look for it to see if it's present. [11:41:56] oh yeah we dont add it to the prototype you mean/ [11:42:03] Yeah, that's what I mean. [11:42:26] ... and so, the initGenerator can become a sort of hash of custom initSelectors. [11:42:40] it can be what ever you want it to [11:42:54] it just needs to return a valid selector [11:42:55] That's an offer one can't refuse. [11:43:21] so you could do .auto-widgetname [11:43:33] for better perf if you wanted instead of attributes [11:43:47] since selectors are much faster [11:43:53] class selectors* [11:43:55] Yeah, for sure. [11:45:17] anyway this got me thinking about our removing the data-attribute namespace [11:45:51] the back compat for this is a little ugly when it comes to selectors [11:46:32] there will be a big perf hit if people dont switch to using data-ui- [11:46:38] to make backcompat work [11:46:56] its also going to litter the code with conditionals about the length of the return [11:47:04] ... and the initGenerator does not allow one to do the two-step query process. [11:47:19] it will have to be modified for 1.5 [11:47:22] to allow it [11:47:30] Yeah. [11:47:31] in the actual enhance function [11:47:56] it will check the return and check a backcompat one [11:48:12] So, the enhancer will be owned by jQM? [11:48:27] no [11:48:39] it will check if $.mobile.ns exists just for one version [11:48:46] and if it does do the fallback [11:49:12] So, where will the enhancer be? external/? [11:49:27] no its part of the jqm repo if thats what you mean [11:49:36] Yeah, that's what I meant. OK. [11:49:41] it will be in js/widgets/ [11:49:52] even though its not a widget it only works on widgets so seems right [11:50:02] Yeah. [11:50:21] It will be of no lesser value to UI for the extra check. [11:50:47] ... because UI will be seeing data-attributes for the first time, so they can start out without any backcompat, going straight to data-ui-* [11:50:56] yes [11:51:16] ok and last thing [11:51:21] Chassis [11:51:34] sfrisk and i met with Yandex on tuesday [11:51:51] and its now looking very likely we will go with a BEM naming convention [11:52:28] nice [11:52:30] its actually very very similar to what we do now just a formalized version using sass [11:52:45] Wasn't there an issue with having lots of rules in that case? [11:52:46] basicly what we have right now in theme.css and in core.css [11:52:58] lots of selectors [11:53:02] will become extends on the other structure classes [11:53:24] its actually not bad depending on how you do it [11:53:39] basicly we already do [11:53:48] Does it positively affect the DOM structure design choices you make? [11:53:58] it just takes some time to get used to it [11:54:00] indifferent [11:54:09] basicly we already do it very close [11:54:22] so right now we have classes like ui-menu-item-heading-icon [11:54:48] they would have ui-menu--item--heading__icon [11:55:05] and not add ui-shadow or ui-corner or things like that [11:55:15] because they would be part fo that already [11:55:23] and the whole -- __ is optional [11:55:28] thats just what they like [11:56:01] OK, but again, with the use of automated CSS generation tools, we should carefully watch their output before a release. [11:56:21] gabriel_schulhof: sass is not a new thing [11:56:40] gabriel_schulhof: we should carefully test [11:56:51] the output is very accurate [11:57:12] what exactly do you propose testing"/ [11:57:14] ? [11:57:33] Yeah, I'm more concerned about performance than correctness. [11:57:53] well performance is a completely seperate thing then what you said [11:57:54] arschmitz: just mean testing if widgets are enhanced as they are supposed to be [11:58:18] jasperdegroot: well that has nothing to do with sass? thats just making sure if we have a new theme we properly implement it? [11:58:25] I don't think we will go over all processed css before a release [11:58:27] arschmitz: I meant that the tool may generate unnecessarily complex CSS resulting in lower performance. [11:58:35] Or a larger CSS file. [11:58:49] gabriel_schulhof: thats not an issue [11:58:51] Although I guess gzip can take care of that. [11:58:55] there are unit tests for both [11:58:59] just like we have test [11:59:03] arschmitz: right, what I mean is that sass doesn't make a difference [11:59:22] exactly [11:59:29] gabriel_schulhof: there are both rendering performance tests [11:59:36] and gzip comparison [11:59:49] Very nice! [12:00:00] and bem done properly is has the smallest file size by far [12:00:18] topcoat the only big framework implementing it current acheives better compression then any other framework [12:00:22] by a large factor [12:00:37] because its all about repeted strings which bem takes full advantage of [12:00:49] when done properly [12:01:22] but this is not really the right place for these sort of discussions [12:01:27] thats tuesdays at 1pm [12:02:04] i think thats everything on the agenda for this week i think does any one have anything else? [12:02:23] when is next meeting? [12:02:30] next week is Chrismas [12:02:39] then newyears [12:02:40] week after New Year's Day, right? [12:02:43] Yep. [12:02:49] Both holidays up here. [12:02:51] no for sure on christmas [12:03:09] I'm out on New Year's Day, too. [12:03:11] we can see whos around on new years if people are we will have on if not week after [12:03:18] ok [12:04:02] Sounds good! [12:04:09] ok thanks see everyone back in -dev [12:04:14] later [12:04:16] bye! [12:04:18] Well, I guess nothin' but Merry Christmas and a Happy New Year, right?