[08:01:37] Thanks scott_gonzalez [08:01:57] The room smells fresh :) [08:02:24] I have no idea what that means :) [08:03:10] oh well [08:03:24] Starting at qunit [08:03:48] We've had some chatter from Samsun who wants to use the junit reporter [08:03:57] We had some licensing lackings, those are fixed now. [08:04:07] Samsung Electronics* [08:04:10] Samsun or Samsung? [08:04:13] lol, ok [08:04:22] I also published both plugins on NPM [08:04:32] composite and junit [08:04:33] Including qunit-composite? [08:04:34] Hmm [08:04:37] ok [08:05:00] Won't work on Node AFAIK unless jsdom/cheerio can simulate iframes [08:05:04] let's standardize on the npm keyword 'qunit-plugin' (like 'gruntplugin') [08:05:08] that'll make discovery easy [08:05:11] but I guess it makes it easier to pull down [08:05:15] Exactly [08:05:18] k [08:05:37] Do we publish QUnit stuff to Bower at all yet? Assuming not since I don't see a bower.json/component.json [08:05:44] qunit-reporter-junit has qunit, qunit-plugin, qunit-reporter, junit [08:05:52] No, we don't. [08:06:13] We shouldn't publish packages to npm unless we know for sure they're useful. [08:06:25] I don't use bower anywhere, nor do I see it used in other jquery projects. I suppose we can add it on -demand, don't feel like adding it prematurely [08:06:45] https://github.com/jquery/sizzle/blob/master/component.json [08:07:06] But before we add anything, we should have a larger discussion about package managers. [08:07:26] scott_gonzalez: Is that why .min and .map are now in the repo? I assume bower is not capable of install hooks? [08:07:40] for sizzle that is [08:07:47] I have no idea. [08:09:10] https://github.com/jquery/qunit/issues?sort=updated&state=open [08:09:34] I've triaged a bit earlier today adding labels where missing [08:09:48] should be a bit more organised now [08:11:55] JamesMGreene: Is there anything in particular you are or would like to work on? [08:18:37] Jenkins [08:18:38] sorry, was busy w/ day job [08:19:51] Jenkins still same old same old. Random out of memory, and web server crashing periodically causing all testswarm jobs to fail. [08:20:26] gnarf and I are waiting for a timezone overlap to get Jenkins moved to its own server. This might fix it, but should at least give better insight [08:21:02] and it'll force us to review what the environment contains (as we'll have to rebuild it) perhaps an opportunity to puppetise some [08:21:06] Krinkle: if you want to work on that yourself, please do [08:21:15] Krinkle: im gonna be even further away next week [08:21:16] portland [08:21:19] I'm supposed to be working through the QUnit PRs for Node compatibility but I've just been swamped lately [08:21:42] Krinkle: just take good notes, my only request :) [08:21:57] perhaps you and jzaefferer can hack it together instead of me being around [08:22:06] gnarf: So what do I need to do exactly [08:22:10] gnarf: Jenkins is already installed, right? [08:22:24] I am also supposed to separate the PhantomJS plugin, though [08:22:27] yeah, move jobs over, make sure they work well, make sure jenkins can scp to swarmy [08:22:29] etc [08:22:34] though = too [08:23:20] Though scott_gonzalez is lamenting so many QUnit repos :) [08:23:20] gnarf: Can they communicate within the subnet? Or does it have to be through full domain names? [08:23:48] gnarf: I imagine 'jq03' could resolve as is, haven't tried though [08:23:50] use the dns, it's probably safest [08:24:03] though honestly [08:24:08] gnarf: what do you mean by use the dns? [08:24:11] maybe we should still use the jenkins. subset for the http [08:24:43] so like jenkins.jquery.com/jobout/jquery/sha/test/ [08:24:59] instead of scp for the whole built test suite [08:25:00] i mean the scp/ssh from jenkins to jq03 [08:25:05] oh [08:25:08] hmm.. [08:25:12] what do you mean [08:25:18] Krinkle: Any update on https://github.com/jquery/qunit/issues/422 ? [08:25:25] yeah, target jqadmin@code.origin.jquery.com for the scp of builds to origin [08:25:29] ^^^ use the dns [08:25:39] right, so over public IP. [08:25:43] right now, all the tests are also hosted in the swarm [08:25:59] but those could be hosted in a subfolder on jenkins.jquery.com/output/ [08:26:01] or something [08:26:10] gnarf: Yes, I'd prefer that actually [08:26:13] same [08:26:20] you feel okay with the "output" folder? [08:26:27] separation of concerns [08:26:36] or maybe [08:26:37] though it'll need to be on apache, as it needs php execution for ajax tests etc. [08:26:43] tests.jenkins.jquery.com ? [08:26:51] screw apache [08:26:53] gnarf: have you, should I still ; set up proxy? [08:26:57] nginx of course [08:27:00] if it doesn't work in nginx/php-fpm [08:27:03] we need to fix it [08:27:04] :) [08:27:06] I meant nginx [08:27:09] yeah [08:27:10] so [08:27:14] apache==web server :) [08:27:29] i'll setup jenkins.jquery.com -> :8000 (or whatever port jenkins runs on) [08:27:37] as a proxy [08:27:42] lets do a subdomain output? [08:27:53] builds.jenkins.jquery.com [08:28:13] I also need to work on some PRs to get the Composite and JUnit plugins to work together correctly (remember we talked about "suite" event emissions?), too [08:28:17] gnarf: ok [08:28:24] JamesMGreene: checking https://github.com/jquery/qunit/issues/422 now [08:28:31] Krinkle: i'll setup that proxy stuff today [08:28:35] So I've got no shortage of stuff to do, though only the Node compat PRs are specific to QUnit core [08:28:47] JamesMGreene: Working on it, though I've also been swamped with stuff [08:28:49] Krinkle: also, i'll make sure jenkins@jenkins has a ssh key that can access jqadmin@code.origin [08:29:03] gnarf: ok [08:29:09] Krinkle: I don't see any updates on 422...? [08:29:21] JamesMGreene: there's nothing to say [08:29:38] it's assigned to me, I'm working it. commit shall appear at some point [08:29:38] oh, I misread your previous message [08:29:51] Thought you said "check" rather than "checking" [08:34:00] gnarf: updated task lists https://github.com/jquery/infrastructure/issues/176 [08:37:07] Krinkle: thanks [08:37:53] gnarf: Only thing I dont' know for sure is how to import the database, but I haven't looked into it either. [08:38:01] mysql dump? Or does it have its own thing [08:38:08] pretty sure it's just a copy of /var/lib/jenkins [08:38:19] don't think it uses sql at all [08:38:54] gnarf: isn't that (part of) the application itself as well? [08:39:09] i think the lib is purely data [08:39:10] Or is the var/lib dir really just the state [08:39:13] ok [08:39:19] confirm with jorn maybe? [08:39:30] will do [08:41:43] So, next, browserstack [08:41:55] working fine from what I can tell, getting stable [08:42:11] JamesMGreene: Do you have an account on splunk.jquery.com? [08:42:17] Not that I know of [08:42:27] https://splunk.jquery.com:8000/ [08:42:39] It is where lots of data is aggregated for analytics [08:42:45] incl. logs and stuff [08:43:04] Data from where? [08:43:09] the servers [08:43:19] access logs, error logs, debug logs [08:43:24] e.g. from testswarm-browserstack [08:44:14] JamesMGreene: username "JamesMGreene" ok ? [08:44:49] Yup [08:46:00] pm'ed password [08:46:03] try logging in [08:46:38] https://splunk.jquery.com:8000/en-US/app/search/browserstack [08:48:16] Splunk has amazing indexing power [08:48:40] making queries is easy and you can just about combine any data and aggregate it and get anything out of it you want [08:48:45] https://splunk.jquery.com:8000/en-US/app/search/php_errors [08:49:29] example search https://splunk.jquery.com:8000/en-US/app/search/flashtimeline?q=source%3D%22%2Fvar%2Flog%2Fphp5-fpm%2Ferror.log%22%20%7C%20search%20NOT%20%22jQuery%20Mobile%20Branch%20Preview%2Fworkspace%2Fbranches%22 [08:49:55] lastly, testswarm [08:50:14] the projects rewrite is landing, today (my time zone) [08:54:59] Yeah, I've used it just a little bit at work before [08:56:05] jzaefferer is at a conference, btw (probably FrontTrends?) [09:05:04] scott_gonzalez: You may lock the door behind us :) [09:06:33] Krinkle: see meetings.jquery.org repo? [09:06:56] https://github.com/jquery/meetings.jquery.org ? [11:01:04] hi [11:01:21] Looks like it's -m up in here [11:01:37] The jQuery Mobile team meeting is starting up [11:01:42] Chime in if you're here [11:05:24] Hi _|Nix|_ [11:06:10] SPEAK [11:06:11] hi! [11:06:17] Hi uGoMobi [11:06:37] <_|Nix|_> Hey! [11:06:38] wondered why it was so quiet here. I must be in op mode so it seemed -m [11:06:49] <_|Nix|_> :) [11:07:03] Hi [11:07:28] Hey _|Nix|_, arschmitz [11:08:02] Hi [11:09:00] Hi agcolom [11:09:05] agenda here: https://docs.google.com/document/d/1yrVEKJuEZa4gaM_bJkwPDm49zzdnLX6LrTYhLNq_HP4/edit# [11:10:06] do we have a wiki page where we're tracking 1.4 changes yet? [11:10:22] Hi johnbender [11:10:34] :) [11:10:39] toddmparker: the page is there, but I haven't added notes there yet [11:10:55] ok, cool [11:10:59] linking that up [11:11:29] might as well start [11:11:34] Team is focused on 1.4 work. Good progress with week in the “next” branch. Preview here: http://view.jquerymobile.com/next/demos/ [11:11:48] https://github.com/jquery/jquery-mobile/wiki/1.4-changelog [11:14:33] thanks uGoMobi - linked up in the notes [11:14:54] will start adding notes there soon [11:14:56] Q on versions - should we switch to core 2.0 in "next" to really test the hell out of 2.0 [11:15:08] toddmparker: next is on core 2.0 [11:15:09] uGoMobi: great. it was super helpful for 1.3 [11:15:19] ah, sweet. master is 1.9? [11:15:22] nope [11:15:26] also on core 1.9 [11:15:36] sorry [11:15:42] also on core 2.0 [11:15:55] I think master should probably still be on 1.9 since we still support ie8 [11:15:55] ok. so all dev is on 2.0 [11:16:10] that's cool. [11:16:20] IE8 is busted indeed [11:16:33] i will be good to figure out a way to test both core versions via a preview link [11:16:37] but we really do need to test 2.0 so good to have next on it [11:16:38] <_|Nix|_> Is IE8 the last of the OldIE browser? [11:16:43] there a way to set that up? [11:17:07] the guys from bocoup have a setup using a query param for it [11:17:11] we can set up a mirror branch [11:17:12] for now, we could leave master on 1.9 and use 2.0 in next [11:17:20] johnbender: what version does content-widget use? [11:17:27] but have to merge master in it manually I suppose [11:17:53] we should look at what bocoup is doing with setting jquery version in url for view [11:17:59] toddmparker: won't matter [11:18:19] arschmitz: ok [11:18:44] toddmparker: the only thing that I can think of is event binding methods and I'm switching to the widget factory _on and _off so it should "just work" [11:18:50] 1.9 and 2.0 should be the same ATM, but they will diverge over time and there could already be subtle differences [11:20:04] i think if master is on 1,9 for now we can easily test old IE [11:20:15] if the new branches use 2.0, that's probably the way to go [11:21:06] once we start merging to master, we may need a way to switch versions so we can do device testing. I know we run automated tests against versions already, but that won't necessarily find everything [11:21:33] anyway, good to hear next is 2.0. that was the main thing [11:22:05] one item i saw - https://github.com/jquery/jquery-mobile/issues/5933 [11:22:33] uGoMobi: I think I agree with your suggestion to remove some magic and make people assign a button role and positioning class in headers [11:22:58] +1 to Deprecate auto-enhancement of links in toolbars [11:22:58] toddmparker: maybe arschmitz knows a good way to make page.sections handle this [11:23:14] but otherwise I think we should deprecate [11:23:26] it is handled by new toolbar widget [11:23:34] page.sections is gone in branch for that [11:23:35] i'm in favor of just being more direct with the markup and making fewer assumptions [11:23:39] right [11:23:55] anyone object? [11:24:06] nope +1 [11:24:15] this change would happen in 1.5 [11:24:24] ok, add it to the wiki then [11:24:58] johnbender: want to prate us on the new branch you're tinkering with? [11:25:04] update :) [11:26:30] sure [11:26:32] so [11:26:35] content-widget [11:26:41] I'm ripping out about half of nav [11:26:53] bit by bit I'm unit testing the parts that I rip out [11:27:01] and running the whole nav test suite for each commit [11:27:02] small commits [11:27:23] if you're interested in more detail on what I have in mind you can read about it here: https://github.com/jquery/jquery-mobile/issues/5427#issuecomment-17026148 [11:27:37] anyhow the initial pass is going to be breaking up nav [11:27:42] into tiny bits [11:27:46] that make sense as a content container [11:27:58] so changePage, loadPage, navigation even handling [11:28:05] getting them tested [11:28:12] so it's actually possible reason about [11:28:33] then moving on to leveraging that [11:28:37] I like how you're using the issue to keep notes and updates flowing [11:28:49] arschmitz: _|Nix|_: I want to keep you guys up to date [11:29:00] there might be a point where you guys can dive in and help out [11:29:03] anyhow [11:29:05] that's that [11:29:09] one other thing [11:29:16] absolutly just let me know [11:29:22] <_|Nix|_> For sure! [11:29:27] your note about scrolling is a good one. that seems to be trouble across browsers [11:29:29] agcolom: did we sort out where I should be pushing api site updates for 1.4? [11:29:34] cool, good stuff johnbender [11:29:57] johnbender: I'll get that done with scott_gonzalez. probably next week [11:30:01] so you asked - "Need to discuss api website versioning" [11:30:08] junx [11:30:19] agcolom: great. [11:30:25] cool [11:30:26] agcolom: thakns [11:30:28] *thanks [11:30:36] We will follow the api ui docs [11:30:36] we need to figure out how to start updating the 1.4 docs [11:30:42] ya [11:30:50] yes, there will be a 1.4 branch [11:31:00] so for now, can people update the API docs at all? [11:31:09] is that branch set up? [11:31:23] if that's the plan, easy enough to make a branch [11:31:23] not set up yet. That's what I need to do with scott [11:31:57] alright, we can wait until you chat with him [11:32:09] thx. [11:32:17] Congrats on being elected to the jQuery Board agcolom [11:32:22] but if we merge that branch in master the info for previous versions will be gone? [11:32:22] woo hoo [11:32:25] Thank you :) [11:32:43] uGoMobi: That's what I'll check with Scott [11:33:02] agcolom for president (sorry Dave)! [11:33:09] agcolom: ok cool [11:34:10] you all see this? [11:34:12] nativeDroid 0.1 - Impressive Android 4.x theme for jQuery Mobile 1.3 - nativedroid.godesign.ch [11:34:22] yeah, nice theme [11:34:28] <_|Nix|_> Highly cool! [11:34:34] and it's in the resources page [11:34:37] really well done [11:34:41] agcolom: rokk [11:35:24] We now have solid 3rd party themes for iOS, WP7, BB10, Android 4.x [11:35:31] pretty cool [11:35:57] agcolom - anything you wanted to discuss? [11:36:29] minor update this week Went to jQuery uk [11:36:38] met johnbender and frequent [11:36:47] nice [11:36:58] and Jason and Ralph [11:37:12] Started to rewrite the events to use the new events template (in the api docs). Completed swipe, swiperight, swipeleft [11:37:12] Fixed errors in api docs (panels) [11:37:12] some minor triage [11:37:13] mobile representing [11:37:40] updated the resources page with the nativeDroid theme and Prime Faces [11:38:12] thanks [11:38:16] (we're doing a course review at work and draft docs are due in tomorrow!) [11:38:28] good luck [11:38:31] thanks agcolom [11:38:33] Thanks [11:38:44] sorry for not doing more recently! [11:38:58] no worries at all, life happens [11:39:12] appreciate all the work you all do, it's sort of amazing [11:39:31] that's because we have the BEST BOSS ever! [11:39:47] aww [11:39:53] thanks [11:39:57] so uGoMobi, _|Nix|_ - you want to talk about what's up on "next" [11:40:04] sure [11:40:15] been a heck of a productive week [11:40:20] <_|Nix|_> Sure! [11:40:27] summary: [11:40:29] <_|Nix|_> Absolutely ... [11:40:29] buttonMarkup has been removed from all widgets [11:40:29] icons are moved to a pseudo element [11:40:29] working on: updating / cleaning up CSS of all the widgets that used buttonMarkup [11:40:29] next step: theme inheritance / reduce addClass() for styling and icons [11:40:44] for those following along - preview here: http://view.jquerymobile.com/next/demos/ [11:41:15] did I forgot anything _|Nix|_ ? [11:41:49] <_|Nix|_> Well, I just push a re-implem of buttonMarkup using only string processing and className. [11:41:50] all the widgets are back into good shape [11:42:06] <_|Nix|_> I do have a potentially controversial thought though. [11:42:24] i do think that having a unique swatch for an inset element like a slider track or the off state of the flip switch might be useful [11:42:31] <_|Nix|_> Now that buttonMarkup is gone, we do a lot of .addClass( "ui-btn ui-btn-" + theme + " ui-corner-all" ) [11:42:31] and one for listviews [11:42:34] <_|Nix|_> etc. [11:42:35] (when we get there) [11:42:42] toddmparker: I agree [11:42:54] _|Nix|_: yes, yes we do [11:43:10] <_|Nix|_> So, here's my thought ... we use .buttonMarkup() :) [11:43:13] tho the hope is uGoMobi will reduce that a lot with inheritance [11:43:19] <_|Nix|_> But before you shoot me ... [11:43:35] WHAT [11:43:38] kidding [11:43:43] <_|Nix|_> I'm only suggesting this amidst thorough perf tests ... [11:44:07] <_|Nix|_> My justification: buttonMarkup is not what it used to be. [11:44:22] <_|Nix|_> For example, it doesn't access any data-* attributes anymore. [11:44:28] <_|Nix|_> It only accesses .className. [11:45:06] <_|Nix|_> ... and I'm thinking about adding an option to buttonMarkup that simply skips checking that too. [11:45:11] so in the last pass, we got rid of button markup and added the class stuff to each plugin - that right? [11:45:17] <_|Nix|_> So, it simply goes over the options and adds the appropriate classes. [11:45:24] <_|Nix|_> toddmparker: Yeah. [11:45:43] <_|Nix|_> The benefit would be that this gives us a chance to change the class names in one place rather than 23. [11:45:51] and we removed all ui-btn-inner and ui-btn-text wrappers! [11:45:56] so there is a perf benefit to centralizing this or just makes the code DRY [11:46:19] sounds like the latter [11:46:37] <_|Nix|_> It's likely a perf hit, but if it's small enough it will likely still be faaaar better than what we have now. [11:47:01] <_|Nix|_> I can do the perf tests to see if this pans out at all. [11:47:09] ok, sounds good [11:47:17] anyone have opinions on this? [11:47:21] if the performance diff is small i like the idea of centralizing it [11:47:22] I think we should first look at reducing the need to add classes [11:47:23] or just wait and see [11:47:32] but performance will be the deciding factor i think [11:47:33] <_|Nix|_> uGoMobi: Agreed. [11:47:35] and then look at how to add the classes we really need [11:47:40] uGoMobi: i agree there for sure. [11:48:04] might be more productive to see what add additions we need to support, then look at this [11:48:20] <_|Nix|_> toddmparker: "add additions"? [11:48:42] for example... with the markup we have for listviews now I can make a basic list with links work without adding a single class to a LI [11:48:47] sorry, see what each widget needs in terms of class decoration [11:48:58] uGoMobi: right, that is awesome [11:49:17] uGoMobi: for sure the less classes are added in js the better [11:49:23] in that case, we'd start encouraging people to add the classes themselves to the UL [11:50:40] <_|Nix|_> ui-btn ui-btn-x ui-corner-all ui-shadow ui-icon ui-icon-x ui-btn-icon-x ui-shadow-icon ui-btn-inline ui-mini [11:50:46] <_|Nix|_> That's what we have now. [11:50:52] the holy grail is that in 1.4, we can support the older data- attr API for things, even if a bit inefficient, but deprecate these in favor of adding a few classes/wrappers to the markup [11:51:01] in 1.5, we drop the old way [11:51:16] _|Nix|_: that is the an issue for sure. [11:51:25] <_|Nix|_> Amen. In that case, we need to announce that buttonMarkup is deprecated. [11:51:32] a default button has a lot of those 'options' as true [11:51:44] <_|Nix|_> After that, we can move it to a private method if we still want to centralize things. [11:52:01] that large amount of classes is mostly because we are in between changing markup and changing theming [11:52:05] so we do end up with a ton of classes [11:52:36] <_|Nix|_> Well, a lot of those correspond 1-to-1 with options. [11:52:36] sure, but since corners, shadows, btw styles, are all granular classes, you do need to add them [11:53:15] if we had a preprocessor, we could have a btn-default class that included ui-corner-all ui-shadow, etc. [11:53:35] <_|Nix|_> However, if we can encode the defaults in CSS, then we do not need to add the classes that are default. [11:53:42] they do, but a lot of options are true by default so you don't need to explicitly set 'em [11:53:53] right [11:54:09] we could decide to change the defaults in 1.4 right? [11:54:15] this somewhat comes back to that idea of using a pre-processor as a class config tool [11:54:23] <_|Nix|_> Wait a sec ... we have ui-btn [11:54:27] uGoMobi: maybe [11:54:37] <_|Nix|_> We could define ui-btn as having all the defaults. [11:55:14] <_|Nix|_> Though I'm not sure how you would turn those off ... [11:55:26] think it may make sense to leave the classes as in generally and introduce a new class like ui-btn-defaultoptions (not really) that includes the true options into it [11:55:36] yeah but if ui-btn has box-shadow because that's the default you need ui-no-shadow to unset [11:55:43] right, that avoids the need to ui-shadow-none [11:56:02] <_|Nix|_> uGoMobi: Yeah, I realized that. It just inverts the whole thing but you need the same amount of classes. [11:56:11] and since we're adding to the class API, it's less distruptive [11:56:28] _|Nix|_: I know you realized but I thought let's finish my line anyway ;-) [11:56:37] heh [11:56:42] <_|Nix|_> That's the one redeeming quality of buttonMarkup: It can merge options ... [11:56:58] right. but it's js-dependent [11:57:06] <_|Nix|_> Well, we could have one class for each combination. [11:57:28] <_|Nix|_> That'd make for a funny name. [11:57:31] so uGoMobi - you're getting close to looking at inheritance and class reduction so that will provide the critical info here [11:58:04] toddmparker: yes [11:58:22] so let's see how that shakes out, then look at potential solutions [11:58:23] <_|Nix|_> uGoMobi: Is all this gradient-background-safe? [11:58:35] <_|Nix|_> uGoMobi: In case somebody wants to make a theme with a gradient background? [11:59:06] _|Nix|_: yeah, shouldn't be a problem [11:59:17] <_|Nix|_> OK. [11:59:18] background can't be inherited anyway [11:59:35] so we have to set it, plain color or gradient doesn't matter [12:00:09] bg can't be inherited? [12:00:43] nope [12:00:47] huh, interesting [12:01:08] <_|Nix|_> uGoMobi: So, correct me if I'm wrong: The goal for theme inheritance is to achieve this: If you set a theme on an element, all its children will have that theme, right? [12:01:09] https://developer.mozilla.org/en-US/docs/CSS/background [12:01:18] uGoMobi: guessing we're going to have to add more widget scopes to get inheritance to work [12:01:39] we have to do something smart with the selectors [12:01:46] right [12:01:53] _|Nix|_: that's right [12:02:02] <_|Nix|_> uGoMobi: OK. Just checking. [12:02:36] especially important for groups of button-y things like list views and controlgroups [12:02:48] yes [12:02:49] <_|Nix|_> uGoMobi: Also, there're multiple kinds of themes. There's theme, and divider-theme, and header-theme, and count-theme, etc. [12:03:02] so you can ideally set it on the parent and it ripples down [12:03:19] <_|Nix|_> uGoMobi: So, if we do that all-the-children-have thing, then we need to do that for each kind of theme. [12:03:20] but you can also add a class on an inter inside and that will take precedence [12:03:46] .ui-body-a .ui-btn { } [12:03:54] ^ right [12:04:24] <_|Nix|_> toddmparker: Exactly. I think of it like poking a stick into a river: It makes a v-shaped wave on the water's surface. Now, if you poke a second stick into this wave, it makes a second smaller v inside the bigger v. [12:04:40] <_|Nix|_> I just had to get that image off my mind. Sorry! [12:05:29] .ui-listview.ui-btn-a li { } [12:05:29] we have to make sure that if you set a theme on a button itself that the selector that matches has a higher level of specificity [12:05:42] right, it's going to be tricky [12:06:00] to make sure the if you specify swatch A it still overrides swatch Z for the body [12:06:17] while style for swatch A precedes swatch Z in the stylesheet [12:06:27] i'm ok with losing some of the inheritance for convenience (i.e. all forms inside a container inherit), my main goal is reducing redundancy for list views and such [12:06:38] i think we need to add a section on css specificity lol people are going to get SOOO confused and file issues [12:06:49] agreed [12:06:55] good faq? [12:07:11] there is a faq about it but i think it needs to be expanded [12:07:22] it basicly just says check your specificity [12:07:26] ok [12:07:32] but maybe add some info about how specificity works [12:07:38] heh. "do it right, ok?" [12:07:51] great work on this stuff [12:08:04] arschmitz: you've gotten some goodies done this week too [12:08:12] yup! [12:08:39] branch page-sections is actually the removal of page.sections [12:09:01] .ui-body-a .ui-btn, a.ui-btn.ui-btn-a { } [12:09:01] .ui-body-z .ui-btn, a.ui-btn.ui-btn-z { } [12:09:12] that should work ^^ [12:09:32] <_|Nix|_> arschmitz: Actually, next anticipates that. I've removed .ui-header > a and .ui-footer > a from the buttonMarkup "initSelector". [12:09:35] my brain hurts [12:09:37] but also need to add button.ui-btn.ui-btn-a selector [12:09:49] it moves logic that was in page.sections to page widget and new toolbar widget [12:09:57] arschmitz: great [12:10:01] moves btn logic for headers to toolbar [12:10:09] be good to have that properly structured [12:10:11] <_|Nix|_> uGoMobi: Only a.ui-btn? What about input and button? [12:10:20] it alows both fixed and regular toolbars outside of pages [12:10:43] that is hot [12:10:55] _|Nix|_: but also need to add button.ui-btn.ui-btn-a selector (and div.ui-btn.ui-btn-a for the input) [12:10:58] Makes true persistant tolbars possivle [12:11:06]