[09:00:21] <DaveMethvin> m_gol gibson042 timmywil markelog gnarf rwaldron jaubourg  core meeting time!
[09:00:32] <DaveMethvin> so i managed to get a connection
[09:00:35] <rwaldron> oh hai!
[09:00:38] <timmywil> wat
[09:00:38] <b-ot> timmywil: whats the difference between window innerHeight and outerHeight? I know one gets the inner, and the other the outer, but will outerHeigh also cover the whole web height?
[09:00:50] <DaveMethvin> haha
[09:01:06] <DaveMethvin> b-ot is becoming too user-like
[09:01:34] <DaveMethvin> agenda at https://docs.google.com/document/d/1su2ZTFZbnp_DD-LGZleuEudTFRJT_g4zf7UfGOMQvco/edit
[09:01:37] <timmywil> it will cover the height of your face
[09:01:53] <DaveMethvin> ooooh burn
[09:02:36] <DaveMethvin> okay we should get moving, i'll probably be interrupted
[09:02:44] <m_gol> present
[09:02:46] <DaveMethvin> up in seattle for some meetings with microsoft
[09:02:53] <DaveMethvin> thanks for the pr m_gol
[09:03:08] <DaveMethvin> so it looks like the release was pretty good
[09:03:34] <DaveMethvin> m_gol has already fixed the one problem that got so much discussion over the weekend with feature detection
[09:04:02] <DaveMethvin> nothing else seems critical so i'm inclined to wait for a while before doing a .1
[09:04:40] <DaveMethvin> timmywil: are you comfortable landing those delegated event fixes in a .1?
[09:04:42] <m_gol> though it is broken
[09:05:04] <timmywil> I am. We've gotten the size down.
[09:05:10] <DaveMethvin> cool
[09:05:24] <DaveMethvin> m_gol: yeah i just wonder about the impact
[09:05:28] <timmywil> and gibson helped address some edge cases
[09:05:29] <DaveMethvin> jaubourg:
[09:05:29] <jaubourg> hi there
[09:05:31] <DaveMethvin> yay!
[09:05:43] <m_gol> hm
[09:05:56] <jaubourg> weren't you supposed not to be here DaveMethvin? :P
[09:05:58] <DaveMethvin> broken isn't bad unless it breaks a lot of code out there ... not sure
[09:06:05] <m_gol> where exactly does the reliableMarginRight test fail?
[09:06:06] <DaveMethvin> i lied just to get you to show up jaubourg
[09:06:14] * jaubourg leaves
[09:06:25] <DaveMethvin> good question
[09:06:29] <jaubourg> sure I got you there for a second
[09:06:35] <m_gol> all our support tables have true there
[09:06:53] <DaveMethvin> let's do a quick look
[09:06:56] <m_gol> so unless that's old Android, I don't see why it's even needed
[09:07:15] <timmywil> iirc, Safari was the troublemaker
[09:07:33] <m_gol> timmywil: which version?
[09:07:37] <timmywil> 5.1 maybe?
[09:07:38] <m_gol> 5.1, 6.0 & 7.0 have true there
[09:07:50] <timmywil> well, our support tables could be wrong
[09:07:57] <DaveMethvin> maybe old Safari?
[09:08:00] <timmywil> the test was wrong
[09:08:00] <m_gol> if they are, our tests are wrong, too
[09:08:06] <m_gol> since Safari 5.1 passes these tests
[09:08:21] <timmywil> I could be remembering wrong too
[09:08:42] <timmywil> let's just double check everything
[09:08:54] <DaveMethvin> seems like it might have been Safari 5.0
[09:09:08] <m_gol> lol
[09:09:08] <m_gol> https://bugs.webkit.org/show_bug.cgi?id=13343
[09:09:10] <m_gol> Safari 3
[09:09:11] <DaveMethvin> http://bugs.jquery.com/ticket/11441
[09:09:34] <timmywil> m_gol: well, introduced in Safari 3
[09:09:43] <DaveMethvin> so maybe we don't support anywhere that it's a problem anymore
[09:10:05] <DaveMethvin> it's telling that nobody has reported a bug on this yet
[09:10:06] <timmywil> yea, looks like it was 5.0
[09:10:17] <timmywil> let's also check ios
[09:10:22] <DaveMethvin> when we REALLY screw up, we hear about it
[09:10:35] <m_gol> this test is HUGE btw
[09:10:47] <m_gol> if we could remove it, that'd be great
[09:10:52] <timmywil> you're huge
[09:10:59] <m_gol> :)
[09:11:03] <timmywil> :P
[09:11:21] <m_gol> yo mama so fat she covers all the support tests by herself
[09:12:12] <DaveMethvin> lol
[09:12:14] <DaveMethvin> you guys
[09:12:30] <DaveMethvin> alright, next
[09:12:36] <DaveMethvin> we are SOOO close on swarmy
[09:12:54] <DaveMethvin> hoping that the clearTimeout thing may be causing the random hangs in sinon
[09:12:55] <timmywil> "swarmy" is cuter
[09:13:25] <DaveMethvin> lately it's been more like the SWARMINATOR
[09:13:31] <timmywil> how many iOS7 problems?
[09:13:50] <timmywil> "moar" sounds like a lot
[09:14:12] <DaveMethvin> we don't need to go looking for trouble by adding more browsers now :)
[09:14:41] <m_gol> ok, not a lot more
[09:14:42] <timmywil> iOS7 is totally, like, released, though
[09:14:44] <m_gol> about 2-3 more
[09:14:45] <DaveMethvin> six ie's now, ugh
[09:15:08] <m_gol> but one nasty one with ready() when jQuery is loaded after DOMContentLoaded
[09:15:11] <m_gol> anyway
[09:15:15] <m_gol> iOS6 fails one only
[09:15:19] <m_gol> so we should start with that
[09:15:24] <m_gol> and go towards iOS7 from there
[09:15:35] <m_gol> I've been checking Android
[09:15:35] <DaveMethvin> yeah agreed
[09:15:41] <m_gol> 4.4 passes everything
[09:15:42] <DaveMethvin> some people have them apple computerz
[09:15:49] <m_gol> though that's Chrome 30 mobile so no surprise ;)
[09:15:59] <DaveMethvin> i hope they skip 31 then
[09:16:02] <m_gol> older ones fail tests, 2.3 about 30, 4.3 about 10
[09:16:06] <m_gol> hahaha
[09:16:24] <m_gol> so there's a question what to do with Android
[09:16:27] <m_gol> we could add 4.4
[09:16:33] <m_gol> but if we just add it to all other browsers
[09:16:40] <m_gol> we'll wait 30 minutes for results :/
[09:16:51] <m_gol> OTH, we definitely should test Android
[09:16:54] <DaveMethvin> perhaps a separate run, just on a schedule?
[09:16:56] <m_gol> so how about creating a separate set
[09:17:02] <DaveMethvin> i did that with Migrate
[09:17:03] <m_gol> jQuery Core - Android
[09:17:06] <m_gol> oh, cool
[09:17:09] <DaveMethvin> it just runs twice a week
[09:17:21] <m_gol> in that way we'd have a separate report for desktop + iOS which are quick
[09:17:31] <m_gol> and once in a while we'll see how we're staying with Android
[09:17:34] <m_gol> starting with 4.4
[09:17:50] <DaveMethvin> plus we can schedule that run during a low time
[09:17:55] <m_gol> I can add those browsers though I need to learn how to create separate tests
[09:17:58] <m_gol> right
[09:18:01] <DaveMethvin> it's in jenkins
[09:18:08] <m_gol> yeah, I have access there now
[09:18:36] <m_gol> iOS5 is hopeless, though
[09:18:42] <m_gol> fails >2x as many tests as 2.3
[09:18:46] <m_gol> * as Android 2.3
[09:18:50] <DaveMethvin> in jenkins.jquery.com you can select New Job, then copy over most of the info from other jobs
[09:18:57] <m_gol> ok, will try
[09:19:01] <DaveMethvin> i believe you can also select a job and copy it,
[09:19:26] <m_gol> what's the Migrate Android setup named?
[09:19:30] <DaveMethvin> thought there was but i can't find it atm
[09:19:34] <m_gol> I don't see it under jenkins.jquery.com
[09:19:38] <DaveMethvin> jzaefferer or Krinkle|detached should know
[09:20:05] <DaveMethvin> oh migrate is just a separate job
[09:20:16] <DaveMethvin> i just meant we don't need to trigger it on a commit
[09:20:22] <m_gol> sure
[09:20:23] <DaveMethvin> we can do it on schedule, which is what migrate does
[09:20:28] <m_gol> ah, ok
[09:20:34] <m_gol> yeah, that would be good
[09:20:42] <m_gol> no one wants to wait 30 minutes after each commit ;)
[09:20:46] <DaveMethvin> you'll need a different browserset, i think jzaefferer set one up for me
[09:20:57] <m_gol> I played a little with their Intel emulator version
[09:21:01] <m_gol> or rather I tried
[09:21:12] <m_gol> it leads to kernel panic on OS X
[09:21:18] <m_gol> known bug, no one does anything about it
[09:21:19] <m_gol> so great
[09:21:48] <m_gol> ok, so I can look into that all
[09:21:49] <DaveMethvin> kind of kills its usefulness, i guess :)
[09:22:16] <m_gol> having an emulator that responds with a 2s lag isn't exactly fully useful either :P
[09:22:36] <DaveMethvin> alright, on the wordpress thing turns out Migrate wasn't needed so no work to do, yay!
[09:22:40] <m_gol> so am I ok to land this UA-sniffing for iOS?
[09:22:49] <m_gol> yeah, that was nice :D
[09:23:06] <DaveMethvin> which pr was that? i didn't look
[09:23:14] <m_gol> https://github.com/jquery/jquery/pull/1496
[09:23:41] <m_gol> those nasty iOS liars
[09:23:43] <DaveMethvin> it doesn't bother me in tests if it's hard to do otherwise
[09:24:01] <m_gol> more impossible than hard :/
[09:24:03] <DaveMethvin> so sniff away
[09:24:17] <m_gol> I wouldn't want to land anything like that in src/
[09:24:35] <jaubourg> we should abandon feature tests and go back to sniffing
[09:24:38] * jaubourg hides
[09:24:42] <DaveMethvin> you could land it there, but you'd have to disguise it with a message like "Tests: fix whitespace"
[09:24:42] <m_gol> lol
[09:24:47] <m_gol> :D
[09:25:05] <DaveMethvin> i see so much bad sniffing code in the real world
[09:25:15] <DaveMethvin> and spend time trying to help ppl fix it
[09:25:41] <jaubourg> thing is I can understand sniffing for certain situations but it's when it's totally unnecessary AND broken that I cry... a lot
[09:25:48] <m_gol> but it's only 19 lines! https://github.com/madrobby/zepto/blob/59d3fe59107a9741bc0878048d3199b6dcc21b98/src/detect.js#L7-25
[09:26:17] <DaveMethvin> what could possibly go wrong? :)
[09:26:20] <DaveMethvin> on the san diego meeting, i sent around the link to the agenda
[09:26:30] <DaveMethvin> please do add items you think we shoudl discuss
[09:26:32] <m_gol> I commented a little there
[09:27:03] <DaveMethvin> also if we could come in with more of an outline, how about if we each choose an item or two and come up with a proposal>
[09:27:04] <DaveMethvin> ?
[09:27:34] <DaveMethvin> so jaubourg i think you guys already talked about $.xhr and promises in amsterdam
[09:27:39] <DaveMethvin> so just outline that better
[09:27:41] <jaubourg> yep
[09:27:50] <DaveMethvin> i can do the events one
[09:28:27] <DaveMethvin> rwaldron can you refresh us on the data attached to events stuff when we're in SD?
[09:28:35] <jaubourg> well, xhr is a no brainer... I mean apart from some API decisions we need to discuss. Promises is an all different can of worm
[09:28:58] <DaveMethvin> yeah, promises are going to be tricky
[09:29:36] <DaveMethvin> i'd like to have some way that we can just give people the option to use a Promise shim for the standard promises
[09:29:43] <DaveMethvin> and we'd use that under some circumstance
[09:29:58] <DaveMethvin> custom builds would be one way
[09:30:23] <DaveMethvin> but if we're returning either Deferred or Promise then it gets a little tricky to maintain semantics
[09:30:36] <jaubourg> it's just impossible
[09:31:07] <markelog> i think we should collect all possible we can do with it
[09:31:17] <markelog> before San Diego meeting
[09:31:17] <DaveMethvin> also jaubourg rwaldron it seems like the current spec is pretty much set for ES6? there still seem to be some big issues left
[09:31:18] <jaubourg> we're probably better off consuming standard promises
[09:31:41] <jaubourg> and let libraries like Q consume ours
[09:31:43] <m_gol> jaubourg: I've never though you'd say that...
[09:31:57] <jaubourg> do I have a choice?
[09:32:15] <DaveMethvin> once the average web dev starts using standard promises i think they may be a little upset
[09:32:26] <DaveMethvin> WHERE DID MAH ERRORZ GO?
[09:32:29] <jaubourg> the average web dev use Deferreds
[09:32:37] <jaubourg> and they're happy with them
[09:32:40] <jaubourg> bu heh
[09:32:44] <markelog> well, can't we block the proposal? if we didn't like it so much?
[09:32:56] <jaubourg> "jquery sucks and all that, yadayadayada"
[09:32:58] <DaveMethvin> i think they just need to build in the error support in the browser
[09:33:11] <markelog> it's one of possible options we can do
[09:33:14] <m_gol> though that won't work too well for polyfills
[09:33:25] <DaveMethvin> yes, polyfills lose big
[09:33:51] <DaveMethvin> and when you mention that it's easy to swallow errors accidentally the proponents say, "Well that's a developer error"
[09:33:55] <gibson042> how about sync vs. async? that's another sticking point
[09:34:04] <markelog> hm, maybe i'm invisible or something )
[09:34:20] <DaveMethvin> markelog: i don't think we can block it, nor should we
[09:34:31] <DaveMethvin> i think it needs a couple of useful additions
[09:34:34] <DaveMethvin> that aren't there right now
[09:34:37] <m_gol> that definitely would put us in a bad light
[09:34:42] <DaveMethvin> and should be there in v1
[09:34:46] <markelog> if we agree we the standrart, why we don't to support it?
[09:34:54] <DaveMethvin> because if they're not there it will be hard to use thme
[09:34:58] <jaubourg> the ridiculous part is that you don't need to catch exceptions at all... it's all too easy to catch them in the handlers then propagate as rejection... the key here is that the motto "rejection = exception" denies the difference between runtime errors and applicative errors... but we're talking to walls of denial here
[09:35:26] <DaveMethvin> jaubourg: i saw you read that article i put on G+
[09:35:33] <m_gol> what article?
[09:35:34] <jaubourg> it's the box model all over again
[09:35:41] <DaveMethvin> lemme find
[09:35:44] <jaubourg> yeah, it's quite awesome and relevant
[09:36:08] <m_gol> so if I make a syntax error, it's going to be turned into rejection, right?
[09:36:13] <rwaldron> no
[09:36:25] <rwaldron> syntax errors happen before that code ever runs
[09:36:30] <markelog> we actually can, we, as part of tc39, can veto it, if recall correctly
[09:36:37] <markelog> rwaldron: i'm i right?
[09:36:40] <rwaldron> static semantics !== runtime semantics
[09:36:43] <jaubourg> gibson042: the sync vs async battle is also a lost one. Some specialist decided that async was better always... adds latency all around applications, but who cares if it's deemed "better". I should retire :/
[09:36:44] <m_gol> sorry, I meant a different thing
[09:36:54] <m_gol> like making a typo in a variable name
[09:36:57] <DaveMethvin> https://plus.google.com/+AleksBromfield/posts/SnwtcXUdoyZ
[09:36:58] <m_gol> that happens after parsing
[09:37:21] <DaveMethvin> right, Dennis Ritchie said, "Never check for an error condition you don't know how to handle"
[09:37:42] <rwaldron> m_gol that's runtime semantics
[09:37:53] <DaveMethvin> by catching a lot of WTF errors and forcing the developer to handle them you add to the burden
[09:37:58] <rwaldron> the parser doesn't know or care if you mistyped an identifier
[09:38:04] <m_gol> sure
[09:38:13] <DaveMethvin> and rethrowing is not the same as having the browser identify the original point of failure
[09:38:34] <DaveMethvin> unless the browser understands the semantics of rethrowing and is willing to give you a stack trace
[09:38:55] <m_gol> well, sometimes there's no other choice - if you want to handle one type of errors, you need to rethrow the rest
[09:39:25] <DaveMethvin> m_gol yes, and i think that is one of the problems with Promises as defined
[09:39:52] <DaveMethvin> the spec just "recommends" but does not REQUIRE that the first arg of the rejection handler be an Error object
[09:40:13] <DaveMethvin> and we went down that road to find it a mess
[09:40:40] <DaveMethvin> the v1 spec doesn't define an always-style handler but if it was ever extended the inconsistent args would be a nightmare
[09:40:51] <jaubourg> it's not just about tracability. In synchronous programming, you have a choice : handle and exception and defacto promote it as a semantically relevant error application-wise or plain ignore it (default) and let it crash the program. That's pretty straight-forward and will be impossible to do properly with standard promises where every single exception is deemed application relevant
[09:41:33] <DaveMethvin> in most JS code, people use return values and not `throw` as an error reporting mechanism
[09:41:37] <DaveMethvin> look at node for example
[09:42:34] <jaubourg> well, go and explain some very thick-headed people that coders actually use conditionals to control the flow of execution of their program, not throw/try/catch statements
[09:43:12] <DaveMethvin> jaubourg: i just think it's part of the desire to forge ahead always, but at least on the client side there are better ways
[09:43:32] <DaveMethvin> for example window.onerror does a fine job of reporting unantcipated problems
[09:43:44] <DaveMethvin> but promises break it
[09:44:07] <m_gol> unless you use .done() at the end of the chain
[09:44:19] <m_gol> which is not specified for the 1st iteration AFAIK
[09:44:20] <DaveMethvin> if you have a chain of promises, but then you get a failure far away from the problem
[09:44:38] <DaveMethvin> so .done() isn't a solution
[09:44:47] <DaveMethvin> unless you add a bunch of stack-trace js around it
[09:44:59] <DaveMethvin> becaues you've broken window.onerror
[09:45:10] <m_gol> right
[09:45:17] <jaubourg> well, it's always fine in 3 lines examples, but when you STORE the promise, the exception analogy falls short: var p  = promise; p.then( something ).done(); p.then( somethingElse ).done();
[09:45:21] <m_gol> Chrome is experimenting with async stack traces now
[09:45:24] <jaubourg> imagine the nightmare tenfold
[09:45:48] <DaveMethvin> i just think better browser support has to be a precondition before promises land
[09:45:51] <DaveMethvin> otherwise we've made the debugging experience worse
[09:46:19] <m_gol> so I guess we could offer alternative promise backends for $.xhr
[09:46:25] <DaveMethvin> but i'm thinking if we can give devs a choice we don't have to be partisan about it
[09:46:26] <jaubourg> m_gol: it's an engineer wet dream, all those problems this approach creates that will need to be handled by bunch of C++
[09:46:31] <m_gol> a polyfill and sth more $.Deferred-like
[09:46:38] <DaveMethvin> people can use Deferred or a Promise shim/native impl
[09:47:10] <jaubourg> anyway, I have to go
[09:47:18] <jaubourg> you guys saw the ajax PR I have?
[09:47:32] <DaveMethvin> yes, haven't reviewed it yet tho
[09:47:33] <jaubourg> for the exception thrown by xhr.send
[09:47:45] <DaveMethvin> seemed like it coudl land for .1 jaubourg ?
[09:47:53] <jaubourg> just let me know, it's pretty straight-forward
[09:47:56] <jaubourg> yeah, .1
[09:48:06] <DaveMethvin> ok, anyone have anything else?
[09:48:20] <m_gol> I've just tried removing the reliableMarginRight test
[09:48:26] <m_gol> and it shaved off 167 bytes on 1.x
[09:48:28] <m_gol> nice
[09:48:36] <DaveMethvin> nothing broke?
[09:48:45] <m_gol> iOS5 works fine without it
[09:49:01] <m_gol> And since Safari 5.1 returns true
[09:49:04] <DaveMethvin> i think it was 5.0.5 and fixed in 5.1 something like that
[09:49:08] <m_gol> I guess it's Safari 5.0-only
[09:49:14] <DaveMethvin> well good
[09:49:25] <m_gol> too late now but we can remove it for 2.2/1.12
[09:49:42] <m_gol> regardless of what we do with Safari 5.1 then
[09:49:50] <m_gol> this also means we don't need to rush with 1.11.1
[09:50:01] <m_gol> since it fixes a bug present only in Safari 5.0 which we don't support ;)
[09:50:14] <DaveMethvin> always nice to make this number go down http://mathiasbynens.be/demo/jquery-size
[09:50:20] <DaveMethvin> yep
[09:50:24] <DaveMethvin> okay, gotta run
[09:50:35] <DaveMethvin> thanks guys, keep putting your thoughts in the agenda