Current list of all InuitCSS modules and correct bower names

[inlikealion]

As many bower package names have changed since dev-test was created, I thought it might be helpful to document a full list of packages as currently-named. bower.json list is organized to match the new example.scss which demonstrates the necessary order of the imports.

You can use npm install:

package.json

{
    "inuit-defaults": "latest",
    "inuit-responsive-settings": "latest",

    "inuit-functions": "latest",
    "inuit-mixins": "latest",
    "inuit-responsive-tools": "latest",
    "inuit-tools-widths": "latest",

    "inuit-normalize": "latest",
    "inuit-box-sizing": "latest",
    "inuit-reset": "latest",
    "inuit-shared": "latest",

    "inuit-headings": "latest",
    "inuit-paragraphs": "latest",
    "inuit-lists": "latest",
    "inuit-images": "latest",
    "inuit-page": "latest",

    "inuit-block": "latest",
    "inuit-box": "latest",
    "inuit-buttons": "latest",
    "inuit-flag": "latest",
    "inuit-layout": "latest",
    "inuit-list-bare": "latest",
    "inuit-list-block": "latest",
    "inuit-list-inline": "latest",
    "inuit-list-ui": "latest",
    "inuit-media": "latest",
    "inuit-pack": "latest",
    "inuit-tables": "latest",
    "inuit-tabs": "latest",

    "inuit-clearfix": "latest",
    "inuit-headings-trumps": "latest",
    "inuit-spacing": "latest",
    "inuit-responsive-spacing": "latest",
    "inuit-widths": "latest",
    "inuit-responsive-widths": "latest",

    "inuit-print": "latest"
}

OR you can use bower install:

bower.json

{
  "name": "",
  "private": true,
  "dependencies": {
    "inuit-defaults": "latest",
    "inuit-responsive-settings": "latest",

    "inuit-functions": "latest",
    "inuit-mixins": "latest",
    "inuit-responsive-tools": "latest",
    "inuit-tools-widths": "latest",

    "inuit-normalize.css": "latest",
    "inuit-box-sizing": "latest",
    "inuit-reset": "latest",
    "inuit-shared": "latest",

    "inuit-headings": "latest",
    "inuit-paragraphs": "latest",
    "inuit-lists": "latest",
    "inuit-images": "latest",
    "inuit-page": "latest",

    "inuit-block": "latest",
    "inuit-box": "latest",
    "inuit-buttons": "latest",
    "inuit-flag": "latest",
    "inuit-layout": "latest",
    "inuit-list-bare": "latest",
    "inuit-list-block": "latest",
    "inuit-list-inline": "latest",
    "inuit-list-ui": "latest",
    "inuit-media": "latest",
    "inuit-pack": "latest",
    "inuit-tables": "latest",
    "inuit-tabs": "latest",

    "inuit-clearfix": "latest",
    "inuit-headings-trumps": "latest",
    "inuit-spacing": "latest",
    "inuit-spacing-responsive": "latest",
    "inuit-widths": "latest",
    "inuit-widths-responsive": "latest",

    "inuit-print": "latest"
  },
  "devDependencies": {}
}

example.scss

Remember: you can set your own settings inline, before the file to be acted on, as Harry demonstrates in the Getting Started documentation.

// Settings ---- Sass vars, etc.
// Tools ------- Functions and mixins.
// Generic ----- Generic, high-level styling, like resets, etc.
// Base -------- Unclasses HTML elements (e.g. `h2`, `ul`).
// Objects ----- Objects and abstractions.
// Components -- Your designed UI elements (inuitcss includes none of these).
// Trumps ------ Overrides and helper classes.

// SETTINGS:
@import "bower_components/inuit-defaults/settings.defaults";
@import "bower_components/inuit-responsive-settings/settings.responsive";

// TOOLS:
@import "bower_components/inuit-functions/tools.functions";
@import "bower_components/inuit-mixins/tools.mixins";
@import "bower_components/inuit-responsive-tools/tools.responsive";
@import "bower_components/inuit-tools-widths/tools.widths";

// GENERIC:
@import "bower_components/inuit-normalize/generic.normalize";
@import "bower_components/inuit-box-sizing/generic.box-sizing";
@import "bower_components/inuit-reset/generic.reset";
@import "bower_components/inuit-shared/generic.shared";

// BASE:
@import "bower_components/inuit-headings/base.headings";
@import "bower_components/inuit-paragraphs/base.paragraphs";
@import "bower_components/inuit-lists/base.lists";
@import "bower_components/inuit-images/base.images";
@import "bower_components/inuit-page/base.page";

// OBJECTS:
@import "bower_components/inuit-block/objects.block";
@import "bower_components/inuit-box/objects.box";
@import "bower_components/inuit-buttons/objects.buttons";
@import "bower_components/inuit-flag/objects.flag";
@import "bower_components/inuit-layout/objects.layout";
@import "bower_components/inuit-list-bare/objects.list-bare";
@import "bower_components/inuit-list-block/objects.list-block";
@import "bower_components/inuit-list-inline/objects.list-inline";
@import "bower_components/inuit-list-ui/objects.list-ui";
@import "bower_components/inuit-media/objects.media";
@import "bower_components/inuit-pack/objects.pack";
@import "bower_components/inuit-tables/objects.tables";
@import "bower_components/inuit-tabs/objects.tabs";

// COMPONTENTS:
// > Your components here <

// TRUMPS:
@import "bower_components/inuit-clearfix/trumps.clearfix";
@import "bower_components/inuit-headings-trumps/trumps.headings";
@import "bower_components/inuit-spacing/trumps.spacing";
@import "bower_components/inuit-spacing-responsive/trumps.spacing-responsive";
@import "bower_components/inuit-widths/trumps.widths";
@import "bower_components/inuit-widths-responsive/trumps.widths-responsive";

@import "bower_components/inuit-print/trumps.print";

[csswizardry]

I was thinking of making an index repo to house all the inuitcss modules and what they do, etc. Whatcha think to something like that?

[nenadjelovac]

+1

[inlikealion]

Hmm… seems redundant to getting-started or starter-kit? Maybe an alternate, expanded option within starter-kit so you could choose “bare minimum, add your own” or “the whole shebang”?

[kmmathis]

I'd love a repo that includes every module, with an example stylesheet that includes them in the right order.

[ghost]

these two are missing from the list ahead (maybe they have been added after this issue was created):

"inuit-spacing-responsive": "latest",
"inuit-widths-responsive": "latest"

Why the dependencies names are different from the .scss files name? (-> inuit-box vs object-box.scss. wouldn't it be clearer to name the dependency inuit-object-box?)

like @kmmathis, I would like an example stylesheet too. like it is now, it's complicated to start with.

[nenadjelovac]

Why the dependencies names are different from the .scss files name? (-> inuit-box vs object-box.scss. wouldn't it be clearer to name the dependency inuit-object-box?)

@desgnl I see there are quite a few people thinking like this. I raised this question here. So @csswizardry would you mind elaborating is that on purpose. Are we missing to see some big picture?

Thank you.

[csswizardry]

So @csswizardry would you mind elaborating is that on purpose.

No reason other than I didn’t want names to get too long. Unfortunately, there isn’t a simple way to unregister and reregister Bower packages :(

H

[nenadjelovac]

@csswizardry thanks.

[inlikealion]

@desgnl - Thanks for pointing out the additions. I have added them in the original post.

@csswizardry I am fine with names staying as is. I get that it is a little confusing, but the fact that the file-names, as imported in my main.scss are short and more globally named (i.e. tools.mixins) helps promote that this is a customizable, integratable framework and not a locked-up UI Toolkit™.

[csswizardry]

that this is a customizable, integratable framework and not a locked-up UI Toolkit™.

:heart:

[ghost]

@csswizardry @inlikealion Thanks for your answers. I understand your point about the integratable framework and I think this is really a good thing, something that gives a strong interest for this project as opposed to the rest of the UI toolkits :). I wanted to use inuitcss on a few projects already, but I never had the time to really dive into it and I had to go with the usual solutions. This time again I am trying to have a good overview… but this is not an easy process: going on the github page of each module, install with bower, copy the link of the component to the main scss file, activate the variables and make an html file… just to see what it can do.

[ghost]

So, I did this to understand the framework: http://desgnl.github.io/inuitcss-demo/

I hope it's not too much in oposition with the project philosophy, and maybe it can be useful for someone…

[inlikealion]

UPDATE: I just added an example.scss block to the original post that shows what I believe is the preferred (often necessary) order of the InuitCSS files.

[VerifiedMarfat]

+1

[blai]

hope this is useful: https://github.com/blai/gulp-inuit Added an sample project to showcase it: https://github.com/blai/gulp-inuit-example

[blai]

For those who are interested, I have added feature to https://github.com/blai/gulp-inuit, that it can now extract variables from inuit modules for customization.

[patrick-wc]

@desgnl Thanks, this was really useful to me. I suppose I should double-check that the variables needed are all the same. I'll report back if not.

@blai I'm sure this would be useful if I used gulp, maybe I should try it out instead of Grunt, but for now I'm learning too many new things to add another one!

@csswizardry Did you ever get round to doing that kickstarter campaign? I would be up for doing some screencasts once I get more familiar with inuitcss, I really like csswizardry grids and I'm very intriguied by ITCSS.io. It would be great to help grow the project. I may be able to get to dotcss in Paris in November, but I'm not 100% yet with work commitments. Anyway cheers

[inlikealion]

UPDATED: I added inuit-pack and inuit-block to the original post in their correct groupings. This should still be a current list of all inuit components for adding to your bower.json and <main>.scss files.

[jacquesletesson]

Thanks @inlikealion

[inlikealion]

No problem @jacquesletesson.

I just added the new trumps.headings above and moved trumps.print the end of the import lists. If you haven't seen the new package, the double-stranded headers are now split out into base.headings for element selectors and trumps.headings for double-stranded classes.

[cjwd]

Just a heads up! In the example stylesheet you missed: @import "bower_components/inuit-tools-widths/tools.widths"

[inlikealion]

Thanks for the notice, @cjwd ! I have added it to both the bower.json and example.scss withe the new tools.widths.

[inlikealion]

UPDATE/HEADS-UP: It looks like @csswizardry has been writing a major overhaul to the widths and grid layout (concepts are similar, but class names are significantly altered).

If you've been developing as this cycle has progressed, a simple bower update is going to destroy your layout logic. For my current project, here's where I need to switch from using "latest" keyword to locked-in versions to keep things rolling for my release deadlines.

@csswizardry I look forward to a quick post explaining your new thoughts on layout + widths. Kudos for not being afraid to shake things up as Inuit is still technically pre-alpha.

[nenadjelovac]

Hey @inlikealion

@csswizardry I look forward to a quick post explaining your new thoughts on layout + widths.

You can find more about new class names in this issue on CONTRIBUTING repo. More about new widths here and of course from actual scss for it ;)

[inlikealion]

@nenadjelovac - Thanks for the links. I had completely missed the discussions in the CONTRIBUTING repo (since the repo itself receives no updates, I have neglected to explore its issue queue). Following along there is terrific for keeping up with these big changes.

[nenadjelovac]

@inlikealion no problem. I suggest you subscribe to the repo ("watching" option) so you get notifications about conversations.

[inlikealion]

@nenadjelovac Great suggestion, and I've just done so.

[corbpaul]

I've been creating a standard base setup with all the modules and variables available: https://github.com/corbpaul/inuit

Be interested to get some feedback

[jacquesletesson]

That's great @corbpaul. Thank you.

The only things that could confuse someone new to inuitcss is that you already create _trumps.scss, _objects.scss, ... and list these files inside main.scss with the annotation Import custom trumps, Import custom objects, ... where they should create partials in the <section>.<file> format.

Because these files are already created, it encourages you to use them where in my opinion you should create _objects.wrappers.scss, _objects.offcanvas.scss, ... to ease readability and have a better control on your partials.

However for a file like _settings.scss it makes sense to already list all the variables available and add it to main.scss

[corbpaul]

Thanks @jacquesletesson

So would you import your _objects.wrappers, _objects.offcanvas directly into the main.scss?

[nenadjelovac]

So would you import your _objects.wrappers, _objects.offcanvas directly into the main.scss?

Exactly. That way you can have more control.

Eg. you might have public.scss (for public pages) and app.scss for logged in users which include different partials (but on the other hand share a lot of other partials). For example public might not need objects.dropdown.scss, objects.avatar or components.file-upload (names are made up).

[corbpaul]

yeah - makes sense.

I've updated the repo

[aaronstezycki]

Not sure if this is the correct place for it, but I'd like to up vote a choice of 'utilities' as a name instead of 'trumps'. @csswizardry does mention that he has to change the name at some point here https://www.youtube.com/watch?v=1OKZOV-iLj4&hd=1 :+1:

Who's with me on this?

[aaronstezycki]

Also, seeing as a table is an unclassed html element, should tables be part of base directory instead of objects.

[csshugs]

@aaronstezycki

Not sure if this is the correct place for it

Unfortunately, it is not, but no worries ;-) I hope you don't mind that I opened an issue in the CONTRIBUTING repository to not drift into off-topic here.

---

Also, seeing as a table is an unclassed html element, should tables be part of base directory instead of objects.

This is definitely an object, because all the selectors in that file are classes and not unclassed html elements. The point is you can choose to use that object or you just don't, and style it on your own. It's not some kind of reset for the html table element, which would in fact belong to the base layer.

If I'd missed something here, please open a proper issue in the objects.tables repository to continue the discussion.

[aaronstezycki]

@csshugs No you hit the nail on the head, and thanks for pointing me in the direction of the contributing repo. :+1:

[dkebler]

This issue started with a listing that is 1.5 years old. Is there an always current, complete master bower.json and main.scss file that is maintained?

Seems too there is no actual documentation for any of these short of each module's readme. In which case has anyone done or thought of doing a simple markdown page that lists all the modules and links to their corresponding readme's. If not I'll spend the time to put this together if the main contributors would buy into maintaining it in terms of keeping the modules and links current.

If this is done then the master bower.json should be registered with bower so that those wishing the full monty can have it.

[nenadjelovac]

If not I'll spend the time to put this together if the main contributors would buy into maintaining it in terms of keeping the modules and links current.

@csshugs @csswizardry what do you guys think?

[dkebler]

Like this. Some input and a thumbs up and I will continue.

https://github.com/dkebler/inuit-all

Could be a separate repo or put within getting-started. With a bit of effort a little code could be written to generate all three files which would make management easy.

[csshugs]

I'll spend the time to put this together

@dkebler By all means go ahead! :+1: I'm not sure what @csswizardry is planning in terms of documentation. I'm not sure either if this could be maintained alongside with the kitchen sink. But there is definitely a benefit to some kind of 'inuit-all'.

I wouldn't encourage people to download all modules via a master bower.json though and then let people opt-out the modules they don't need. Because this is what inuitcss don't wants to do (off by default). I've written it before in other occasions: This is the part, inuitcss cannot do for you or any other inuit user; Choosing the inuit modules to use in a project is a very opinionated act and it differs from project to project. Some projects do need some inuit modules, whereas other projects need completely other inuit modules. Putting together a bower.json with the inuit modules to use is the bit, every dev should do on his own from project to project.

But having a single README file containing a list of all modules is good idea.

[dkebler]

Three days later....

from the perspective of someone who has read all things Harry and is on board but has yet to try inuitcss but might the organization and lack of documentation has me searching elsewhere. Not only is having to open up each separate repo to see what is there tedious, but most of the readme.md files in those repos have very terse to no documentation. I really didn't see any with a reference list of classes or functions, mixins, etc that those modules encompass, let alone use examples. Looking in the source for that was well...nearly hopeless.

So for those who have been using inuitcss for awhile or have created or contributed maybe they already know what the various modules/repos contain and how to use them. The kitchen sink page makes things a tiny bit better in terms of documentation but that's it.

So maybe the current users/contributors are happily using inuitcss and see no reason to invest time to improve documentation and therefore make inuitcss more generally appealing/useful. I can understand that. I can make that page that pulls things together but that won't fix each individual module's documentation shortcomings and not being an author of any module clearly I can't fix that.

I could only suggest tougher documentation criteria to accept each module into the inuitcss account. That only leaves a mountain of "unpaid" documentation debt for the modules/repos already therein :-).

---

As to the starter that's ok, although it make more sense to have not just a minimal starter but a more typical use case of modules. That said the starter's lack of documentation per above, and no examples use (including some html) make it time consuming to jump in. It's kinda a wide divide between the start kit and all the modules. When developing I tend to start with all options commenting out those not needed (later to be cleared out if need be). Each @import could even have a inline comment about that module to make things easier including url. Basscss (which I mention below) has a nice "custom" page where you can choose the modules and generate the css. Something similar could be done here choose what you want from a webpage and have it generate bower.json and @import files. Could even have presets like, bare bones starter, typical,...,all.

As an example of much better documentation (albeit still missing more reference style documentation) is http://basscss.com. In fact I started using it although a major downside for me it that is uses postcss not sass and thus I can only incorporate a custom pre built version.

I'd like to contribute if I knew that the authors of individual modules/repos would up their corresponding readme.md files and if there was consensus as to what they should contain at a minimum. I'd like to use inuitcss being as it was Harry's baby and he is a guru of css.

On Mon, Feb 1, 2016 at 2:12 AM, Dennis Heibuelt notifications@github.com wrote:

I'll spend the time to put this together

@dkebler https://github.com/dkebler By all means go ahead! [image: :+1:] I'm not sure what @csswizardry https://github.com/csswizardry is planning in terms of documentation. I'm not sure either if this could be maintained alongside with the kitchen sink http://csshugs.github.io/inuit-kitchen-sink/. But there is definitely a benefit to some kind of 'inuit-all'.

I wouldn't encourage people to download all modules via a master bower.json though and then let people opt-out the modules they don't need. Because this is what inuitcss don't wants to do (off by default https://github.com/inuitcss/getting-started#off-by-default). I've written it before in other occasions: This is the part, inuitcss cannot do for you or any other inuit user; Choosing the inuit modules to use in a project is a very opinionated act and it differs from project to project. Some projects do need some inuit modules, whereas other projects need completely other inuit modules. Putting together a bower.json with the inuit modules to use is the bit, every dev should do on his own from project to project.

But having a single README file containing a list of all modules is good idea.

— Reply to this email directly or view it on GitHub https://github.com/inuitcss/getting-started/issues/4#issuecomment-177891461 .

Cheers, Cuidate, TTFN http://www.youtube.com/watch?v=5Gu50vq5ux4 David

[nicoqh]

BEM, ITCSS, skinless (no components) is exactly what I'm looking for.

I only use ~5% of whatever other framework, and the naming conventions are usually incompatible with my project.

I'm sorry for going off topic, but I've been trying to find an answer for a while: Is there any other alternative to InuitCSS, or has Harry lately given a hint as to the project's future? This project, or something like it, really needs to exist :)

[csshugs]

This issue is fixed in the beta version by providing a single repo instead of various modules delivered independently through npm/bower. The beta version also provides an example main stylesheet to make the whole thing easier for inuitcss newcomer.

So, I don't close this issue but will instead lock it, since this content is still relevant to people using the pre-alpha version.

Thanks @inlikealion for the effort you made with pointing out all the modules and providing an example stylesheet!