[09:00:16] <jzaefferer> jQuery UI weekly meeting! Agenda: http://bit.ly/jqueryui-agenda3 Ping uGoMobi agcolom arschmitz gnarf kborchers mikesherov petersendidit rxaviers scott_gonzalez tj_vantoll
[09:00:28] <kborchers> yo
[09:00:30] <rxaviers> hello
[09:00:55] <uGoMobi> I am around
[09:01:18] <jzaefferer> rxaviers: let's start with AMD? Can you summarize the CSS dependencies disucussion?
[09:01:20] <arschmitz> hi
[09:02:27] <mikesherov> YOOOOOOOO
[09:03:16] <rxaviers> sure
[09:03:31] <tj_vantoll> hey
[09:03:50] <rxaviers> So far, we raised pros and cons of using AMD to handle CSS dependencies.
[09:04:52] <rxaviers> there's a cons of adding a dependency for AMD-users (which, by the way, can be skipped with few configuration);
[09:05:41] <rxaviers> there's a pro of much more robust way of handling the dependency when compared to a adhoc comment.
[09:06:05] <jzaefferer> I have to dig into your examination here: https://github.com/jquery/jquery-ui/pull/1029#issuecomment-27179992
[09:06:06] <b-ot> jzaefferer: Pull request #1029 by rxaviers (3mon 2w ago): AMD support
[09:06:25] <jzaefferer> I still can't tell what we should do
[09:06:30] <rxaviers> ok, let me know on any doubt. I have broken down the discussion into smaller questions.
[09:06:37] <rxaviers> Because, discussion was going beyond the original goal
[09:06:38] <jzaefferer> it seems like there's no de-facto solution
[09:07:07] <rxaviers> yeap, that's what I understood too.
[09:07:30] <tj_vantoll> Is it possible to just skip handling CSS dependencies for now?
[09:08:01] <tj_vantoll> Since there's no clear way of handling this.
[09:08:18] <rxaviers> actually, there's although not de-facto
[09:08:44] <jzaefferer> rxaviers: what do you mean?
[09:08:50] <arschmitz> tj_vantoll: well they need to be handled somehow for the build
[09:08:59] <rxaviers> we know how to handle it. Although, it's not a de-facto way
[09:09:10] <jzaefferer> I agree that it might be better to not solve this, then implementing something that (some loud) people will yell at us for later
[09:09:58] <jzaefferer> I guess source comments like jQuery Mobile would avoid configuration in download builder, while skipping actually solving it?
[09:10:06] <tj_vantoll> arschmitz: Ah true.
[09:10:19] <rxaviers> We can skip it, technically
[09:11:09] <rxaviers> Can we decouple AMD into JS (1029) vs. style and templates (new issue)?
[09:11:41] <jzaefferer> rxaviers: if we skip it, how do we deal with it in DB?
[09:11:45] <tj_vantoll> Yeah my opinion would be the comments since that doesn't affect the end user, or just nothing and we do what download builder is already doing. None of the AMD plugin solutions seem like a path we want to go down.
[09:11:45] <rxaviers> One pro of having everything AMD is standardization, possibly easier when it comes to DB.
[09:11:48] <jzaefferer> also, "templates"?
[09:12:04] <rxaviers> If we skip it, we deal as we currently do: hard coded code
[09:12:40] <jzaefferer> rxaviers: anything against source comment, as an intermediate solution?
[09:12:54] <rxaviers> I think we should either: do nothing, or finish the discussion.
[09:13:39] <rxaviers> using source comment, as pointed out in the comments, doesnt help much where we currently are with DB
[09:13:55] <jzaefferer> which comment was that?
[09:14:12] <tj_vantoll> So it would essentially just move the hardcoding from DB to the source comments.
[09:14:21] <rxaviers> check the section "2) Handle CSS dependencies via AMD defines or comments?"
[09:14:35] <rxaviers> Nope
[09:14:46] <rxaviers> Source comments will add adhoc complexity in DB
[09:15:02] <rxaviers> which AMD would solve
[09:15:08] <jzaefferer> but it removes the configuration for UI, doesn't it?
[09:15:14] <jzaefferer> and we could use it for Mobile as well
[09:15:43] <arschmitz> yup
[09:15:49] <rxaviers> UI and Mobile's themes are completely different. I dont know at which point it helps, or it complicates things
[09:15:56] <arschmitz> it would make db not tied to a specific project
[09:16:10] <arschmitz> rxaviers: it wouldnt matter how different they are
[09:16:22] <arschmitz> rxaviers: the comment tells you what files to include
[09:16:27] <jzaefferer> it should be just a matter of concatenating the specified files?
[09:17:14] <rxaviers> Why not using AMD to solve part of this problem = resolve the paths and get the content for us?
[09:17:34] <rxaviers> And the dependencie
[09:17:36] <rxaviers> And the dependencies
[09:17:54] <rxaviers> Look at the "Apendix 1:" example I gave
[09:18:06] <rxaviers> jquery.ui.accordion.js requires css!jquery.ui.accordion.css
[09:18:16] <rxaviers> jquery.ui.core.js requires css!jquery.ui.core.css"
[09:18:23] <jzaefferer> rxaviers: is there an official require.js CSS plugin?
[09:19:02] <rxaviers> If user code depends on jquery.ui.accordion.js (or if user wants to build a package containing jquery.ui.accordio.js)
[09:19:15] <tj_vantoll> I think the reason would be it would enforce a CSS plugin on people who want to use jQuery UI's source files.
[09:19:36] <rxaviers> Our adhoc comments dependency manager code will have to solve dependencies.. But, we're duplicating what AMD already does.
[09:19:50] <arschmitz> personally i think its better to avoide amd for css until there is at least some sort of generally agreed upon solution
[09:19:54] <jzaefferer> I don't think core.js has a dependency on core.css; all the other CSS files do, though
[09:20:06] <tj_vantoll> arschmitz ++
[09:20:16] <rxaviers> tj_vantoll, that's not true.. That will enforce the dependency on AMD-users only (not hard to overcome with configuration though)
[09:20:19] <arschmitz> and right now that just does not exist
[09:20:52] <tj_vantoll> Yeah, my opinion is that we should avoid the dependency for AMD-users.
[09:21:24] <rxaviers> I think then we should finish the discussion including SlexAxton and the person that scott wanted to hear about
[09:21:33] <jzaefferer> rxaviers: did you look at how the CSS dependency comments in Mobile are parsed?
[09:22:09] <arschmitz> amd for css effects the usability of individual files for some people where comments are just for builder and make no functional difference in the files
[09:22:47] <rxaviers> I dont see why we should decide picking comments in hurry now
[09:24:28] <rxaviers> I agree there's a cons for the AMD-users (I was the first one to raise that issue)
[09:24:36] <rxaviers> But, I also assume there are benefits with AMD.
[09:24:47] <rxaviers> That perhaps outweights this cons
[09:25:01] <rxaviers> And that we should carefully check before going in one direction.
[09:27:47] <jzaefferer> rxaviers: we want to use DB for both UI and Mobile asap, so going with comments has immediate benefits
[09:28:04] <arschmitz> jzaefferer: ++
[09:28:07] <jzaefferer> rxaviers: I'd like to get an estimate how much effort it would be to support comments as an intermediate solution
[09:28:25] <jzaefferer> doesn't have to be now, but soon, so that we can decide how to move forward
[09:28:39] <tj_vantoll> I'm assuming it's not a whole lot of extra coding as well since mobile already has code to parse the comments.
[09:28:52] <jzaefferer> csnover may still weigh in, but I doubt it'll change much
[09:29:58] <jzaefferer> rxaviers: if you're happy with that approach, we can discuss this in Amsterdam next week (skype you in) or in a separate meeting, tomorrow or Friday?
[09:30:08] <jzaefferer> let's move on for now
[09:30:26] <jzaefferer> the updated tooltip PR looks much better. tj_vantoll could you test that once more?
[09:30:43] <jzaefferer> arschmitz: do you have any news on the button rewrite? An estimate for a PR to review css-only buttons?
[09:31:10] <arschmitz> oh hold on 2 secs i do the pr
[09:31:22] <arschmitz> its in a branch
[09:31:41] <tj_vantoll> jzaefferer: Yeah I'll test it tomorrow.
[09:31:51] <jzaefferer> cool, thanks
[09:32:29] <jzaefferer> I've put the next two, Dialog and Scoped Themes on the agenda for Amsterdam next week.
[09:32:37] <arschmitz> https://github.com/jquery/jquery-ui/pull/1126
[09:32:37] <b-ot> arschmitz: Pull request #1126 by arschmitz (37s ago): Button: first pass at css only buttons
[09:32:38] <jzaefferer> I don't think we've made any progress on those since last week
[09:33:01] <arschmitz> http://view.jqueryui.com/button/demos/button/css-only.html
[09:33:20] <jzaefferer> nice, I'll look at that later
[09:33:21] <tj_vantoll> Looking good.
[09:34:05] <jzaefferer> fnagel: the menu-styles branches are somewhat confusing - can you shine some light on that? The discussion on the wiki for that seems to be gone, so I can't quite tell what that is all about
[09:34:06] <arschmitz> iv started rewriting the widget as well its basically just a glorified class toggle now
[09:34:42] <fnagel> We discussed menu item style because of a selectmenu wiki comment
[09:35:12] <scott_gonzalez> I'm here now :-)
[09:35:12] <fnagel> Scott adivised me change this for master (aka menu and selectmenu widget) and added the todo list in the selectmenu wiki.
[09:35:19] <scott_gonzalez> There are a few things related to the menu styles.
[09:35:26] <jzaefferer> hey scott_gonzalez
[09:35:38] <scott_gonzalez> The most recent thing that prompted this was selectmenu options that span multiple lines.
[09:35:55] <jzaefferer> ah, right
[09:35:56] <fnagel> Here's a proposed change: http://view.jqueryui.com/menu-item-styling/demos/menu/default.html
[09:35:57] <scott_gonzalez> It was hard to tell if it was a seconditem or a long item (without hovering)
[09:36:13] <jzaefferer> curiously none of the updated styles include a multi-line item
[09:36:15] <fnagel> Right, better multiline and a difference between button and item
[09:36:21] <jzaefferer> which might help to judge the result
[09:36:26] <scott_gonzalez> But even before that, the menu styles just looked odd.
[09:36:42] <scott_gonzalez> The rounded corners on items with spacing around them didn't seem quite right.
[09:36:55] <fnagel> no, none of the menu demos have mutlipline line, I've added some in my local fork
[09:36:55] <scott_gonzalez> This was something that had been brought up a few times by the community.
[09:37:24] <jzaefferer> so fnagel added lots of space, scott_gonzalez removed it?
[09:37:32] <jzaefferer> you guys should talk more :p
[09:37:48] <fnagel> away, sorry, but we have some trouble here at work
[09:38:00] <scott_gonzalez> Well, we can increase the spacing between items, but we definitely want a cleaner, tighter look.
[09:38:20] <kborchers> agree
[09:38:59] <arschmitz> i agree also before it was oo hard to tell the difference
[09:43:47] <scott_gonzalez> Snover's going to comment on the PR.
[09:43:50] <jzaefferer> fnagel: can you take a look at Scott's branch and integrate that into yours? along with some multi-line items
[09:43:51] <scott_gonzalez> about AMD
[09:44:35] <jzaefferer> we have 13 more tickets, compared to a week ago. Most of that is probably Dylan reporting a11y issues
[09:44:59] <jzaefferer> mikesherov: got something to report on Effects or Draggable?
[09:45:12] <kborchers> i've been slooooooowly trying to kill regressions
[09:45:17] <jzaefferer> rxaviers: any news on Globalize and CLDR?
[09:45:55] <fnagel> back
[09:46:03] <rxaviers> yeap, I have pushed to the CLDR list some (lot) of questions about documentation
[09:46:24] <rxaviers> basically, all assumptions were correct and they are fixing docs:
[09:46:32] <fnagel> Where to find scotts branch?
[09:46:45] <rxaviers> - http://unicode.org/cldr/trac/ticket/6788
[09:46:46] <rxaviers> - http://unicode.org/cldr/trac/ticket/6789
[09:46:46] <rxaviers> - http://unicode.org/cldr/trac/ticket/6790
[09:46:57] <fnagel> scott_gonzalez: where to find your menu item branch?
[09:47:00] <rxaviers> and
[09:47:00] <rxaviers> unicode.org/cldr/trac/ticket/6780
[09:47:22] <jzaefferer> fnagel: there's links in the agenda; also here: http://view.jqueryui.com/menu-style/demos/menu/default.html
[09:47:40] <rxaviers> Also, I am reviewing new $.datepicker with TJ and making comments on CLDR stuff
[09:47:43] <rxaviers> (still working on that)
[09:47:51] <fnagel> jzaefferer: I will take a look soon
[09:48:32] <jzaefferer> rxaviers: where are you communicating with the CLDR folks? their mailing list?
[09:48:35] <jzaefferer> or private mail?
[09:48:41] <tj_vantoll> I have to leave in a minute so quick update. I made some progress on multi month calendar keyboard support. Also $.date only uses jQuery as a namespace, so there's no real dependency to remove. We just have to figure out the final resting point and name of that file.
[09:48:44] <jzaefferer> along with trac, obviously
[09:48:47] <rxaviers> "cldr-users@unicode.org" <cldr-users@unicode.org>
[09:49:13] <jzaefferer> tj_vantoll: and a global name to export, along with some form of UMD wrapper?
[09:49:58] <tj_vantoll> Yep, we'll have to do some bike shedding on that at some point.
[09:50:59] <tj_vantoll> Are you guys going to talk about datepicker's API in Amsterdam?
[09:51:35] <scott_gonzalez> It's on the agenda.
[09:51:56] <scott_gonzalez> But it's hard to tell where we'll start and what we'll get to.
[09:52:13] <mikesherov> So, update on draggable: I'm continually hardening the test suite
[09:52:27] <mikesherov> and have the whole widget in my brain
[09:52:35] <mikesherov> just hammering out kinks in IE, etc.
[09:52:40] <mikesherov> effects, no update yet
[09:52:43] <mikesherov> but getting there
[09:52:49] <mikesherov> it's next after fixing 9379
[09:52:53] <tj_vantoll> Ok just curious. I could potentially Skype in but I'm fine with any decision being made without me. I'd like to get the API nailed down to move forward.
[09:53:35] <jzaefferer> tj_vantoll: I think a separate meeting for datepicker API would be better
[09:53:42] <jzaefferer> we'll have a lot of ground to cover in Amsterdam anyway
[09:53:53] <tj_vantoll> Sounds good.
[09:54:27] <tj_vantoll> Until then I'll work on polishing up the multi month pickers because there are still a few rough edges.
[09:54:48] <tj_vantoll> I'm taking off. I'll be back in an hour or so.
[09:55:13] <jzaefferer> alright, thanks
[09:56:01] <jzaefferer> I think we're pretty much done here anyway. Unless someone got something else?
[09:56:12] <jzaefferer> Dev Leads meeting in four minutes, too