[09:00:21] <scott_gonzalez> arschmitz: gnarf jzaefferer kborchers mikesherov petersendidit rxaviers
[09:00:25] <scott_gonzalez> tj_vantoll
[09:00:26] <jzaefferer> hallo
[09:00:27] <rxaviers> hello!
[09:00:31] <arschmitz> Hello
[09:01:57] <scott_gonzalez> Let's start with the 1.11.x regressions.
[09:02:13] <scott_gonzalez> I'll be reviewing https://github.com/jquery/jquery-ui/pull/1398 today
[09:02:20] <scott_gonzalez> Which is for http://bugs.jqueryui.com/ticket/10721
[09:02:35] <scott_gonzalez> The slider floating point step regression.
[09:03:23] <scott_gonzalez> I haven't heard anything from mikesherov on http://bugs.jqueryui.com/ticket/10590
[09:03:43] <scott_gonzalez> Hopefully he'll have an update when he joins later (he's usually a little late).
[09:04:10] <tj_vantoll> In another meeting.
[09:04:36] <scott_gonzalez> rxaviers: What's going on with AMD loading in tests and demos?
[09:05:40] <rxaviers> Same issues, no update. jzaefferer do you have time this week to welk thru some of those together?
[09:05:45] <rxaviers> walk*
[09:06:09] <jzaefferer> Sure, though I don't think we need more discussion until the helper refactoring is done
[09:06:21] <jzaefferer> Loading the helpers statically in a single file, instead of through AMD
[09:07:04] <fnagel> hey
[09:07:35] <rxaviers> hm, true. It's on my end then
[09:08:11] <rxaviers> will get the ball rolling...
[09:08:16] <scott_gonzalez> tj_vantoll: What's the status of AMD minified files? http://bugs.jqueryui.com/ticket/10674
[09:10:48] <scott_gonzalez> We'll come back to that when tj_vantoll is out of his other meeting.
[09:11:10] <scott_gonzalez> jzaefferer did another round of review on classes.
[09:11:17] <scott_gonzalez> I believe the next step is for arschmitz to do another round of updates.
[09:11:19] <scott_gonzalez> Is that correct?
[09:11:37] <arschmitz> yes
[09:11:51] <scott_gonzalez> What's the setatus of button?
[09:11:57] <scott_gonzalez> Waiting on updates or waiting on review?
[09:12:03] <arschmitz> kinda both
[09:12:12] <arschmitz> i had updated based on last round of comments
[09:12:22] <arschmitz> but it had not yet been updated to new classes implementation
[09:12:31] <arschmitz> i just finished that
[09:12:43] <scott_gonzalez> Ok, so tasks are:
[09:12:44] <arschmitz> and will push a new pr based on new classes pr this afternoon
[09:12:47] <scott_gonzalez> Alex to push classes update
[09:12:55] <scott_gonzalez> Jörn to do another round of review after that
[09:13:03] <scott_gonzalez> correct?
[09:13:20] <arschmitz> correct
[09:13:56] <arschmitz> most of the changes are minor
[09:14:01] <scott_gonzalez> ok
[09:14:07] <arschmitz> controlgroup has pretty major changes
[09:14:24] <scott_gonzalez> I'm going to push RTL till later since we have some people missing right now, we'll come back to that at the end.
[09:14:39] <scott_gonzalez> Tooltips in native dialogs is an interesting beast.
[09:14:39] <scott_gonzalez> http://bugs.jqueryui.com/ticket/10739
[09:15:13] <scott_gonzalez> The problem is that a native modal dialog (<dialog> with element.showModal()), has magical CSS handling.
[09:15:28] <scott_gonzalez> Tooltips are appended to the body, they don't have any .ui-front logic.
[09:15:36] <arschmitz> Yay for magic css
[09:15:41] <jzaefferer> arschmitz: there are no API changes for the classes PR upcoming, so any changes there shouldn't have in affect on button anymore, right?
[09:15:42] <scott_gonzalez> And everything in the body shows up below the modal overlay.
[09:15:59] <jzaefferer> arschmitz: if so, it makes sense to review button now, otherwise I'd wait until classes are really done
[09:16:04] <arschmitz> jzaefferer: correct i already updated button based on it after the review today
[09:16:17] <jzaefferer> arschmitz: are you going to do a new PR?
[09:16:21] <arschmitz> yes
[09:16:28] <mikesherov> no update on 10590, but it's on my list... just was very busy past few weeks
[09:16:29] <arschmitz> because it should be based on the new classes pr
[09:16:30] <jzaefferer> okay, I'll review that one when available
[09:16:43] <scott_gonzalez> mikesherov: ok
[09:16:52] <scott_gonzalez> Ok, back to tooltips.
[09:16:53] <arschmitz> jzaefferer: yup just fixing some backcompat i broke and will push this afternoon and open the new pr
[09:17:22] <scott_gonzalez> So, even using the .ui-front logic won't do anything for us, because it won't find the native dialog.
[09:17:40] <scott_gonzalez> We can adjust the .ui-front logic to look for native dialogs (seems like a good idea, since it's basically a native implementation of what .ui-front does).
[09:17:49] <scott_gonzalez> And that would get the tooltip to show up in the right place.
[09:18:07] <jzaefferer> does this magic dialog CSS affect any other widgets using popup elements, like autocomplete, datepicker or selectmenu?
[09:18:09] <scott_gonzalez> The only strange thing here is that then tooltip's dimensions are attempted to be constrained to the dialog.
[09:18:40] <scott_gonzalez> If we update .ui-front to check for native dialogs, nothing else should break.
[09:18:52] <scott_gonzalez> Except for this dimension constraining weirdness.
[09:19:11] <arschmitz> so it wont let the tooltip be bigger then the dialog?
[09:19:31] <scott_gonzalez> Disclaimer: I didn't check the spec on this and I only tested in Chrome.
[09:19:43] <scott_gonzalez> The browser tries to constrain with tooltip to be within the dialog.
[09:19:58] <jzaefferer> Would we update the _appendTo() method in all widgets that have one, and add one to tooltip?
[09:20:10] <scott_gonzalez> So while a tooltip may normally be able to fit on a single line, if it would go past the right edge the dialog, the tooltip element will actually shrink and cause wrapping.
[09:20:40] <scott_gonzalez> But it's not a real overflow constraint, because you can push the tooltip element far enough right, or use big enough elements/words to prevent wrapping and go past the right edge.
[09:21:04] <scott_gonzalez> jzaefferer: Yes, that's the portion of the .ui-front logic that would chagne.
[09:21:22] <tj_vantoll> Back.
[09:21:25] <scott_gonzalez> We wouldn't necessarily need to add an appendTo option to tooltip, just add the logic.
[09:22:05] <arschmitz> so its either deal with weird constraints or not support it at all it seems like right?
[09:22:23] <tj_vantoll> I couldn't find anything in the spec about the overflow weirdness, granted I didn't look that thoroughly.
[09:23:13] <scott_gonzalez> Ok, maybe as a next step, I should just ping browser vendors.
[09:23:19] <scott_gonzalez> And maybe Hixie.
[09:23:43] <arschmitz> seems like that would be logical
[09:23:55] <tj_vantoll> Chrome is the only implementation too, afaik.
[09:24:02] <tj_vantoll> So it's hard to say if that's just implementation detail.
[09:24:23] <scott_gonzalez> Ok, I'll take on that task.
[09:24:37] <jzaefferer> Task = talk to browser vendors?
[09:24:45] <scott_gonzalez> yeah
[09:24:48] <jzaefferer> Okay
[09:24:54] <jzaefferer> We can still update tooltip later
[09:27:51] <jzaefferer> Let's talk about RTL?
[09:28:13] <scott_gonzalez> sure
[09:28:20] <scott_gonzalez> So RTL support has come up a few times in the past.
[09:28:37] <arschmitz> I had talked to Aryia about this in chicago
[09:28:41] <scott_gonzalez> Recently, Qi Ruan from IBM has expressed interest in getting this implemented.
[09:28:55] <arschmitz> He had people that wanted to work on it but never got back to me
[09:29:10] <scott_gonzalez> I'd like to have a wholistic view of how we'll support this across widgets before we start doing things piecemeal though.
[09:29:23] <scott_gonzalez> So there are obvious things like changing the display order.
[09:29:34] <scott_gonzalez> Which sometimes doesn't actually require us doing anything.
[09:29:44] <scott_gonzalez> Because of the markup direction already being set to RTL.
[09:29:55] <scott_gonzalez> But there are some open issues for tricker things.
[09:30:11] <jzaefferer> On the testing side, we need someone with experience implementing, or better yet, using RTL mode. Hopefully IBM can provide that
[09:30:16] <scott_gonzalez> Like horizontal scrollbars (presumably from poor offscreen placement logic).
[09:30:28] <scott_gonzalez> Yeah, that's what I'm hoping for with IBMs contributions.
[09:30:44] <scott_gonzalez> There are interesting things like arrow key functionality in menus.
[09:30:52] <arschmitz> The person Ariya had mentioned was a native speaker
[09:30:55] <scott_gonzalez> And slider having the min value on the right.
[09:31:07] <jzaefferer> As for dir="rtl", is that something to specify on <html> or <body> or on each individual widget?
[09:31:08] <arschmitz> Might be worth pinging him
[09:31:16] <scott_gonzalez> arschmitz: Great. Can you track down who it is?
[09:31:28] <arschmitz> Yeah ill ping Ariya about it
[09:31:32] <scott_gonzalez> We should probably schedule a call with the people who have experience with this and hash out all the details.
[09:31:43] <scott_gonzalez> I think Hans may be beneficial here as well.
[09:31:59] <tj_vantoll> Just for reference here's a Kendo UI example: http://demos.telerik.com/kendo-ui/numerictextbox/right-to-left-support, although I don't think they're necessarily doing it right.
[09:32:26] <scott_gonzalez> Yeah, I think that example is correct.
[09:32:28] <jzaefferer> Maybe ask Dylan?
[09:32:31] <scott_gonzalez> sure
[09:33:25] <arschmitz> we have had several related PR's on mobile too but no one ever knew enough to know if they were right
[09:33:29] <scott_gonzalez> So the suggestion I made to Qi in email discussions was to use the `dir` attribute in markup instead of adding an option to the widgets.
[09:33:57] <arschmitz> makes sense
[09:34:02] <jzaefferer> Isn't RTL mode something you want to apply to the whole page?
[09:34:02] <scott_gonzalez> I feel like when a widget is RTL isn't only RTL because everything surrounding it is RTL.
[09:34:14] <jzaefferer> Or are there usecases where it only applies to partials?
[09:34:15] <scott_gonzalez> I asked Qi about that because I've never used it.
[09:34:25] <scott_gonzalez> I believe it's something that can be applied at any portion.
[09:34:41] <jzaefferer> We need to learn more about that
[09:34:42] <scott_gonzalez> Think about if you had a quote from an RTL language.
[09:34:47] <scott_gonzalez> You'd only want that one quote to be RTL.
[09:35:12] <arschmitz> that makes sense
[09:35:14] <jzaefferer> Let's start with discussing this with Ariyas contact, Hans, Dylan and IBM
[09:35:15] <tj_vantoll> this.elements.parent( "[dir=…]" ).length > 0? That sort of thing?
[09:35:43] <scott_gonzalez> tj_vantoll: Something like that, probably `this.element.closest( "[dir]" )`
[09:35:52] <tj_vantoll> Gotcha
[09:35:53] <jperrault> I'll bring up the desire for an RTL resource on this week's internal governance call.
[09:36:01] <scott_gonzalez> Thanks jperrault.
[09:36:01] <tj_vantoll> Yeah my syntax was garbage :P
[09:36:57] <scott_gonzalez> Ok, so next step is find the right people and schedule a call.
[09:37:08] <scott_gonzalez> That's spread across a few people.
[09:37:11] <jzaefferer> scott_gonzalez: you love scheduling calls, right?
[09:37:22] <scott_gonzalez> Oh, it's wornderful. The more timezones the better.
[09:38:04] <jzaefferer> Well, unlike the next PEP call, I don't need to be on this one
[09:38:17] <arschmitz> i had a great effort recently 12 hour spread
[09:38:36] <jzaefferer> Still only half way around the world :p
[09:38:53] <arschmitz> i know i should have pinged people at samsung
[09:39:31] <arschmitz> could have hit 18hours
[09:40:08] <jzaefferer> I think that's all for RTL, for nw
[09:40:10] <jzaefferer> *now
[09:40:21] <jzaefferer> two more things on the agenda
[09:40:26] <jzaefferer> 1. selectmenu issue: http://bugs.jqueryui.com/ticket/10743
[09:40:34] <jzaefferer> Should we check for hidden options?
[09:40:43] <scott_gonzalez> This seems like a sane thing to handle to me.
[09:41:07] <arschmitz> Oh we have run into this recently in mobile
[09:41:14] <fnagel> Seems like a very specific use case to me. And an odd one too.
[09:41:16] <arschmitz> hiding options does not work in all browsers
[09:41:19] <arschmitz> native
[09:41:29] <scott_gonzalez> Oh, really?
[09:41:30] <fnagel> Perhaps we shoud advise him to use disabled attr in addition to display:none and hide the generated, disabled items via CSS.
[09:41:40] <scott_gonzalez> That's an easy way to say that we won't implement then.
[09:41:46] <arschmitz> its very inconsistent actually
[09:41:54] <jzaefferer> I was wondering about that, if it doesn't work cross browser, we shouldn't support it
[09:42:07] <scott_gonzalez> arschmitz: Do you want to take on the task of closing it with the reason?
[09:42:13] <arschmitz> Yup
[09:42:16] <scott_gonzalez> thanks
[09:42:20] <arschmitz> i can link up the mobile issue
[09:42:40] <fnagel> Perhaps give a hint regarding the usage of attr disabled
[09:43:05] <arschmitz> fnagel: you mean to do that instead of trying to hide?
[09:43:22] <fnagel> Or in addition (I assume its somehow needed to hide them)
[09:44:00] <scott_gonzalez> At least the hiding will work consistenly in *our* widget :-P
[09:44:04] <arschmitz> lol
[09:46:15] <jzaefferer> Let's talk about the new theme
[09:46:25] <jzaefferer> I had a discussion with rxaviers about that today
[09:46:39] <rxaviers> Sure
[09:46:42] <rxaviers> The new-proposed-theme seems very straightforward to me.
[09:46:47] <rxaviers> Except for the change in `tooltip.css`, everything else have been made onto `theme.css` and are bound directly to a variable. It means TR can generate it just fine for 1.12, 1.11 or earlier packages (I need to check what's the baseline, anyway).
[09:47:00] <rxaviers> Note it doesn't necessarily mean user will be able to use the TR interface to come up with the above theme. Because, a few variables changed here have no corresponding UI (i.e., `bg*Url`, `bg*XPos` and `bg*YPos`).
[09:47:17] <rxaviers> Currently, the default theme of a custom downloaded package is UI Lightness. The theme that reflects the base theme is called Smoothness. We could either update the Smoothness theme to reflect the new-proposed-theme or create a new named theme for it.
[09:47:39] <rxaviers> Jörn and I have just discussed this. We discussed the inconsistency of having UI Lightness as the default theme of a custom download, but using the base (aka smoothness) theme as default on the repo and demos (including the one in the api docs).
[09:47:48] <rxaviers> One suggestion is to use the new proposed theme as a default for everything: the custom download, repo and demos (including the one in the api docs).
[09:47:53] <rxaviers> I would personally give it a new name and still keep "UI Lightness" and "Smoothness" untouched as available choices.
[09:47:55] <rxaviers> Suggestions?
[09:48:23] <arschmitz> I like making it the default for all and a new name makes sense to me
[09:49:06] <tj_vantoll> ^ +1
[09:49:17] <jzaefferer> in the UI repo its called "base", we could use that for DB and TR as well
[09:50:39] <fnagel> rxaviers: sounds good to me
[09:51:54] <rxaviers> ok, unless anyone has any other idea, I can update gh with the above and get that implemented on DB/TR.
[09:52:22] <jzaefferer> No changes needed on the UI PR for that, right?
[09:52:46] <rxaviers> Considering moving the changed from tooltip.css to theme.css is one.
[09:52:50] <rxaviers> but, not mandatory.
[09:52:55] <rxaviers> changes*
[09:54:07] <jzaefferer> I guess mixing this new base theme.css with the old tooltip.css would look pretty bad
[09:54:29] <jzaefferer> Can you comment on the PR for that? Maybe Jasper has an idea what to do about that
[09:54:34] <scott_gonzalez> That shouldn't matter. We don't support mixing versions.
[09:55:24] <jzaefferer> Well, rxaviers earlier said: "It means TR can generate it just fine for 1.12, 1.11 or earlier packages (I need to check what's the baseline, anyway)."
[09:56:05] <rxaviers> As far as I know 1.12 has no new css variable compared to 1.11. Is that correct?
[09:56:09] <jzaefferer> It also odd that tooltip carries visual styling in its css file, we don't do that anywhere
[09:56:15] <scott_gonzalez> yeah
[09:58:15] <jzaefferer> We have ui-widget-shadow in theme.css and don't use it anywhere (I think)
[09:58:36] <jzaefferer> Probably because its not actually a shadow, just a half-transparent element
[09:58:56] <jzaefferer> Could update that to carry box-shadow and add it to .ui-tooltip
[09:59:56] <jzaefferer> We still "demo" it on http://jqueryui.com/themeroller/
[10:00:20] <scott_gonzalez> That along with putting the shadow class in the classes option seems fine.
[10:00:50] <tj_vantoll> I've got to head out. I'll be back in #dev later this afternoon.
[10:00:59] <jzaefferer> That should still work fine with 1.11, which bundles the box-shadow in tooltip.css
[10:01:15] <scott_gonzalez> yup
[10:01:20] <jzaefferer> rxaviers: are you typing in the agenda?
[10:01:33] <jzaefferer> guess not
[10:01:41] <rxaviers> nope
[10:02:23] <jzaefferer> So: Update tooltip to use ui-widget-shadow class (via classes option, once that lands), move box-shodow definition into theme.css/.ui-widget-shadow, update TR to demo that instead of the weird fake shadow we have currently
[10:02:25] <rxaviers> I had a comment about the tooltip thing on the PR, I can add the above convo to it.
[10:03:26] <jzaefferer> rxaviers: yeah, since Jasper hasn't responded, would you look into making this change as well?
[10:03:36] <jzaefferer> Or just comment again with the suggestion
[10:03:51] <jzaefferer> though it should wait for classes to land in master...
[10:04:04] <rxaviers> I can certainly add the comments and if he doens't respond I can learn on how to make that change.
[10:04:38] <jzaefferer> Alright, let's add comments, then get back to it later
[10:04:44] <jzaefferer> That's all, thanks everyone!