[09:00:31] <DaveMethvin> timmywil gibson042 markelog jaubourg rwaldron gnarf mikesherov m_gol Core meeting time!
[09:00:43] <timmywil> hooray!
[09:00:51] <DaveMethvin> that's what i wanna hear!
[09:01:05] <timmywil> jquery unite
[09:01:16] <DaveMethvin> we need a secret handshake
[09:01:44] <timmywil> I'll be "heart"
[09:01:51] <DaveMethvin> anybody else around?
[09:02:24] <timmywil> There's a richard
[09:02:25] <m_gol> present!
[09:02:31] <DaveMethvin> this should be a good week for me, i'm actually around all week and not traveling
[09:02:54] <m_gol> but on a mercy of a 3G connection ;)
[09:02:55] <timmywil> I'm traveling today, but back tomorrow
[09:02:59] <gibson042> hello hello
[09:03:09] <DaveMethvin> now it's a party
[09:03:35] <DaveMethvin> so a bunch of stuff has piled up pull-wise
[09:03:43] <DaveMethvin> figured we'd run thru them quickly
[09:04:58] <DaveMethvin> that one i was doing with cross-frame focus,, i did a bit of triage on it and saw that it's the selection of the element failing in old Opera .... still not worth trying to fix it but I can use that to skip it better
[09:05:24] <DaveMethvin> sounds like jaubourg is gonna be  out for a while so let's look at those ajax tix
[09:06:14] <DaveMethvin> on #14207 seems like the fix of removing || 404 would work and return it to 1.x behavior
[09:06:53] <DaveMethvin> and having readyState 0 for a request that doesn't return, isn't that the correct behavior anyway?
[09:07:09] <DaveMethvin> oh "fail without contacting a server"
[09:08:04] <DaveMethvin> anyway I'll give this a run, not sure whether we have tests for it
[09:09:20] <m_gol> yeah, especially that jaubourg already confirmed it can be fixed in this way
[09:10:04] <DaveMethvin> on #14424 it seems like we'd need to bring back createActiveXHR in 2.0 to support local access, which is fine with me
[09:10:14] <DaveMethvin> but we'd want to use it only on local access
[09:11:05] <timmywil> fine with me too
[09:12:01] <DaveMethvin> thFor #14475 we can't feature-detect the same way in IE11 but I have the workaround for that somewhere
[09:12:02] <gibson042> yeah, that's pretty much 1.x anyway
[09:12:11] <DaveMethvin> has to be an explicit test as I recall
[09:12:30] <DaveMethvin> IE11 is trying to  hide all the implied "is this IE?" checks
[09:12:53] <DaveMethvin> i'll take that one too
[09:12:57] <m_gol> hmm
[09:13:08] <m_gol> why is that a problem that the standard XHR is used always in IE11?
[09:13:57] <DaveMethvin> the standard one in IE11 won't allow local file access, kind of like Chrome
[09:14:02] <DaveMethvin> but the activex one will
[09:14:07] <DaveMethvin> unlike chrome :)
[09:14:08] <m_gol> ah
[09:14:11] <m_gol> weird
[09:14:30] <DaveMethvin> backcompat no doubt, they had to still allow it for the activex version
[09:15:02] <DaveMethvin> https://github.com/jquery/jquery/pull/1425
[09:15:03] <b-ot> DaveMethvin: Pull request #1425 by mzgol (1d 16h ago): Fix #14340. Remove remnants of oldIE from unit tests.
[09:15:12] <gibson042> it'll be just like 1.x-master: https://github.com/jquery/jquery/blob/ef7f8f1ead0d80e53cde0a2c7d6af289bd182ce0/src/ajax/xhr.js#L9-L20
[09:15:18] <m_gol> so why do we need to support their backcompat activex weirdness?
[09:15:29] <DaveMethvin> because people want to get local files
[09:15:41] <DaveMethvin> and they can get them on 1.x but not 2.x
[09:16:15] <DaveMethvin> you can get them on chrome too, but only if you launch with some command line flag
[09:16:22] <m_gol> I wonder what happens if IE12 removes the ActiveX XHR completely ;)
[09:16:48] <DaveMethvin> then people are screwed like they are in Chome, which won't hurt my feelings
[09:17:29] <m_gol> ok, so we're patching it for now for backcompat but if IE removes the workaround, we stop caring
[09:17:33] <m_gol> fine by me
[09:17:46] <DaveMethvin> yeah if they took it out it would be a cantfix to us
[09:17:47] <timmywil> 1425 can probably land
[09:17:52] <DaveMethvin> agreed
[09:18:07] <DaveMethvin> it does introduce more diffs between the branches but it cleans up the tests which i like
[09:18:38] <m_gol> and it makes some tests more strict
[09:18:41] <timmywil> ah true, more potential for cherry-pick conflicts
[09:18:54] <timmywil> but I can deal
[09:18:59] <DaveMethvin> i don't think they'll cause much problem
[09:19:10] <gibson042> agreed
[09:19:21] <m_gol> I don't think most of these tests get modified too often :)
[09:19:46] <DaveMethvin> plus there are some ugly things in there
[09:19:47] <DaveMethvin> https://github.com/jquery/jquery/pull/1421
[09:19:48] <b-ot> DaveMethvin: Pull request #1421 by ChrisAntaki (5d 11h ago): Reduced size by reordering variable declarations
[09:19:55] <m_gol> ;)
[09:20:00] <timmywil> $25 per byte is a STEAL
[09:20:05] <DaveMethvin> lol
[09:20:27] <gibson042> make sure to send checks to team members first :D
[09:20:36] <DaveMethvin> let's land this if everyone wants but not make a pattern of it since it causes a bunch of conflicts
[09:20:54] <gibson042> +1
[09:21:00] <DaveMethvin> and 19 bytes is not that much
[09:21:31] <DaveMethvin> actually let's land this last
[09:21:37] <DaveMethvin> see how well it survives
[09:21:43] <m_gol> haha
[09:22:05] <DaveMethvin> https://github.com/jquery/jquery/pull/1419
[09:22:06] <b-ot> DaveMethvin: Pull request #1419 by gibson042 (6d 12h ago): Fix #14492: More correct jQuery.parseJSON
[09:22:08] <m_gol> it makes sense to do such modifications on code that is kind-of stable
[09:22:17] <m_gol> less so if we plan to modify it
[09:22:21] <DaveMethvin> call me chicken but i'm worried about .parseJSON(null)
[09:22:49] <DaveMethvin> all the other cases not so much
[09:23:11] <DaveMethvin> i still like Migrate warning on it
[09:23:12] <m_gol> I guess we could cast to a string before passing to the method
[09:23:21] <gibson042> well, Android 2.3 will barf on it unless we always insert ourselves in front of JSON.parse
[09:23:22] <m_gol> since the spec does it anywa
[09:23:22] <m_gol> y
[09:23:46] <gibson042> fixing that means changing 2.x as well
[09:23:51] <DaveMethvin> gibson042 yeah i know
[09:24:04] <DaveMethvin> which is why i am just worried but haven't wanted to do anything about it :)
[09:24:23] <gibson042> our docs specify string input...
[09:24:32] <DaveMethvin> oh gibson042 you slay me :)
[09:24:37] <DaveMethvin> docs! ha!
[09:24:54] <m_gol> ;)
[09:25:00] <m_gol> OTH the fix is really simple
[09:25:02] <m_gol> and short
[09:25:08] <m_gol> +'' and we're done
[09:25:16] <DaveMethvin> jquery 1.2.1 did it that way, if it was good enough for grampa it's good enough for me
[09:25:29] <m_gol> ah, not so simple since we would have to wrap it in a function as well
[09:25:35] <DaveMethvin> true dat, but we can't delegate directly to JSON.parse
[09:25:50] <m_gol> yeah, that's what I just noticed ;)
[09:25:52] <gibson042> meh
[09:26:03] <DaveMethvin> also "[object Object]"
[09:26:16] <gibson042> if it has us talking this much anyway, let's just do the string cast in both branches and move on
[09:26:33] <DaveMethvin> good point, gibson042
[09:26:40] <DaveMethvin> you want to do the honors?
[09:26:46] <gibson042> yep
[09:26:54] <timmywil> gibson042: hurrah!
[09:26:58] <m_gol> one more reason to slay Android 2.3 ;)
[09:27:24] <DaveMethvin> https://github.com/jquery/jquery/pull/1415
[09:27:24] <b-ot> DaveMethvin: Pull request #1415 by brynary (1w 3d ago): Add Code Climate badge
[09:27:27] <gibson042> it'll be a good day when 2.x drops it :)
[09:27:51] <DaveMethvin> i'm okay with this badge in the readme, i like the complexity reminder
[09:28:33] <DaveMethvin> if people start making PRs *just* to reduce complexity then i think they've missed the point
[09:28:41] <timmywil> I don't think it needs to be in the README. Seems better as a dev tool (as in a grunt task)
[09:29:11] <DaveMethvin> JSHint has several of these measures
[09:29:20] <DaveMethvin> but i would prefer not to have more output during build
[09:29:23] <timmywil> even more of a reminder as I never look at the readme unless I'm changing something
[09:30:00] <m_gol> yeah, we don't look at README and some users do
[09:30:13] <DaveMethvin> is that good or bad m_gol :)
[09:30:15] <m_gol> seems like we want to aim the other way round :)
[09:30:36] <m_gol> I mean in this case, not in general :P
[09:31:02] <DaveMethvin> seems like nobody is particularly excited one way or the other
[09:31:33] <timmywil> It's a question of audience and the README seems like the wrong place for those kinds of metrics. It's more of an AD for code climate than a reminder of complexity to the development team.
[09:31:49] <DaveMethvin> fair point, i'll close it
[09:31:53] <DaveMethvin> https://github.com/jquery/jquery/pull/1415
[09:31:54] <b-ot> DaveMethvin: Pull request #1415 by brynary (1w 3d ago): Add Code Climate badge
[09:32:11] <DaveMethvin> https://github.com/jquery/jquery/pull/1400
[09:32:12] <b-ot> DaveMethvin: Pull request #1400 by iliakan (3w 6d ago): Remove elem property from event handle
[09:32:14] <DaveMethvin> there that one
[09:32:39] <DaveMethvin> we can do this for 2.x but not 1.x since we need elem for cleaning up oldIE
[09:33:10] <DaveMethvin> i think I need to look a bit more at this, but would like to land it
[09:33:25] <m_gol> can we test it somehow?
[09:33:34] <timmywil> yea, I defer to you on that one.
[09:34:21] <DaveMethvin> the problem he mentions with data would be fixed if we attached data to the element directly
[09:34:37] <DaveMethvin> so this is one-half of it
[09:35:03] <DaveMethvin> we need to go back and work on the .data() impementation in 2.x which is slower than 1.x right now anyway
[09:35:17] <gibson042> gotta run for a bit, but to weigh in on data-* scraping: I vote to match the HTML5 and shim backcompat with jquery-migrate
[09:35:18] <timmywil> agreed
[09:35:42] <DaveMethvin> ok thanks gibson042
[09:35:45] <m_gol> rwaldron seems attached to this impl ;)
[09:35:54] <DaveMethvin> https://github.com/jquery/jquery/pull/1384
[09:35:55] <b-ot> DaveMethvin: Pull request #1384 by ameyms (1mon 2w ago): Keep copyright year up-to-date
[09:36:19] <DaveMethvin> doesn't solve the whole problem but let's land this ... and make a note to change the other places come January :)
[09:36:38] <m_gol> I'm actually not sure if it's a good idea in this form
[09:36:51] <m_gol> if we see a generated year, we might forget it's not generated in other places
[09:37:00] <timmywil> I'd like to hear Scott's thoughts
[09:37:04] <DaveMethvin> what are your concerns m_gol
[09:37:22] <m_gol> so I'd like to make it generated everywhere
[09:37:28] <rwaldron> DaveMethvin, m_gol I had an impl that used expandos, but it rotted
[09:37:57] <timmywil> this is something we could do the same way across all the projects, which is appealing to me but admittedly not necessary
[09:38:19] <DaveMethvin> yeah it's mainly one of those annual "we forgot a place" exercises :)
[09:38:42] <m_gol> I see only one other place that contains 2013
[09:38:44] <m_gol> it's in intro
[09:38:51] <m_gol> and we could tackle it in a build stepa
[09:38:54] <m_gol> * step
[09:38:57] <m_gol> as we do with date
[09:39:02] <m_gol> it should probably land as one commit
[09:39:07] <DaveMethvin> do you want to tackle that m_gol
[09:39:14] <m_gol> I'm not sure why Scott claims it can't be dynamic here
[09:39:33] <timmywil> might have something to do with lawyers :P
[09:39:35] <m_gol> maybe I'll ask ameyms first if he wants to do it since he reported the PR
[09:39:36] <rwaldron> DaveMethvin should I update the data-as-expandos patch?
[09:39:37] <DaveMethvin> it just will have to do it every time, a bit repetetive
[09:39:49] <m_gol> ha, didn't think about that ;)
[09:39:49] <DaveMethvin> rwaldron it'd be great to see that impl
[09:39:53] <rwaldron> suer
[09:39:55] <rwaldron> sure*
[09:40:31] <m_gol> so I can get on top of that but I'd like to hear what scott_gonzalez has to say about it
[09:40:35] <DaveMethvin> m_gol good point, might as well ask him to do it
[09:40:37] <DaveMethvin> sure
[09:40:41] <rwaldron> This should be simple actually
[09:40:42] <DaveMethvin> just ask him on that pull
[09:40:50] <rwaldron> all the changed appear to be in the Data class itself
[09:41:02] <m_gol> yup
[09:41:21] <DaveMethvin> we may be able to avoid a lot of cleanData, at least if there are no events bound
[09:42:23] <DaveMethvin> https://github.com/jquery/jquery/pull/1377
[09:42:23] <b-ot> DaveMethvin: Pull request #1377 by johnkpaul (1mon 2w ago): Integrate Sinon.JS fake timers into effects tests
[09:42:47] <timmywil> I would love to land that, but we should do it for both branches
[09:42:54] <DaveMethvin> i'd love to get this in soon, guess we should ping johnkpaul
[09:42:58] <m_gol> 3G -> EDGE :(
[09:45:08] <DaveMethvin> so gibson042 https://github.com/jquery/jquery/pull/1367
[09:45:08] <b-ot> DaveMethvin: Pull request #1367 by gibson042 (1mon 3w ago): Fix #13353; #13428; #14359: Better treatment of native-backed events (focus/blur/checkbox-click)
[09:45:32] <DaveMethvin> how about if we land this after refactoring events to do the low-level API?
[09:45:50] <gibson042> works for me
[09:45:54] <DaveMethvin> it's a 2.2 thing for sure
[09:46:13] <gibson042> I'm not 100% committed to landing it, but having that gap really irks me
[09:46:21] <DaveMethvin> maybe we even try to do native event triggering rather than our fake triggering
[09:46:35] <DaveMethvin> it would be a big change but so nice not to do all that junk
[09:46:44] <DaveMethvin> i have no idea whether it's possible tho
[09:48:04] <DaveMethvin> https://github.com/jquery/jquery/pull/1340
[09:48:04] <b-ot> DaveMethvin: Pull request #1340 by njhamann (2mon 2w ago): Fix #14036 - ajaxLocation Includes HTTP Basic Authentication Info
[09:48:50] <DaveMethvin> seems like somethign is broken right now
[09:49:04] <DaveMethvin> i haven't looked at it for a while
[09:49:49] <m_gol> well, the substitution is wrong
[09:49:49] <m_gol> we should ping the author again
[09:50:23] <DaveMethvin> done
[09:50:50] <DaveMethvin> so, what's everyone thinking regards http://bugs.jquery.com/ticket/14376#comment:7
[09:50:58] <DaveMethvin> other than I HATE DATA
[09:51:00] <m_gol> there's one more PR
[09:51:07] <m_gol> https://github.com/jquery/jquery/pull/1426
[09:51:07] <b-ot> m_gol: Pull request #1426 by mzgol (16h 57m ago): No ticket. Remove the unnecessary guard in addGetHookIf.
[09:51:10] <m_gol> ;)
[09:51:51] <DaveMethvin> +1 on that from me m_go
[09:52:20] <m_gol> I was actually convinced I commited that in this way...
[09:52:22] <timmywil> m_gol: +1
[09:52:32] <m_gol> I had to forgot about it
[09:52:55] <timmywil> as for #14376, is it crazy to allow both?
[09:53:31] <DaveMethvin> whynotboth.gif
[09:53:38] <gibson042> DaveMethvin: YES it is crazy
[09:53:42] <timmywil> maybe it is, data-foo42 vs. data-foo-42: which takes precedence
[09:54:06] <DaveMethvin> i really dislike the camel-no-camel confusion this brings
[09:54:29] <DaveMethvin> and now the data- attributes can sometimes have dashes sometimes not depending on whether they follow a letter
[09:54:34] <timmywil> maybe if users want camelCase conversion, they should do this: dataCAMELfooCAMEL42
[09:55:33] <timmywil> well, if I have to choose, I vote to follow the spec
[09:55:38] <DaveMethvin> maybe we can just take a hard look at the full semantics and how they compare to data- attribute semantics
[09:55:52] <DaveMethvin> i am not sure we have completely written it down
[09:56:00] <gibson042> any camelcasing at all seems insane, but since it's in the spec we can redirect the blame to them
[09:56:03] <DaveMethvin> and if we did whether i could keep my lunch down while reading it
[09:56:04] <timmywil> better to be future-proof than backwards compatible
[09:56:15] <DaveMethvin> but there are two data stores in play here
[09:56:21] <DaveMethvin> that's the confusion
[09:56:24] <gibson042> like removing a Band-Aid...
[09:56:33] <timmywil> nice
[09:56:39] <rwaldron> timmywil yes... follow the spec... but that means we break back compat.
[09:56:50] <rwaldron> it's not as simple as "let's just do the right thing"
[09:56:58] <DaveMethvin> right
[09:57:09] <timmywil> rwaldron: I know, I thought you were for that as well?
[09:57:10] <DaveMethvin> and no matter what it's even MORE confusing
[09:57:18] <rwaldron> the right thing: Not conflating data() and data-* to begin with.
[09:57:43] <DaveMethvin> for now imma leave it open, we're almost out of time and there's more to be discussed
[09:57:59] <m_gol> rwaldron: THAT would be breaking ;)
[09:57:59] <DaveMethvin> yeah, combining this was the wurst thing evar
[09:58:03] <gibson042> but even if we did that, there's still two similar implementations doing dash removal, and it'll be better for all parties if the rules match
[09:58:33] <DaveMethvin> we don't do dash removal at all for internal data storage
[09:58:35] <rwaldron> gibson042 there is a bug in Chrome
[09:58:40] <rwaldron> FF does it right
[09:58:43] <DaveMethvin> only to match stuff we pulled from data-
[09:58:45] <rwaldron> I haven't looking in anything else
[09:59:01] <rwaldron> Where this falls down is...
[09:59:01] <gibson042> yeah, Chrome just adds another turd to the punchbowl
[09:59:13] <rwaldron> $("div").data("foo42", 1) <---
[09:59:33] <rwaldron> and then
[09:59:40] <rwaldron> (or alternatively)
[10:00:07] <rwaldron> $("div").data("foo42"); // was that data-foo-42, data-foo42 or just a plain old property?
[10:00:25] <gibson042> you set it, it's your problem
[10:00:35] <DaveMethvin> hmm, maybe we deprecate the data- access via data and switch to .dataSet()
[10:00:38] <rwaldron> I'm inclined to lean that way
[10:00:54] <DaveMethvin> let me just cover the last two items quickly --- can we publish this beta to npm?
[10:00:56] <rwaldron> but even more harshly: don't put numbers in your data-* attr names
[10:01:16] <rwaldron> DaveMethvin sounds like a plugin...
[10:01:23] <DaveMethvin> yeah it does to me too
[10:01:37] <DaveMethvin> unless we also deprecate .data() sucking in data- attributes
[10:01:47] <DaveMethvin> and put this whole damn thing away
[10:01:59] <timmywil> rwaldron: brilliant
[10:02:00] <rwaldron> also... I merged that patch...
[10:02:03] <gibson042> anyway, I'm up against a hard stop, but one last thing: major props from someone I met over the weekend for jquery-migrate
[10:02:09] <m_gol> this is big so we might want to lean to a longer deprecated period
[10:02:14] <rwaldron> I'm shocked at how easy that was
[10:02:22] <timmywil> m_gol: this is also true
[10:02:22] <gibson042> they're on 1.9 now, but without it they'd either still be using 1.4 or some other library entirely
[10:02:29] <DaveMethvin> gibson042 yay!
[10:02:40] <DaveMethvin> yeah migrate turned out to be a good way to solve it
[10:02:51] <gibson042> AND they're done with migrate as of this week, making it a correct use :D
[10:02:58] <DaveMethvin> timmywil i need to ping you on how to publish to bower
[10:03:08] <timmywil> migrate: document.write('<script src='data-star-shit.js'>')
[10:03:14] <DaveMethvin> lol
[10:03:32] <DaveMethvin> alright, gotta go
[10:03:41] <m_gol> so do we publish to npm?
[10:03:48] <m_gol> the beta, that is
[10:03:51] <timmywil> DaveMethvin: sorry, I plan to automate this for you in the release script. what day are you wanting to publish the beta?
[10:03:52] <m_gol> as a canary build
[10:04:02] <DaveMethvin> how about thursday this week?
[10:04:03] <timmywil> yea, we can do npm and bower in one go
[10:04:04] <DaveMethvin> i like thursday
[10:04:07] <DaveMethvin> good!
[10:04:21] <timmywil> ok, I'll try to have an update for you by then
[10:04:24] <DaveMethvin> thanks
[10:04:27] <m_gol> timmywil DaveMethvin: the release script should differentiate between beta & final versions wrt publishing on npm
[10:04:38] <m_gol> we don't want `npm install jquery` to install a beta
[10:04:42] <DaveMethvin> yep, it knows based on the version number
[10:04:52] <timmywil> m_gol: agreed
[10:05:01] <DaveMethvin> lots of stuff like the cdn builds don't get done on betas
[10:05:13] <DaveMethvin> see you guys back in -dev
[10:05:20] * timmywil peace