[11:01:19] jasperdegroot: gseguin: agcolom: cgack: gabriel_schulhof: Meeting Time! [11:01:31] * gabriel_schulhof waves [11:01:34] howdy [11:01:36] I'm here [11:01:39] hi all [11:02:06] agenda https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdG5nSmZiSUhjYm4ya29CdjhLZmJwSWc&usp=drive_web#gid=43 [11:04:04] ok so 1.4.4 [11:04:47] we are planning on releasing on friday morning [11:05:00] at the conf [11:05:13] things are looking good [11:05:18] 4 prs left [11:05:19] Weeeeell ... friday release ... mmmm ... [11:05:33] 3 are ready [11:05:39] gabriel_schulhof: it will be early [11:05:58] so it should be fine and at a conf is i think worth more then a different day as far as visibility [11:06:08] and it'll be announced at the conf so tweeted by a bunch of people [11:06:09] and there will be a lot of buzz because of the conf [11:06:14] right [11:06:25] OK. Well, I'm no PR expert ;) [11:06:33] the last 2 got a lot of attention [11:06:38] even though they failed :) [11:06:46] and it's Friday the 12th, not the 13th ;-) [11:06:53] hey now, they didn't fail [11:06:54] LOL :) [11:07:01] there was a technical hiccup [11:07:22] lol [11:09:03] there are only a couple 1.4.4 issues left after these prs [11:09:31] so if anyone wants to look at one this weekend i think we can extend the code freeze a little since we are in such good shape [11:09:35] Too bad you can't filter out issues that have PRs against them. [11:09:47] OK. [11:10:26] Gah ... https://github.com/jquery/jquery-mobile/issues/7644 can be closed. [11:10:37] It didn't autoclose because it landed against 1.4-stable, not master. [11:10:39] I'll close it. [11:10:49] ok [11:10:50] was about to ask [11:11:10] sorry got held up by a neighbour! here now [11:11:19] agcolom: no problem welcome [11:11:25] agcolom: and good timing [11:11:44] i had a pretty major docs issue brought to my attention on irc [11:11:44] hi Anne [11:12:18] https://github.com/jquery/api.jquerymobile.com/issues/332 [11:12:40] right ok [11:12:58] Right, yeah ... we agreed that we'd put all extensions into one file. [11:13:09] so just table widget and those 2 should go into examples in there? [11:13:11] That's done in the review, but I guess we wanna do it for 1.4.x as well, right? [11:13:19] Nono. [11:13:22] gabriel_schulhof: look at the code examples [11:13:39] every one is wrong and wont work [11:14:00] OK, so we're bring this part of the widget review up to 1.4.x, right? [11:14:04] bringing [11:14:06] im amazed no one filed an issue about this already [11:14:20] gabriel_schulhof: its not about the widget review [11:14:29] its about our docs being 100% wrong [11:14:42] Right, but the fix is a part of the widget review. [11:14:51] huh? [11:15:01] We have a table widget review API docs PR wherein it's fixed. [11:15:15] ah ok [11:15:20] but that's for 1.5? [11:15:21] jasperdegroot: $( ".selector" ).table-columntoggle( "option", "columnBtnText", "Show columns" ); [11:15:42] arschmitz: Oh, right. That's because the code generation. [11:15:45] Definitely wrong. [11:15:48] yes [11:15:49] right [11:15:52] OK. [11:15:59] every example in the column toggle and reflow is like this [11:16:10] my huh? was regarding that the fix is part of widget review [11:16:12] should it just be table? [11:16:19] thats a big problem its not about the separate pages [11:16:22] agcolom: yes [11:16:37] so it should go in the table widget page? [11:16:52] I'll move the relevant bits from the widget review PR into a separate PR that fixes this issue, and I'll rebase the widget review PR once that lands. [11:17:03] gabriel_schulhof: ok that will work [11:17:28] thanks gabriel_schulhof [11:17:41] i think it shows though people are looking at the demos more then the api [11:17:45] for code examples [11:17:52] Good. [11:17:52] yes [11:17:56] that no one previously reported this [11:17:59] I think the API docs are more academic. [11:18:09] I would agree with that [11:18:12] yeah [11:18:26] i happened to see someone paste it in #jquery [11:18:31] and asked them where they got it [11:18:46] oops ;-) [11:18:47] arschmitz: Man! [11:18:53] That's like getting caught red-handed :) [11:19:04] yeah [11:19:24] The good news is docs can be fixed, tagged, and released whenver. [11:19:33] and they followed it up by pointing out some hungarian notation in our code ha ha ha [11:20:35] Man ... I think calling it Hungarian notation is an overstatement. We only ever point out jQuery objects, not /all/ data types. [11:20:44] But whatever. [11:20:52] Needs to go. [11:20:56] gabriel_schulhof: it is an example of hungarian notation [11:21:00] Yeah. [11:21:07] just because we dont do it everyhwere [11:21:21] and our style guide does forbid it [11:21:41] but anyway they were just giving me a hard time [11:21:50] its someone i help often [11:22:09] ok so 1.5 [11:22:43] one more semi big change is going to have to happen were we say OPPS we got it wrong [11:22:48] icons [11:22:58] we thought :pseudo elements was a good idea [11:23:09] since we have realized its not as awesome as we though [11:23:10] t [11:23:32] and there are 2 good reasons we should switch back asap [11:23:51] Lemme guess: slow selectors? [11:24:05] 1.) let the :pseudo ones die as quick as possible so as few people are impacted as possible [11:24:22] 2.) ui button re-writes are based on spans [11:24:40] gabriel_schulhof: thats part of the reason we were wrong in the first place [11:25:02] we never did test it though [11:25:05] arschmitz: How do we do anchors thing? [11:25:06] gabriel_schulhof: it also makes the css kinda gross and non semantic [11:25:22] gabriel_schulhof: people add the span in their markup [11:25:29] gabriel_schulhof: this is also how bootstrap does it [11:25:33] OK. [11:25:39] I'm good with that. [11:25:55] or the widget will do it for you [11:26:05] ... right, in case of a button. [11:26:14] and the widget will once again work on any element you like [11:26:20] button a div etc [11:26:21] do we stick with SVGs with PNG fallback? [11:26:28] jasperdegroot: yes for now [11:26:32] or back to sprites like UI does [11:26:38] arschmitz: Wait a sec ... we're not gonna add anchors to the initSelector, are we? [11:26:38] svg [11:26:40] ok [11:26:48] gabriel_schulhof: thats up for debate [11:26:57] I vote an emphatic NO! [11:26:59] but no matter what its customizable [11:27:11] Yes, that supports my vote. [11:27:12] people can always set the init selector to whatever they want [11:27:20] People can add it to the initSelector if they like. [11:27:47] gabriel_schulhof: yes id be open to what people think on this im not firmly one way or the other [11:28:10] arschmitz: I'd say that instantiating a widget for every link is very, very bad. [11:28:22] arschmitz: Think of a listview. [11:28:24] sorry, but I don't follow [11:28:41] jasperdegroot: so id like for 1.5 if you could focus on updating the theme to use icons again [11:28:44] jasperdegroot: If we add anchors to the initSelector for a button widget, then every link will be a button widget. [11:28:45] i mean spans for icons [11:29:16] but we already decided that people have to add classes to anchors themselves, right? [11:29:32] arschmitz: ok [11:29:38] jasperdegroot: right now we dont support using button or anchor for the button widget at all [11:29:43] the new widget does support this [11:29:43] jasperdegroot: Exactly, and now we (should) extend that to also having to add a span. [11:29:51] so the question is what the init selector should be [11:29:53] yes [11:30:02] arschmitz: ah ok, gotcha [11:30:15] should you opt in or opt out for buttons and anchors [11:30:36] arschmitz: Opt in. Think about all the memory taken up by useless button widgets. [11:31:09] arschmitz: I mean, when we had buttonMarkup, we optimized the living daylights out of it just to make it be fast in a listview. [11:31:09] gabriel_schulhof: well in controlgroup it will always enhance them [11:31:11] yeah, I agree with gabriel_schulhof [11:31:22] just fyi [11:31:44] but thats part of controlgroups job enhance its children [11:31:46] arschmitz: ... and buttonMarkup was just a plain function, with, like, almost nodata. [11:32:21] arschmitz: ... and still it was terrible. [11:32:22] gabriel_schulhof: im inclined to agree on the init selector just being open [11:32:38] at least for anchors [11:32:48] arschmitz: Yes, please! ... and besides, that's what we have now. [11:32:49] buttons i would tend to go for init selector [11:33:12] links can be a link or a button [11:33:18] but buttons should always be buttons [11:33:23] lol [11:33:31] arschmitz: A button doesn't submit by default, does it? [11:34:41] depends on browser [11:34:57] but regardless buttons should always look like buttons [11:35:04] regardless of if they submit [11:35:31] arschmitz: I think it's best to work on spans instead of pseudo elements for icons in a branch that contains the new button widget [11:35:42] and controlgroup and checkboxradio widegt [11:35:44] widget* [11:35:50] jasperdegroot: yes in a branch for sure [11:36:12] Whew ... this'll be a PR on a PR :) [11:36:14] yes but a branch that contains the new widgets [11:36:15] jasperdegroot: i was thinking just work on the css to start [11:36:32] and we can pull the widget in once they are ready [11:36:47] arschmitz: but don't you think that will give a lot of conflicts [11:36:52] jasperdegroot: there is a small bit of debate about classes still [11:36:58] I see [11:37:03] jasperdegroot: no [11:37:24] becuase we will pull external files so there will be no conflicts its completely new [11:37:34] the button widget will not be in /js any more [11:37:47] it will be in external/jquery-ui/button.js [11:37:53] ok [11:38:18] I think lot of our button icon stuff is core.css [11:38:37] jasperdegroot: yeah and we wont pull the css from ui [11:38:44] only the js [11:38:53] but ok, I'll make the changes first and then we will see if we have to move things to other files [11:39:15] which brings me to something else i realized that gseguin can hopefully help with [11:39:28] what is it? [11:39:30] css dependency comments [11:39:37] are going to break [11:39:44] because ui will point to their css [11:39:50] but we will want to use our own [11:40:03] we will need something like a require paths config [11:40:15] to say this path really should point to this different file [11:40:26] gseguin: thoughts? [11:40:43] arschmitz: Are we going to have a js/widgets/forms/button.js which depends on the external file, like we have for tabs? [11:40:56] arschmitz: ... if so, we need only ignore paths that are unavailable. [11:41:04] that sounds hairy [11:41:05] gabriel_schulhof: the idea is to get rid of those now that ui uses amd [11:41:34] gabriel_schulhof: and hiding hidden would be bad it would hide errors [11:41:37] gseguin: It's like paths in requirejs [11:41:51] arschmitz: True. [11:42:02] arschmitz: We need to call our file jquery.ui.button.css [11:42:12] honestly I hate to bring this back on the table but why aren't we using something like: https://github.com/guybedford/require-css [11:42:24] That would take care of that problem [11:42:25] gabriel_schulhof: that would not even work it would be in wrong directory [11:42:41] gseguin: a variety of reasons [11:42:53] arschmitz: No, because if we implement paths the way requirejs has paths, then the path would be correct, and the filename would also be correct. [11:43:34] arschmitz: I'm just saying, if the filename is the same, we need implement nothing different from requirejs's paths. [11:43:37] gseguin: id rather not get back into that right this second i can find the issues thread if you want [11:44:17] arschmitz: that's fine. I sort of recall not wanting to impose RequireJS as the AMD loader [11:44:49] thats part of it [11:45:08] arschmitz: Also, ummm ... symlinks ... ? [11:45:13] * gabriel_schulhof ducks behind a large rock [11:45:58] gseguin: i have not looked recently but it seems fairly straight forward to add a paths config option to the builder [11:46:12] arschmitz: we could use the same paths as in the requirejs's path config [11:46:18] pass in an object and then check the paths against it [11:46:23] gseguin: yup [11:46:28] thats a great idea [11:47:01] jquery-ui/path/to/style.css [11:47:12] or jquery-mobile/path/to/style.css [11:47:31] and find a way to resolve the path via requirejs [11:47:54] yeah we just need to be able to have the comment in their file resolve to our file [11:48:02] because we wont pull any of their css [11:48:17] oh ok [11:48:26] But then the paths config for css has to necessarily be different from the paths config for JS. [11:48:36] gabriel_schulhof: yes [11:48:39] then current-project/path/to/style.css [11:49:08] gseguin: you will probably want to get with rxaviers on this [11:49:14] ok [11:49:21] Does requirejs have a plugin for the way it reads dependencies? [11:49:24] I'll sit with him next week [11:49:31] i plan is still to switch to ui builder [11:49:37] Last time I checked it was sticking the retrieved file into an eval() statement. [11:49:42] but they are using our builder for the css [11:49:43] That's pretty hard-coded. [11:50:33] If the process of harvesting deps from a given file were pluggable, our problems would be over. [11:50:54] so this brings me to the next 1.5 topic and task [11:51:11] updating every widget to use a proper classes option [11:51:14] * jasperdegroot wonders if he is disconnected [11:51:17] We could also use require-css internally and provide a noop shim to our bower consumers [11:51:20] jasperdegroot: You're not. [11:51:37] gseguin: i think this is a great topic for next week [11:52:03] * gseguin shuts up now about require-css [11:52:03] gabriel_schulhof: id like you to try to work through the current widgets adding the classes option [11:52:11] gabriel_schulhof: actually I was for few minutes :( [11:52:35] arschmitz: OK. [11:52:49] gabriel_schulhof: most of it should be pretty straight forward [11:53:03] but there is one topic up for discussion with classes currently that will effect [11:53:33] arschmitz: sed -r s/("ui-[^"]*")/this._classes( \1 )/g [11:53:36] which is should it work via setOptions [11:53:37] :) [11:53:49] gabriel_schulhof: that will not work [11:53:54] ui-icon will never be mapped [11:54:07] and there may be places we will add classes that we dont currently [11:54:09] arschmitz: I know ... I was oversimplifying :) [11:54:25] because every element must have its own class [11:54:58] for example there wont be a ui-button entry in any widget execpt button [11:55:01] I personally also like guybedford/require-css, although yeap gseguin it would impose that for AMD users. A css plugin isnt yet a consensus among AMD developers... [11:55:10] arschmitz: Yeah. We need to formalize which elements are considered parts of the widget's structure, and each element will have a class like ui-widgetname-structurename [11:55:29] all elements are part of widget structure [11:55:40] but not all currently get a ui-widgetname class [11:55:40] rxaviers: let's talk about this next week [11:55:43] arschmitz: OK, then for all. [11:55:53] About the requirejs config option, as far as I could follow, builder could read each project's different config. [11:55:53] arschmitz: They'll now have to. [11:55:55] Sure. [11:56:00] gabriel_schulhof: exactly [11:56:06] arschmitz: ... and what about wrappers. [11:56:08] arschmitz: ? [11:56:13] what about them? [11:56:29] arschmitz: They currently get the ui-widgetname class. I guess that continues to be OK, right? [11:56:34] yup [11:56:39] arschmitz: ... because they're technically structural elements. [11:56:44] yup [11:57:02] we will now have a lot of ui-widgetname-icon classes that do nothing lol [11:57:07] So, ui-widgetname is given to the outermost element, not the element upon which the widget is defined. [11:57:21] gabriel_schulhof: there is not 100% standard for that [11:57:32] its what makes sense [11:57:47] arschmitz: ... because we could go with ui-widgetname-wrapper [11:58:01] ... and then we'd have consistency, whereby ui-widgetname is always given to this.element [11:58:04] gabriel_schulhof: its just what makes sense to that widgets structure [11:58:21] for example ui-selectmenu is not a class at all [11:58:39] in the ui selectmenu [11:58:50] You mean there are no rules associated with that selector? [11:59:02] no i mean there is no class ever placed in the markup [11:59:13] Oh, there isn't? Wow! [11:59:16] that class does not exist [11:59:28] this is something we could talk about formalizing though [11:59:36] when we are al together next week [11:59:47] No, but we do add ui-select [11:59:54] yes we do they dont [12:00:15] so the open issue on classes is should you be able to update it after init [12:00:31] and if you can should it actually do anything [12:00:55] right now it can be updated but has no effect it is not handled in setOptions [12:01:05] Well, if you can, it should behave as expected, which is that the particular structural element will have its classes updated. [12:01:09] the problem here is there is no way to optimize or abstract this [12:01:12] ... which is why you shouldn't be able to. [12:01:19] Yes there is. [12:01:39] You give a hash of class-name -> structural element [12:01:45] gabriel_schulhof: no there isnt how would you optimize or abstract this? [12:02:04] You already have ui-widgetname-structurename -> classes [12:02:09] yes [12:02:24] You make a second hash ui-widgetname-structurename -> jQuery object [12:02:58] so you have to track every element you make a change to separately [12:03:10] and they dont always map to a single element [12:03:10] Then you jQuery.object.removeClass( oldClasses ).addClass( newClasses ) [12:03:17] That's fine. [12:03:23] jQuery object can contain multiple elements. [12:03:27] yes [12:03:47] i dont know this seems like a bit much [12:03:53] Oh, definitely. [12:04:03] I vote we don't do it, but not because it's not possible. [12:04:10] there is actually a use case for allowing changes but not handeling in setoptions [12:04:19] What's that? [12:04:26] controlgroup with selectmenu [12:04:42] selectmenu changes its corner classes based on open/ closed [12:04:54] combine this with the excludeInvisibles option [12:04:55] ... but not in controlgroup. Right. [12:05:18] and you need to be abled to change the option values as things are shown hidden [12:05:29] but you dont care if it does anything right that second [12:05:42] just that it re-checks the option value every time [12:06:10] That's fine. We can document that we don't support changing the value at runtime, and still make use of this. [12:06:36] gabriel_schulhof: anyway its not been decided yet so if you have an oppinion i suggest you comment on the pr [12:06:47] We can even be specific and document that changes in the value will not be reflected immediately, but only upon subsequent lookup. [12:07:02] arschmitz: URL, please? [12:07:27] https://github.com/jquery/jquery-ui/pull/790 [12:08:08] another change for 1.5 will be icons on input buttons will no longer be supported [12:08:16] this will remove ever needing a wrapper [12:08:31] ui has never supported icons on input buttons [12:09:03] we will however have css in place to make sure that you never get a blank space or a button with no text or icon [12:09:10] People can add them in with data-enhanced=true [12:09:21] so it will never be visually broken [12:09:22] ... add the wrapper themselves. [12:09:31] gabriel_schulhof: or just not use input buttons [12:09:41] there is absolutly no reason for them [12:09:45] last one sounds better [12:09:52] agreed [12:10:08] thats why