[11:06:22] Hi all [11:06:34] The jQuery Mobile meeting is starting up in a minute [11:07:10] hey [11:08:29] hiiiii [11:08:32] :) [11:08:45] agenda here: https://docs.google.com/document/d/1qfUJRXkfpyCQLwjIW-1c3ukVrKXRI8F6BhH1TKLl5Iw/edit# [11:08:59] toddmparker: we were going to have a face to face discussion [11:09:01] :D [11:09:12] <_|Nix|_> Yo! [11:11:49] hey-o [11:12:01] So we're in full 1.4 mode right now [11:12:23] on the theming side [11:12:39] uGoMobi met with Scott, Mat and I last week [11:13:13] uGoMobi has started work on the Markup & style simplification in the "next" branch [11:13:31] cool! [11:14:17] <_|Nix|_> +1 ... getting rid of buttonMarkup would be an insane win. [11:15:16] uGoMobi: think that's looking possible? [11:15:44] yeah I think it should be possible [11:15:53] there might be few exceptions [11:16:18] but then we can move it to the widget itself [11:16:45] like if we still need to wrap an input type button [11:16:58] <_|Nix|_> uGoMobi: That's already in the widget. [11:17:07] yeah? [11:17:08] <_|Nix|_> uGoMobi: Only the widget calls .buttonMarkup on the wrapper. [11:17:16] i see [11:17:17] <_|Nix|_> toddmparker: Yeah, pretty sure. [11:17:20] _|Nix|_: ah, you're right [11:17:49] <_|Nix|_> Funny thing is we should probably deprecate buttonMarkup for a version. [11:17:59] <_|Nix|_> Like, $.fn.buttonMarkup = $.noop; [11:18:15] backwards compat is still up for grabs [11:18:32] i want to see how far we can go, then decide if we stage this [11:18:38] across multiple releases [11:18:43] <_|Nix|_> toddmparker: OK. [11:18:57] for example, removing button inner is probably fine [11:19:26] but changing markup requirements may either need a backwards compat option or we need to look at versioning [11:19:35] <_|Nix|_> toddmparker: Right, but not button-text, eh, because many will have used it to replace the text. [11:19:52] <_|Nix|_> toddmparker: We never promised either. [11:20:15] <_|Nix|_> toddmparker: If people do not understand the concept of encapsulation, we are not their teachers. [11:20:16] that is the tricky thing [11:20:45] anything we do can break something [11:20:46] <_|Nix|_> The problem with the Web is there is never any real encapsulation :/ [11:20:50] but we need to walk that line [11:21:12] uGoMobi: have you tinkered much more since last week? [11:21:27] <_|Nix|_> Here's an idea. [11:21:37] <_|Nix|_> The anchor gets ui-btn-texgt. [11:21:42] <_|Nix|_> ui-btn-text [11:22:10] <_|Nix|_> Well, NM. $( "a .ui-btn-text" ) will fail :( [11:22:18] _|Nix|_: yeah, complicated [11:22:33] maybe we need to provide a hook [11:22:44] <_|Nix|_> uGoMobi: What do you mean? [11:22:56] we're also testing icon fonts vs. SVG [11:22:58] https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdEFwbzNFSmJjWUd1dkZldDY4MVFyR0E#gid=1 [11:23:09] uGoMobi: I added a tab for Grunticon and will fill that out [11:24:04] _|Nix|_: nevermind [11:24:47] _|Nix|_: people would have to wrap the text in ui-btn-text span before the framework enhance the element or something [11:24:59] <_|Nix|_> uGoMobi: Yep. [11:25:05] but you can do that at pagebeforecreate event [11:25:33] toddmparker: yeah, the font icon test page toddmparker: have been looking at font icons http://view.jquerymobile.com/next/demos/test/icons/font-icons.php [11:25:51] that's also a test of simplified markupp [11:25:55] uGoMobi: nice! [11:26:24] all the buttons there have data-role="none" [11:26:39] ah, so not enhanced [11:26:55] it's just classes on the native element [11:27:03] _|Nix|_: be cool to compare that page to a similar one in 1.3.1 [11:27:07] nice! [11:27:08] perf-wise [11:27:26] yeah, maybe better to test outside view. [11:27:41] true [11:28:02] although that shouldn't mater for JS [11:28:06] be cool to have a jsbin set up to use the next css and js links [11:28:26] on lists, can you add ui-btn-a to the UL instead of the LI's? [11:28:36] same for some of those other classes too [11:28:54] toddmparker: yeah [11:28:56] <_|Nix|_> toddmparker: I don't even know how to compare that. No JS vs. some JS ... [11:29:03] heh [11:29:08] <_|Nix|_> toddmparker: Maybe with window.performance ... [11:29:11] that works fine, but would have to add few more selectors [11:29:18] <_|Nix|_> toddmparker: ... but window.performance is not available on mobile :( [11:29:31] uGoMobi: right, played with that a bit [11:29:37] <_|Nix|_> uGoMobi: Does it work across all supported browsers? [11:30:06] we also have to keep in mind that it should be possible to override for one list item [11:30:21] .ui-btn, .ui-listview.ui-btn a { … } [11:30:28] sure [11:30:38] _|Nix|_: do you mean this markup/css? [11:30:42] think that would work [11:30:54] _|Nix|_: should, yes [11:31:25] <_|Nix|_> OK. Good. Unlike frequent's which didn't work in Chrome. Good stuff! [11:31:46] uGoMobi: nice work! [11:31:51] <_|Nix|_> Indeed! [11:31:55] I didn't test IE7 but all other browsers are fine [11:32:05] <_|Nix|_> Very, very cool! [11:32:30] page scales really well when you increase font size [11:32:55] everything is em values in there [11:33:41] that's nice. tho nesting gets ugly [11:33:53] another one to mull over [11:33:57] seems like there is an alignment issue in Chrome Canary [11:34:13] that's because they break everything in can act gseguin [11:34:37] gseguin: ah I see it [11:34:43] didn't test canary before [11:34:52] I think I saw the same on FF Mobile [11:35:12] huh [11:35:15] it's just first pass, I am sure we can fix that [11:35:24] <_|Nix|_> Awesome work! [11:35:26] yeah, css works. we promise. [11:35:32] last thing: [11:35:35] Pre-processor research [11:35:35] Hoping a CSS pre-processor could help with class mapping between UI and Mobile. See http://wiki.jqueryui.com/w/page/65050459/Classes%20Option [11:35:36] Need to set up a test of this, maybe with SASS/Compass [11:35:39] yeah great job [11:35:42] display inline block + vertical align issue [11:35:49] the markup is super clean [11:36:00] yep, it is [11:36:51] oh, one thing... [11:36:55] uGoMobi: be cool to maybe play with SASS in the next branch so see how we might be able to compile stuff differently [11:36:56] the icon only buttons [11:37:37] I think we might still need to wrap text in icon only buttons [11:37:49] to make them hidden-accessible [11:38:10] right [11:38:21] wonder if that will be something we need to keep [11:38:25] in general [11:38:25] maybe we can think of a better way [11:38:29] yeah [11:38:44] hate to have any wrappers inside if we can avoid it [11:38:55] you already removed ui-btn-inner here too? [11:39:02] toddmparker: yes [11:39:08] no wrapping at all [11:39:15] only native elements [11:39:23] cool [11:39:32] would work as C-grade too if the classes are there [11:40:19] the text of icon-only buttons I wrapped in a span though [11:40:29] gotcha [11:40:35] asking filamenters for ideas on that [11:41:34] toddmparker: I have one idea but didn't tested it yet [11:42:00] nice. [11:42:05] scott and mat have some ideas too [11:42:22] set size 0 for the native element and position the :before element as button [11:42:31] tricky [11:42:40] the pseudo element also contains the icon [11:42:49] not sure if that works, tricky indeed [11:43:05] scott: you could apply an icon font or grunticon to an :after element [11:43:18] anyway, this is fantastic. we can keep plugging away. [11:43:30] uGoMobi: please tell us how we can help out [11:43:39] i'll test the icons and grunt icons at least [11:43:56] so that's the big update on the markup nd style stuff [11:44:11] what's the update on the API/Performance Re-factor [11:44:20] we have to set up a test page for grunticons where they are not bg images but content of pseudo element [11:44:23] _|Nix|_ or arschmitz [11:44:33] uGoMobi: good point [11:44:37] <_|Nix|_> toddmparker: Not much. I've replaced jqmData with getAttribute in listview. [11:44:48] nice, saw that [11:45:06] have you guys started reviewing widgets for compliance? [11:45:21] might be good to take a pass thru the form elements to start [11:45:30] <_|Nix|_> toddmparker: http://jsperf.com/listview-jqmdata-vs-getattribute/2 [11:45:38] sure there is some low hanging fruit there [11:45:54] <_|Nix|_> toddmparker: I've already centralized the option setting for some easy widgets. [11:46:00] <_|Nix|_> toddmparker: That's part of the review. [11:46:04] <_|Nix|_> toddmparker: Tons. [11:46:09] cool [11:46:15] looks like a nice perf bump [11:46:17] <_|Nix|_> toddmparker: However, I got sidetracked with the performance and these popup bugs. [11:46:38] <_|Nix|_> toddmparker: However, I think the biggest chunk of performance improvement will come from "next". [11:47:19] <_|Nix|_> toddmparker: The Samsung guys are pushing really hard for performance, so I'm looking in all the nooks and crannies to try to eliminate some of the nooks and crannies. [11:47:20] agree on that [11:47:38] thinking you guys can mainly ensure that we're being good widget factory citizens [11:47:55] <_|Nix|_> toddmparker: That's still very much in the forefront. [11:48:25] <_|Nix|_> toddmparker: My next victim shall be the dialog, I think. [11:48:42] excellent [11:48:42] <_|Nix|_> toddmparker: I've conveniently marked all the widgets that have on-the-fly options with my optionDemultiplexer. [11:49:14] <_|Nix|_> toddmparker: ... which we've agreed to remove, so, coincidentally, getting rid of optionDemultiplexer out of all the widgets will make those widgets compliant. [11:49:17] sounds high tech [11:49:27] ok, got it [11:49:30] <_|Nix|_> Well, a demultiplexer is a H/W term. [11:49:43] ah [11:50:04] <_|Nix|_> But that's exactly what it is: A component that says you go left, you go right, you go straight, you take road https://github.com/jquery/jquery-mobile/issues/5, etc. [11:50:04] _|Nix|_: Issue #5 by scottjehl (31mon 4d ago): maximum scale 1 in meta? [11:50:08] <_|Nix|_> Bah! [11:50:14] <_|Nix|_> number frigging 5 [11:50:56] <_|Nix|_> Anyway, so that's where that's at. [11:52:14] great [11:53:32] gseguin: you've been in download builder land [11:53:54] indeed aka hell [11:54:06] Ghislain "please fix it" Seguin [11:54:13] :) [11:54:14] I:) [11:54:22] <_|Nix|_> :) [11:54:36] faster [11:54:38] I fixed it "ASAP" [11:54:56] so it looks like it's holding up [11:55:06] great [11:55:07] I've closed a few issues there [11:55:14] thanks for staying on that [11:55:47] I'm waiting on a change in RequireJS 2.1.6 that will make it super easy to dump the file list in a build.txt [11:56:26] other than that, linting and build stuff [11:56:50] I need to code something for 1.4, I feel like I don't know jQM anymore ;) [11:57:11] <_|Nix|_> :) [11:57:19] JQM still knows you :) [11:57:29] indeed. [11:57:41] gseguin: we'd love you help with widget cleanup [11:57:47] k [11:58:00] i'll have to check with bender [11:58:27] but my big goal for 1.4 is to make sure that the individual ui widgets are as standalone as possible [11:58:55] and that the auto-init and ajax nav features are encapsulated as much as possible [11:59:10] he was looking at that, but might be a good place for you to help with gseguin [11:59:20] <_|Nix|_> The way to check that is to run grunt --modules= [11:59:39] <_|Nix|_> ... and than using the resulting dist/jquery.mobile.js file in a plain JS + jQuery page. [11:59:40] if someone just wants to use or form widget or popup but none of the auto init or ajax nag, should be very crisp to do that [11:59:50] sounds good [12:00:00] maybe we just need to write up how to do that and provide some good demos [12:00:19] _|Nix|_: that would be grunt --suites= [12:00:24] <_|Nix|_> gseguin: No. [12:00:30] <_|Nix|_> gseguin: --suites is for tests. [12:00:30] oh [12:00:35] still a perception that the ajax nav and autoinit make this a monolithic framework [12:00:39] <_|Nix|_> gseguin: I'm talking about a manual test page. [12:00:39] oh that's right! [12:00:41] sorry [12:00:49] yeah yeah got it [12:01:21] was thinking about SASS in the meantime [12:01:28] <_|Nix|_> gseguin: We could add pages to demos/, one per widget, which use requirejs to pull in that widget and that widget alone. [12:01:33] _|Nix|_: is the widget registry the piece that is basically the autoinit controller [12:01:40] <_|Nix|_> toddmparker: Np. [12:01:42] wondering if it means you can only see CSS changes in a build [12:01:42] <_|Nix|_> No. [12:01:55] <_|Nix|_> The registry is the access point for enhancement. [12:02:32] <_|Nix|_> It's like "if you could take this element and enhance it for me that'd be greeeeat." [12:02:42] if you wanted to not use the auto-init and markup config how do we explain that simply [12:02:57] <_|Nix|_> markup config? [12:03:11] so it now holds the init selectors for widgets? [12:03:25] <_|Nix|_> toddmparker: No. That's still in the widgets' namespace. [12:03:31] <_|Nix|_> toddmparker: $.mobile.popup.initSelector [12:03:38] if you wanted to use popup like a standard jQ UI widget and call popup on an element... [12:03:44] <_|Nix|_> toddmparker: Notice it's not $.mobile.popup.prototype.options.initSelector anymore. [12:03:47] ah, ok [12:04:09] <_|Nix|_> toddmparker: You can do that with popup, but if the div has data-position-to="window" that will still be honoured. [12:04:21] <_|Nix|_> toddmparker: ... because $.mobile.widget parses that for you. [12:04:31] ok, got it [12:04:34] <_|Nix|_> toddmparker: That's not part of enhancement, but part of our concept of widgets. [12:05:16] <_|Nix|_> toddmparker: Still, enhancement has been reduced to one call: $.mobile._enhancer.enhance( theElementYouWantEnhanced ); [12:05:31] i think a few widget pages would help a lot here then [12:05:32] <_|Nix|_> toddmparker: No more myriad pagecreate handlers. [12:05:43] <_|Nix|_> Definitely. [12:06:07] if yo just wanted our panel, what is the the least markup, style and js you'd need [12:06:07] <_|Nix|_> When I tried to rip popup out of the whole navigation/init framework, I had to do some work to make it function correctly. [12:06:08] _|Nix|_: that doesn't look public [12:06:13] or the swipe events only [12:06:15] <_|Nix|_> gseguin: Not yet. [12:06:17] or just form elements [12:06:19] etc. [12:06:19] is that on purpose? [12:06:22] <_|Nix|_> gseguin: We can decide to expose it later. [12:06:45] so your experience is what i'd like to tidy up as we look at widgets [12:06:48] ok so how do people manually enhance? [12:06:56] in fact, building a standalone widget page might be a good task [12:07:04] by trigger "create" ? [12:07:18] <_|Nix|_> gseguin: Yep. That'll still work. [12:07:22] k [12:07:36] <_|Nix|_> gseguin: There's a single handler that calls $.mobile._enhancer.enhance() [12:07:55] in ui, can call it like this: [12:07:56] $( "#slider" ).slider(); [12:08:03] are you saying that's not possible? [12:08:09] <_|Nix|_> gseguin: ... kept for compatibility, but not deprecated, because it conveniently separates the implementation of the enhancement from the interface that's used to trigger it. [12:08:20] <_|Nix|_> toddmparker: It's possible. [12:08:37] <_|Nix|_> toddmparker: But if you wna to say $( "#myPage" ).allTheWidgets(); [12:08:47] <_|Nix|_> toddmparker: You say $( "#myPage' ).trigger( "create" ) [12:08:52] <_|Nix|_> toddmparker: ... just as you do now. [12:09:01] <_|Nix|_> toddmparker: ... only the implementation is waaay cleaner. [12:09:09] sounds good [12:09:37] <_|Nix|_> #myPage was a bad choice. I don't mean pages. I mean whatever element. [12:10:14] <_|Nix|_> In fact, exposing the registry is only necessary for allowing third-party widgets to register. [12:10:41] <_|Nix|_> Otherwise they keep having to register pagecreate handlers, and they cannot declare enhance-time dependencies. [12:11:51] _|Nix|_: ah, gotcha. that makes sense. you're talking about enhancing all widgets via create [12:11:59] <_|Nix|_> toddmparker: Yeah. [12:12:07] sweet [12:12:14] that is a big timesaver inho [12:12:32] i see we're already a bit over. think we all got to say our peace. [12:12:40] anything else we should review? [12:13:02] <_|Nix|_> *scratch head* I think we're good. [12:13:11] yeah think so too [12:13:15] <_|Nix|_> Time for the crickets and the tumbleweeds ... [12:13:18] yup [12:13:45] <_|Nix|_> Doo bee doo bee doo ... dum dum dum .... [12:14:01] <_|Nix|_> *rattlesnake* [12:14:11] alright, see you guys in -dev [12:14:15] later! [12:14:18] <_|Nix|_> K L8R [12:14:29] later all, thanks for all the hard work