[12:00:12] ?pepteam [12:00:12] arschmitz bethge jdalton jrossi jrossi1 jrossi2 jrossi3 jrossi9billion M4rius scott_gonzalez snover [12:00:17] hi [12:02:39] Hi [12:03:26] Let's start with bethge's PRs. [12:03:33] I reviewed all three. [12:03:39] Just some very minor changes needed. [12:04:06] ensuring mouse is always an active pointer (https://github.com/jquery/PEP/pull/282) [12:04:43] Nice! Just saw, I will go over them this weekend. [12:05:29] assert that the capturing node is connected to the DOM (https://github.com/jquery/PEP/pull/283) [12:05:38] add more tests (https://github.com/jquery/PEP/pull/281) [12:06:16] about new MouseEvent, I was using it to modify the value buttons, I will check if I can just modify the `buttons` property directly on the event. [12:07:50] Hopefully you can. I know some properties you can't touch. [12:08:31] If not, we can detect if MouseEvent is supported and use it where we can, then fall back to document.createEvent() [12:08:54] Ah, good idea. [12:09:17] But it'll be pretty shitty if we have to tell users that `buttons` won't work in IE. [12:10:28] That part is just for the unit test though [12:15:25] Doesn't look like you can change it. [12:15:29] I just tested in IE11. [12:17:41] darn [12:20:41] I'll ping someone from Microsoft and see if they have any ideas. [12:21:14] sweet, thx [12:21:57] Regarding the boundary events during capture. [12:22:10] This is still an ongoing discussion in W3C. [12:22:42] But people are generally on board with getting rid of them. [12:22:56] yeah iv been following that [12:23:03] seems like they are going to be removed [12:23:24] To make this sane, there will be some extra work. [12:23:46] Assuming that at the time setPointerCapture() is called, the pointer is over a different element, then: [12:24:05] We'll walk the DOM to find the common ancestor of the currently hovered element and the capturing element. [12:24:19] Fire pointerleave from the currently hovered element up to the common ancestor. [12:24:36] Then fire pointerenter from the common ancestor down to the capturing element. [12:24:52] This will make it seem like the pointer just moved to the capturing element, in terms of events and CSS :hover. [12:25:08] That sounds good, makes sense. [12:25:09] Then during capture, there are no boundary events, and :hover will be stuck on the capturing element. [12:25:21] We'll do the reverse during release. [12:25:50] The Chrome team wants to go ahead and implement this now, even though the spec hasn't changed. [12:26:00] Then see if there are any web compat issues. [12:26:20] Since I think this is a sane model, I'd like to propose that we do so as well. [12:26:28] What do you think? [12:27:10] I agree. Sounds simple enough, without many(any?) edge cases. [12:27:43] sounds goot to me [12:27:55] Cool. I'll file an issue for that. [12:28:52] Are there any signals from IE yet, as to whether they would also adapt their behaviour? [12:28:52] Is there anything else to discuss today? [12:29:43] There were IE reps on yesterday's call, but Jacob wasn't there, and he's the one that would know the history behind Edge's current implementation. [12:30:16] There's a pretty strong case that Edge's current implementation is wrong though, because they fire pointerenter and pointerleave all the way up the document during capture. [12:30:39] And the one scenario that he brought up to say why boundary events were important actually doesn't make sense. [12:30:47] The use case was implicit capture on native buttons. [12:31:23] But buttons don't actually have an implicit capture. I verified this by placing an anchor next to a button and then pressing down on the button and moving my mouse over the anchor. [12:31:38] The anchor showed hover state. [12:31:59] Also, if you were to build a custom button in JavaScript, you wouldn't want capture because that would make styling much harder. [12:32:08] right [12:32:08] And it would make detecting clicks much harder. [12:32:22] Because instead of relying on the browser's hit testing, you'd now be stuck doing bounds checks. [12:32:34] To determine if the pointer is still over the button. [12:33:28] Makes sense [12:34:11] So we're waiting on feedback from Jacob before we make any changes to the spec. [12:35:13] Maybe while at it you could clarify: https://github.com/w3c/pointerevents/issues/15 [12:35:52] Yup, that's related but orthogonal. The behavior is tightly coupled to the resolution of this, but the timing issue is not. [12:36:22] We did discuss it on the call though. [12:36:33] But again, we're waiting for feedback on Edge's implementation. Because while it doesn't match the spec currently, it does seem like better logic. [12:36:50] And the spec is based on Edge's implementation, but we think Jacob just missed some details when explaining it. [12:37:38] Right, would be really great if all browsers could have the same behaviour for capture. [12:37:47] yup [12:37:50] We'll get there. [12:37:59] \o/ [12:38:00] It's just taking a lot of time ;-) [12:38:10] :) [12:38:25] Chrome's implementation is still behind a flag, which is what allows them to try deviating. [12:38:48] Is there anything else to discuss? [12:40:53] I guess that's all for today. [12:40:55] Thanks everyone. [14:02:27] apsdehal: agcolom: sfrisk: gabrielschulhof: jasperdegroot: cgack: cogwurx: meeting time [14:02:35] YAY! [14:02:35] howdy [14:02:39] Hey [14:02:48] hi [14:03:18] hi [14:04:34] lets get started [14:04:39] the main thing is selectmenu [14:04:50] but looks like we dont have gabrielschulhof [14:05:12] and thats just waiting on some questions i had for him now and how it relates to a ticket on ui he opened [14:08:55] does any one have any updates or anything to discuss [14:08:59] In the meantime, I have some questions for each of you regarding various old issues. [14:09:28] cgack: Can we close this now? https://github.com/jquery/jquery-mobile/issues/7360 [14:10:20] jasperdegroot: I was looking into https://github.com/jquery/jquery-mobile/issues/8260 , as of now theming is still not supported, what is our final take on this? [14:10:51] let me check [14:11:04] by the way apsdehal great job on the issues [14:11:22] arschmitz: :) [14:11:22] and semi related for anyone who does not know already [14:11:28] we lost our second GSoC student [14:11:33] the one working on hammer integration [14:11:46] arschmitz: https://github.com/jquery/jquery-mobile/issues/5987 , there is a comment for you in this. [14:11:48] yeah, awesome job on triage apsdehal [14:11:50] he decided to after acceptance take another internship and dropped out of GSoC [14:12:06] oh too bad [14:12:38] yes [14:12:39] apsdehal: I think we could, but there are some items there in the checklist that might be useful for documentation/api/upgrade guide work [14:12:54] since we cant replace him since he did it a week after the deadline [14:13:01] I am not sure about this one, there hasn't been any discussion on this: https://github.com/jquery/jquery-mobile/issues/7233 . If this issue is still relevant. [14:13:32] cgack: Then let's keep that open till 1.5 launch [14:13:41] apsdehal: which gabrielschulhof was here for that one [14:13:45] apsdehal: probably best. thanks! [14:13:47] but i think thats something we would like to happen [14:14:03] we have implmented preventDefault handling in many other places [14:14:52] jasperdegroot: Was there any updates on this: https://github.com/jquery/jquery-mobile/issues/5822 [14:15:03] arschmitz: So I will leave the ticket open for now [14:15:06] apsdehal: Re: https://github.com/jquery/jquery-mobile/issues/8260 ... I have to see if that's still an issue with pages styled as dialog now dialogs themselves are deprecated. Assigning the ticket to myself and will comment [14:15:48] jasperdegroot: Issue is still there. I was asking if we need to fix it, since dialog is deprecated. [14:16:09] apsdehal: dialog is but page styled as a dialog is not [14:16:24] there is now a dialog option on the page widget which styles a page as a dialog [14:16:30] apsdehal: that what arschmitz said [14:16:35] the difference is dialog had special naviagation handling [14:16:41] So we will have to provide theme option for page styled as dialog [14:16:58] it *should* just be the theme option on the page widget [14:17:33] And dialog should inherit it? [14:17:41] dialog is just an option [14:17:52] its just a different style of page its purely visual [14:18:32] normal pages have no real style a dialog page shows the page contents in what "looks like" a dialog [14:18:35] maybe the theming option for page is enough and this is not an issue anymore, but have to check that [14:18:35] Ok, so probably we should reconfirm the issue and see its title can be changed [14:18:45] yup [14:18:56] we need to check and figure out from there [14:18:57] jasperdegroot: Thanks, kindly check that and close accordingly [14:19:06] arschmitz: https://github.com/jquery/jquery-mobile/issues/6298 [14:19:12] apsdehal: will do, assigned ticket to myself [14:19:18] Thanks [14:19:20] there may be something to fix because there is extra wrapper etc [14:19:46] @apsdehal thats very relevant still [14:20:01] something we hoped to do for 1.5 but didnt make it [14:20:07] Description isn't good, couldnot really understand what the issue is about [14:20:10] was start a nav review [14:20:38] all ways of configuing or turning on or off ajax nav basicly [14:20:50] and the point is there are way too many ways [14:21:00] thats its madness to make them all work and make sense together [14:21:05] so we need to clean that up [14:21:21] So I will leave that open for now [14:21:37] arschmitz: https://github.com/jquery/jquery-mobile/issues/5293 [14:21:39] yeah feel free to update the description to clairify [14:21:43] A comment for you again :) [14:21:45] i can see why it was confusing [14:22:13] apsdehal: short answer yes [14:22:23] slightly longer answer some of those may no longer need it [14:22:49] since classes and events are automagicly removed by the facotry in the root destroy method [14:22:49] Ok, I will discuss that later [14:23:03] https://github.com/jquery/jquery-mobile/issues/8399 [14:23:10] arschmitz did you see https://github.com/jquery/jquery-mobile/issues/5822? [14:23:39] I suggest to leave it open for now and look into this for 1.6 [14:23:42] thats an oldie ill have to look at it more [14:23:47] yeah [14:23:50] I confirmed the issue 8399, and it is really bad [14:23:54] its not an issue im familiar with off the top of my head [14:24:07] apsdehal: ok [14:24:23] sounds like something we should try to get fixed before 1.5 final [14:24:59] Last one: https://github.com/jquery/jquery-mobile/issues/7039 [14:25:14] I can have a look at it again once selectmenu is on 1.5 [14:25:57] sounds good [14:26:13] hopefully that can land soon i mostly just have questions for gabrielschulhof [14:26:22] Rest issues were for gabrielschulhof, but he isn't here. So I don't have anything more except for [14:26:26] based on an email / issue he opened about controlgroup [14:26:35] on jquery-ui [14:26:42] https://github.com/jquery/jquery-mobile/pull/8431 [14:26:46] https://github.com/jquery/jquery-mobile/issues/8399 is missing a JS Bin test page [14:26:47] im not sure if 1 hes depedning on a fix for that [14:26:50] Phantomjs upgrade [14:27:06] and 2 if the way i fixed it will mess with what he was doing [14:28:56] apsdehal: for 8399 [14:29:05] you shoudl copy that to a jsbin [14:29:16] Tests are passing for phantomjs version 2 and we can land it after a review [14:29:21] because he has some css in there i think is causing it potentially [14:29:31] Sure! [14:29:46] [data-role="header"]{ position: fixed; top:0px; width:100%;} [14:29:46] [role="main"] {margin-top: 32px;} [14:29:46] .ui-content {overflow-y: scroll; position:fixed; top: 44px; bottom: 40px; -webkit-overflow-scrolling:touch;} [14:29:48] [data-role="footer"] {position: fixed; bottom:0px; width:100%;} [14:30:06] thats like completely changing how we layout a page [14:30:08] Yes, just saw that [14:30:21] and [14:30:25] -webkit-overflow-scrolling:touch; [14:30:32] is known to be super buggy [14:30:46] just commented [14:30:50] and may cause this all on its own [14:30:58] because I was thinking the same [14:31:56] yeah simple to test though [14:31:58] http://jsbin.com/vucahibayu/1/edit?html,output [14:32:22] can you reproduce with that [14:32:42] might be worth just for fun to make the header and footer fixed the right way too [14:32:46] bysetting the options [14:32:59] and see if either of them reproduce [14:33:12] if not id just comment and close [14:33:39] Yeah, looking into it. Except that, that is all I have for today [14:34:06] ok [14:34:26] well unless someone has anything else i think we can call it a wrap then [14:34:44] ill try to catch up with gabrielschulhof before the next meeting and get selectmenu figured out [14:38:26] ok see everyone back on dev [14:39:37] later all