[10:02:06] ping arschmitz cgack helen ianmaffett jzaefferer kborchers michaelarestad scott_gonzalez [10:02:39] :) [10:02:42] Meeting Notes: https://docs.google.com/spreadsheets/d/1FUdRcAq2d8njs8KAcfQmEyoZL74SXLsLp1rtc7E9z_I/edit?usp=sharing [10:02:43] hello [10:03:19] Hi [10:04:47] hope everyone had a good holiday [10:05:51] hello [10:06:00] dam____: Hi [10:07:39] Okay, so it's been awhile since we've had a meeting. Hope the rest of you managed to avoid the Plague going around. [10:08:26] First up on the list is our favorite talk, which is which SVG icon set to use. Seems we're starting to get a bit more focused in this discussion, and looking at which icons we want to support this first go [10:08:33] and which ones will probably be needed in a project [10:09:03] Id like to see a huge variety available as a builder option [10:09:06] but a small set in the default build [10:10:07] I like that idea a lot [10:10:15] I think we should start with a minimum viable set. [10:10:23] i hate having to go look for icons that are not built in [10:10:24] And then build out from there . [10:10:42] but i also hate being forced into icons i dont need lol [10:10:43] Right. [10:10:46] I felt like we were limiting ourselves prematurely by not considering use cases [10:11:20] I would be cool with a minimal set and then just add them as users need [10:11:20] best of both worlds? [10:11:42] I think builder is key if we have an easy to user builder there can be as many or few as people want (Within the limits of maintainability ) [10:12:06] and no one is forced into anything [10:12:45] I personally feel like the big use case to consider as far as minimal set though is what will be in the default build on cdns [10:12:59] I think a builder is key, however, getting to that point is another issue. We should start small. Focus on the rest of the project and keep building onto the icons (and implement a builder) once we have a good baseline. [10:13:04] plus it seems like whatever we use we will make it possible to switch them out with custom ones so no biggie [10:13:06] we dont want to bloat that but we need to know what the common ones people actually use are [10:13:19] I agree with dam____ [10:13:29] I agree we should not get bogged down or waste time on what specific icons we want right now [10:13:38] pragmatism is understandable [10:13:38] whatever we do choose to do with svg icons, make it easy to switch out custom ones [10:13:53] ^that [10:13:53] its easily changed over time [10:14:21] michaelarestad: i think is right other things are much more important at this stage [10:14:31] agreed [10:14:33] Honestly, while the defaults will be great for an example and use, the ability to drop in fifty SVGs I prefer and build will be the major benefit. [10:14:47] totally [10:14:52] So I'm all about a small baseline to get things rolling. [10:14:58] Even if it's three icons. [10:15:12] for right now just haveing 3 would be enough to build around [10:15:41] because thats all we need for now is something to basicly use as a place holder was we develop the rest [10:15:50] was/while [10:15:57] Cool. How about: Circle, Triangle, Square? [10:16:04] works for me [10:16:13] sweet [10:16:24] they are just essentially place holders so simple is best [10:16:24] Cool. Will make/pr [10:16:29] yep [10:17:07] <3 [10:17:37] Cool. [10:17:43] awesome! [10:17:58] Sounds good to me [10:18:14] what is next on the agenda? [10:18:31] how about my delinquent perf stats? [10:18:36] https://docs.google.com/spreadsheets/d/1FUdRcAq2d8njs8KAcfQmEyoZL74SXLsLp1rtc7E9z_I/edit?usp=sharing [10:18:59] doh! thatnks [10:19:06] I think Style Guide was next [10:19:30] So i feel like we are REALLY REALLY Confusing several different things here [10:19:43] huh? [10:19:51] in the style guide issue [10:19:53] yeah, that style guide issue is a bit all over the place at times, depending on how people are defining style guides [10:20:13] I liked the change of wording to a pattern library [10:20:20] I feel like we may want both ;) [10:20:28] the original thing was just about having a page that had examples of all the components [10:20:40] to be able to look at to see if everything looks ok in a single glance [10:20:41] which is more of a pattern library to me [10:20:48] but now there is talk of generated style guides based on comments in code [10:20:54] right [10:20:57] yup [10:21:03] which also creaps into api style docs [10:21:06] Issue is Style Guide can mean like 3 very different things [10:21:10] which is nice to have once you are in production [10:21:17] ^THAT [10:21:24] exactly [10:21:43] that why i said i thing we are confusing this issue a lot [10:21:43] style guides to me infer color swatches etc. more design focused [10:21:55] could even be a static design file [10:21:57] to me style guides are more code style like [10:22:02] that too [10:22:03] ha [10:22:12] http://contribute.jquery.org/style-guide/css/ [10:22:32] pattern library to me means working examples of components [10:22:33] Ok, so: Code style guide, Pattern library, Design style guide (with design thinking)? [10:22:42] YES [10:22:45] Style Guide can mean a Design Style Guide, Style Guide on how code is written, and the coding side of the design style guide [10:22:47] michaelarestad: yeah [10:23:14] I like this @michaelarestad guy [10:23:20] and then there are api style docs which sometimes get mixed in though they should not [10:23:27] yeah [10:23:38] From the initial description in the issue, I would say this discussion is about a pattern library. [10:23:49] api style docs? [10:23:49] michaelarestad: yes thats correct [10:23:55] michaelarestad: yes [10:24:16] dam____: like normal documentation on actually using the framework [10:24:32] ah usage guides [10:24:53] just normal basic documentation [10:25:03] totally [10:25:03] OK [10:25:26] should we / I open separate issues for all of these items? [10:25:39] probably and try to be very clear what each is [10:25:40] update existing issue to pattern library [10:25:46] I can do that [10:25:47] I think there is already one about design thinking. [10:25:56] I think there is a design one [10:25:58] make new one for code style guide etc. [10:25:58] cool [10:26:02] michaelarestad: Ah right [10:26:06] there is one for code style guides [10:26:07] I believe [10:26:26] https://github.com/jquery/css-chassis/issues/23 [10:26:30] we may need to just link people to that in the pattern library one when confusion arrises [10:26:47] seems doable enough [10:26:52] https://github.com/jquery/css-chassis/issues/12 [10:26:58] So for now i dont think there is much to do for the pattern library one until we have components [10:27:04] right [10:27:23] docs there is nothing until we have things to document [10:27:24] Yeah. We can investigate generating it or building it. [10:27:27] I have been playing with the pattern lib generators though [10:27:32] I already created an issue on jquery-content tied into that too, to update the html style guide [10:27:39] But that's a low priority atm. [10:27:39] would be nice to gather criteria for the output [10:28:02] One thing i can say in general that i find with most auto generated documentation [10:28:12] is i find its not very good quality [10:28:20] and tends to clutter up the code with comments [10:28:43] for instance: do we need usage info next to the component? What about code? [10:28:44] this can be true [10:28:46] That's the one thing I get frustrated about when it comes to css code generated comments [10:28:49] I like to think of dev time and prod time code differently [10:29:13] as long as prod code has comments stripped I am a fan of docs inline [10:29:15] dam____: the reason i dont like the clutter [10:29:34] right [10:29:34] is that when your looking at the file you see much less of it [10:29:38] it i very convenient to have it authored all in the same place though [10:29:54] dam____: thats true for sure [10:30:10] otherwise you have multiple files open, checking syntax etc. w [10:30:36] that was why we eventually settled on including it in the files [10:30:40] yeah there are trade off's on both sides [10:30:40] the clutter is annoying though FOR SURE [10:30:49] super open for brainstorming a better way [10:31:28] Yeah im open i just generally prefer to not have that stuff inline just a preference [10:31:29] Let's split the "to autogenerated (or not)" pattern library conversation into a new issue. [10:31:44] michaelarestad: agreed [10:32:01] cool [10:32:01] Okay, shall create new issue [10:32:40] Rad. [10:32:41] My biggest concern is that all the documentation be High quality [10:32:47] regardless of how its generated [10:32:47] I agree. [10:32:57] that [10:33:23] Some of it can come as we decide what we want the final product to look like too [10:33:48] because we may find its simple or nearly impossible to auto-generate depending on the requirements we decide [10:34:12] right. Gather criteria for output first [10:34:53] yup once we have a few components we can make mock ups of what we want it to look like [10:34:54] and then see what it will take to generate it [10:35:04] some due diligence on checking out exiting generators seems to go with that as well. Some compare contrast [10:36:01] yup [10:36:11] ideally we would use something pre existing [10:36:19] not a fan of re inventing the wheel [10:36:25] Yep. [10:36:49] or find something closest and contribute the missing parts [10:36:58] yeah [10:37:14] feels good to contribute to existing projects :) [10:37:14] to me more or less the same thing :-) [10:37:23] if i use it and it does not do what i need i try to contribute :-) [10:37:32] Okay, first pass at the issue: https://github.com/jquery/css-chassis/issues/31 [10:37:48] making note in #11 regarding switching that part of the conversation over to #31 [10:38:17] I would take api out of the title might confuse people [10:38:24] other then that looks good to me [10:38:39] +1 [10:38:43] +1 [10:41:10] Okay, updated, and updated issue #11 as well [10:41:18] Boom. [10:42:14] So, does anyone have anything else they want to discuss regarding the giant blob that is style guides in general? [10:42:36] or does everyone think we've done a pretty good job of defining everything/creating issues and shall move onto the next issue? [10:42:49] id like to see us put some thought into filling out the reset of the code style guide on the contribute website [10:42:55] with sass rules [10:43:23] ah interesting. Agreed [10:43:36] michaelarestad: I am sure would have a lot to add there [10:43:41] my notes for this are getting loooong [10:43:43] Yep. [10:43:52] and we definitely still need to rework the html docs [10:44:00] since those are a bit limited at the moment [10:44:06] html code style guide* [10:44:13] they are simplely based on current jQuery Products [10:44:39] Yeah, I foresee adding to the current css style guide due to decisions made in this project [10:44:39] I have limited time, but I'd like to discuss folder structure and components before I head out, though. [10:45:03] That's probably all we have time for at this point, michaelarestad [10:45:03] sfrisk: exactly and i dont think thats a rush [10:45:04] just wanted to throw it out there for people to think about [10:45:17] cool. [10:45:55] so directory structure then? [10:46:14] if anyone has any thoughts on code style guides over the next week or so, add them here: https://github.com/jquery/css-chassis/issues/12 [10:46:48] Okay, so on file structure, both michaelarestad and cbracco brought up atomic structure [10:46:51] https://github.com/jquery/css-chassis/issues/29 [10:47:37] I'm personally a fan of michaelarestad's suggestion [10:47:40] which seems to meld nicely with the naming conventions discussed previously [10:47:49] definitely, dam____ [10:47:53] I have little opinion [10:48:22] whatever people like im good with [10:48:59] the only issue I have is that all the 'atomic' projects I have seen assume a monolithic file structure [10:49:35] as in all the folders in one project even though it lends itself to being modular [10:49:59] dam____: not sure i follow you mean you would like to see components in seperate repos? [10:50:04] yes [10:50:20] Interesting. [10:50:24] I personally dont like breaking componeents into seperate repos [10:50:31] right [10:50:59] i like them being modular but in a single repo [10:50:59] as long as they can work independently I am ok [10:51:06] Yeah 100% for complete modularity and independance [10:51:22] the multi repo approach can be annoying but it does force module independence [10:51:23] Another thing to consider is the type of project. We're building a project in react and are toying with the idea of bundle component styles with the component rather than in the sass folder. [10:51:35] I do that as well [10:51:56] was using RCSS even which is one more step abstracted :/ [10:52:14] but [10:52:26] you can include/require an external style sheet [10:52:35] Sure. [10:52:42] which feels like the most interoperable approach [10:53:12] but requires different repos in the current github/npm/bower way [10:53:44] maybe there is a better way [10:54:14] Right. [10:54:15] hmmm, sounds interesting. [10:55:10] I've definitely worked on some angular projects that worked that way, where you have the html/js/css etc for specific controllers all in the same folder together [10:55:11] i can attest to the multi repo working, but also to it's annoying maintenance over head [10:55:21] as well as it scaring off contributors [10:55:30] actually, I can't remember if css was in there, but definitely html and js [10:55:44] It's worth exploring or maybe even showing off in one of the components we build. [10:56:24] https://github.com/topcoat/button-bar-template/tree/master/example [10:56:43] ^That was a POC to demo the approach [10:57:00] Cool. [10:57:17] adding that link to meeting notes for example [10:57:22] it uses underscore like templates, but you could imagine it with angular or react whatever [10:58:54] My gut feeling is to keep component CSS in the sass folder for this. [10:59:32] Added that suggestion dam____ to the issue [10:59:34] I may need a demo file structure to be able to wrap my tiny brain around what you mean michaelarestad [11:00:01] thanks sfrisk [11:00:18] Cool. I'm build one and add it to the issue. [11:00:23] *I'll [11:00:24] Although I can see michaelarestad's point - it might be confusing if most of the scss code is in that folder, and then components are separate? [11:00:42] sass folder* [11:00:59] i personally would keep all sass in a single folder with sub folders [11:01:08] it is hard to follow [11:01:08] yeah [11:01:09] which i think is what michaelarestad is suggesting ? [11:01:13] but allows a lot of flexibility [11:01:14] Unless you're already in a component mindset. [11:01:18] arschmitz: Yep. [11:01:24] ok then +1 for that [11:01:27] :-) [11:02:24] just for the record, what you are suggesting makes it harder for someone to JUST use button for instance without pulling down the whole shebang [11:02:27] which it fine [11:02:32] just something to note [11:02:36] I agree. [11:02:43] dam____: unless you have a good builder [11:02:47] sure [11:02:57] or use something like npm copy or bower copy [11:03:04] or submodules? subtrees? [11:03:06] which just pulls out the files you want from your dependencies [11:03:10] or folders [11:03:17] ah that could work [11:03:23] thats what we do in jQuery mobile because we use only a few files from ui [11:03:25] We should try that@ [11:03:26] but there are some [11:03:52] so we "depend" on ui via bower [11:03:58] i have never had much success with copy, will give it a whirl [11:04:15] dam____: i can point you to exactly how we do it [11:04:26] link please aschmitz for notes? [11:04:34] this does definitely put a lot of emphasis on getting the folder structure right though ( which is a good thing ;) ) [11:04:40] https://github.com/jquery/jquery-mobile/blob/master/Gruntfile.js#L975 [11:04:57] awesome, thanks [11:05:05] Okay, so it's a little past 2pm [11:05:16] Alrighty, I'm going to make a base file/folder structure and PR. [11:05:36] awesome, sounds good [11:05:43] I have to run. Same time next week? [11:05:51] also everyone check out michaelarestad's initial pass on typogrpahy [11:05:52] I'll be here [11:05:57] Will do [11:06:01] http://codepen.io/MichaelArestad/full/abbe07c15c81010d04473f341dbcc137/ [11:06:08] Thanks everybody! [11:06:11] (maybe make a pr for it, so people can comment on it) [11:06:16] Yep. [11:06:18] and yes, michaelarestad, same time next week [11:06:33] bye guys! [11:06:40] Thanks everyone, great discussions today! [11:07:18] I'll getting the meeting notes updated to http://meetings.jquery.org/category/chassis/ sometime today [11:08:33] Thanks every one!