[09:02:15] ok, let's get started [09:02:18] ok [09:02:53] danheberden: any update on the view.jqueryui.com repo becoming public? [09:04:42] scott_gonzalez no, i haven't been able to get to it yet [09:04:56] ok, any other infrastructure updates? [09:05:24] no, not really [09:05:46] rworth: any docs update? [09:06:04] no updates, next steps (todos) are current on the wiki page [09:06:51] I had a meeting with ajpiano and Andrew Wirick about widget factory docs [09:07:11] we discussed how and what to document [09:07:23] we came up with a decent outline, i think andrew's workin on some content yeah? [09:07:24] and there's a (temporary) repo to house the docs: https://github.com/scottgonzalez/widget-factory-docs/ [09:08:02] once they're fleshed out, we'll figure out what goes where [09:08:19] since we'll have api.jqueryui.com, jqueryui.com and learn.jquery.com [09:10:02] next item is about initializing widgets on disconnected elements [09:10:10] http://bugs.jqueryui.com/ticket/6796#comment:8 [09:10:32] I'm for adding [09:10:32] that specific bug is about detecting RTL on buttonsets [09:10:58] so just append to body if the element isn't in the DOM? [09:11:07] Slider is one widget where auto append could be a problem [09:11:08] (18 hours 40 mins ago) tell jzaefferer wondering what your thoughts on https://github.com/jquery/jquery-ui/pull/419 are. That and adding the missing divs for the fraction test to position_deprecated.html seems to fix most if not all of those errors. [09:11:08] (13 hours 30 mins ago) tell jzaefferer i did some digging and the grooveshark autocomplete uses UL/LI so not an example of other structures :( [09:11:08] (2 hours 54 mins ago) tell jzaefferer i will be in a meeting all morning and may only be able to lurk during the UI meeting. i will try to have IRC open on my ipad during my meeting so if you have any questions about Menu status for the meeting, i will try to answer them and try to chime in during the meeting [09:11:31] Yikes [09:12:08] jzaefferer: how would it be a problem? [09:13:15] Don't you init a slider with a disconnected DOM element, then insert it somewhere? [09:13:28] Sorry about that [09:14:18] jzaefferer: who are you asking? [09:14:36] You, rworth [09:14:44] how is that a problem? [09:15:10] if it get's appended to the body and then you insert it somewhere, it will end up somewhere [09:16:09] More appending then necessary, but I guess not an actual problem [09:16:12] Nevermind then [09:16:58] I wonder if this is an actual problem or if the user is relying on classes to change the direction [09:17:46] oh look, he links to a test case that doesn't do anything with direction :-/ [09:19:42] seems to work fine [09:19:46] I think he's just wrong [09:19:53] o [09:19:55] ok [09:20:33] Oh well [09:20:35] Next! [09:21:57] next major action for 1.9 [09:22:13] bringing at least one widget to completion or starting on the API redesign for another widget [09:22:26] jzaefferer said he want me to move on to another widget [09:24:17] I'll take silence to mean nobody cares :-P [09:24:23] and I'll move on to dialog [09:26:11] gnarf: any update on animation tests? [09:30:16] kborchers, jzaefferer: update on position? [09:31:47] In another meeting ... Issue with deprecated tests but I think inukshuk has a fraction support pull that addresses it [09:32:33] jzaefferer: menu, selectmenu, datepicker, download buidler? [09:32:56] Menu see todos on wiki need input on a couple [09:36:36] I guess that's it [09:36:49] scott_gonzalez: nope, no update, sorry to be running late today [09:38:35] I'll be gone all of next week [09:38:42] have fun [09:38:43] and I think jzaefferer will be too [09:38:47] thanks [09:38:48] I'll be around [09:42:22] hey, what happened with https://github.com/jquery/jquery-ui/pull/390 btw? [09:45:04] I'm waiting to see the code [09:45:48] he probably has cases where he knows ahead of time that he'll always position to the right [09:45:54] and so knowing that it flipped is useful [09:46:04] but in general, knowing that it flipped isn't too useful [09:46:14] knowing where you ended up in relation to the `of` element is [09:47:49] so he says that he has tooltips with connectors [09:48:02] right [09:48:06] I'm sure it's easy to use the class if you're the one setting the position [09:48:17] but if he was trying to build an extension that adds a connection [09:48:20] he'd be screwed [09:48:27] point [09:48:46] i kinda agree with your whole argument on that commit [09:49:20] but i don't think a class is correct either [09:50:00] maybe we could .data() some deatils about the .position math? [09:50:30] I think we should expose it in the using callback [09:50:51] is options the missing word? :) [09:51:27] well, there's nothing stateful about .position() [09:52:37] right, a callback makes some sense, but then you need to juggle the callback function if you are writing an extenstion [09:53:27] i was thinking that just storing the position options, and the final position info on a .data() might be a little more straightforward [09:54:41] maybe, I don't really like the idea of putting data on an element just because you positioned it though [09:54:50] fair [09:57:49] Wouldn't it be enough to provide a Boolean isFlipped param in using? [09:59:04] kborchers: part of my argument is that you don't care if it flipped [09:59:10] you care where you are relative to the of [09:59:27] knowing that you flipped requires knowing where you were trying to be positioned in the first place [09:59:47] which means (for plugin authors) dissecting the position options [10:01:12] ok, grid meeting time [10:01:37] jzaefferer: do you have an update on editing? [10:02:43] looks like jzaefferer isn [10:02:47] 't here [10:02:52] check the editing wiki page for the latest [10:03:07] ok, borismoore, you wanna catch us up with you work on template? [10:03:13] Sure [10:03:28] Who is here apart from me and Richard? [10:03:38] brado23 [10:03:44] yup [10:03:45] OK [10:03:52] anyone else, gnarf ? [10:04:27] OK, so just the three of us. Shall we stay IRC or go Skyoe? [10:04:39] Skype [10:04:42] irc best for me atm [10:04:49] ok [10:05:00] i prefer irc too [10:05:09] sorry, was getting some coffee :) [10:05:19] Cool... So I have created [10:05:39] a version of jsrender that doesn't have a jQuery (or DOM) dependency [10:05:47] And some demos that go with that [10:06:20] the demos seem to reference jsrender.js [10:06:44] Sure, that is the non-jquery version [10:07:01] there's a file called jsrender-logicless.js [10:07:15] https://github.com/BorisMoore/jsrender/blob/master/jsrender.js https://github.com/BorisMoore/jsrender/tree/master/demos/step-by-step-nojquery https://github.com/BorisMoore/jsrender/blob/master/jsrender-logicless.js [10:07:43] So those are the non jQuery version, the corresponding demos, and finally, a third version [10:07:52] which is the logicless work in progress [10:07:58] so jsrender.js is logicless? [10:08:49] No, jquery.render.js is the plug in (with logic), jsrender.js is the non-jquery version (with logic) both using the existing semantics and syntax [10:09:05] ok, so no demos of jsrender-logicless.js [10:09:13] and finally jsrender-logicless.js is work in progress on logicless [10:09:24] that's what I was expecting the demos to be of, hence my confusion in seeing them reference jsrender.js [10:09:26] No demo yet because it is not complet [10:09:29] ok [10:10:29] I am moving to a new team as a result of a reorg (internal to MS) so (as I warned 2 or 3 weeks ago) I have less time for this work, unfortunately [10:11:13] It is going to get worse too, unless the new team decides to use JsRender and JsViews, in which case I can continue to work on it in that context [10:11:28] I'm working on getting them to do that, but it is too soon to say... [10:11:47] Also logicless is a BIG re-implementation [10:12:05] So demos will come progressively as I manage to complete it. [10:12:16] so, what's the status of jsrender-logicless.js? And what are the next steps? [10:12:41] But some of the work already is very encouraging - independantly of the syntax and semantics [10:13:05] Namely the result should be faster (for rendering compiled templates) [10:13:18] much easier to debug [10:13:27] because the rendered templates are way more friendly [10:13:42] (more friendly that handlebars compiled templates also) [10:13:59] the code size is similar (so far) to previously [10:14:32] and extensibility (custom tags/helpers) is a lot easier [10:14:58] I had a sync up with Joern on Friday [10:15:18] and he had some feedback on the syntax. He preferred a different style [10:15:20] shown here [10:15:51] https://docs.google.com/spreadsheet/ccc?key=0Aurq5o3uCfr4dFQ1VTR2Ry1nODV0djdZUy1MbWJQcVE# [10:17:04] Either syntax would be the same semantically - i.e. logicless, you have to use registered helpers/functions if you want to do what previously you did with expressions in the template [10:17:56] So the next stage is to continue from the AST which is implemented, to finish plumbing in the compile step and render-time implementation [10:18:17] and create corresponding demos and samples [10:18:18] * gnarf is totally lost absorbing the meaning of logicless in this conversation [10:18:38] gnarf: see http://wiki.jqueryui.com/w/page/41375604/Template-Comparison [10:18:40] thanks [10:18:59] see the table, we're only implementing the features under Core [10:19:04] The AST can be the same whichever syntax style we choose, but currently it is handlebars style [10:19:15] no expressions, no comparisons [10:19:38] So if we choose the second style, we need to change the parsing (regex etc) to give the same AST [10:19:45] only output, truthiness (if), iteration (each) [10:20:03] yup [10:20:10] So that's about it... so far... [10:20:24] aha [10:20:27] thanks [10:20:37] thanks borismoore [10:20:43] ok - thx [10:20:43] gnarf: do you have an update? [10:22:14] just a couple of tiny points on mask this week, been working on getting it to handle multi character values in prep for moving onto timepicker [10:22:32] I've been looking at the mac os x timepicker in sys prefs for a little inspiration there [10:22:47] where left/right always highlight the next/previous "field" [10:23:25] would tab/shift-tab move to next/previous input then? [10:23:30] yes [10:23:34] ok [10:23:42] mask should only be a single tabstop [10:23:48] same with timepicker [10:23:56] also, updated the demos quite a bit today [10:23:59] could this work for other masks as well? [10:24:24] say, phone number, left/right arrows move between groups of digits? [10:24:39] it could, but I'm not sure thats what you want [10:24:58] I guess you really want to control the carat in that case [10:25:01] with the single character wide values - backspace / typing will "insert" and "shift" values [10:25:04] since it's not a spinner, right [10:25:04] ok [10:25:14] great, thanks [10:25:21] brado23: did you have any update? [10:25:27] i figured if you were using multi character fields you kinda want to update the whole field [10:25:32] Sure...just quickly... [10:25:58] I spoke with Joern last week about whether or not "refresh" in the editing API / events should have old/newValues supplied. [10:26:00] ... [10:26:20] -1:s/today/this last week [10:26:41] It turns out that we're having trouble determining whether we want "refresh" in the API/events at all... [10:26:55] ...and whether this shouldn't be a "remove all" followed by "insert new". [10:27:32] I'm going to prototype a $.observable.beginChanges()/endChanges() that would make a paired remove/insert be treated as atomic by some listeners. [10:27:39] that's what it means in effect, as far as a safe way to handle it [10:27:59] Our primary usecase was sorting, which, like filtering, isn't about editing [10:28:23] Yes, there will be some that will want to interpret remove/insert as a batch [10:29:08] The other concern too here is that we have _other_ APIs/events that are trying to be "batchy". Hard to decide which stay/go without knowing what we'll have as a facility for batching. [10:29:31] "refresh taking multiple objects" is one of these "batchy" APIs. [10:29:34] I thought we agreed that anything "batchy" should exist at a higher level because it can [10:29:53] I don't understand "refresh taking multiple objects" [10:30:02] sorry. "remove" [10:30:14] "remove taking multiple objects" [10:31:19] Yeah, being able to drop that one would let us simplify the remove event and impl a lot [10:31:35] Could then be consistent with insert event [10:31:49] ok [10:32:34] Right. To continue this line of design, we'll need some way for select listeners to still determine that a set of API calls are logically a batch. [10:32:39] set=sequence [10:33:15] so, random curiosity, if I were to remove 200 entries from this thing, is it going to fire 200 listeners? [10:33:40] We may want to avoid to much chattiness, though, even if listeners can batch thanks to start and end [10:33:49] My thinking is that it will fire "begin change events", 200xchange events, "end change events". [10:34:05] So still very busy [10:34:18] thats a lot of function calls for tiny browsers like ie6 [10:34:46] Let me think more about that. [10:34:57] Do you think it'll really be a problem? [10:35:02] I don't [10:35:14] I worry about it [10:35:25] more importantly, I think we should worry about it once we show it is a problem [10:35:32] We can do some perf tests [10:35:58] My concern is that we'll complicate things by forcing listeners to be aware of batches, even if they don't care about the batch. [10:36:24] With "begin/end change events" events, those who don't care about the batch can ignore these. [10:36:27] back to the begin/end, I feel this can live above, so please prototype it at a higher level, where the actor+listener are binding to something that depends on this below [10:36:41] But the others will be firing a lot of their own handler code [10:36:49] yes, that's right. [10:36:55] It is not just the perf cost of the triggers [10:37:18] how are listeners forced to be aware of batches? [10:37:19] if you have an app with alot of batch-unaware handlers, then you need to tune [10:37:31] they aren't with "begin/end change events" [10:38:17] rworth -- can you elaborate on "at a higher level"? [10:38:31] build a plugin that depends on this plugin [10:38:52] if someone wants to do batches and to listen to batches, they use that plugin [10:38:58] why is that? if the batching primitives are optional, why does it matter that it's one plug-in? [10:39:01] and those events fire in addition to the lower level onws [10:39:02] ones [10:39:26] because we aren't in agreement that it belongs at the core level [10:39:37] because it can exist above, it should [10:39:53] hmm... [10:40:00] file size, complexity, API, etc. [10:40:15] the lower level is not affected by batches [10:40:30] nor is anyone not using batches on the sending or receiving end [10:40:52] so there's no reason it has to be built-in to that low level [10:41:20] But if it makes it hard to do a performant app without adding a second plugin... That is complex also [10:41:36] that's a reason to use that second plugin [10:41:39] It certainly pushes us at least to support remove all etc. [10:41:47] that's not a reason to force everyone to have it even if they'll never use it [10:41:49] if we don't do begin end [10:42:22] In my mind, what we'll have in the editnig API when we're done is a small number of primitives. To rationalize why this is so, I feel we need to have the bracketing to support the minimalist design. [10:42:29] what helpful difference is there between remove all and refresh? [10:43:01] Refresh == replace the current contents with this new contents [10:43:29] It allows listeners to compare old and new and figure out the delta if they want [10:43:31] refresh == some or all changes have occured, act as if everything is new because you don't know otherwise [10:43:34] for better rendering etc [10:43:42] rworth -- Would it make sense to resume this on Skype (now or later)? I feel we're goign to spin on IRC. [10:43:57] I can do a skype call now, sure. jzaefferer? gnarf? [10:44:10] We have an 11:00 right [10:44:14] Later, not now [10:44:16] oh, that's right [10:44:27] um, 45min from now should work, for me [10:44:53] sure 45min is good for me too [10:45:04] Not sure I can, but if not, meet without me I guess [10:45:17] i should be around [10:45:38] but consider me an observer in this one, still don't know too much about the internals there :) [10:45:41] jzaefferer ? [10:47:02] Seems like we lost jzaefferer [10:47:32] he has limited avail. atm, which is (likely) why he said now doesn't work for him [10:47:47] let's do a call in 45min, jzaefferer will join if he can [10:47:49] thanks all [10:47:56] fine by me. see you then [10:48:03] thx [10:52:04] I hope I'm home by then, already half an hour late [11:37:29] bot-t: involved is http://docs.jquery.com/Getting_Involved [11:37:30] rwaldron, Stored "involved". [11:37:36] ?involved [11:37:37] http://docs.jquery.com/Getting_Involved [11:38:55] bot-t: style is http://docs.jquery.com/JQuery_Core_Style_Guidelines [11:38:55] rwaldron, Stored "style".