suitcss / suit

Style tools for UI components

SUIT CSS

Style tools for component-based UI development.

SUIT CSS provides a reliable and testable styling solution for component-based web application development. The project includes:

• CSS base styles for web apps.
• CSS utilities.
• CSS components.
• A future-facing CSS preprocessor

Each of these modules are made up of smaller modules, making it easy to customize your setup and build pipeline.

Documentation.

Quick start

Install the SUIT package and preprocessor with npm:

npm install suitcss --save
npm install suitcss-preprocessor --save-dev

Create an index.css that will import the SUIT packages. Add values for the custom media queries and any custom properties that you wish to override:

@import "suitcss";

@custom-media --sm-viewport (min-width: 320px) and (max-width: 640px);
@custom-media --md-viewport (min-width: 640px) and (max-width: 960px);
@custom-media --lg-viewport (min-width: 960px);

:root {
  --Grid-gutterSize: 25px;
}

Packages can also be installed independently for a more modular build:

npm install suitcss-utils-size suitcss-components-grid --save

@import "suitcss-components-grid";
@import "suitcss-utils-size";

Add an entry to the scripts object in package.json that will run the preprocessor:

"scripts": {
  "build": "suitcss index.css build/build.css"
}

Now run npm run build on the command line to output the built packages to build/build.css. The preprocessor can also watch for file changes by passing the -w flag e.g. npm run build -- -w.

Refer to the SUIT theme for a more thorough example.

Community Packages

Components

• https://github.com/antontrollback/select
• https://github.com/giuseppeg/suitcss-toolkit
• https://github.com/simonsmith/suitcss-components-form-field

Utilities

• https://github.com/frekyll/suitcss-utils-spacing
• https://github.com/simonsmith/suitcss-utils-image
• https://github.com/simonsmith/suitcss-utils-list

Example

SUIT CSS makes use of variables, custom media queries, and dependency resolution for CSS.

HTML:

<article class="Excerpt u-cf">
  <img class="Excerpt-thumbnail u-sizeFit" src="{{src}}" alt="">
  <div class="u-sizeFill">
    <h1 class="Excerpt-title"><a href="{{url}}">{{title}}</a></h1>
    <p class="Excerpt-text u-textBreak">{{description}}</p>
    <span class="Excerpt-readMore">
      <!-- BUTTON COMPONENT -->
    </span>
  </div>
</article>

CSS:

/** @define Excerpt */

@import "suitcss-utils-layout";
@import "suitcss-utils-size";
@import "suitcss-utils-text";
@import "./Button";

/**
 * Content excerpts. Agnostic of image size, and with a clear call to action.
 */

:root {
  --Excerpt-padding: 20px;
  --Excerpt-highlightColor: orange;
}

.Excerpt {
  padding: var(--Excerpt-padding);
}

.Excerpt-thumbnail {
  border: 2px solid var(--Excerpt-highlightColor);
  border-radius: 3px;
  margin-right: 10px;
}

.Excerpt-title {
  border-bottom: 1px solid #ccc;
  margin: 0 0 15px;
  padding-bottom: 5px;
}

.Excerpt-readMore {
  display: inline-block;
  margin-top: 10px;
}

CSS packages

Each CSS package can be installed with npm. It's suggested that you depend on individual packages as and when you need them, however, you can install all the CSS packages at once if you prefer:

• npm: npm install suitcss

Each package is stand-alone, contains its own documentation and tests, and is written to follow a common set of naming conventions.

• base: a thin reset for web apps, built on top of normalize.css.
• utils: all the utility packages.
• components-arrange: flexbox-like horizontal arrangements.
• components-button: robust, structural button styles.
• components-flex-embed: aspect-ratios for embeds.
• components-grid: a grid foundation.
• components-test: structure for visual tests.
• theme: example theme.

You can also download pre-built bundles to try things out without setting up a build process:

• base bundle
• utils bundle
• components bundle
• everything bundle (only 4.4KB minified and gzipped)

Build and test tools

The suitcss-preprocessor runs CSS through a build pipeline. It performs per-file tests for conformance to the SUIT CSS naming conventions, offers minification and allows additional PostCSS plugins to be added. A CLI and Node API are available

The preprocessor makes use of:

• PostCSS: A tool for transforming styles with JS plugins
  • postcss-import
  • postcss-custom-properties
  • postcss-calc
  • postcss-custom-media
  • autoprefixer

Packages are linted with postcss-bem-linter and minification is provided by cssnano.

Complementary tools and libraries

Libraries / frameworks for component-based development:

• React
• Ember.js Components
• AngularJS

Tools and dependency managers:

• npm: package manager.
• html-inspector: test HTML templates for SUIT CSS conformance.

Development

Install Node (comes with npm).

To generate a build:

npm run build

Browser support

• Google Chrome (latest)
• Opera (latest)
• Firefox 4+ (28+ for flex)
• Safari 5+ (6.1+ for flex)
• Internet Explorer 9+ (10+ for flex)

Refer to the caniuse page for flexbox.

suit's Issues

Component builder plugin

plugin to pass the css through the preprocessor when building via Component. can also be included in generator-suit. use to distribute builds for suit-base, suit-utils, and suit.

builds should include both unprocessed and processed css. people can use a build with variables if they want to use the processor, but not use Component to handle components.

Write the docs to be more digestible

A lot of the constraints in the system need to be exposed more clearly in discrete sections. It will also make them easier to link to by url hash.

Add rework-inline to suggested build tools

You suggest that the user should make use of @imports in their CSS but it might be unclear how to inline these.

Not sure what you use but I've created a rework plugin for this which might be useful.

Component-based spacing vs. Space utilities

First of all, thanks for sharing all the great SUIT thoughts!

What I've found when using SUIT-type architecture is that often I can build a lot of components by using existing generic utilities, and the only reason to assign a new Component name to a small block is to give it spacing (margin/padding). While I might need this class later for other theme-level styling, it's quite annoying to have a lot of components that only have a margin definition inside. Each new component also requires time to think about a good name for it, which we know is one of the hardest things in development.

What are your recommendations in these situations ? Do you use the Space utilities for that purpose or more often you create a new component just for spacing it and having it defined for later use ?

Update suit dependancies

Hi, just a friendly note that the bower/component packages do not seem to use the most recent versions of the different suit components.

For instance, installing with bower currently gives suit-buttons 2.0.0 instead of 3.0.0.

List of 3rd party tools

• https://github.com/dombojs/rework-splitsuit
• https://github.com/dshimkoski/grunt-splitsuit
• https://gist.github.com/peteschaffner/8783632

0.4.0: add build tools to generate the bundle

Remove Makefile

Clarify "with-" prefix usage

In the component docs, it states the usage should be "with-ComponentName": https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md#with-ComponentName

However, in this example, you show it in use as ".with-tweetActionsToggle .Tweet-actions" and as a modifier ".Tweet--withExpansion".

Is the modifier starting with "with" just a coincidence in this case?

As far as the ".with-tweetActionsToggle .Tweet-actions", I'm a little confused what "tweetActionsToggle" is referring to and when you would want to use it.

Project migration

Migrate all repos to the new 'suitcss' org. Will involve update the Git endpoints in the Bower registry. This should make it easier to find all Suit-related repos and surface components build by other people, but following the same principles.

Existing repos:

new repo location	bower name	done
suitcss/suit	suit	done
suitcss/arrange	suit-arrange	done
suitcss/button	suit-button	done
suitcss/button-group	suit-button-group	done
suitcss/flex-embed	suit-flex-embed	done
suitcss/grid	suit-grid	done
suitcss/grid-layouts	suit-grid-layouts	done
suitcss/utils	suit-utils	done
suitcss/utils-dimension	suit-utils-dimension	done
suitcss/utils-display	suit-utils-display	done
suitcss/utils-layout	suit-utils-layout	done
suitcss/utils-link	suit-utils-link	done
suitcss/utils-state	suit-utils-state	done
suitcss/utils-space	suit-utils-space	done
suitcss/utils-text	suit-utils-text	done
suitcss/generator-suit	N/A	done

Ref #9

One syntax for modifiers and states

I keep returning to the idea that modifiers and states could share syntax, the state-of-component syntax.

<button class="Button is-primary is-larger is-disabled">
<button class="Button Button--primary Button--large is-disabled">

The main advantage would be greater simplicity. The distinction between states and modifiers becomes unimportant (something I've seen people new to SUIT have had problems with).

Another advantage, according to me, is that HTML attributes would be a bit more readable and shorter.

A drawback I can think of is that it becomes unclear which component the modifier/state belongs to if an element has more than one component base class added to it.

Thoughts? Is the distinction important?

Descendant naming

Should components ever have a descendant with more than one hypen? For example:

<div class="Component">
    <header class="Component-header">
        <a class="Component-header-link" href=""></a>
        <!-- Or -->
        <a class="Component-headerLink" href=""></a>
    </header>
</div>

The first example feels more correct as the hyphen denotes another child level but it also has the potential to lead to ugly class names with multiple class names.

Should the second camel-cased version be employed instead?

Install Error

I'm not sure if it's something I'm doing wrong, when I run bower install suit --save I get the following error message:

bower error suit not found

There were errors, here's a summary of them:
- suit not found

Online docs

It would be pretty cool if you enable Github Pages for this repo and move docs from master to gh-pages. So anybody can visit http://necolas.github.com/suit to see SUIT docs without need to clone repo and open docs locally.

Reusable tabs, no js appearance, and content jump

Some issues with the tabs that need to be considered:

• Styling of content without JS. At the moment you cannot see any tabs other than the first one when JS is disabled. They should all be visible by default.
• Content jumping. When you click on one of the tabs, the viewport jumps up sometimes as the content is hidden/show.
• Reusable tab component. The style of the tabs themselves should be independent of the js tabs because you might want to use them for main navigation too. As part of this we'll probably want a hz list mixin.

We could avoid reinventing the wheel by taking the good bits of the tab plugin from Bootstrap or existing jQuery plugins for this.

Should component descendants always be html descendants?

I'm come across a few situations where I wanted a component descendent, but it was much easier in the html if it wasn't actually a decedent.

Do you think this should be avoided?

.u-sizeFit floats an object, which might not be a desired effect as it needs to be contained

Example: http://codepen.io/thomasdobber/pen/EiwIG

0.4.0: media-specific class naming convention

I'm wondering if you've given any thought to formalizing a naming convention for media specific classes. I've noticed you have media specific component classes in the grid-layout module, but I don't see any mention of naming recommendations in the docs.

I imagine most of the time a media specific class would conceptually fall into the realm of utility classes (e.g., something that sets display:none or converts inline-block to block when the viewport is less than 30em), but as your grids exemplify, they may also apply to component classes.

After giving it a bit of thought I think a named media query prefix makes the most sense. The convention would be:

.[mediaName-]ComponentName { }
.u-[mediaName-]utilityName { }

If you named your media query hand to refer to anything less than 30em, then you'd get something like this:

@media (max-width: 30em) {
  .u-hand-hidden {
    display: none !important;
  }  
  .u-hand-blockList {
    display: block !important;
  }
}

Thoughts?

0.4.0: documentation tasks

• Add component, component-builder-suit, and react to suggested tooling.
• Add css-flip to recommended tools: https://github.com/twitter/css-flip
• Add https://github.com/suitcss/rework-suit-conformance to tooling
• Update API docs.
• Link to builds of 'suit-base', 'suit-utils', and 'suit'.
• Simplify utilities docs.
• Simplify component docs.
• Simplify design principles docs.
• Document variables defined by each package.
• Document how to do theming.
• Update code style docs.

Does the naming pattern `className` have any meaning in SUIT?

From what I can tell, SUIT uses the following naming patterns:

u-:
u-is:
is-:
with-:
js-:

Is this list meant to be exhaustive? If so, would that mean that a class named className would be a misuse of the system?

I'm asking because I'd like to create a rule that supports the SUIT naming conventions in HTML Inspector and throw warnings/errors when class names aren't used properly.

Document multiple files for same component

For example, if you have deferred styles for a component (like an editing state for logged-in users) you need a separate stylesheet that will be bundled with other deferred styles.

In the above example, the file name would be: component-name.editing.css

Consider class name format change

Liking the format that montagejs is using. The structures are identical but they reflect it differently:

.namespace-ComponentName-componentChild--modifier {}

e.g.

.suit-Button {}
.suit-Button--small {}

.suit-ButtonGroup {}
.suit-ButtonGroup-item {}

Work on some examples using themes

Probably write a simple theme and then use it in this repo's gh-page as an example.

Consider depending on preprocessing of CSS

It could add some configurability (especially to packages like 'utils-space') by using CSS variables. It would introduce a dependency on preprocessing which means that I'd probably have to commit the built version too.

https://github.com/visionmedia/rework-vars

Rethink the interface for JavaScript

I'm thinking that perhaps it's best to let JavaScript use any component classes is selectors, rather than just js- as is currently recommended? An example bit of HTML:

<div class="Tweet">
  <a class="u-linkComplex" href="{user.url}">
    <img class="Tweet-avatar u-pullLeft" src="{user.avatar}" alt="">
    <b class="Tweet-fullname u-linkComplex-target">Horse_ebooks</b>
    <span class="Tweet-username u-textMute">@Horse_ebooks</span>
  </a>
  <p class="Tweet-text">{text}</p>
  <ul class="Tweet-actions">...</ul>
</div>

JavaScript shouldn't use the utilities in selectors. The utilities are generic abstractions and might also appear several times within a component's HTML. Like in CSS, JavaScript should rely on short selectors, preferably classes.

But is it really that bad if JavaScript uses the same component classes that the CSS does?

There are times when it could result in a lot of duplicate classes just to use a js-* class. The SUIT names are already very structured, so using the same selectors in the JS would be clear and easy to search for. If you're rearranging the component's HTML and changing the class names, then you're refactoring the component and can also easily replace the class names being used in JS files.

There would still be a reason to use js-* classes, but more like JS utilities (behaviour that is independent of any particular component). It's much easier to use a single, tailor-made JS class if you need to be able to bind to nodes in many different components. CSS definitely shouldn't be applied to those classes.

Restructure project, use Sass

I've been thinking - and spoke to Addy about this previously - that we should just go "toolkit" with this.

The idea of providing reusable structural "templates" is still sound, I think, but we can layer a simple "theme" upon them so that: a) the project is usable immediately, even for beginners; b) we provide an example way of how you can sit a "theme" on top of the structure. So the scope is still narrower than Bootstrap and our focus is primarily upon providing really solid component "templates" that any type of button/icon/dropdown/accordion etc can be built upon.

So Sass sounds like the right tool for this. We can abstract out any repeated code, abstract out the template parts, etc. Compile it all to CSS and give instructions on how to do that or which apps will do it in the background.

Proposed structure:

/scss
    accordion.scss
    base.scss
    buttons.scss (inc. button-group)
    forms.scss
    dropdown.scss
    icons.scss (work in <button>, as <a>, with hidden text content) - sprite- or font-based?
    media-object.scss
    media-grid.scss
    mixins.scss
    modal.scss
    normalize.scss
    style.scss
    tables.scss
    tabs.scss
    variables.scss
/css
    style.css
    style.min.css
/js
    async-script-loading.js
    jquery.accordion.js
    jquery.dropdown.js
    jquery.modal.js
    jquery.tabs.js

.gitattributes
.gitignore
README.md
styleguide.html

Something like button.scss would have 2 sections. One is the "stable template" which contains (as much as possible) no theming, just structural styles and workarounds that all other buttons make use of. The other is the "theme" layer. If someone wants to change the style of the buttons, they can largely forget about the template and just focus on the theme.

All the HTML of the components can live within styleguide.html which acts as a test file too.

Lint using CSSComb once it supports alphabetical ordering

Issue: csscomb/csscomb.js#158

CSSComb can lint code style pretty well, just needs alphabetical sorting. Remove use of CSSLint in modules.

0.5.0: tool for media query reworking

rework-breakpoints has a strange, mixed API. Want something simpler, clearer, and that doesn't have an API that collides with the CSS var spec.

Thinking about something that mimics rework-vars but uses a different definition/function name and only operates on @media rules.

definition:

:root {
  query-sm: (min-width: 400px);
}

source:

/**
 * query(sm, (min-width: 320px)) falls back to the value after `,` if no `sm` defined
 */

@media query(sm, (min-width: 320px) and (orientation:portrait)) {
  /* ... */
}

yields:

@media (min-width: 400px) and (orientation:portrait) {
  /* ... */
}

If there's no definition and no fallback, throw a warning and remove the media block (and is contents).

Component structure

At the moment we're structuring components as self-executing (IIFE) blocks of code. This is as opposed to encapsulating them within jQuery plugins.

I think this approach is fine if we intend on presenting them as snippets (which I think the original idea was), however, if we feel that we might end up releasing these as an actual component pack, it probably makes sense to turn them into jQuery plugins instead. They're fairly basic at the moment and wouldn't be too hard to convert.

I'd like to leave this issue open for us to discuss structure at some point once we have more work done on initial snippets/demos.

List of components to create

• flexbox thing

Add proper code style guide

Include idiomatic-css with some explicit choices (like alphabetical order).

Create a Yeoman generator for SUIT components

Quickly scaffold out a new component or utility

https://github.com/suitcss/generator-suit

Drop the `with-*` naming convention

No compelling use case that I can see. Plus, sticking to a "modules with utilities" setup is simple to grasp and does enough.

Script to combine CSS files

Look into writing some Node tooling that can help import/order CSS files intelligently.

Probably get the dependencies from Bower, sort all the SUIT utilities together, and all the SUIT components together. I think SUIT's authoring principles should mean that the load order of component CSS shouldn't matter, just needs to be after the utilities.

Create conformance checking tool

• Check that class names conform to patterns defined by the framework and that every rule in a module starts with the namespace.

.ProfileCard {}
.ProfileCard-descendent {}
.ProfileCard--modifier {}

/* this would trigger an error/warning */
.Avatar {}

• Some way of marking module rules that are wrapping legacy templates (i.e., non-modular; dependent on an ancestral context without that being clear; broken when rendered in different contexts)

/* @skiptest - don't complain about the classes after
 * the namespace coz we've got legacy problems*/
.ProfileCard-wrapFollowButton .follow-button span.icon {}

• Disallow binding styles to nested component modifier/state classes. Avoids things breaking when those decorator/state classes are changed. All you can really be sure of is that the core component will be there.

/* OK */
.ProfileCard-wrapFollowButton .Button {}

/* Not OK */
.ProfileCard-wrapFollowButton .Button--small {}

Full page examples, real-world applications?

Examples in the docs focus on single, small components, but it would be interesting to see examples of how an entire page or set of pages would would look using SUIT. This could include common design elements such as headers/footers/navigation, and how they might be marked up with SUIT components.

Is there a list of any real-world, public-facing projects using SUIT?

Update style docs

• Rename to STYLE.md
• Update indentation choice

Purpose of `with-ComponentName`

Might want to change to has if it's just to apply necessary styles to an ancestor (e.g., making sure a dropdown is within a relatively positioned element). It indicates that it is receiving styles from one of its child components.

But sometimes you need to modify a component based on actions on the ancestor, like a hover state.

Use 'bower_components' in documentation

Replace instances of 'components' in paths that refer to the dir where Bower installs package contents. Change to 'bower_components' to disambiguate from UI components.

Contribute new suit components?

Is there a list of components you would like to see get added to suit? Are there limits to the kind of components that you see as suit-able?

Essentially I am wondering what your preferred method of contributing new components to suit would be?

Simplify utility naming conventions

I think the explicit u-isStateName convention could be dropped to simplify the naming convention and the divisions within the utility abstractions.

The is prefix of the utilities in the 'state' package can be reunderstood as just another package-specific labelling-prefix, like link and text are in the respective 'utils-link' and 'utils-text' packages.

There should also be an adjustment to the rules around class name patterns reserved for use by JavaScript. Rather than saying JS can only add/remove u-isStateName utilities, it could be allowed to add/remove any utility classes. In reality, there will rarely be a need to use the non-state utilities.

0.4.0: update all gh-pages test files

Make sure all the public tests are updated before next release.

Make sure all test files have meta viewport too.

Update:

• base
• utils
• utils-align
• utils-after
• utils-before
• utils-display
• utils-layout
• utils-link
• utils-offset
• utils-position
• utils-size
• utils-state
• utils-text
• components-arrange
• components-button
• components-button-group
• components-flex-embed
• components-grid
• components-test

Improve docs w.r.t. components

• components within components (in the HTML)
• components as being written without knowledge of context
• breaking a components up into multiple files / collections of modifiers
• components as concept rather than "only for reusable parts"
• DRY vs encapsulated
• components drift (can components to appear/disappear from use "organically"?)

Twitter web intents aysnc-script-loading

Wondering if it would be possible to bake Twitter web intents into the async-script-loading.js?

Simplifying naming conventions?

Are you guys planning on simplifying the naming conventions in suit? They seem unnecessarily complicated.

For example, here is the current basic syntax for suitcss components:

/* .Component */
.Tweet
/* .Component-subcomponent */
.Tweet-header
/* .Component.state */
.Tweet.is-expanded
/* .Component--modifier */
.Tweet--promoted
/* .u-utility-name */
.u-pointer
/* .namespace-Component */
.twt-Button

It could be simplified to this:

/* .component */
.tweet
/* .component-subcomponent */
.tweet-header
/* .component.state */
.tweet.is-expanded
/* .component.mixin */
.tweet.as-promoted
/* .use-mixin */
.use-pointer
/* .namespace-component */
.twt-button

A system like this reduces the perceived complexity. In the current example, there are several similar things which could be implemented in a similar way, but instead each have a very different implementation:

1. There is a mixture of dashed-case, camelCase, and PascalCase, where it could just be a single dashed-case.
2. The states are implemented as is-[name], while the "mixins" or "modifiers" are implemented as --[name]. If this were a JavaScript API, it would be equivalent to having two different naming conventions like this: .is(name), and ._Use(name). That would be strange. The syntax here could be simplified to just is-[name] and as-[name]. In that case, the distinction is clear and simple: states use is and mixins/modifiers use as, basically creating a subtype/subclass for the component.
3. While the states have a nice is-[name], the utility have an abbreviated u-[name] syntax, which isn't as easy to read as if it were written with the same verb idea in mind, such as use-[name] or with-[name].
4. Because the modifier is part of the class name .Component--modifier, you have to include extra boilerplate, such as <button class="Button Button--default">, when it could just be <button class="button as-default">.

If we reduce the naming conventions down to dashed-case with human-readable naming conventions for states is-expanded, mixins as-default, and utilities use-shadow, then the HTML would be very tidy, the CSS components would be very simple and easy to read, and it would be a joy to use css.

Instead of this:

<button class="Button Button--default is-disabled u-pointer" type="button">…</button>

we make it:

<button class="button as-default is-disabled use-pointer" type="button">…</button>

#29

I am really stoked about the ideas behind suitcss. The way all the stuff is organized and the way this will simplify writing css so things don't bleed and you can reuse code, will be huge. But because of the current naming conventions, I can't use it. TBH it feels too bulky and verbose. If we're already making a new framework with such new design patterns, might as well go all the way.

What are your thoughts about this? I would be totally down to help you refactor the stuff to use these naming conventions. It is perfect timing now rather than later imo because it's still new. Also, component is already writing all of their components basically this way, so that's nice too.

Suggestions for file/component organization (especially w/ Sass)

I'm using SUIT with Sass and I'm debating the best way to organize things.

Currently I've been sticking with a strict 1 file per component, but it can start to seem a laborious when I have a tiny components, e.g. .Container in _container.scss:

.Container {
  @include clearfix;
  @include rem(max-width, 960px);
  padding: 0 $grid-padding;
  margin: 0 auto;
}

I'm wondering if being strict on this rule is worth it, or if there's a better solution to group these tiny components.

Similarly, I have several wysiwyg editor/cms-friendly classes like:

.Piped {
  @include piped-list;
}

.Bulleted {
  @include bulleted-list;
}

.NoBullets {
  @include unstyled-list;
}

.Columnize {
  @include column-count(2);
}

.Columnize--3 {
  @include column-count(3);
}

.Columnize--4 {
  @include column-count(4);
}

...where initially it seems like overkill to have a file for each.

Thoughts, ideas, suggestions?

0.4.0: depend on variables where appropriate

Support configurable theming by relying on custom properties and a build step.

When to use a utility

I'm pretty clear on using utlity classes most of the time, but the lines blur a bit and I wonder if there are any guidelines on using them vs putting the styles in the component?

I have a feeling that you can go a bit mad with utility classes and essentially replicate inline styles.

An example:

<a href="/" class="Logo">
    <p class="Logo-title">My website</p>
    <p class="Logo-subtitle">A slogan</p>
</a>

My first pass at component styles were the following:

.Logo {
    display: inline-block;
    text-transform: lowercase;
    text-decoration: none;
    color: inherit;
}

.Logo-title {
    font-size: 26px;
    font-weight: bold;
}

.Logo-subtitle {
    color: #777;
    font-size: 14px;
}

.Logo-subtitle, .Logo-title {
    margin: 0;
    display: inline-block;
}

Now, some of these can be replaced with utility classes, namely the display and margin:

<a href="/" class="Logo u-inlineBlock">
    <p class="Logo-title u-inlineBlock u-marginAn">My website</p>
    <p class="Logo-subtitle u-inlineBlock u-marginAn">A slogan</p>
</a>

I could go even further, but already the repetition feels wrong in the markup.

What is the general view on this? Do I just need to judge it on my own tastes?

Sold on the Suit methodology so far though, great stuff.

Broken link in the documentation

Hi,
When you renamed code-style.md by STYLE.md, you broke the link on "Code style" in suit/doc/README.md#L19.

Post updated README with component list and design principles

Must. Do. This.

Should all components be namespaced?

See original plan in #8

I think I ended up wanting SUIT components to seamlessly blend into application code, but there might be some benefit to using the suit- prefix.