[09:00:37] hey all [09:00:45] I'm running the final vote count for 1.7 now [09:00:51] k [09:01:17] Here. [09:01:41] ok [09:01:45] okay, guess I can stop voting then? [09:01:55] jzaefferer: probably, yeah :) [09:02:17] well, I hope my vote on #7523 still counts [09:02:31] the polls are closed! [09:02:55] we need a better voting system next time [09:03:29] scott_gonzalez: how would you make it better? [09:03:29] especially if something that got voted on for 1.7 gets voted on again for 1.8 [09:03:44] are we removing the vote comments afterward? [09:03:50] scott_gonzalez: no, we're not [09:03:54] timmywil: well, for one, I should be able to see what I haven't voted on [09:04:04] you'd prefer cross-reference support or something along those lines scrott_gonzalez? [09:04:09] scott_gonzalez: patches welcome! [09:04:15] lol [09:04:30] OK [09:04:35] scott_gonzalez: you mean more than the description? [09:04:35] so I have the votes in the spreadsheet [09:04:53] did al gore win this time? [09:04:57] timmywil: I know I didn't vote on about 10 tickets, I have no idea which ones [09:05:03] Dave: I wish [09:05:04] al gore nevar wins [09:05:07] to find out, I'd have to look at all 81 tickets individually [09:05:24] an inconvenient patch [09:05:33] lol [09:05:33] scott_gonzalez: ah, ok [09:05:36] here is a final vote talley: https://spreadsheets.google.com/spreadsheet/pub?hl=en&key=0AuWerG7Xqt-8dG0yTEs2ZTFWQUhDRUp5dzRyc3NwV2c&hl=en&gid=2 [09:06:07] we have a bunch that didn't get a single down vote [09:06:14] we can move through those pretty quickly [09:06:15] does miketaylr win a prize? [09:06:34] haha [09:06:34] (and a bunch that didn't get a single upvote) [09:07:18] is everyone OK with me going through all the no downvote ones and just assigning them to 1.7? [09:07:28] ok with me [09:07:28] fine by me [09:07:32] I think thats fine [09:07:32] and me going through all the no upvote ones and closing them as wontfix (or similar) [09:07:39] sounds good [09:07:42] OK [09:07:43] +1 :P [09:07:45] sounds like a good start [09:07:58] What an agreeable bunch we are today <3 [09:08:03] it depends whether I reported the bug or not [09:08:05] JohnResig: some with no upvotes might have some good commentes [09:08:06] and all the all downvote ones can be closed? [09:08:08] lol [09:08:13] might be worth reading through them before closing [09:08:33] scott_gonzalez: well, we're not deleting the tickets, right? [09:08:34] but not in the meeting [09:08:51] is there any long-term plan to "clean up jQuery"? like a jQuery 2.0 that isn't backwards compatible? [09:08:59] you can always resurrect them if we made some mistakes [09:09:08] if that is a desirable milestone, some of those tickets could get assigned to that [09:09:11] JohnResig: sure, go ahead and just close them, I'll check if there were any interesting ones we should circle back on for some reason [09:09:19] scott_gonzalez: k! [09:09:20] jzaefferer i think at jQuery Conf SF, there was a definitive "no" [09:09:23] jzaefferer: not really, no [09:09:33] jzaefferer: most of the no-upvote ones are plugin requests [09:09:38] i would like to have 1.7 deprecate a list of things that we might be able to pull out or pluginify in the future [09:09:46] but i don't think 1.7 should pull out any features [09:09:51] +1 dave [09:09:54] $.browser? [09:09:58] >:| [09:10:00] yeah like that [09:10:04] DaveMethvin: shouldn't we have voted on that? [09:10:05] we can take a stand [09:10:12] we kind of did, with :input [09:10:13] was about to mention $.browser - are we deprecating that this time? [09:10:24] well, we didn't vote on it, so no [09:10:24] be the first library to _officially_ drop support for browser sniffing [09:10:24] there were tickets for deprecating specific features [09:10:37] like :input [09:10:46] browser is alrready on the deprecation list but we aren't taking it out now [09:10:46] didn't get to vote on that, but deprecating it makes sense [09:10:53] need to get people of that lawn [09:10:59] even though I originally added that :o [09:11:10] ok, let's talk about the contenteous issues [09:11:14] what we need is MORE people on that lawn...specifically browser vendors :-) [09:11:17] outerWidth/Height? [09:11:22] $.browser is among those :/ [09:11:28] jzaefferer and it got a lot of +1 votes [09:11:54] First up: http://bugs.jquery.com/ticket/6652 [09:12:14] ok, so it's me [09:12:50] config flag sounds like a bad idea [09:12:58] 6652 seems to ahve been proposed twice? [09:13:01] oh god no config flag please! [09:13:03] meh i forgot to join [09:13:04] agreed [09:13:10] can we assign to 1.7 and try to find a good solution? [09:13:16] this ticket and I think scott_gonzalez wrote a similar proposal [09:13:36] so I don't think the proposed implementation is what we want [09:13:41] as pointed out by a few comments [09:13:44] for which ticket? [09:13:45] I still don't like it, but if I'm the only one, no biggy [09:13:51] but I think we can handle this in specific methods [09:13:56] yeah, I wasn't keen on the proposed solution either [09:14:01] ben_alman http://bugs.jquery.com/ticket/6652 [09:14:05] right, scott_gonzalez I had +0'ed this in favor of your proposal [09:14:06] needs to check if the default opacity would be 1 before removing [09:14:07] like fadeIn and fadeOut can specifically remove it [09:14:11] we are voting on tackling the issue, not on the proposed solution, right? [09:14:13] or save the orig [09:14:18] which it does [09:14:20] hmmm [09:14:30] but maybe not fadeTo even if it hits 100% [09:15:15] scott_gonzalez: I think it could if that's what it will be without the filter (if there's an easy way to know that) [09:15:27] I dunno, I feel like it's a lot of trouble for something that will look horrid while animating [09:15:32] sure, the more places we can remove it, the better [09:15:33] anyway [09:15:51] jzaefferer: i agree debate is prolly best kept to whether to tackle the issue, and it may turn out we have no tackler or no solution in 1.7 after someone takes a look [09:15:55] jaubourg: not a really a during-animation issue [09:16:06] DaveMethvin jzaefferer +1 [09:16:06] ok, so yes to 6652, pending solution [09:16:12] JohnResig +1 [09:16:15] +1 [09:16:25] next up: http://bugs.jquery.com/ticket/8157 [09:16:31] timmy: well, the rendering problem will occur while animating... I know that first hand by having dealt with it on a site I made [09:16:38] jaubourg: you again ;) [09:16:43] hehe [09:17:21] scott: you confirm it's not a change event trigerred when there's no change we want here? [09:17:25] it's a little confusing. not sure jaubourg saw the problem at the time [09:17:26] (just saw your comment) [09:17:36] #8157 looks like Julian didn't get it, but everyone else did and +1 ? [09:17:39] ( JohnResig I add 6652 to the meeting doc ) [09:17:42] added* [09:17:53] rwaldron: I've been keeping track of the votes in the spreadsheet [09:17:56] if it's a real change we fail to detect, then fix [09:18:02] jaubourg: did you see the jsbin? [09:18:06] ok cool, i'll let you do that [09:18:09] yeah, it's a real change that we fail to detect [09:18:10] I was confused by how the thing was being presented [09:18:19] rwaldron: for example: http://gyazo.com/dcb50d360c9202200a4870dafd3413d8.png [09:18:22] our special change event listens to focus and clears a flag [09:18:29] JohnResig awesome [09:18:31] but if the field is already focused, then the flag shouldn't get cleared [09:18:36] ok [09:18:41] -1 => +1 [09:18:43] next [09:18:49] K [09:18:57] I want to circle back and make sure we're on the same page for: http://bugs.jquery.com/ticket/6362 [09:19:16] at some point i want to discuss #4446 and #4596 together [09:19:36] ben_alman: we'll get there [09:19:41] just making sure [09:19:43] np [09:19:50] ben_alman: we can do it next [09:19:58] after rereading, +1 on #6362 [09:20:13] what is the exact change we're planning to make for 6362? just changing what .index("selector") does? [09:20:48] yeah, I guess we need to figure out exactly what we're changing it to [09:20:49] As noted in my +1, I want it named semantically. [09:20:56] Didn't vote on it, but agree with rwaldron's comment about a more semantically correct name for the thing. [09:21:00] Its like "indexOf" [09:21:02] ^ what he said. [09:21:09] +1 rick tooµ [09:21:20] I wrote .ordinal() years ago [09:21:23] all: http://jsfiddle.net/rwaldron/9R9kP/ [09:21:27] well if we create a new name the semantics are a blank slate [09:21:28] it seems like it should be the equivalent of doing a filter and finding the position of the first element that matches that [09:21:30] it sounds like the requist is to add an additional signature? [09:21:35] cause the OP is actually requesting a new signature [09:21:35] lol [09:21:37] instead of the .children() thing we have now [09:21:39] eh, that fiddles sucks [09:21:59] rwaldron: yeah, essentially like what you have [09:22:04] but there already is a string signature [09:22:06] JohnResig, the .children() is only when you do .index() with no args, isn't it? [09:22:11] so his request would break back-compat [09:22:13] uhhh [09:22:32] ben_alman, it's not a "new" signature, currently you can pass a jquery obj and it'll use the first elem [09:22:51] ajpiano: you're right - the string does a global selector [09:22:56] ajpiano ben_alman http://jsfiddle.net/rwaldron/9R9kP/ [09:23:02] a relative filter would make more sense [09:23:04] right now $(elem).index(selector) will find elem in selector, he wants $(elems).index(selector) to find selector in elems [09:23:07] heh [09:23:11] right? [09:23:18] or have i got it wrong [09:23:21] ben_alman: right, and I agree with that [09:23:33] so what we need to figure out is if we care strongly enough about this to break the old API [09:23:38] https://projects.workxpress.com/js/src/jquery/jquery.ordinal.js [09:23:48] I'm meh [09:23:57] considering how much people freak out over API changes, this may have to get a pass [09:24:02] yeah [09:24:05] yeah [09:24:06] (even though I like the proposed change) [09:24:07] i would not change a sig like that ... deprecate index and replace with indexOf if it's needed [09:24:08] i do as well [09:24:15] but I'm pretty sure the request is not to break anything [09:24:20] +1 DaveMethvin [09:24:21] can we put it on a "look at for 3.0" list? [09:24:24] or change anything in existance [09:24:28] but to _add_ something new [09:24:37] they just gave a crappy name for it [09:24:39] ben_alman: I'll add a revisit-2.0 keyword to it [09:24:40] "indexIn" [09:24:51] if it's a proposal to add indexOf or indexIn I think it would be nice to prove its value [09:24:53] rwaldron, i think he wants to change the existing signature to work as an .indexIn method and change the current .index method [09:25:03] to support the new behavior [09:25:05] JohnResig: didn't you say five minutes ago there won't be a 2.0? [09:25:11] the way the current string one is designed assumes you're trying to find out the index of a single element you already have, not search a set of element sfor a particular selector [09:25:15] jzaefferer, that's why i suggested 3.0 [09:25:17] :P [09:25:20] jorn: shush you :P [09:25:22] lol [09:25:26] JohnResig, will you be putting together a report for any revisit-2.0 items that get tagged as such? [09:25:26] eh. eff breaking things [09:25:34] addyosmani: yes! [09:25:39] great! [09:25:48] rwaldron: jzaefferer i think the "there is no 2.0" thing means "there isn't going to be a gigantic paradigm shift" [09:25:52] it doesn't mean there won't be a jquery versoin 2.0 [09:26:04] moving on? [09:26:08] I'm using "2.0" as a metaphor here for "things that'll break stuff" [09:26:13] ok, next bug [09:26:16] I mean like a 2.0 where .each and $.each has the right signatureâ€¦ [09:26:21] *have [09:26:40] jzaefferer: that ship has sailed ... :P [09:26:42] http://bugs.jquery.com/ticket/8685 [09:26:52] 27 mins... 3 tickets. [09:27:00] wait... this is 6 yes [09:27:02] hang on [09:27:06] JohnResig: ya.... was... ok [09:27:07] :p [09:27:17] ps i'm super hapy that got tackled :) [09:27:20] oh, nm [09:27:23] but hot though rite? [09:27:29] :D [09:27:36] timmywil: ya for real :) [09:27:39] ok, animate hooks: http://bugs.jquery.com/ticket/8498 [09:27:54] jaubourg again [09:27:59] and DaveMethvin [09:28:05] seems like a bunch of people weren't really into animateHooks, per se [09:28:06] so I want to be clear what I'm talking about here [09:28:08] it's cause he's french or something [09:28:13] +1 to timmywil's solution. [09:28:13] but rather having .animate take a look at cssHooks when animating [09:28:24] The growth of the animation code has me worried [09:28:38] I really like adding hooks for gnarf [09:28:46] gnarfHooks? [09:28:46] *like what gnarf proposed [09:28:47] I think the problem is that cssHooks doesn't provide any string transformation utility... just setting stuff in the element [09:29:00] I think we should set hooks for that [09:29:05] we should expand cssHooks [09:29:09] meta-level hooks for CSS [09:29:13] not bury things in effects.js [09:29:13] animate can't use cssHooks [09:29:15] forget the animate business [09:29:36] I want it so that people can make meta-property plugins mapping margin -> margin stuff [09:29:42] same thing for border, padding, etc. [09:29:43] +1 john [09:29:45] and other properties [09:29:52] +1 [09:29:52] the problem is some things should really only be for effects (setting margin in css is different than animating) [09:30:00] i like that, esp if it keeps them from asking to have core include it [09:30:09] DaveMethvin: yep! [09:30:12] DaveMethvin helllllssss yeah [09:30:17] what does "mapping margin -> margin" mean? [09:30:35] I think I already ask that question but cannot remember the answer : Can't all that already be achieved through $.fx.step.margin ? [09:30:35] jzaefferer: see: http://bugs.jquery.com/ticket/8498#comment:9 [09:30:42] maring => marginTop, marginRight, marginBottom, marginRight [09:30:49] louisremi: no [09:31:00] you need to animate individual sides individually [09:31:22] wel, maybe, but not in a DRY way [09:31:30] ok, so next one [09:31:32] http://bugs.jquery.com/ticket/9401 [09:31:34] scott_gonzalez: but you could do that in your step function [09:31:37] better hooks organization [09:31:46] maybe add the map thing to cssHooks, but not add the logic in css to read from maps (more of an effects-only map) [09:31:49] some props shouldn't animate [09:32:01] So, I proposed this, but honestly... its like way too much effort and will likely be a headache [09:32:05] timmywil: we can explore both [09:32:14] rwaldron: ok yeah, minimal benefit [09:32:20] let's cut it! [09:32:25] SNIP [09:32:28] next :) [09:32:41] thanks rwaldron, just saved me a lot of typing [09:32:41] :p [09:32:44] next: http://bugs.jquery.com/ticket/5684 [09:32:55] ajpiano secretly, I'm a reasonable guy [09:33:01] I gotta run to a meeting. bbl! [09:33:02] so it seems like we want to fix this, we're just not sure if a solution exists [09:33:09] so yes to this, pending working solution [09:33:13] ajpiano, don't you hate having all that typing then just cmd-a, delete ? [09:33:25] yep, as long as the original exception is not lost, I'll take any solution [09:33:40] ben_alman: didn't get that far ;) [09:33:45] next: http://bugs.jquery.com/ticket/6838 [09:33:46] nice [09:34:08] so this is a gnarly sizzle bug [09:34:18] we should definitely fix that, I think only priority needs to be discussed [09:34:20] positioning semantics inside of :not() has always been weird [09:34:31] JohnResig, does .not(':first') work correctly? [09:35:17] er [09:35:20] there is specific weirdness going on here in IE that's really hard to track down [09:35:24] .not('.Item:first') [09:35:35] I've seen variations of this issue for years now [09:35:42] ben_alman: the actual .not() method works fine [09:35:42] is ticket priority going to be discussed in this meeting (as it was just mentioned), or left for another time? [09:35:50] addyosmani: in this meeting [09:35:52] it just sucks that time has to be spent on non-qsa selectors [09:35:59] I agree completely [09:36:06] which is why I'm not terribly enthused by this [09:36:15] is this a larger problem though? [09:36:18] patchwelcome? [09:36:24] if we leave it borked maybe people will use standard selectors :P [09:36:28] like, fuyndamental sizzle bug? [09:36:57] I remember weird bugs relating to this even before sizzle [09:37:07] it was just weird traversal issues with IE that were hard to pin down [09:37:25] in the back of my mind i am wondering who will volunteer for this suicide mission [09:37:32] i think JohnResig should [09:37:35] * jaubourg looks at John [09:37:39] lol [09:37:40] * jaubourg hides [09:37:42] there's always that patchwelcome.. [09:37:56] resigclonewelcome [09:37:56] addyosmani: +1 [09:38:02] ha [09:38:14] haha, <3 resigclonewelcome [09:38:35] patchwelcome and next then? [09:38:35] like, right now, I'd be more inclined to rewrite sizzle to extract all the non-qsa selectors and turn them into qsa-compatible stuff then fix that bug [09:38:39] so that's saying something [09:38:39] well you can put it on the list of stufff to look at and we can drop it back off if nobody has time [09:38:56] DaveMethvin: so it's not a blocker, then [09:39:04] yeah [09:39:08] ok [09:39:14] +1 complete sizzle rewrite [09:39:17] heh [09:39:17] it's not like there isn't a workaround [09:39:27] ajpiano, yeah, just don't use IE [09:39:29] next: http://bugs.jquery.com/ticket/8468 [09:39:41] similar issue, of sorts [09:39:45] only this is a problem with qsa [09:40:19] wasn't this mainly an Opera bug? [09:40:20] miketaylr said it was being addressed by Opera [09:40:22] do we have news about any fix Opera-side? [09:40:31] k [09:40:36] wontfix [09:40:39] alright, push to opera [09:40:40] ppl should avoid that selector in their code if the yahve opera users? [09:40:40] yeah, it's been fixed [09:40:43] in CORE [09:41:03] or upgrade to latest opera that fixes it [09:41:05] next: http://bugs.jquery.com/ticket/8921 [09:41:22] ben_alman: specifically using a comma selector with the right-hand selector including :selected [09:41:26] doesn't happen too often [09:41:40] JohnResig, heh and standing on your head patting your tummy [09:41:58] heh [09:42:01] JohnResig: it seems that this and 8909 are inextricably link [09:42:17] JohnResig: not specific to :selected [09:42:22] https://github.com/jquery/jquery-ui/pull/286/files [09:42:50] scott_gonzalez: that's not a qsa selector? [09:42:58] ok so we lost timmywil who's the one who -1ed 8921 [09:43:17] also gnarf explained why it was a problem immediately after to timmy [09:43:30] yes, and it makes a LOT of sense [09:43:39] like i said, it seems to part of his cleannup for 8909, which was unanimously +1'd [09:43:42] JohnResig: huh? was replying to you saying "right-hand selector including :selected" [09:43:47] ajpiano: k [09:43:53] well except for jaubourg :p [09:44:00] :P [09:44:08] scott_gonzalez: right, what you're pointing to is likely a different bug [09:44:17] really? [09:44:19] I didn't -1ed it [09:44:20] it Opera only [09:44:27] extremely similar [09:44:50] most likely opera isn't throwing ANY exeptions after a comma, even thou it has a custom selector [09:44:53] same bug probably, doesn't throw an exception on non-standard pseudo selectors unless they're the first thing passed in [09:45:01] yeah! :P [09:45:02] * miketaylr finds bug [09:45:13] next: http://bugs.jquery.com/ticket/8951 [09:45:37] looks like we're making that one not a blocker [09:45:53] miketaylr: ah, ok [09:45:54] Looks fairly low-priority [09:46:05] (querySelectorAll does not throw for an unsupported pseudo-class part of selector if there is a valid part first) [09:46:27] k, making 8951 a lower priority [09:46:39] prio doesn't seem that high i agree, also is there some way to feature detect the issue? [09:46:41] (however, fixed in Presto now... so whatever heh) [09:46:51] next: http://bugs.jquery.com/ticket/9106 [09:47:08] i hate this [09:47:16] 9106 wat [09:47:20] yeah [09:47:27] can we kill the submitter [09:47:34] yeah, so stupid [09:47:36] with an anti-html shiv [09:47:39] that looks like it was downboated [09:47:39] into the chest [09:47:46] its essentially the defaultDisplay bug, but on the html element [09:47:46] why on earth did I +1 this? [09:47:47] its dumb [09:47:55] * jaubourg checks what he's smoking [09:47:58] perhaps you were drunk, jaubourg :) [09:48:01] next: http://bugs.jquery.com/ticket/9399 [09:48:15] jaubourg: this is your baby [09:48:19] ah, touchy [09:48:31] I know why I introduced .success and .error [09:48:50] but they're confusing because people mix them with deferred semantics [09:48:55] i like the relationshipt of jqXHR.success and .error to ajaxOptions success and error [09:48:58] how hard is this really to maintain [09:49:02] i think it makes it easier for ppl to grok [09:49:04] tbh [09:49:09] scott, ben, and myself all seem to aggree about ^^ [09:49:13] it's not hard to maintain, really [09:49:18] it just allows them to put 1+1 together [09:49:19] it's two affectations [09:49:36] well like i said in the ticket, it seems like a fast deprecation [09:49:38] but it's kind of a mess [09:49:53] we encourage people to use done and fail [09:49:57]