Help Wanted?

[robguy21]

I've built a bunch of stuff using this repo.

But I don't have the time to investigate what's missing and have no idea what direction you're thinking on taking this or what's still needed to be added.

But if you have some ideas to implement I'd really enjoy it if I could help out where I can.

[larrybotha]

Hey Rob! :D

You're still using this as a basis for dev?! That's awesome :)

I hope you've been working from the inuit branch - I've made a number of changes, most importantly using mixins for all components (as per Zurb's Foundation) instead of placeholders.

I'd love to make this framework more approachable, but with limited time I only update things here and there when I see an opportunity.

The biggest things I can see are:

• [x] replace master with the content from the inuit branch
• [x] replace gulp workflow with a simple npm script
• [ ] add scss linting?
• [x] make the defaults config easier to navigate
• [x] evaluate and improve file structure (should mixins and utilities be co-located to make finding them easier?)
• [x] changing the repo name to something more meaningful - this is a framework, not a styleguide
• [ ] replace the actual styleguide with docs on the thinking behind the framework. GatsbyJs would be great here.
• [ ] move docs to the gh-pages branch exclusively to keep master clean
• [x] make importing the framework into a project easier (with a script?) - cloning it doesn't feel right because the user doesn't necessarily want upstream changes once they begin work... or do they? In that case, do we split core away from custom? If so, how do we make it easy to install core via npm, while allowing non-core to be added to a project without any ties to upstream? Do we / can we use LernaJs to treat the project as a mono-repo? Do we then split modules out even further and allow users to explicitly import only the modules they wish? How do we treat variables that are dependencies of those modules then? So many unknowns here, and are the gains worthwhile the effort?

These are pretty much my biggest frustrations.

What are your biggest frustrations with the project? That may be a good place to start, too.

EDIT: Many of these can be further broken down into their own task lists

[robguy21]

basis for dev

Oh yeah. Every project I touch uses this framework (They are all locked to commits before 4c2c72b587a3698257c42fc68d5ed72c448390f3 since that would introduce way too many breaking changes that I don't have the energy to fix up).

When I have some free time I'll get started on the master branch. I think that solves my onboarding problem which is my major concern right now.

The only downfalls I've experienced are... 1) Onboarding new devs to the framework- I started working on some docs to explain the reasoning of the structure as well as explaining some css principles/patterns, but can't remember how far I got and how much company-internals are in there not relevant to the actual framework.

2) Updating to have new fancy structure (one project exists on pre-0dd99d828ef43093b025474b264f114dee7649b5 and that's my favourite commit 😢)

3) Support for external fonts or default fonts is a feature that can be done it just takes too long in my opinion. That's been the only pain I've experienced. This would help with a more seamless integration into existing projects as well as start-up time on new projects. This is easy to add for a project, but I doubt anyone who isn't familiar with the framework would be able to add it easily.

Over the last few years I've added many small features to solve niche problems on a project, but at the moment I can't really recall any of them except the above external font.

But yeah I'd love to help out as much as I can! I really dig this framework and after playing around with the new bootstrap4 I realised how awesome this framework is in comparison to other options.

Also Come up with that name! It's so awkward calling it "this framework" all the time 😅

[larrybotha]

Yup, Bootstrap is horrid. Foundation is much better, but it still feels like a tool better suited to prototyping than building custom experiences from scratch.

Oh wow - https://github.com/larrybotha/styleguide/commit/0dd99d828ef43093b025474b264f114dee7649b5 things have moved on since then O.o

I've opened a new issue here for the name: https://github.com/larrybotha/styleguide/issues/12

Ye, fonts are a bit of a pain to setup. Regarding external fonts - do you mean using @import statements inside your CSS?

[robguy21]

Oh yeah it's a while back. Recently started up a new project so it's really the only chance I get to use a newer version unless I get a chance to spend a few hours updating...

My uses haven't been with @import, more that the font was already loaded by something else.

The font-face mixin was getting in the way so I added a new param to skip https://github.com/larrybotha/styleguide/blob/inuit/scss/core/mixins/_font-face.scss#L6-L12 and changed my font set up to this...

// /custom/config/_fonts.scss
/**
 * Base Font Face
 *
 * This font is enabled via custom/base/_fonts.scss
 */
$font-base          : "Source Sans Pro";
$font-base-path     : "";
$font-base-filename : "";
$font-base-stack    : $font-base, sans-serif;

// custom/base/_fonts.scss
/*------------------------------------*\
    $BASE FONT
\*------------------------------------*/
@include font-face(
  $font-base,
  $font-base-filename,
  $font-base-path,
  $weight: normal,
  $style: normal,
  $skip_load: true # <-- this is the custom param I pass to font-face
);

Which is okay, it just wasn't an intuitive solution in my opinion.

[larrybotha]

Ye, that could be solved by checking if $font-base-path or $font-base-filename are empty inside font-face. Also, there are currently too many parameters in the font-face call - that should be changed to a map so that one doesn't need to pass empty strings through.

Created https://github.com/larrybotha/styleguide/issues/13 for just that!

[larrybotha]

Made a bunch of changes to this project:

• structure more closely follows ITCSS
• merged inuit branch
• made grids modular and explicitly importable, greatly reducing compile size
• improved variable definitions
• simplified font face declarations
• updated the name of the project
• added a note to the readme for installing via degit
• added tests
• added CI
• published to NPM (still trying to get semantic-release to actually deploy a version number...)

Still some work to do, primarily with documentation, but everything is much leaner, more modular, and less coupled now.

Font face declarations are much more manageable now:

• _fonts.scss
• _font-faces.scss
• _font-face.scss (mixin)

[robguy21]

Sweeto!

I'll need to look at how long it'll take to refactor our work to work with latest, where would be a good place for me to help out?

[larrybotha]

@robguy21 I wouldn't refactor your existing work to get up to date with the latest changes, but new projects will benefit from the new structure.

I'd have a look at the utility mixins and classes, however; there's a lot to gain from using those. The idea is similar to SUIT CSS / Tailwind, but allows one to choose whether they would like to use an explicit class, or a mixin inside a component. You get the same CSS properties whether building a component or applying a utility class in HTML.

The remaining tasks are primarily around documentation, so not much else to do here without getting your hands really dirty.

[robguy21]

Busy setting this up in a new project- any thing I should focus on when contribing to the docs?