[09:07:50] * gnarf cheers
[09:07:55] <danheberden> but i just got help from gnarf on how to do it!
[09:07:56] <danheberden> haha
[09:08:16] <danheberden> on, and now the options show up in linkinus - sheesh
[09:08:19] <gnarf> I'll prolly never be the first guy at a meeting, but scott_gonzalez could prolly use some ops here ;)
[09:08:21] <danheberden> s/on/oh/
[09:08:53] <danheberden> maybe we should leave it -m'd?
[09:09:14] <gnarf> its not us leaving it -m'ed its whoever met yesterday +m'n it ;)
[09:09:17] <ajpiano> lol, was just on top of doing that anyway
[09:10:28] <scott_gonzalez> ok, let's get started :-)
[09:10:49] <scott_gonzalez> infrastructure
[09:11:05] <scott_gonzalez> I updated the index for code.jquery.com to list out all 1.8 and 1.7 versions
[09:11:06] <danheberden> well you got the index page done
[09:11:47] <scott_gonzalez> is the cron job for view.jqueryui.com fixed?
[09:11:54] <danheberden> aye
[09:11:58] <scott_gonzalez> and is it pulling from all branches properly?
[09:12:05] <danheberden> so far so good
[09:12:09] <scott_gonzalez> cool
[09:12:14] <danheberden> the only baby bug is it lists master twice
[09:12:22] <danheberden> but they link to the same folder, so it's just a display issue
[09:12:34] <scott_gonzalez> heh, ok
[09:12:40] <danheberden> and i put the form back up
[09:13:44] <danheberden> i need to make sure the repo is clean of private info, but i'll make it public
[09:13:53] <danheberden> and open up issues
[09:13:58] <danheberden> if there's anything else that is wonky
[09:14:36] <scott_gonzalez> great
[09:14:57] <scott_gonzalez> I don't think there's much to report on for docs, since rworth and jzaefferer aren't around
[09:15:20] <danheberden> well t hen
[09:15:25] <kborchers> ruh ro
[09:15:40] <scott_gonzalez> woops
[09:15:48] <danheberden> i heard scott_gonzalez is on time warner internets
[09:15:51] <danheberden> haha, still on AOL
[09:15:54] <scott_gonzalez> haha
[09:16:15] <gnarf> (sry afk again, i'll be quick)
[09:16:43] <scott_gonzalez> a few of us are going to discuss how to improve the widget factory docs tomorrow morning
[09:16:46] <danheberden> i think docs needs to be two separate tasks
[09:17:14] <danheberden> meh, scratch that - i'll just work that out on my own
[09:17:17] <scott_gonzalez> well, there are many tasks for docs
[09:17:44] <danheberden> yeah, i just feel the deployment part is being ripped away from infra
[09:18:08] <scott_gonzalez> defining the XML schema, writing the actual docs, implementing the XSLT, creating the deployment plan, searching, etc.
[09:18:34] <danheberden> do you need help tomorrow morning for wf docs?
[09:18:42] <danheberden> or y'all pretty much have it covered
[09:18:56] <scott_gonzalez> I think we've got it covered, but if you want to join you can :-)
[09:19:06] <scott_gonzalez> we're not going to write actual docs tomorrow
[09:19:21] <scott_gonzalez> just discuss what should be covered, how it should be laid out, etc.
[09:19:34] <danheberden> k
[09:20:57] <scott_gonzalez> I landed 1.6.x support in 1-8-stable :-)
[09:21:09] * gnarf claps
[09:21:09] <scott_gonzalez> and tagged 1.8.15
[09:21:35] <scott_gonzalez> so we now have official support for 1.3.2 - 1.6.2
[09:21:46] <scott_gonzalez> thanks to $.fn.propAttr = $.fn.prop || $.fn.attr :-P
[09:21:46] <danheberden> yay, no need to update the home page now! :p
[09:22:01] <ajpiano> woooo
[09:22:30] <scott_gonzalez> we're just waiting for the Google CDN to update before announcing 1.8.15
[09:22:34] <ajpiano> fyi scott_gonzalez MS is apparently cool with letting us use contents from their widget factory chapter from project silk in the WF docs :)
[09:22:51] <scott_gonzalez> yup, we'll probably pull a bunch of content from there
[09:23:02] <ajpiano> spent like an hour and change reviewing the content with Don last week
[09:23:19] <scott_gonzalez> cool, I reviewed it a few months ago
[09:23:25] <scott_gonzalez> gave them a bunch of feedback
[09:24:02] <ajpiano> yeah, i looked at it a few times, they definitely incorporated your input.. i feel pretty good about it
[09:24:22] <ajpiano> i'm gonna go AFK for a bit now gents.... need to figure out why jQuery.fn.offset() is failing in chrome extensions :/
[09:24:36] <scott_gonzalez> ok, on to testing
[09:24:44] <scott_gonzalez> we've got a few new things
[09:25:09] <scott_gonzalez> so last week I added /tests/unit/all.html to run all of the test suites on a single page
[09:25:31] <scott_gonzalez> now you can do /tests/unit/all.html?jquery=1.6.1 to run against a specific version of jQuery
[09:25:39] <scott_gonzalez> master supports 1.6, 1.6.1, 1.6.2, git
[09:25:52] <scott_gonzalez> you can also do that on any individual test suite
[09:26:15] <scott_gonzalez> e.g., /tests/unit/accordion/accordion.html?jquery=git
[09:26:53] <scott_gonzalez> I also added test suites for individual widgets to run against all supported versions of jQuery
[09:27:00] <scott_gonzalez> e.g., /tests/unit/accordion/all.html
[09:27:15] <scott_gonzalez> will run accordion.html and accordion_deprecated.html against 1.6, 1.6.1, 1.6.2, and git
[09:28:24] <scott_gonzalez> when gnarf gets back he can give an update on animation tests
[09:28:27] <gnarf> I stalled on post-animation testing for the widgets - didn't get anything done this week on it - If anyone else wants to give it a try they are welcome to it, otherwise I hope to get a chance to dig this week if I'm not too busy with grid stuffs
[09:28:43] <scott_gonzalez> ok
[09:29:49] <scott_gonzalez> kborchers: wanna give a menu update?
[09:30:06] <kborchers> collision detection has been updated in position
[09:30:32] <kborchers> my changes removed the rounding i when calculating position though so all of the unit tests fail
[09:30:39] <kborchers> that should be fixed with jqbug.com/ui/p190
[09:30:52] <kborchers> then all of the tests will need to be updated that use position
[09:31:25] <kborchers> navigation menu is ready to go
[09:31:45] <kborchers> we decided to not worry about target="_blank" with keyboard nav of the menu
[09:32:04] <jzaefferer> that's actually something worth discussing
[09:32:04] <kborchers> just needs someone to review the pull
[09:32:13] <jzaefferer> I don't think the menu should include the location.href stuff
[09:32:27] <jzaefferer> that's something the user can do in a custom select event if he wants it
[09:32:38] <jzaefferer> I wasn't quite clear enough on that in the PR comment
[09:32:57] <kborchers> but then keyboard won't work on a nav menu
[09:33:10] <jzaefferer> why not?
[09:33:31] <jzaefferer> .menu({ select: function(event, ui) { location.href = ui.item.attr("href"); })
[09:34:05] <kborchers> i see what you're saying just thought that should work by default for accessibility
[09:35:14] <jzaefferer> while it would be nice to have that built-in, if you're using a menu you probably want to have it do something else
[09:35:34] <jzaefferer> figuring out how to override the unwanted default behaviour isn't really something we should be dealing with
[09:35:35] <scott_gonzalez> this gets into the web vs. app debate
[09:35:41] <jzaefferer> kinda, yeah
[09:35:55] <jzaefferer> the point of the demo is to show how you can implement the web variant
[09:36:08] <jzaefferer> but the menu is really something for building apps, that's the primary purpose
[09:36:28] <jzaefferer> styling a list of links isn't that hard, you can still tab through them for keyboard support
[09:36:38] <scott_gonzalez> well, yes, but many people will use it purely for navigation
[09:36:58] <scott_gonzalez> anyway, this is a much larger discussion than we can have right now
[09:36:58] <kborchers> which is the angle i was viewing from
[09:37:24] <jzaefferer> that's fine, but supporting that usecase can't come at the price of breaking other non-navigation usecases
[09:37:34] <kborchers> for now then, i will remove the nav menu changes and update the demo to just show how to do it manually
[09:37:42] <jzaefferer> this is a problem: https://github.com/jquery/jquery-ui/pull/414/files#L1R477
[09:38:11] <jzaefferer> if we can figure out a way to have built-in support for the navigation menu that isn't as intrusive...
[09:38:29] <kborchers> which may come from hans's look into focus
[09:38:45] <jzaefferer> very unlikely
[09:39:25] <gnarf> if you make the <a> the focused element, you don't even really needed that event anymore, you just make select cancelable, and pass that canceled state up the line
[09:39:39] <jzaefferer> btw. not too long ago the menu did event.preventDefault whenever you clicked an item
[09:39:39] <kborchers> that's what i was getting at but ...
[09:39:56] <jzaefferer> we actually removed that, I'm wondering if we need to put it back if it doesn't actually work anyway
[09:41:01] <jzaefferer> gnarf, making the anchor the focussed element has a lot of issues; changes to the menu won't be noticed by the screenreader, it needs special handling to work for autocomplete
[09:41:20] <kborchers> jzaefferer: would make sense if we expect nav handling in select ... no need for the default anymore i don't think
[09:41:52] <gnarf> jzaefferer: hrm - strange
[09:41:52] <jzaefferer> yeah, will get rid of # showing up in the URL all the time for non-navigation menus
[09:42:13] <jzaefferer> let's go for that and document the issue on the Menu wiki page?
[09:42:21] <jzaefferer> its not like we're setting this in stone
[09:42:37] <kborchers> ok
[09:42:37] <jzaefferer> but without more input or alternatives it just blocks us from moving forward
[09:43:15] <gnarf> well, in a nav menu, you really do want to use tha <a> as focus, i can see in a non-nav menu being tied to that is kinda strange/silly, but if somehow that feature was configurable, it would make nav menus way easier if you could just tell them to use the <a>
[09:44:29] <kborchers> other than that just working on the best way to handle text inputs in input menu ... focus issues
[09:45:58] <scott_gonzalez> I'm not sure that it actually matters for a web-style menu that the anchor gets focus, so much as clicking it follows the link
[09:46:05] <jzaefferer> scott_gonzalez, do you have a contact to the guy working on https://github.com/jquery/jquery-ui/pull/190 ?
[09:47:04] <jzaefferer> I don't quite understand what's blocking that anyway
[09:47:12] <scott_gonzalez> I've just been talking to him via GitHub
[09:47:13] <jzaefferer> can't we split 1-8 support?
[09:47:20] <jzaefferer> and land in master now?
[09:47:30] <scott_gonzalez> yes, that's what we're doing
[09:47:55] <jzaefferer> we haven't landed in master yet, or have we?
[09:47:59] <scott_gonzalez> not yet
[09:48:14] <scott_gonzalez> but there's nothing blocking it now
[09:48:32] <scott_gonzalez> there was (lack of 1.6 support) for a long time
[09:48:40] <jzaefferer> the patch for ui.position is a bit silly, just comments code instead of removing it
[09:48:49] <jzaefferer> but the tests are useful
[09:49:19] <gnarf> i thought one of kris' commits solved that in master
[09:49:23] <gnarf> or was that something else
[09:50:10] <scott_gonzalez> it sounded like he had to land the same change
[09:50:16] <kborchers> i think this one does the same as his just without the tests https://github.com/kborchers/jquery-ui/commit/48d1606fa1477c52f13c849715322a9edcfa04e9
[09:50:17] <scott_gonzalez> but I don't think it has landed in master yet
[09:50:18] <socialhapy> http://bit.ly/nnoO0M kborchers (5 days ago) on jquery-ui: Position: Calculated better collision detection in flip and fit and created visual tests for each
[09:50:52] <kborchers> and my other changes for better collision detection
[09:51:00] <jzaefferer> kborchers, could you merge the test(s) from 190 to your branch?
[09:51:13] <kborchers> sure
[09:51:21] <jzaefferer> that PR needs to be updated anyway, then we can just leave it open for the 1-8-stable support?
[09:51:40] <jzaefferer> then we can land the smarter collision detection
[09:51:52] <jzaefferer> which is awesome :-)
[09:52:06] <scott_gonzalez> kborchers: when you merge his tests, can you leave a comment on his PR so he can check it out?
[09:52:13] <kborchers> will do
[09:52:27] <scott_gonzalez> yeah, it'll be really nice having this finally land
[09:52:37] <scott_gonzalez> then we just need flipfit :-)
[09:53:29] <jzaefferer> Felix asked me via email today where to put the code for the new selectmenu
[09:53:43] <jzaefferer> he already has two branches related to selectmenu in his UI fork...
[09:54:20] <jzaefferer> I don't know if and when we can expect contributions from OCAD people, or what is going on with jQuery Mobile...
[09:54:25] <scott_gonzalez> we should have an official selectmenu branch
[09:54:33] <gnarf> anyone else think we should do another pull request review session?
[09:54:46] <scott_gonzalez> gnarf: yes
[09:54:48] <jzaefferer> can we give Felix write access, asking him to commit only to our selectmenu branch?
[09:55:35] <scott_gonzalez> sure
[09:55:43] <danheberden> git checkout -B selectmenu™
[09:55:58] <danheberden> ^^ official
[09:56:01] <jzaefferer> okay, I'll take care of that and ask Felix what's up with the remaining open issues
[09:56:31] <jzaefferer> I guess we'll hear back from Colin eventually, I'll ping John Bender as well
[09:56:53] <jzaefferer> k?
[09:57:18] <scott_gonzalez> ok, though I don't think we can do much collaboration with Mobile right now
[09:57:24] <scott_gonzalez> that's going to be a massive undertaking
[09:57:32] <scott_gonzalez> which will be painful with how much work they've done already
[09:57:43] <scott_gonzalez> I was thinking that wouldn't happen until after 1.9
[09:58:05] <jzaefferer> well, I want to see what they're up to anyway
[09:58:23] <jzaefferer> maybe he can at least comment on the "what to do on mobile" question
[10:00:01] <gnarf> scott_gonzalez: pull reviews after grid meeting? anyone else?
[10:00:15] <scott_gonzalez> gnarf: sure
[10:01:11] <gnarf> kborchers: you able to be there? you are 5 of em ;)
[10:01:18] <jzaefferer> I can try to help
[10:01:49] <kborchers> i can over irc but not skype ... at work and have to still "appear" to be working ;)
[10:01:58] <gnarf> any quick comments on datepicker / download builder / disco'ed widgets / next 1.9 action?
[10:02:20] <gnarf> skypin bout jquery issues doesn't look like work? what a shame :)
[10:03:00] <kborchers> i know ... i have to be making mundane content updates and helping contributors update their web pages :(
[10:03:24] <jzaefferer> I've pinged felixge a few minutes ago, if I reach him I'll ask him to just commit whatever he has by now
[10:03:53] <kborchers> if you guys skype, i'll be on IRC if you have ?'s
[10:04:04] <jzaefferer> major 1.9 action is up to Scott I guess?
[10:04:19] <jzaefferer> let's discuss disco widgets later
[10:04:29] <jzaefferer> GRID MEETING NOW
[10:05:15] <jzaefferer> looks like gnarf, borismoore, brado23 and chrisBannon are here, Richard can't make it today
[10:05:23] <jzaefferer> am I missing someone?
[10:07:43] <jzaefferer> well, agenda is here: http://bit.ly/jqueryui-agenda
[10:07:55] <jzaefferer> I'll just go through the updates, let me know if you have any comments or questions
[10:08:19] <jzaefferer> I've been working on the editing components, the main demo got some heavy updates: http://view.jqueryui.com/grid/grid-editing/grid.html
[10:08:40] <jzaefferer> the Country column now has a custom editor, text input with autocomplete
[10:08:58] <jzaefferer> bitcoins is still a spinner, Random is also a spinner but with random step options
[10:09:16] <jzaefferer> all configured via data-attributes, implemented as custom editors
[10:09:36] <jzaefferer> which reminds me that I need to start speccing out the actual editor
[10:09:57] <jzaefferer> the grid now generates the columns option properly, reading a customizable set of data-attributes when not specified directly
[10:10:23] <jzaefferer> last but not least, $.observable as specced is implemented almost completely and integrated in that demo
[10:11:01] <jzaefferer> next step there is to experiment with event binding support on $.observable, which goes way beyond the initial design, but should help getting rid of the jQuery12312312312321 attributes on data attributes
[10:11:24] <jzaefferer> and once jQuery has a seperate pub/sub API, we can switch to that
[10:12:01] <borismoore> What is the concern about jQuery attributes on data, as long as they don't get serialized...?
[10:12:19] <jzaefferer> well, that's the concern, you have to adapt your serializer to ignore it
[10:13:06] <borismoore> Regular JSON serialization ignores based on criteria which are covered by those attributes, doesn't it...
[10:13:08] <jzaefferer> and the whole thing is only a workaround for issues related to DOM objects anyway
[10:13:27] <jzaefferer> criteria?
[10:13:30] <jzaefferer> what criteria?
[10:13:52] <jzaefferer> I'm pretty sure right now JSON.stringify just serializes those extra attributes
[10:14:03] <borismoore> I'll look for it, in a minute.
[10:14:10] <gnarf> jzaefferer: I'm pretty sure that the expando property has a toJSON that returns null
[10:14:19] <borismoore> correct, that's iut
[10:14:29] <borismoore> so stringify skips it
[10:14:32] <borismoore> it
[10:15:05] <jzaefferer> good to know
[10:15:17] <borismoore> If we store event handlers elsewhere, then when objects are disposed, you have to ensure cleanup
[10:15:22] <jzaefferer> so I guess its just my custom serialization code that had issues
[10:15:24] <gnarf> https://github.com/jquery/jquery/blob/master/src/data.js#L73
[10:15:32] <borismoore> We have no $.clean for objects
[10:16:03] <jzaefferer> says 1.5 only - does 1.6 have a better solution?
[10:16:05] <borismoore> $.html() etc. mean you can override $.clean, but nothing like that for objects
[10:16:14] <gnarf> jzaefferer: no, thats a csnover comment left there
[10:16:24] <gnarf> I've got some core 1.7 .data() issues tho
[10:16:25] <jzaefferer> so its still valid?
[10:16:30] <gnarf> and I think thats going to stay
[10:16:59] <jzaefferer> isn't jQuery.noop just function() {}?
[10:17:05] <jzaefferer> that is, return undefined, not null?
[10:17:10] <gnarf> yeah, undefined is better
[10:17:13] <gnarf> for toJSON
[10:17:35] <borismoore> Yes, but if there is a toJSON member, stringify skips
[10:17:49] <gnarf> ?js var o = {}; $(o).data("test", "test"); JSON.stringify( o );
[10:17:50] <borismoore> We don't call toJSON
[10:17:56] <jzaefferer> so JSON.stringify basically checks if a property has a toJSON method? if it has and it returns undefined, the property is ignored?
[10:18:05] <gnarf> doh no bot-t
[10:18:27] <borismoore> Not sure if it needs to return undefined, but if it exists, yes
[10:18:37] <jzaefferer> borismoore, right, but in my demo I had some custom serialization code that threw up over that property
[10:18:59] <jzaefferer> anyway, I'll go back and inspect the issue based on that, thanks guys
[10:19:04] <gnarf> if it has a toJSON property, it uses the value of toJSON to stringify
[10:19:07] <borismoore> You should follow the standard rules, which stringify does...
[10:19:11] <gnarf> so undefined == ignored
[10:19:17] <borismoore> ah OK
[10:20:30] <jzaefferer> there may still be some value in $.observable(object).bind("change", ...)
[10:20:39] <jzaefferer> but it would then just wrap the jQuery bind call
[10:20:56] <jzaefferer> and could use something else once available, instead of going through jQuery
[10:21:01] <jzaefferer> makes sense?
[10:21:07] <gnarf> also beware of $( obj ) where obj has a length property
[10:21:23] <gnarf> unless they recently fixed that, its buggy
[10:21:31] <borismoore> Right, but we are not using that
[10:21:52] <gnarf> if we are binding events to the data objects, we may be
[10:22:07] <borismoore> yeah
[10:22:07] <jzaefferer> currently doing $([ obj }).bind
[10:22:15] <jzaefferer> err, $([obj])
[10:22:20] <borismoore> that's right, [obj]
[10:22:46] <jzaefferer> which I think would be good to hide in $.observable(obj).bind
[10:22:53] <borismoore> Binding to arrays, too
[10:23:18] <borismoore> But yes, maybe an observable().bind makes sense
[10:23:38] <gnarf> solid
[10:23:47] <brado23> jzaefferer -- what's coming that we'd use instead of jQuery events?
[10:23:59] <brado23> just curious what you have in mind here
[10:24:02] <gnarf> ill stay quiet til we get down to my section then, u guys got this covered ;)
[10:24:09] <jzaefferer> there were discussions for jQuery Core to include a plain pub/sub option
[10:24:14] <jzaefferer> without going through jQuery
[10:24:26] <jzaefferer> no idea if that is still on the radar though, maybe gnarf knows more?
[10:24:34] <gnarf> pubsub in core?
[10:24:37] <brado23> k, if you have an URL I could review, I'd look it over
[10:24:42] <gnarf> haven't heard much talk about it
[10:24:52] <gnarf> but the pubsub impl that people seem to like is....
[10:25:00] <jzaefferer> lemme quickly check core agenda...
[10:25:03] <borismoore> A while back it was suggested, and decided against...
[10:25:15] <gnarf> http://bugs.jquery.com/ticket/7547
[10:25:19] <gnarf> its a wontfix
[10:25:20] <gnarf> so
[10:25:24] <jzaefferer> ah
[10:25:42] <brado23> There's certainly lots happening in eventing / pub\sub in other frameworks...like async, batching, etc.
[10:26:09] <borismoore> That quote from John is what I was remembering : This was discussed in the jQuery 1.6 roadmap meeting and we agreed that this was not something that we were going to put into core (leave as a plugin).
[10:26:09] <brado23> Don't know how big a limitation of jQuery this is in practice.
[10:26:21] <gnarf> http://weblog.bocoup.com/publishsubscribe-with-jquery-custom-events
[10:26:26] <jzaefferer> so let's add $.observable.bind as a wrapper around jQuery's event support, that should make it easy to use something else by overriding the bind and trigger methods on $.observable.prototype
[10:26:27] <gnarf> http://higginsforpresident.net/js/static/jq.pubsub.js
[10:26:38] <gnarf> its fn tiny
[10:26:57] <brado23> sounds reasonable
[10:27:15] <jzaefferer> so the todos there:
[10:27:17] <jzaefferer> 	•	add $.observable(obj).bind, delegating back to jQuery([obj]).bind, and update custom serialization to behave like JSON.stringify does 
[10:27:17] <jzaefferer> 	•	also refactor event triggering into a _trigger method, so that it can be customized (along with bind) 
[10:27:24] <gnarf> if you think it'd be useful for observable events, it might be worth externing it, but there are there licensee issues with new BSD / AFL ?
[10:27:55] <borismoore> There will always be the clean up issue. Need unbind too, obviously, partly for that reason.
[10:28:29] <gnarf> well, if you are using a pub/sub - you aren't binding to a specific object
[10:28:37] <jzaefferer> so add $.observable.prototype.unbind to delegate to jQuery.fn.unbind?
[10:28:44] <gnarf> you just publish a "observablechanged", observable, changeData
[10:29:04] <jzaefferer> gnarf, with pub/sub you define channels by giving them names, here the object is the channel
[10:29:08] <jzaefferer> right?
[10:29:16] <gnarf> i suppose you could use the object as a channel name
[10:29:27] <gnarf> i prefer strings that make sense
[10:29:54] <brado23> We're not changing the target of the subscription now, right?  These obs.bind/unbind are helpers over binding/unbinding to the data, right?
[10:30:07] <brado23> ...not to the observable?
[10:30:08] <jzaefferer> brado23, yeah, not planning to change that
[10:30:25] <brado23> k, sounds good
[10:31:05] <gnarf> there is a bit of overhead involved with jQuery events, but we are using them everywhere in UI
[10:31:24] <gnarf> might as well stick with the pattern for now i guess
[10:31:51] <brado23> jzaefferer - when do you want to discuss old/newValue re: refresh?  offline?
[10:31:57] <jzaefferer> if it works for mousemove events, it should also work for editings events, not that many updates
[10:32:16] <jzaefferer> brado23, well, still need to get back to you on that
[10:32:28] <brado23> sure, thx
[10:32:41] <jzaefferer> I'd be fine with extending the event, but that also needs to change in the method, which needs some discussion
[10:33:07] <brado23> agreed.  pls let me know, so we can discuss further
[10:33:14] <jzaefferer> will do
[10:33:46] <jzaefferer> so gnarf, wanna update us on custom inputs?
[10:33:56] <borismoore> Templates?
[10:34:07] <borismoore> Did Richard have any findings?
[10:34:11] <gnarf> so - mask is coming along pretty quickly
[10:34:24] <gnarf> i have a few choices need to be made there
[10:34:35] <gnarf> and there is some caret position issue with my droid
[10:34:47] <gnarf> not sure whats happening there yet, haven't found a great way to try to debug it
[10:35:25] <gnarf> there are some notes on the Mask wiki
[10:35:38] <gnarf> I want to try to handle doing a "hh:mm:ss" style mask
[10:35:47] <gnarf> its going to be a pain
[10:36:14] <jzaefferer> did you implement a value method that returns the raw input?
[10:36:18] <gnarf> yeah
[10:36:34] <gnarf> need to change that on the wiki still
[10:36:45] <jzaefferer> okay, can you also update the spec?
[10:36:52] * gnarf nods
[10:36:58] <jzaefferer> we can discuss the rest in -dev
[10:37:18] <jzaefferer> I'd rather have you figure those out, skip on hh:mm:ss and start with the timepicker (demo)
[10:37:35] <gnarf> well the hh/mm/ss kinda falls into timepicker :)
[10:37:50] <gnarf> but i need to move away from that problem for a bit and look for some inspiration
[10:38:02] <gnarf> so it makes sense
[10:38:14] <jzaefferer> yeah, let's see how the spinner can interact with mask first
[10:38:17] <gnarf> i want to try to get this droid issue fixed
[10:38:18] <jzaefferer> then get back to that if necessary
[10:38:26] <jzaefferer> also mobile is not a priority
[10:38:47] <jzaefferer> though feel free to bug the mobile team about caret positioning
[10:38:50] <gnarf> just note it on the wiki that still having issues with caret positions?
[10:38:57] <jzaefferer> yeah
[10:39:01] <gnarf> k
[10:39:16] <jzaefferer> borismoore: I don't have much to add on Templating beyond what's on the wiki
[10:39:40] <jzaefferer> Richard wrote me an email before he left for training this week, mentioning that he discussed with you once more, and that you may be working on updates for jsrender
[10:40:05] <borismoore> Yes, I just updated status on the agenda.
[10:40:05] <jzaefferer> apparently his evaluation of various engines wasn't very productive in the end, not sure what to do with that
[10:40:19] <jzaefferer> ah, okay, cool
[10:40:29] <borismoore> Has created a jsrender.js version that has no jQuery dependency. (And of course, no DOM dependency). Also working on a logic-less version of JsRender. Making good progress.
[10:41:30] <jzaefferer> would be nice to have jsrender work without jQuery ala Globalize, but then add a wrapper (in ui.core maybe?) that allows you to use it kind of like you could with jquery-tmpl, something like $.render( template, data) which would return an actual jQuery object, not just a string
[10:41:35] <borismoore> All local for the moment, BTW
[10:42:11] <borismoore> I have some of that kind of approach in there. To be developed further, probably...
[10:42:11] <jzaefferer> okay, let us know when there's something to look at
[10:42:40] <borismoore> sure
[10:43:57] <jzaefferer> well, that's mostly it for grid; there are some updates on Menu and Selectmenu, which are part of grid, but we're handling that as part of the regular UI meeting
[10:44:03] <jzaefferer> dunno if anyone is interested?
[10:45:41] <jzaefferer> apperently not, its on the wiki pages and agenda anyway
[10:46:02] <jzaefferer> unless we set up seperate meetings, see you next week!