[09:00:13] <scott_gonzalez> arschmitz gnarf kborchers mikesherov rxaviers tj_vantoll1
[09:00:31] <rxaviers> hello
[09:00:50] <kborchers> hey
[09:01:30] <arschmitz> hi
[09:02:01] <scott_gonzalez> rxaviers: Want to start with an update on AMD?
[09:03:05] <rxaviers> Sure, Im working the tests change to AMD... I will probably have a new commit today with an initial change, so I can show you what Im about to do in the other files as well, and check if this is what you expect.
[09:03:54] <scott_gonzalez> ok
[09:03:56] <rxaviers> When Im done with that, I will switch to DB and work on the support AMD issues.
[09:04:47] <rxaviers> s/support AMD/support 1.11/
[09:05:42] <scott_gonzalez> sounds good
[09:05:50] <tj_vantoll1> Here now.
[09:06:13] <scott_gonzalez> Perfect timing, tj_vantoll1.
[09:06:23] <scott_gonzalez> Just about to talk about change events.
[09:06:25] <scott_gonzalez> http://bugs.jqueryui.com/ticket/9688
[09:06:47] <scott_gonzalez> The question is whether we should change the value when an value-restricting option is chagned.
[09:07:01] <scott_gonzalez> For example, with slider or spinner, if you set the min higher than the current value.
[09:07:08] <scott_gonzalez> Does the value become invalid or does it get changed?
[09:07:22] <scott_gonzalez> tj_vantoll1 researched the native behavior for HTML5 controls.
[09:08:03] <tj_vantoll1> The only case where the native controls alter the value is <input type="range">, because they kind of have to there.
[09:08:19] <tj_vantoll1> <input type="number">, <input type="date">, etc do not alter the value or fire any events.
[09:08:33] <scott_gonzalez> So basically, if the user is able to manually type in an invalid value, then the value would stay invalid when changing an option.
[09:08:52] <scott_gonzalez> For controls where the UI doesn't afford for invalid values, then changing the options would change the value.
[09:08:53] <tj_vantoll1> Yep
[09:09:07] <scott_gonzalez> Did you check if an event is triggered in that case?
[09:09:39] <tj_vantoll1> They are not: http://jsfiddle.net/tj_vantoll/wLe4b/ (see the range input)
[09:10:28] <fnagel> Sorry guys, I'late
[09:11:17] <tj_vantoll1> So the question is whether we should be consistent with spinner and datepicker.
[09:11:57] <tj_vantoll1> UI's slider actually is actually consistent with the native control currently.
[09:13:12] <scott_gonzalez> Yeah, let's make datepicker and spinner consistent with the native controls.
[09:13:53] <tj_vantoll1> Ok I agree. For datepicker I can add that to the wiki for the rewrite. min and max have not been implemented yet.
[09:14:00] <scott_gonzalez> thanks
[09:14:02] <tj_vantoll1> For spinner I can create a ticket.
[09:14:17] <scott_gonzalez> perfect
[09:15:23] <scott_gonzalez> arschmitz: Any news on button/checkbox/radio?
[09:15:49] <arschmitz> did testing on mobile devices
[09:16:04] <arschmitz> fixing some things i found there and addressing issues for button on trac
[09:16:32] <arschmitz> also still waiting to talk to you about theme colors to use in places
[09:18:25] <scott_gonzalez> Let's discuss colors now.
[09:18:25] <arschmitz> also i did testing on select menu on about 30 devices
[09:19:11] <arschmitz> ok basicly there is the color for the icon background for checkboxes and radios
[09:19:50] <arschmitz> and the color of the center dot for radios
[09:20:05] <fnagel> arschmitz: Which selectmenu?
[09:20:19] <arschmitz> http://view.jqueryui.com/button/demos/button/checkbox.html turn on icon
[09:20:38] <arschmitz> fnagel: the one currently in master mostly started the native one but have not finished yet
[09:22:06] <fnagel> arschmitz: Any issues in the master branch?
[09:22:34] <arschmitz> fnagel: yes i have a list just was not sure if you wanted me to file issues or put them in wiki since its on master now
[09:22:45] <scott_gonzalez> arschmitz: How is the box for the checkbox styled?
[09:22:59] <scott_gonzalez> I don't see an element specifically for the box, so I'm not sure where the background color is coming from.
[09:23:15] <arschmitz> its an :after pseudo element
[09:23:44] <arschmitz> its just an icon with background and border radius
[09:24:07] <scott_gonzalez> hmm...so that means you can't use classes, right?
[09:24:30] <arschmitz> well you put the class on the actual element
[09:24:49] <arschmitz> and just apply it to :after in the css
[09:25:26] <scott_gonzalez> But that means you can't do things like using ui-statte-active on the box.
[09:25:34] <arschmitz> right
[09:25:51] <scott_gonzalez> That breaks our CSS framework.
[09:25:59] <fnagel> arschmitz: Mhh, I'm fine with both but I thought we do not create tickets for non released widgets?
[09:26:26] <scott_gonzalez> The widget CSS isn't allowed to contain colors.
[09:26:37] <arschmitz> it does not need to
[09:27:02] <scott_gonzalez> For selectemenu, all issues go on the wiki.
[09:27:26] <arschmitz> it can still get the right colors you just use the theme roller variables in a new class in the theme
[09:27:38] <rxaviers> Guys, I need to leave now. I can answer any question when Im back (in about 2-3 hours).
[09:27:47] <scott_gonzalez> Thanks rxaviers.
[09:28:04] <scott_gonzalez> That new class can't be used though.
[09:28:11] <scott_gonzalez> Because it's a pseudo-element.
[09:28:23] <arschmitz> why cant it ?
[09:28:33] <scott_gonzalez> How are you going to put a class on it?
[09:29:02] <arschmitz> you add the class to the element and in the theme css you have .newclass:after
[09:29:15] <arschmitz> and nothing for just .newclass
[09:29:27] <arschmitz> so all it does is affect :after elements
[09:29:39] <scott_gonzalez> But it doesn't make sense in terms of the CSS framework.
[09:29:52] <arschmitz> why?
[09:30:45] <scott_gonzalez> What's a name that would make sense to put on an element which doesn't get the actual styles?
[09:31:40] <arschmitz> well since its acting on the elements after element .ui-icon-state:after
[09:32:00] <arschmitz> acting on elements icon i mean
[09:33:58] <fnagel> Isn't it  a question of browser compat, too? http://caniuse.com/#search=AFTER
[09:34:04] <scott_gonzalez> Won't that break all the existing icons?
[09:34:11] <arschmitz> scott_gonzalez: no
[09:34:18] <fnagel> :after does not work IE7
[09:34:33] <scott_gonzalez> We won't support IE7 by the time this lands.
[09:34:55] <arschmitz> and in ie7 you just dont get icons the same as you dont get rounded corners
[09:35:20] <fnagel> scott_gonzalez: We drop support for IE7 in 1.11?
[09:35:23] <scott_gonzalez> no
[09:35:30] <scott_gonzalez> This isn't part of 1.11
[09:35:42] <fnagel> Ah ok, sorry :-)
[09:35:47] <arschmitz> and same as inputs dont get icons for buttons
[09:36:47] <scott_gonzalez> This just seems wrong to me.
[09:36:52] <scott_gonzalez> But I'm not a CSS person either.
[09:37:28] <arschmitz> well things will be weird using after for icons at all will be weird until everything switches to it
[09:37:55] <scott_gonzalez> The icon state probably shoudn't be independent of the widget state either.
[09:38:10] <arschmitz> it does not have to be
[09:38:51] <scott_gonzalez> Why are we using :after?
[09:39:06] <scott_gonzalez> You've probably explained this to me before.
[09:39:16] <arschmitz> because when you and i discussed it whats what we decided
[09:39:29] <arschmitz> because then you dont need to add the span
[09:39:36] <arschmitz> and can do everything with just classes
[09:39:57] <arschmitz> thats how you are able to do the css only buttons
[09:40:02] <scott_gonzalez> Oh, this is to facilitate people who want to just write straight markup?
[09:40:20] <arschmitz> well the widget uses the same markup
[09:40:20] <scott_gonzalez> That's really annoying.
[09:40:42] <scott_gonzalez> That comment wasn't about the widget using the same markup.
[09:41:00] <scott_gonzalez> It was about the pure markup version changing how things work.
[09:41:01] <arschmitz> ok
[09:41:28] <arschmitz> the other option is force people to manually add the span
[09:41:37] <scott_gonzalez> I'm not sure this is a good idea for checkbox/radio.
[09:41:57] <arschmitz> well i was making checkbox radio share markup with button
[09:42:16] <arschmitz> since its basicly a special button
[09:42:42] <scott_gonzalez> I think that's a bad goal if it's putting us in awkward situations where we need to change the CSS framework.
[09:43:07] <arschmitz> its no more awkward then the :After for icons
[09:43:09] <arschmitz> for buttons
[09:43:35] <arschmitz> the awkward part is from supporting both ways depending on the widget at all for icons
[09:43:44] <scott_gonzalez> Buttons aren't doing anything that violates our CSS standards.
[09:44:39] <arschmitz> i guess im not clear on what css standard is being violated
[09:44:53] <scott_gonzalez> Putting colors in the widget CSS.
[09:45:03] <scott_gonzalez> And you're proposing that we can avoid that by adding to the CSS framwork.
[09:45:11] <scott_gonzalez> But I don't see anything that needs to be added at that level.
[09:45:49] <scott_gonzalez> Unless this just can't be done with the existing states.
[09:45:55] <scott_gonzalez> For example, inverting the state on the actual icon.
[09:46:07] <scott_gonzalez> So when the button is default, the icon is active.
[09:46:14] <scott_gonzalez> When the button is active, the icon is default.
[09:46:29] <arschmitz> have you looked at how it is now?
[09:46:35] <arschmitz> in that branch
[09:46:40] <scott_gonzalez> yes
[09:47:07] <scott_gonzalez> label.ui-radio-label.ui-radio-checked:after,
[09:47:07] <scott_gonzalez> label.ui-radio-label.ui-radio-checked:hover:after{
[09:47:07] <scott_gonzalez> 	background-color: black;
[09:47:07] <scott_gonzalez> }
[09:47:49] <scott_gonzalez> But I'm still not sure where the other colors come from.
[09:48:07] <arschmitz> yes that one was one i needed advice on the rest are in the theme
[09:48:19] <scott_gonzalez> The use of :after is making this really hard for me to inspect.
[09:48:44] <arschmitz> cant you just click the after element?
[09:48:56] <arschmitz> chrome stable as those in the dom now
[09:50:18] <scott_gonzalez> I need to reinstall Chrome.
[09:50:25] <scott_gonzalez> It never updates for me.
[09:50:52] <arschmitz> lame
[09:51:37] <scott_gonzalez> I'm probably not the right person to give you an answer about this.
[09:51:44] <scott_gonzalez> I was hoping that someone else would chime in.
[09:52:33] <uGoMobi> arschmitz: do you have a link so I can take a look?
[09:53:00] <arschmitz> http://view.jqueryui.com/button/demos/button/checkbox.html
[09:53:03] <uGoMobi> thanks
[09:54:21] <arschmitz> to be honest im very open to better ways
[09:54:38] <arschmitz> this is just the best i could come up with
[09:55:24] <fnagel> arschmitz: the checkbox icon is broken after reset in FF26
[09:55:49] <arschmitz> fnagel: thanks ill take a look
[09:57:14] <uGoMobi> arschmitz: first you had the icon bg color change on hover, right?
[09:57:24] <uGoMobi> arschmitz: this looks better
[09:57:45] <uGoMobi> oh wait, it still does
[09:58:09] <fnagel> uGoMobi: the icon BG color does not change in FF
[09:58:10] <uGoMobi> but only if the checkbox is checked
[09:58:26] <fnagel> uGoMobi: right, it changes if its checked
[09:58:49] <uGoMobi> I think that's a bit confusing
[09:58:51] <arschmitz> yeah there is some weird ness there i need to figure out
[09:59:50] <arschmitz> the question is the approach to where colors come from make sense
[09:59:50] <fnagel> arschmitz: I'm porbably a little late with this question, but anyway: why do we use input wrapped in a label. This is known to cause a11y issues (for example Twitter Bootstrap changed this in v3.0)
[10:01:13] <uGoMobi> arschmitz: let's discuss on -dev another time
[10:01:15] <arschmitz> fnagel: jzaefferer had commeneted this is no longer an issue
[10:01:25] <arschmitz> just a sec ill get the link
[10:01:54] <arschmitz> fnagel: https://docs.google.com/document/d/1yFD_Y9QuuMTI4NOc-JQYRjPTrcVV52h7ZeLKLPbSj40/edit
[10:02:32] <fnagel> arschmitz: I'm fine with using :after for changing background if all needed browser support this. No reason not to use it in my opinon.
[10:02:46] <fnagel> arschmitz: Thanks I will take a look