[09:00:38] <DaveMethvin> hey everybody!
[09:00:43] <DaveMethvin> who's here?
[09:01:02] <DaveMethvin> looks like timmywil started an agenda, thanks
[09:01:14] <timmywil> yurp
[09:01:26] <timmywil> or as jdalton would say...yap
[09:02:39] <DaveMethvin> looks like gibson042 is hiding here
[09:02:53] <DaveMethvin> m_gol markelog you guys here?
[09:05:10] <gibson042> here
[09:05:20] <markelog> give me a sec
[09:05:23] <markelog> hey-hey
[09:07:51] <DaveMethvin> maybe it's just a feeling of new paint, but it seems easier to reply to issues now that we're on GH issues
[09:09:04] <DaveMethvin> imma start, i have a hard stop at 1pm altho i think we can finish before that
[09:09:19] <DaveMethvin> trac still can be slow but it's a lot better now that we don't depend on it
[09:09:33] <DaveMethvin> many thanks to m_gol for migrating all the stuff
[09:09:54] <DaveMethvin> the new tags are there
[09:10:26] <DaveMethvin> so last time i think we said we'd just assign issues to milestones and leave the others without any milestone
[09:10:33] <DaveMethvin> which is fine with me
[09:10:42] <DaveMethvin> we can do a query for those i think, let me check
[09:11:11] <m_gol> Present
[09:11:27] <DaveMethvin> oh we do have the "future" milestone ... do we want it?
[09:11:29] <m_gol> ok, too late :D
[09:11:52] <m_gol> or not too late
[09:11:54] <m_gol> nvm
[09:12:06] <DaveMethvin> yeah it's all pretty easy to change
[09:12:14] <m_gol> actually, Trac became fast too me today :P
[09:12:22] <DaveMethvin> WHAT!
[09:12:24] <m_gol> maybe it works better when it feels there are no bugs
[09:12:27] <m_gol> to handle
[09:12:39] <DaveMethvin> yeah on most pages it just displays very quickly
[09:12:46] <DaveMethvin> some reports can be slow
[09:13:42] <DaveMethvin> gibson042: any progress on that PR for promises?
[09:14:11] <gibson042> actually yes, but it's not quite prime-time yet
[09:14:26] <DaveMethvin> ok can you get to it this week?
[09:14:31] <gibson042> definitely
[09:15:06] <DaveMethvin> so i was wondering ... should we put out a 1.12 just to wrap up the patches we've done so far? It's been a while since a release
[09:15:37] <DaveMethvin> we just haven't had a lot of stuff broken
[09:15:44] <DaveMethvin> so it didn't seem worth doing a release
[09:15:46] <m_gol> there were breaking changes...
[09:15:55] <DaveMethvin> yeah we've landed some of those
[09:16:02] <DaveMethvin> so if we did a 1.12 we'd have to back those out
[09:16:24] <DaveMethvin> probably not worth the trouble
[09:16:43] <m_gol> depends on when we'll be ready with 3.0 =)
[09:16:58] <DaveMethvin> the main thing is the breaking change with promises
[09:17:14] <DaveMethvin> we can drop the deprecated stuff like andSelf
[09:17:36] <DaveMethvin> if anyone wants to break something else, now is the time :)
[09:18:06] <DaveMethvin> i will put out the3.0  blog post later this week
[09:18:25] <m_gol> so, what we're doing with browser support?
[09:18:29] <markelog> each, map arguments? :)
[09:18:33] <m_gol> hahaha
[09:18:59] <DaveMethvin> that's CRAZY markelog!!!! :)
[09:19:12] <gibson042> and tempting :D
[09:19:24] <DaveMethvin> browser support
[09:19:25] <DaveMethvin> yeah
[09:19:44] <DaveMethvin> i left that out of the blog post with the idea that we might fiddle with it
[09:19:44] <m_gol> so, there's this one project called AngularJS
[09:20:02] <m_gol> which officially depends on jQuery >=2.1.1 in version 1.3
[09:20:11] <m_gol> (thought it should work with jQuery >=1.7)
[09:20:15] <m_gol> and it supports IE9
[09:20:28] <markelog> what about light jQuery?
[09:20:44] <markelog> it doesn't use it anymore?
[09:20:46] <DaveMethvin> ok so to work with Angular we'd need to ensure we stay with ie9 in the regular branch
[09:20:51] <m_gol> so if we drop IE9 from the master branch, it's going to lock Angular 1.3 into specifically using jQuery 2.1.1
[09:20:57] <DaveMethvin> jqlite is still in 1.3
[09:21:05] <DaveMethvin> they're dropping it in angular 2.0 tho
[09:21:10] <m_gol> markelog: jqLite is embedded; a small jQuery-like API subset
[09:21:18] <m_gol> if jQuery is on the page, it's using jQuery instead
[09:21:24] <m_gol> yeah, but Angular 2.0 is a complete rewrite
[09:21:28] <m_gol> and it's not going to come soon
[09:21:31] <DaveMethvin> right
[09:21:35] <markelog> right, okay
[09:21:46] <m_gol> probably not earlier than in a year
[09:21:46] <DaveMethvin> so would moving ie9 to the -compat branch cause issues for Angular?
[09:21:52] <m_gol> yes
[09:21:58] <DaveMethvin> LET'S DO IT!
[09:22:00] <DaveMethvin> :)
[09:22:03] <markelog> do we want to move ie9 to compat?
[09:22:05] <m_gol> :P
[09:22:12] <markelog> does it save us something?
[09:22:15] <DaveMethvin> just looking at options
[09:22:27] <DaveMethvin> well the main thing would be that ie9 lacks several nice things like ajax cors
[09:22:33] <markelog> we could check out how many bugs we fixing for ie9
[09:23:00] <m_gol> DaveMethvin: yeah, but jQuery doesn't depend on CORS
[09:23:02] <DaveMethvin> i think it turns out a lot of the bugs continued to ie10, other than the ajax stuff
[09:23:08] <DaveMethvin> m_gol: right
[09:23:23] <DaveMethvin> so it's mainly a burden on the app writer not us
[09:23:27] <m_gol> it's mostly an issue for apps & frameworks, less so for libs
[09:23:49] <m_gol> same with missing pushState, strict mode support etc.
[09:23:59] <DaveMethvin> other than ie9, are there any other browsers that we should be dropping or moving?
[09:24:02] <m_gol> (ok, strict mode support would be nice even for us some time in the future ;))
[09:24:13] <m_gol> we were talking about Safari 5.1
[09:24:18] <markelog> opera 12.x
[09:24:21] <markelog> ?
[09:24:23] <m_gol> but it has more or less the same workarounds as Android 2.3
[09:24:36] <m_gol> I'm fine with dropping Opera 12.x in 3.0.0
[09:24:36] <DaveMethvin> yeah android 2.x is a pain
[09:24:55] <m_gol> so unless we drop Android 2.3, there's not much gain in dropping Safari 5.1
[09:25:08] <DaveMethvin> we could drop testing for opera 12.x and safari 5.1 and not officially support them
[09:25:11] <m_gol> Safari 5.1 is not a huge PITA in tests either
[09:25:26] <DaveMethvin> but at the rate we are going we won't be able to eliminate code until android 2.x drops near zero
[09:25:27] <m_gol> but I'm ok with dropping them
[09:25:28] <markelog> but what is the point to test in it?
[09:25:34] <markelog> if no one use it?
[09:25:35] <m_gol> it's just that it'll save us infra effort but not much code
[09:25:50] <m_gol> ok, let's do it ;)
[09:25:52] <DaveMethvin> and then we'll need to do a 4.0 to drop a big round of browsers
[09:26:12] <DaveMethvin> ok then, drop Opera 12 and safari 5.1
[09:26:18] <m_gol> I wonder what dies first, IE8 or Android 2.3
[09:26:37] <m_gol> if IE8, we can always copy master to compat and drop Android 2.3 on master ;)
[09:26:47] <m_gol> but ok, let's not talk about what will happen in 100 years now
[09:26:50] <m_gol> ;)
[09:26:59] <markelog> do you want to make a bet? :)
[09:27:41] <DaveMethvin> 100 years we should be so luck
[09:27:43] <DaveMethvin> y
[09:27:59] <gibson042> I wonder if there's a way to find out what devs really want from us
[09:28:06] <m_gol> statcounter shows 5% usage of IE8 worldwide
[09:28:18] <DaveMethvin> it's the pockets of interest that kill you
[09:28:20] <m_gol> they're counting visits, though, IE8 users are sure less active
[09:28:30] <DaveMethvin> in terms of numbers android 2.x is less than ie8
[09:28:41] <m_gol> gibson042: drop everything and see who shouts the loudest? :P
[09:28:46] <gibson042> i.e., a small master is no good if everyone wants functionality on browsers it doesn't support
[09:28:48] <DaveMethvin> but ask the mobile guys if they want us to drop android 2.x in master :)
[09:28:53] <DaveMethvin> gibson042: right
[09:28:56] <gibson042> but mostly the differences are in edge cases anyway
[09:29:03] <gibson042> it's not one-dimensional
[09:29:21] <m_gol> I wonder
[09:29:25] <gibson042> I can use master on anything if it's just for traversal
[09:29:33] <m_gol> the Mobile strategy is interesting
[09:29:35] <DaveMethvin> if there's a better way to look at this i'm all for it
[09:29:37] <m_gol> with all those support tires
[09:29:51] <m_gol> I mean, probably most people would hate us for dropping Android 2.3 support completely
[09:30:03] <m_gol> not sure, though, if they cared for right margins moved by 1px
[09:30:17] <DaveMethvin> graded support kind of addresses what gibson042 said about traversal etc
[09:30:37] <DaveMethvin> you could list what isn't supported on certain platforms
[09:31:13] <m_gol> some people were also asking about a build step to exclude certain workarounds
[09:31:19] <m_gol> probably not worth in most cases
[09:31:24] <DaveMethvin> as we found, tho, some of the nicest optimizations fail in a way that prevents us from putting them in, like *ElementChild
[09:31:27] <m_gol> but some css hooks etc. could be done
[09:31:29] <DaveMethvin> or apply to a nodelist
[09:31:30] <m_gol> esp. on Android 2.3
[09:32:29] <DaveMethvin> in reality the biggest thing that -compat needs is the special handling for IE-specific methods like events
[09:32:33] <DaveMethvin> the rest is pretty small
[09:32:58] <DaveMethvin> so i guess we don't sweat it for now
[09:33:20] <DaveMethvin> oh i remember one i wanted to resurrect discussion about
[09:33:26] <DaveMethvin> fractional width/height
[09:34:13] <DaveMethvin> i'm sure mikesherov willl have an opinion on that
[09:34:40] <DaveMethvin> that would mean not using offsetWidth/Height
[09:34:58] <DaveMethvin> and definitely would break code not expecting floats
[09:35:48] <m_gol> apart from that, are there any issues with that?
[09:36:21] <DaveMethvin> on the -compat branch we'd still need offsetWidth
[09:36:40] <DaveMethvin> since there's no computedStyle in IE8
[09:36:55] <DaveMethvin> so the code would get bigger there
[09:37:32] <DaveMethvin> but it might be worth it for master
[09:37:53] <m_gol> seems worth a try
[09:38:10] <DaveMethvin> did we migrate an issue for that? let me check
[09:38:25] <DaveMethvin> https://github.com/jquery/jquery/issues/1724
[09:38:26] <DaveMethvin> yeah
[09:38:36] <DaveMethvin> and it's assigned to 3.0
[09:38:54] <DaveMethvin> anybody want to take it?
[09:39:34] <gibson042> I think I'm doing quite enough damage already
[09:39:38] <DaveMethvin> haha
[09:39:46] <m_gol> :D
[09:39:47] <DaveMethvin> ok i'll find a sucker or look at it myself
[09:39:49] <m_gol> I can get this
[09:39:53] <DaveMethvin> oh ok
[09:39:54] <DaveMethvin> great
[09:39:56] <markelog> btw, are we gonna create issue labels for modules?
[09:40:06] <DaveMethvin> do you think they're useful?
[09:40:07] <markelog> like "core", "effects", etc?
[09:40:09] <m_gol> unless mikesherov wants
[09:40:22] <markelog> we use them before, i think they can be
[09:40:23] <m_gol> since he's currently assigned there
[09:40:29] <DaveMethvin> m_gol: could you take it and ask mikesherov about that?
[09:40:34] <m_gol> k
[09:40:58] <DaveMethvin> if they are useful we can add them
[09:41:18] <DaveMethvin> other than grouping things I didn't find i used them often
[09:41:22] <markelog> i remember mikesherov has a goal to solve all "css" bugs
[09:41:27] <m_gol> :)
[09:41:36] <markelog> without those labels he couldn't do that
[09:41:36] <DaveMethvin> we could just assign them all to  him :)
[09:41:37] <markelog> )
[09:41:42] <m_gol> I could've migrated them together with the rest ;)
[09:41:53] <DaveMethvin> NOW you tell me :)
[09:41:55] <m_gol> now it'll be a little more difficult
[09:41:57] <m_gol> haha
[09:42:02] <m_gol> but doable, I guess
[09:42:11] <m_gol> since each issue starts with a link to the old tracker
[09:42:12] <markelog> i could do that i suppose
[09:42:47] <markelog> oh
[09:42:50] <DaveMethvin> we only have 89 open issues so it's not too much of a problem to do them as we go
[09:42:51] <markelog> https://github.com/jquery/jquery/issues/1784
[09:43:04] <markelog> are we still close shadow dom tickets?
[09:43:22] <DaveMethvin> we have a single ticket for all of them right?
[09:43:26] <m_gol> I think it's good to have a discussion about that now
[09:43:35] <m_gol> last time it was all extremely unstable
[09:43:41] <markelog> DaveMethvin: i don't think so
[09:43:48] <markelog> we wanted to someone to make plugin first
[09:43:52] <DaveMethvin> yeah i wonder if we should be bugging the standards groups to think about the issues here
[09:43:54] <m_gol> DaveMethvin has some good points in this discussion
[09:44:07] <m_gol> perhaps we could cc some folks from Google/Mozilla there?
[09:44:21] <DaveMethvin> people are reporting all these issues in different forms, all related to the shadow dom
[09:44:52] <DaveMethvin> also remember it may not go just one level down, you can have components nested in components
[09:45:28] <markelog> DaveMethvin: it should increase our size by a lot i think
[09:45:34] <markelog> support for it i mean
[09:45:34] <DaveMethvin> and kill perf
[09:45:36] <gibson042> and performance
[09:45:37] <markelog> right
[09:45:38] <markelog> )
[09:45:44] <DaveMethvin> other than that, it's FINE
[09:45:48] <DaveMethvin> :)
[09:46:13] <DaveMethvin> i'm not even sure something like this is easy to do as a plugin
[09:46:21] <DaveMethvin> it would need to hook into a bunch of apis
[09:46:37] <DaveMethvin> all that look at connectedness or climb the tree, potentially
[09:47:32] <gibson042> ugh, contains being broken is going to show up in non-qSA selectors as well
[09:48:05] <markelog> polymer has a lot of hacks for shadow dom, maybe we should refer to them instead of trying to fix these stuff
[09:48:35] <markelog> as far as i know you it pointless to use shadow dom without something like polymer dep
[09:48:42] <DaveMethvin> gibson042: there are even new selectors for piercing the shadow dom
[09:48:55] <markelog> but discussion about it is definatly intersting
[09:48:55] <DaveMethvin> you can use shadow dom by itself
[09:49:07] <DaveMethvin> but i don't know whether all of this is well thought out
[09:49:18] <DaveMethvin> talking with the polymer guys is a good idea
[09:49:19] <markelog> you can, but who would do that?
[09:49:25] <markelog> there is a lot to deal with
[09:49:34] <DaveMethvin> "who would do that" --- hahahahahahha
[09:49:38] <markelog> )
[09:49:55] <DaveMethvin> i don't know if it makes sense to do that, i agree
[09:50:02] <DaveMethvin> but someone is asking to do it already
[09:50:14] <markelog> there was a story about it
[09:50:14] <DaveMethvin> maybe they're using it wrong, i dunno
[09:50:20] <markelog> there you go
[09:50:20] <markelog> http://developer.telerik.com/featured/web-components-arent-ready-production-yet/
[09:50:49] <markelog> The answer is, Polymer’s shadow DOM polyfill wraps a large number of DOM methods — at least 25 of them — with a series of customized shims that exclude elements that reside within its internal list of shadow roots, and it does this for over 30 HTML element interfaces. No, I’m not kidding.
[09:50:50] <markelog> like
[09:50:51] <markelog> wow
[09:50:52] <DaveMethvin> yeah tj's article shows they haven't worked a lot of tit out
[09:51:23] <markelog> i mean we wouldn't want to shim 30 elements or something like that
[09:51:29] <DaveMethvin> now, take all that shimmed stuff and expect jquery to work inside it
[09:52:02] <markelog> that is what polymer does and it has some hacks to work with jQuery too
[09:52:04] <DaveMethvin> let me see if i can get some thoughts from the polymer or web standards folks
[09:52:13] <markelog> okay
[09:53:36] <DaveMethvin> alright, last item ... roadmap page?
[09:54:08] <DaveMethvin> dunno who added it
[09:54:20] <DaveMethvin> do we need a wiki for the roadmap?
[09:54:43] <markelog> i could live without it
[09:54:54] <m_gol> me too
[09:55:01] <DaveMethvin> if we were adding a lot of features i guess it would be useful
[09:55:06] <DaveMethvin> but we're pretty stable at this point
[09:55:09] <m_gol> I have one feature
[09:55:13] <DaveMethvin> and trying not to add stuff
[09:55:18] <m_gol> that I get a lot of feedback about recently
[09:55:20] <markelog> btw, so we're not introducing new ajax interface in 3.0, right?
[09:55:32] <DaveMethvin> markelog: yeah, i had that on the agenda
[09:55:38] <DaveMethvin> not introducing $.xhr
[09:55:52] <markelog> and nothing else new too?
[09:56:01] <DaveMethvin> but we can try to come up with a $.fetch shim
[09:56:13] <DaveMethvin> which happens to integrate with the new serviceworker
[09:56:16] <markelog> plugin first?
[09:56:18] <DaveMethvin> when it's native
[09:56:26] <DaveMethvin> but yeah, i think a plugin would be better there
[09:56:50] <markelog> okay, so in 3.0 only promise compat
[09:57:00] <DaveMethvin> the main breaking changes for 3.0 will be the deferred behavior and browser support changes
[09:57:08] <m_gol> and visibility for effects
[09:57:17] <DaveMethvin> plus a few minor ones like dropping deprecated stuff
[09:57:23] <m_gol> btw, I was at an Angular conference last week and two people asked me specifically about addClass/removeClass not working on SVG ;)
[09:57:23] <markelog> i remember jaubourg was always against new ajax interface, he would be happy i suppose )
[09:57:24] <DaveMethvin> yeah visibility
[09:57:44] <DaveMethvin> well if the world is going to fetch we shouldn't try to build something different
[09:57:57] <markelog> m_gol: we do not support svg
[09:58:01] <m_gol> I know
[09:58:05] <DaveMethvin> we can try to break fetch and find out if it's better than shadow roots
[09:58:20] <markelog> break fetch?
[09:58:22] <m_gol> I just think we should, just a little bit
[09:58:42] <DaveMethvin> i don't know that fetch() has been well tested at this point
[09:58:50] <markelog> so in the docs we would have: we support SVG (a little bit) :-)
[09:58:59] <DaveMethvin> so we might be discovering it doesn't cover all the cases
[09:59:00] <m_gol> almost everyone I've heard complaining said specifically about classes
[09:59:01] <DaveMethvin> but if so that's fine
[09:59:18] <markelog> DaveMethvin: it doesn't :-)
[09:59:24] <m_gol> I don't think it has to be all-or-nothing
[09:59:46] <markelog> m_gol: i don't we should have something like that, they could use a plugin
[09:59:51] <DaveMethvin> so if we switch to the class attribute rather than className does that fix it for svg and not break it for everyone eles?
[09:59:53] <DaveMethvin> else?
[10:00:00] <DaveMethvin> and not kill perf?
[10:00:14] <DaveMethvin> since it's a dom1 method it should be two-way reflected
[10:00:22] <DaveMethvin> IN THEORY
[10:00:30] <m_gol> we need to check if it doesn't kill performance
[10:00:36] <m_gol> if not, I'm for the change
[10:00:45] <DaveMethvin> if that fixes it i'd be good with it
[10:01:00] <markelog> -1 from me :-)
[10:01:11] <gibson042> Sizzle already falls back on the attribute
[10:01:23] <DaveMethvin> remembering also that even "killing perf" by 20% hardly matters since most of the time the browser reflows after a class change
[10:01:30] <DaveMethvin> which kills it a lot more
[10:01:31] <m_gol> right
[10:01:46] <gibson042> https://github.com/jquery/sizzle/blob/2.0.0/src/sizzle.js#L1058
[10:01:47] <DaveMethvin> gibson042: when do you have to fall back?
[10:01:53] <DaveMethvin> doesn't everything have className?
[10:01:57] <gibson042> when elem.className is not a string
[10:02:03] <gibson042> XML/SVG/etc.
[10:02:06] <DaveMethvin> hahah
[10:02:09] <gibson042> ;)
[10:02:09] <DaveMethvin> well that's our case here too
[10:02:10] <m_gol> see? ;)
[10:02:11] <DaveMethvin> :)
[10:02:30] <DaveMethvin> then at least we're consistent now
[10:02:52] <DaveMethvin> do we have a volunteer to look at this?
[10:03:31] <DaveMethvin> m_gol don't any of your friends want to come join you and have fun with open source?
[10:03:41] <markelog> gotta go, hope to create module labels tomorrow
[10:03:48] <DaveMethvin> we need more blood, er, volunteers
[10:03:56] <m_gol> haha
[10:04:01] <DaveMethvin> ok i gotta run
[10:04:08] <m_gol> I'll think about it ;)
[10:04:13] <DaveMethvin> see you guys later
[10:06:18] <m_gol> markelog: you'll need the labels created by sb with admin rights
[10:06:20] <m_gol> like DaveMethvin