ITCSS

[austinstarin]

I'm proposing that we adopt ITCSS (or a variation of) for our in-house CSS architecture. I recommend checking out Harry's talk, where he outlines a compelling case for the approach https://www.youtube.com/watch?v=1OKZOV-iLj4

This is a pattern that aims to:

• Create a sane CSS authoring environment that is accessible to lots of people
• Tame and manage source order, cascade and specificity for large scale CSS projects
• Create a clear place for everything to live
• Reduce waste and redundancy

The architecture breaks down project level CSS into groupings outlined below:

Settings - Global variables Tools - Mixins Generic - Ground-zero styles (normalization, resets) Base - Unclassed HTML elements Objects - UI Abstractions (media object, card, button, etc.) Components - One-off components (header, footer, etc.) Utilities - Utility selectors

Would love to hear everyone's thoughts. I'm looking for specific feedback on whether or not we should adopt this as a way of thinking of/structuring CSS.

cc/ @agilbert @boutell @colpanik @kyjoya @grdunn @bgantick @stuartromanek

[boutell]

I am in favor. Even if the object/component distinction is a little fuzzy, any consistent policy will yield major benefits from the support team's standpoint. And I like that ITCSS attempts to preserve at least some division between content and presentation.

On Fri, Oct 28, 2016 at 10:20 AM, Austin Starin notifications@github.com wrote:

I'm proposing that we adopt ITCSS (or a variation of) for our in-house CSS architecture. I recommend checking out Harry's talk, where he outlines a compelling case for the approach https://www.youtube.com/watch? v=1OKZOV-iLj4

This is a pattern that aims to:

• Create a sane CSS authoring environment that is accessible to lots of people
• Tame and manage source order, cascade and specificity for large scale CSS projects
• Create a clear place for everything to live
• Reduce waste and redundancy

The architecture breaks down project level CSS into groupings outlined below:

Settings - Global variables Tools - Mixins Generic - Ground-zero styles (normalization, resets) Base - Unclassed HTML elements Objects - UI Abstractions (media object, card, button, etc.) Components - One-off components (header, footer, etc.) Utilities - Utility selectors

Would love to hear everyone's thoughts. I'm looking for specific feedback on whether or not we should adopt this as a way of thinking of/structuring CSS.

cc/ @agilbert https://github.com/agilbert @boutell https://github.com/boutell @colpanik https://github.com/colpanik @kyjoya https://github.com/kyjoya @grdunn https://github.com/grdunn @bgantick https://github.com/bgantick @stuartromanek https://github.com/stuartromanek

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/punkave/best-practices/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB9fZ80ekG0nSQvOSfEe6lBCtU2o9i1ks5q4gS4gaJpZM4KjfZR .

THOMAS BOUTELL, SUPPORT LEAD P'UNK AVENUE | (215) 755-1330 | punkave.com

[agilbert]

Even if the object/component distinction is a little fuzzy, any consistent policy will yield major benefits from the support team's standpoint.

I share this sentiment. Also, a consistent standard allows us to scaffold more things into our boilerplate, thus speeding up the initial startup time for projects.

@austinstarin: would you say NaturePHL represents a good example of this in practice? I can definitely appreciate how lean and well organized the CSS is on that project.

One pattern I've seen and used in the past is having a set of LESS files that correspond to specific pages / page types. For example, if you're on the home page, you might want to give the header extra padding. Would we eliminate that pattern altogether with ITCSS? Or would pages get folded into one of these classifications.

[agilbert]

Also @austinstarin I noticed that you put your styleguide classes for naturephl right into site.less. This is a temporary thing or does that fit into the pattern somehow?

[agilbert]

I understand the separation of objects, components, settings, tools.

Can you refresh my memory why the contents of base and generic need to be split into separate directories? Could the stuff in here be combined into a single directory?

Also, utilities = the "trump" stuff? Why is this called utilities? Feels super similar to tools.

[austinstarin]

@boutell @agilbert objects would be UI abstractions or (object-oriented CSS). This would be things like buttons, lists, cards or anything that is "modified". A component would be something that's not modified. A footer on a website generally is a "one-off" piece of UI and that would fall under components. components also have higher specificity than objects.

Example object https://gist.github.com/austinstarin/8e1e07358d4b2a976d6d9d502c8657d8

@agilbert I'd recommend that we not tie any CSS to pages or Apostrophe structure. ITCSS would approach layout from a component level perspective.

@agilbert I don't have any strong opinions about that style guide less hanging out there. I've been removing the code before launch.

@agilbert base is ground zero scaffolding. This would include things like normalization or reset. generic would include unclassed HTML (i.e. where you would style body, h1, h2, h3, etc.). utilities and trumps are the same thing. These are immutable selectors. Things like .visually-hidden or .is-active. They are often referred to as "utility classes". I'm open to either of the names for this grouping.

[agilbert]

Thanks for the following up. Regarding base and generic, I just re-read your initial post and you actually said the opposite:

Generic - Ground-zero styles (normalization, resets) Base - Unclassed HTML elements

To me this is an indication that the names aren't explicit enough. Same goes for utilities / tools / trumps.

Overall it's making sense though.

@austinstarin what items from this structure would you recommend become part of the boilerplate?

[austinstarin]

I think the rough definitions that Harry provides for each of the groupings makes a lot of sense; maybe we should start with that first and not get hung up on the naming of the groups:

Variables Mixins Ground zero styles (normalize.css, resets) Unclassed HTML elements UI Abstractions (object-oriented css) One off designed components (footer, header, etc.) Single purpose (immutable) selectors

The only thing I'm proposing is that we structure (top to bottom) less files this way — in order of specificity. If there's better naming conventions around this pattern completely open to suggestions.

[agilbert]

Yup, makes sense.

[agilbert]

I don't have any strong opinions about that style guide less hanging out there. I've been removing the code before launch.

Why remove this code before launch? I find it helpful to refer to the styleguide from time to time. Doesn't the support team ever look at it? Asking in here because it seems useful to have a place to properly organize these styles.

[austinstarin]

Awesome. I wonder if this pattern is enough or if the team feels strongly about creating a folder structure naming convention around it? How's everyone else feeling about it?

@agilbert I have been using the style guide to jump start a project and then I have been abandoning it as timeline compresses. So I'll remove the code that's not being used anymore so I'm not sending it down the pipes.

[boutell]

I look at the style guide. I would be against removing it.

On Tue, Nov 1, 2016 at 4:13 PM, Austin Starin notifications@github.com wrote:

Awesome. I wonder if this pattern is enough or if the team feels strongly about creating a folder structure naming convention around it? How's everyone else feeling about it?

@agilbert https://github.com/agilbert I have been using the style guide to jump start a project and then I have been abandoning it as timeline compresses. So I'll remove the code that's not being used anymore so I'm not sending it down the pipes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/punkave/best-practices/issues/14#issuecomment-257681510, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB9fYolMiaXo11KAYVjSV0Dku7JTm51ks5q551qgaJpZM4KjfZR .

THOMAS BOUTELL, SUPPORT LEAD P'UNK AVENUE | (215) 755-1330 | punkave.com

[agilbert]

So in that case, the styleguide stuff would just have a file inside objects, right?

[austinstarin]

Is this for the style guide chrome?  If so, that feels to me like a "component" or something one off that's not extended or modified.

[grdunn]

I'm a fan of the majority of this. I think we should definitely keep styleguide stuff as it pertains to support, and future maintainability. It came in handy several times. Planning to implement a version of this into the Covenant House build to get a sense / feel.

[kerrygilbert]

Austin and Brian, can you add some documentation on this to the main readme