[11:01:31] <agcolom> arschmitz: meeting time?
[11:01:58] <arschmitz> up
[11:02:00] <arthurvr> hi
[11:02:01] <arschmitz> yup
[11:02:04] <agcolom> hi!
[11:02:09] <agcolom> agenda https://docs.google.com/spreadsheets/d/1xGEVtftLDEHAA37YYlA23J_EZwIRyMUaseBY790byPM/edit#gid=510248145
[11:02:35] <arschmitz> gabriel_schulhof: sfrisk: jasperdegroot: cgack: lisa_deluca: Meeting Time!
[11:02:41] <sfrisk> allo
[11:02:47] <lisa_deluca> hola
[11:02:53] <cgack> howdy
[11:02:56] <jasperdegroot> hi all
[11:03:07] <gabriel_schulhof> Hey, all!
[11:04:33] <arschmitz> Ok lets start with classes
[11:04:44] <arschmitz> Im still itterating on this
[11:04:51] <arschmitz> its should land within a few days on master
[11:05:13] <arschmitz> its just waiting on adding some backcompat on a few of the ui widget we decided to make changes on
[11:05:35] <arschmitz> related to this last time we talked about the propper way to do class tests
[11:05:44] <arschmitz> the plan here changed again
[11:05:57] <arschmitz> pretty sure we have a final answer now though
[11:06:22] <arschmitz> i wrote 2 new custom asserts which im going to publish as a quint plugin
[11:06:48] <arschmitz> hasClasses and lacksClasses( element, classsting )
[11:07:12] <arschmitz> you dont need to use a message and it will generate an actual usable diff when it fails
[11:07:21] <arschmitz> and its also not order dependant
[11:07:41] <arschmitz> lacksClasses is the same as !element.hasClass( "class" )
[11:10:40] <arschmitz> gabriel_schulhof: also discovered an issue with controlgroup
[11:11:00] <jasperdegroot> yeah, I just noticed it's broken in ui-1-12
[11:11:02] <arschmitz> which was discussed in the ui meeting yesterday and thats going to be fixed
[11:11:13] <arschmitz> jasperdegroot: only with invalid markup
[11:11:22] <jasperdegroot> ah ok
[11:11:28] <arschmitz> jasperdegroot: but we are changing whats valid markup
[11:11:44] <jasperdegroot> I was about to update controlgroup and checkboxradio demos
[11:12:01] <arschmitz> jasperdegroot: right now controlgroup cant have textinputs with out an extension or scelectmentus
[11:12:18] <arschmitz> and inputs nested inside a label for checkboxradios dont work
[11:12:24] <arschmitz> because the input MUST be a child
[11:12:28] <jasperdegroot> I see
[11:12:33] <arschmitz> but going to make an execption for that
[11:12:41] <arschmitz> because that should be valid
[11:13:15] <jasperdegroot> yes
[11:13:25] <arschmitz> so the tests branch just has one broken test left
[11:13:39] <gabriel_schulhof> ... which I'm fixing.
[11:13:41] <arschmitz> which i gabriel and i discussed today and have a plan to fix that
[11:14:00] <arschmitz> yup
[11:14:08] <cgack> i also noticed checkboxradios has a bad init selector on ui-1-12 too.. see http://view.jquerymobile.com/ui-1-12/demos/flipswitch/
[11:14:08] <arschmitz> so we will merge that as soon as hes done
[11:14:21] <arschmitz> cgack: thats fixed in tests branch
[11:14:29] <cgack> right on
[11:14:31] <arschmitz> gabriel_schulhof: right?
[11:15:23] <gabriel_schulhof> Yep.
[11:15:29] <arschmitz> ok great
[11:15:51] <cgack> super!
[11:16:23] <arschmitz> ok anything else that any one has noticed for ui-1-12 related stuff?
[11:17:50] <gabriel_schulhof> Just a generic thing.
[11:18:14] <gabriel_schulhof> I have a bunch of PRs pending, which will modify master a great deal, so we might have a bear of a time rebasing.
[11:18:29] <gabriel_schulhof> Even without any of those PRs it won't be smooth.
[11:18:49] <gabriel_schulhof> I'm not sure how we'll wrestle all the branches into master without losing fixes in the process.
[11:18:52] <arschmitz> its fine ill rebase ui-1-12 after we land them
[11:19:06] <arschmitz> you just need to go 1 commit at a time
[11:19:29] <gabriel_schulhof> Yes, and be aware which side of the conflict intends to achieve what.
[11:19:38] <arschmitz> yup
[11:19:50] <arschmitz> im so used to it with all the back and forth on branches in ui and mobile
[11:20:23] <gabriel_schulhof> Well, alright.
[11:20:23] <arschmitz> this has been a crazy development cycle
[11:20:33] <arschmitz> too much intedependency on changes
[11:20:42] <gabriel_schulhof> I'll sign any document that states that ... I think I just signed one.
[11:21:16] <gabriel_schulhof> ... and we thought 1.4.0 was hectic ... :)
[11:21:32] <arschmitz> it was in a different way
[11:21:35] <gabriel_schulhof> insanity²
[11:21:52] <arschmitz> that was hard to keep track of this has been pretty linear
[11:22:07] <arschmitz> its just 1 step forward 2 steps back constantly lol
[11:22:33] <gabriel_schulhof> :)
[11:22:51] <arschmitz> ok RTL call will be next week
[11:22:59] <gabriel_schulhof> The only other thing I had was a shoutout to jasperdegroot to please have a look at https://github.com/jquery/jquery-mobile/issues/4259
[11:23:10] <gabriel_schulhof> But anyway, jasperdegroot, whenever you have some time.
[11:23:18] <gabriel_schulhof> jasperdegroot: I suspect I'm out of my league for that one.
[11:23:30] <jasperdegroot> ah, that one
[11:23:36] <gabriel_schulhof> Yes, /that/ one.
[11:24:06] <jasperdegroot> ok, I will take a look again
[11:24:11] <gabriel_schulhof> jasperdegroot: Thanks!
[11:24:48] <arschmitz> ok jasperdegroot thank you
[11:24:53] <gabriel_schulhof> arschmitz: Got any specific coordinates for the RTL call? I'd love to be a fly on the wall.
[11:25:08] <arschmitz> gabriel_schulhof: talk to scott_gonzalez hes organizing it
[11:25:14] <gabriel_schulhof> OK. Thanks!
[11:26:04] <arschmitz> ok accordion
[11:26:30] <arschmitz> sfrisk: got a chance to get a start on that this morning
[11:26:38] <scott_gonzalez> gnarf: It will be some time next Friday afternoon, exact time not chosen yet.
[11:26:39] <arschmitz> but she got pulled away on "REAL" work
[11:26:55] <gabriel_schulhof> scott_gonzalez: Thanks!
[11:27:02] <arschmitz> so no update other then she started
[11:28:57] <arschmitz> no updats on data attributes or autoinit iv been on other things
[11:29:47] <arschmitz> so this morning gabriel_schulhof brought up concern over accessing dom element.id directly
[11:30:12] <arschmitz> we often tend to access dom properties directly like this to avoid the jquery overhead
[11:30:30] <gabriel_schulhof> We still can use direct DOM access, but via .getAttribute()
[11:30:45] <gabriel_schulhof> ... if we don't have a jQuery object handy.
[11:31:06] <gabriel_schulhof> IIRC DaveMethvin once said that .getAttribute() was pretty stable.
[11:31:12] <arschmitz> gabriel_schulhof: i think we should generally stick to jquery this points out edge cases which can be eaisly avoided
[11:31:18] <arschmitz> gabriel_schulhof: for exampel this is not just ids
[11:31:25] <arschmitz> this same thing is true for any property
[11:31:47] <arschmitz> if you name an input with the id of any native property this can happen
[11:32:11] <gabriel_schulhof> OK, but we shouldn't unnecessarily instantiate jQuery objects.
[11:32:46] <arschmitz> gabriel_schulhof: unless its in a super critical location and in a loop the over head here is not going to be a concern
[11:33:10] <gabriel_schulhof> Yeah, OK ... like, event handlers (other than maybe resize or updatelayout) I guess are good.
[11:33:16] <arschmitz> and i think just about always we are doing somethign else besides just getting a single attribute
[11:34:06] <arschmitz> we dont want to get caught up on micro optimization
[11:34:08] <gabriel_schulhof> Actually, that's an excellent point. We don't normally use .id on a whim, so there's probably a good reason we don't want to use .attr( "id" ) - like performance.
[11:34:31] <gabriel_schulhof> So, I think if we go over all the instances of .id, we can make a case-by-case call as to whether we should go with .getAttribute() or .attr()
[11:35:15] <arschmitz> i would prefer to see us consistently use .attr unless there is a place where it is going to make a real difference
[11:35:26] <arschmitz> which would i think have to be in a pretty tight loop
[11:35:56] <arschmitz> and that would make me question we were doing it right in the first place
[11:36:29] <gabriel_schulhof> ... or in _create() for a widget which can appear many times on a page.
[11:36:29] <arschmitz> attributes dont change that often generally to have to re check that often
[11:36:35] <gabriel_schulhof> Like a button, or a checkbox.
[11:36:45] <arschmitz> potentially
[11:36:48] <gabriel_schulhof> ... or a textentry.
[11:37:13] <arschmitz> im sure there are cases where its going to make sense but lets deal with those as they come up
[11:37:15] <gabriel_schulhof> I'm most concerned with _create(), actually.
[11:37:25] <gabriel_schulhof> Yeah - case-by-case, definitely.
[11:38:37] <arschmitz> gabriel_schulhof: ok and you have a few things
[11:38:50] <gabriel_schulhof> Oh, on the agenda?
[11:38:53] <arschmitz> yes
[11:39:51] <gabriel_schulhof> Well, we've established wrt. testing the build, and I don't think I'll prioritize .animationComplete() handler removal.
[11:40:08] <gabriel_schulhof> The issue is open, but for now, it's classes, classes, classes, and then ... more classes.
[11:40:41] <gabriel_schulhof> ... and the perf bug is pretty much PR-ed.
[11:40:58] <arschmitz> yeah
[11:41:04] <arschmitz> classes is priority #1 right now
[11:41:16] <arschmitz> we need to get to a beta soon
[11:41:21] <arschmitz> and we can fix bugs in beta
[11:41:39] <gabriel_schulhof> There's a small side-effect of the perf bug fix.
[11:41:56] <gabriel_schulhof> I also modified popup to to the active element retrieval inside a try {}
[11:42:19] <gabriel_schulhof> So far, pagecontainer had the try{} but not the skip-body-and-window, and popup had the skip-body-and-window, but not the try.
[11:42:24] <gabriel_schulhof> After this PR, both have both.
[11:42:32] <gabriel_schulhof> In fact, this is $.fn material.
[11:42:55] <gabriel_schulhof> How to safely blur something.
[11:43:04] <arschmitz> hmmm
[11:43:15] <arschmitz> this also is an issue directly in core and in ui
[11:43:25] <arschmitz> so maybe we want to have a larger discussion on this
[11:43:40] <gabriel_schulhof> Yeah, I guess it's pretty common code.
[11:43:47] <gabriel_schulhof> ... and, of course, all because of IE :(
[11:43:49] <arschmitz> we are all basically copy and pasting the same logic
[11:43:54] <gabriel_schulhof> Yep.
[11:44:06] <arschmitz> ill bring this up in dev leads
[11:44:17] <gabriel_schulhof> There's two distinct things though: The try{} around retrieving document.activeElement, and the checks before you .blur().
[11:45:12] <agcolom> got to go... sorry
[11:45:21] <gabriel_schulhof> agcolom: L8R
[11:45:21] <arthurvr> bye agcolom!
[11:45:38] <arschmitz> agcolom: bye
[11:46:20] <gabriel_schulhof> arschmitz: The only way to handle both in one API would be $.safelyBlur( elements /* jQuery object or element or, if absent, referring to document.activeElement */ )
[11:46:36] <arschmitz> yeah
[11:47:23] <gabriel_schulhof> arschmitz: I could whip up a quick PR, I suppose, so people can have code to tear apart.
[11:48:36] <arschmitz> gabriel_schulhof: what ever you think makes sense
[11:49:16] <gabriel_schulhof> Yeah, sure. Can do.
[11:50:09] <arschmitz> ok anything else?
[11:52:07] <arschmitz> i guess not
[11:52:25] <arschmitz> ok see every one back on -dev