Make inuitcss a little more opinionated?

[csswizardry]

I’ve been thinking.

I want inuitcss to be configurable. That is one of its greatest strengths IMO—the fact that you can completely alter look-and-feel per project just through config. However, I’m thinking about taking some stuff out and becoming a little more opinionated.

There are two main candidates so far:

Namespaces

Related to discussion at https://github.com/inuitcss/objects.media/pull/3, I’m thinking of forcing all utilities to carry u- namespaces, and all objects to carry o-.

The benefits of namespaces are huge (I’m currently writing a post called More Transparent UI Code with Namespaces which will explain in detail), so I’m thinking of making it a core part of inuitcss. I will still leave in the option to namespace the entire library, in case people want to sandbox inuitcss from their own code.

Placeholder/silent classes

It’s widely accepted that @extend is a pretty bad idea[1][2][3]. inuitcss has bundled silent versions of every class to allow developers to use a safer @extend workflow[1], but I do feel it would be better to avoid encouraging @extend usage completely. Removing the % classes will help this.

1. http://csswizardry.com/2014/01/extending-silent-classes-in-sass/
2. http://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
3. http://www.sitepoint.com/avoid-sass-extend/

[nenadjelovac]

@csswizardry +1

Related to discussion at inuitcss/objects.media#3, I’m thinking of forcing all utilities to carry u- namespaces, and all objects to carry o-.

What are your final thoughts about prefixing components and prefixing o- children?

Placeholder/silent classes

I am not sure about this. I often extend %list-bare, sometimes %list-inline and maybe %flag a few times (can't remember if I extended anything else). So I do use it with caution and would probably miss it.

But I can see what you'd like to do with these changes, and inuit could probably benefit from being a little bit more restrictive. Edit: For example I would leave only fractions for widths.

[csshugs]

For example I would leave only fractions for widths.

:+1:

[andrewehipp]

:+1:

[renatocarvalho]

:+1:

[florianbouvot]

@csswizardry

Namespaces

I'm totally for adding namespace to utilities. But I have mixed feelings about objects, like @nenadjelovac I'm waiting to know how you will deal with children?

Placeholder/silent classes

:+1: Good idea

[Crawleyprint]

I was bitten by @extend once, I'll salute to their departure :)

[jacquesletesson]

:+1:

[nenadjelovac]

For example I would leave only fractions for widths.

Some of reasons why I would do this are listed here. To be clear, I am for u-1/2 notation, and against u-1-of-2 or one-half (from previous trumps.widths version).

TL;DR is:

• More consistent (only one way of using widths, not two)
• Easier to use in markup (eg. u-5/12 than five-twelfths)
• Easier to maintain (changing u-5/12 to u-1/12 vs five-twelfths to one-twelfth)
• Easier to read markup (see example in this comment)
• Less prone to errors (typos)

[florianbouvot]

Namespaces

Adding prefix is beneficial : give us more information about ITCSS layer, easy to read, easy to maintain, etc. For object I think that every class need to be prefixed :

• .o-media
• .o-media__img
• .o-media--rev

---

For example I would leave only fractions for widths.

:+1:

[jacquesletesson]

@florianbouvot If you do namespace utilities and objects, shouldn't be it the case for components as well?

• .c-slider
• .c-slider__title
• .c-slider--loading

[florianbouvot]

@jacquesletesson it's a possibility you can add namespace for every layer : components, theme, etc.

[nenadjelovac]

@jacquesletesson you can read more about it here -> https://github.com/inuitcss/objects.media/pull/3.

[nenadjelovac]

What are your final thoughts about prefixing components and prefixing o- children?

So I think I got my answer http://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/ ("Object Namespaces: o-" section) ;)

cc @florianbouvot @jacquesletesson

[csswizardry]

I was just coming to post that! :D

[jacquesletesson]

That was quite a long (but very interesting) read! These new namespace conventions really make sense and I already feel at ease with them.

Thank you for sharing with us your final (let's say current) thoughts on that topic.

[jacquesletesson]

Just created a little REGEX expression (probably not perfect) to quickly find and replace classes like .desk-1/12 and add the namespace to it .u-1/12-desk within a whole project : http://regexr.com/3aiak

[corbpaul]

Brought this up amongst colleagues recently as generally we all found this would be of use - especially if a new developer comes into a project part way through.

The only down side was how far would you take it. For example in inuit.css there is the lede class within the base files. Its the only class name I could find so would you prefix this with b- ?

[nenadjelovac]

Its the only class name I could find so would you prefix this with b- ?

The class would (will) go to trumps layer. The same was with base headings. Classes are now split into their own partial in _trumps.headings.scss, leaving only tags (h1 - h6) styling in base (as it should).

[corbpaul]

@nenadjelovac cool - makes sense

[iRouge]

It’s widely accepted that @extend is a pretty bad idea[1][2][3]. inuitcss has bundled silent versions of every class to allow developers to use a safer @extend workflow[1], but I do feel it would be better to avoid encouraging @extend usage completely. Removing the % classes will help this.

Well, I would rather say that @extend is too often misused or ill-understood as you written yourself. The're are still some specific cases where I use @extend (on silent placeholder classes). For exemple, you might call me old-fashion, I like to burry my developing classes under semantic ones, the formers being placeholders --and placeholders only-- for the laters. Definitions are kept at one place and there's no code intricacy.

That being said, I could live without the placeholder classes, but as an "adult" developer, I think I can make my choices and don't feel the need for being protected from myself.

Cheers

[nenadjelovac]

@csswizardry @anselmh @florianbouvot @csshugs

Let's bring this topic back to life ;)

That being said, I could live without the placeholder classes, but as an "adult" developer, I think I can make my choices and don't feel the need for being protected from myself.

I can understand this and try to be safe as well with extending, but I think @csswizardry is trying to make inuitcss encourage good practices upon you, or better say not let you easily do bad practices :)

Now, the question is should silent classes be replaced with mixins (as @florianbouvot suggested here)? (I am not sure what the answer is). If so, the action step could be that all inuitcss is examined to see where silent classes should be replaced with mixins, and where they should be removed altogether. On top of my head, I think %list-bare and %list-inline should probably be rewritten as mixins (as these two are the ones I usually extend now).

[csshugs]

@nenadjelovac @csswizardry @anselmh @florianbouvot

I think %list-bare and %list-inline should probably be rewritten as mixins

I am using these classes very often in my markup, so for me it would be OK to just drop the silent class, so that I'm able to use the class in HTML. The question now is (for developers with your preference to assign these things in CSS @nenadjelovac), shoud we then do for every object the same as with clearfix, which is to swap out the given declarations into a mixin in the tools layer (for usage in CSS) and then define a class in the objects layer where this mixin gets assigned (for usage in markup)? I'm afraid, (without reconsidering this in detail) this could lead into a little bit mess (more modules to include), which I would be OK with, but would make the introduction for inuitcss newcomers potentially harder as it is now.

[csshugs]

An alternative would be to just drop the silent class (no mixin) and extend the "normal" class selector:

@extend .list-bare;

... with the potential pitfalls

[florianbouvot]

@nenadjelovac I don't want to replace every silent classes with mixin. Clearfix is specific case in my mind, but there may be a better solution...

I think %list-bare and %list-inline should probably be rewritten as mixins

Like @csshugs I use classes in my markup <ul class="site-nav__list o-list-inline u-mb u-text-center"> and I'm afraid, it will become a mess (if inuitcss use so many mixin).

EDIT: I would like each trumps use utility namespace and in a second time all objects. And we could avail this update to remove silent classes ;).

[nenadjelovac]

I am using these classes very often in my markup, so for me it would be OK to just drop the silent class, so that I'm able to use the class in HTML.

Yes, exactly. This is what I've been actually doing recently, except for .list-bare (as for why, pls check bottom of this comment).

I'm afraid, (without reconsidering this in detail) this could lead into a little bit mess (more modules to include),

Exactly my thoughts. If not mess then little more complexity. That's why I am not sure what the answer is.

which I would be OK with, but would make the introduction for inuitcss newcomers potentially harder as it is now.

Didn't think about that but this is a valid concern as well.

An alternative would be to just drop the silent class (no mixin) and extend the "normal" class selector @extend .list-bare;

But then it would seem that by removing silent classes in order to not encourage using bad practices, we did just that - encouraged it.

I've gone through objects and trumps layers now and it seem that if we agree to add mixins instead of extends then only list-bare should be it ATM. All other objects and trumps actually do something, while list-bare is just sort of a reset. Actually, that is the main reason why I don't like using list-bare in markup (it feels wrong). When building a component (or part of it) that is a ul or ol, there is a need to reset it to clean state and then add your styles for it. I think we shouldn't rely on html to hold these reseting styles (without which component might break).

Other reasons for not using list-bare in markup are that it is DRYer without it, reseting styles are probably css responsibilities in the first place, and there is less typing involved (maybe not so of a valid point, but still a point :)).

[csshugs]

@nenadjelovac

Other reasons for not using list-bare in markup are that it is DRYer without it, reseting styles are probably css responsibilities in the first place, and there is less typing involved

That is, of course, a matter of taste. As often as I use list-bare, the CSS "bloat" would be too much for me when assigning the mixin everytime it is needed (because I can avoid it when using the class in the markup). But anyway I'm with you, feeling it's "wrong" using it in the markup. Just wanted to point out, that these are two very subjective approaches to handle this and ultimately the old story of whether putting everything in the markup or keeping everything in the CSS.

Despite that, I'm absolutely with you. If just the list-bare object is concerned of all this, this should definitely go into a tools.list-bare mixin:

@mixin inuit-list-bare() {
    margin:  0;
    padding: 0;
    list-style: none;
}

I would like to see a objects.list-bare module though, just assigning the mixin:

.#{$inuit-list-bare-namespace}o-list-bare {
    @include inuit-list-bare();
}

...but that could also be something, that one could write himself easily and therefore doesn't have to be included in the framework anymore.

[nenadjelovac]

@csshugs

Just wanted to point out, that these are two very subjective approaches to handle this and ultimately the old story of whether putting everything in the markup or keeping everything in the CSS.

Exactly.

I'm sorry I didn't make it clear, but I am for keeping the module, but for replacing extend with mixin (and not removing extend altogether). Just like you described in second part of your last comment. That way both use cases stated in our comments would be possible.

[csshugs]

@nenadjelovac

not removing extend altogether.

So you are thinking of something like this?

.#{$inuit-list-bare-namespace}u-list-bare,
%#{$inuit-list-bare-namespace}u-list-bare {
    @include inuit-list-bare();
}

[nenadjelovac]

@csshugs No, what I meant (and since Harry is suggesting to remove silent placeholders) then it should be:

.#{$inuit-list-bare-namespace}o-list-bare {
    @include inuit-list-bare();
}

Just as in your previous comment. That way you can use the class in markup or use mixin in (s)css where you see fit.

TL;DR tools.list-bare and objects.list-bare the way to go :)

[csshugs]

@nenadjelovac Sorry, now I really got it :smile: Yeah, then we are totally sharing our opinions here.

---

tl;dr: Adding a tools.list-bare mixin:

// _tools.list-bare.scss
@mixin inuit-list-bare() {
    margin:  0;
    padding: 0;
    list-style: none;
}

Dropping the silent class and include the mixin in objects.list-bare:

// _objects.list-bare.scss
.#{$inuit-list-bare-namespace}o-list-bare {
    @include inuit-list-bare();
}

This will provide a class for all markup fetishists out there and anyone else can use the mixin in CSS instead of @extend %list-bare;

---

@csswizardry @florianbouvot @anselmh Any other suggestions/opinions?

[florianbouvot]

I have mixed feelings when I use list-bare, I wonder if it's an object or rather a sort of trumps. Like @nenadjelovac I think it's a reset and I imagine a collection of reset: .reset-list, reset-button...

tools.list-bare + objects.list-bare is right for me but I would like to hear from @csswizardry.

@nenadjelovac @csshugs If Harry approves the mixin logic (clearfix, list-bare) what is the best solution: one file by mixin or one with all mixin?

[nenadjelovac]

If Harry approves the mixin logic (clearfix, list-bare) what is the best solution: one file by mixin or one with all mixin?

@florianbouvot one file by mixin seems cleaner; all in one mixin seems easier (eg. you include only objects.list-bare). I'm leaning towards first option, though.

[csshugs]

@florianbouvot I'd definitely vote for one file for each mixin. Feels more modular and cleaner for me, too.

[nenadjelovac]

@csshugs @florianbouvot actually, current _tools.mixins has only one mixin in it, but naming (plural) suggest other mixins should go there. @csswizardry can you help clarifying this please?

[csshugs]

Namespaces

Related to discussion at inuitcss/objects.media#3, I’m thinking of forcing all utilities to carry u- namespaces, and all objects to carry o-.

The benefits of namespaces are huge (I’m currently writing a post called More Transparent UI Code with Namespaces which will explain in detail), so I’m thinking of making it a core part of inuitcss. I will still leave in the option to namespace the entire library, in case people want to sandbox inuitcss from their own code.

Placeholder/silent classes

It’s widely accepted that @extend is a pretty bad idea[1][2][3]. inuitcss has bundled silent versions of every class to allow developers to use a safer @extend workflow[1], but I do feel it would be better to avoid encouraging @extend usage completely. Removing the % classes will help this.

I'm pretty sure, we will not implement both points in this version of inuitcss. Instead we have already addressed both points in the beta version.

@csswizardry Close this?

[aaronstezycki]

I personally would like to see the option of removing namespaces if you don't want them. At the minute I'm 50/50 on using these, as they tend to add alot of bloat to the markup (and by that I mean seeing -o- and -c- and -u- everywhere). I understand the reason why, and the usage, but I think it might be something that people want to decide on by themselves. ?

[csshugs]

@aaronstezycki Unfortunately, this is one of the few things inuitcss is opinionated about and encourages its users to do. Therefore the new version will not let the users opt-out of the namespaces, as this would bloat the (SCSS-)source code just as the modules of this version do right now.

After a while you gonna love the namespaces, I promise 😉 .

[inlikealion]

I've found since expanding our team of developers, the u- o- and c- prefixes add a lot of clarity and I'm happy to accept the 2 char 'cruft' they introduce.

[csshugs]

Since this repository is now officially deprecated, I close this.

Thank you all for your time and your effort of contributing to this discussion.