basscss / addons

Basscss

Low-level CSS toolkit – the original Functional CSS library https://basscss.com

Lightning-Fast Modular CSS with No Side Effects

Basscss is a lightweight collection of immutable utilities designed for speed, clarity, performance, and scalability.

Stable

Basscss v8 is the final version of Basscss, which means no major, breaking changes will be introduced. Minor features and patches may be added, but due to the nature of this CSS approach, there are virtually no bugs in Basscss.

---

Features

Code with Confidence

Using clear, humanized naming conventions, Basscss is quick to internalize and easy to reason about while speeding up development time with more scalable, more readable code.

No Side Effects

Things behave exactly as expected with immutable utilities and styles that follow the open/closed principle to help prevent common pitfalls with CSS.

Composable

Reusable, interoperable styles work like building blocks to lay the foundation for any stylesheet and can be mixed and matched in any number of combinations.

Designed for Design

Basscss strikes a balance between consistency and flexibility to allow for rapid prototyping and quick iterative changes when designing in the browser.

Responsive by Default

Basscss provides lightweight, performant styles and flexible utilities to design for any device and to help reduce boilerplate in stylesheets.

Unassuming

Modular and customizable typography and layout styles don’t dictate what things should look like and play well with other stylesheets and frameworks.

Read More

---

Other Packages

Base styles

The core Basscss package does not include any base element styles. For an out-of-the-box solution, see:

https://github.com/basscss/basic

Addons

In addition to the core modules, optional modules, including responsive margin, padding, layout, and typography styles, can be found here:

https://github.com/basscss/addons

Ace.css

For a bundle with the core Basscss and all optional modules, see:

https://github.com/basscss/ace

---

Contributing

See CONTRIBUTING.md

Related

• Tachyons
• Buzzfeed Solid
• OOCSS

Thanks

This library was largely inspired and influenced by the following people

• Nicole Sullivan
• Nicolas Gallagher
• Adam Morse
• Jessica Harllee
• Zack Sears
• Diana Mounter
• John Otander

---

MIT license

addons's Issues

btn-primary + bg-* is not working

I'm trying to create a primary button with a custom background color:

<a class="btn btn-primary bg-silver">Click here</a>

But in the end the background color is still the default primary color.

CDN and NPM download broken?

Please take a look, thanks!

Don't like the add on separation!

Now I am having to pull in stuff I need, and the code bloat by doing npm install for each module. I rather save space on my drive thank you very much!

It's really annoying to have to pull in all these "plug-ins", I rather have a single minified version! Ya I know about CDN, this still stinks.

Also thanks for increasing network bandwidth of having to do multiple DL, because the internet needs more noise and latency to download stuff! Having a single DL would be a lot faster than this solution IMHO! #

basscss-forms not accessible from npmcdn from /css directory...

Hi,

The read me: https://github.com/basscss/addons/blob/master/README.md

indicates you can grab the css from npmcdn, like:

Works for:

https://npmcdn.com/basscss-colors/
https://npmcdn.com/[email protected]/css/colors.css <-- exists

But doesn't work, for forms:

https://npmcdn.com/basscss-forms/
https://npmcdn.com/[email protected]/css/forms.css <-- does not exist

Instead I can access here:

https://npmcdn.com/[email protected]/index.css

I don't know if forms should be accessible under css, but I did get confused here.

Button color overrides do not seem to work in v8

Hello - upgrading to v8, I'm referring to https://github.com/basscss/addons/tree/master/modules/btn-primary, and setting my class like this:

<button type="submit" class="btn btn-primary bg-red rounded-right x-group-item">Subscribe</button>

... but the color override does not work.

I can set the default button color, using the variables:

  --button-color: var(--white);
  --button-background-color: var(--teal);

What can I look into to see why this might not be working?

background-images should include utility for `background-repeat`

As the browser default is almost never what you want.

CSS directory for `responsive-white-space` is not being included

The compiled version of responsive-white-space is not being included in the node_modules directory.

bg-darken and bg-lighten missing from background-colors

The bg-darken and bg-lighten classes are missing from the background-colors package even though the text in the README could lead to the assumption that they are included. I would suggest either removing these from the README or preferably adding them to the package.

Breaks in Angular without forms

In Angular 2 you can simply have a single input field without wrapping it in a form, this is the preferred way for simple input, since Angular 2 has it's own way to bind value and events, don't really need submit unless you're developer for proper form.

With Angular2 apps the styles breaks, workaround cut-n-paste styles for .input class.

    <input
      type="text" #messageRef
      (keyup.enter)="onSend(messageRef.value); messageRef.value=''"
      class="input"
      placeholder="Type a message">

I would remove the form > input relationship, or define an additional one like '.ng-input', do this for other form elements as well.

border-width

Might be worth looking into adding border-width customizability.

.border-width-1
.border-width-5

Or maybe similar to the padding utilities.

bw2
bwx1
bwl2 bwlr2

Maybe too verbose.

.Input and .select are are a different height to .btn

I've noticed that buttons are a different height to input fields and select dropdowns.

If I remove height: 2.5rem; from the .input class it becomes the same size as the button.
If I add height:2.25rem to the .select class it becomes the same size as the button.

Why is .mb2 embedded in form addon elements?

There's a margin-bottom: 1rem embedded in inputs, selects and textareas in the form addon.

Is this for convenience (i.e. an assumption that .mb2 would always be used on inputs, selects and textareas anyway, so it preempts), or is there another reason (best-practice, a11y, something else)?

It doesn't seem to derive from --space-2 either (appears hardcoded, but maybe this is just output and I'm missing the generator - can't say I looked hard).

I personally end up writing a custom override (:metal:) for this margin-bottom declaration and handling form element spacing manually. But was just curious as to its rationale.

Consistency: btn-outline and btn

I think you'd want .btn and .btn-outline to have the same default appearance. The btn-outline add's border radius while the btn module dosen't.

Heres what it looks like out of the box with btn 1.1.1 and btn-outline 1.1.1

Any reason for not including xs?

Forms in v8 - seem to not honor col-x, block vs inline

Hi - thank you for what must have been an enormous amount of work on v8. I'm trying to upgrade.

In the previous docs, it mentioned using col-n to specify width of form fields, but in v8, this no longer seems to work.

<input type="email" name="emailAddress" class="col-4 email-octopus-email-address field rounded-left x-group-item" placeholder="Your Email Address">

Changing field to input works to get some formatting on the field, but, the col-4 no longer works, & the field just spreads out across the page.

In addition, even though I am loading the v7 optional ui-groups css, the x-group-item does not seem to actually group the components.

Is this expected? Do I need to set width simply using, say, inline styles. Also, should the x-group-item still work if I have those styles loaded, e.g:

/* Basscss UI Utility Groups */

.x-group-item { margin-left: -var(--border-width) }
.x-group-item:first-of-type { margin-left: 0 }

.y-group-item { margin-top: -var(--border-width) }
.y-group-item:first-of-type { margin-top: 0 }

.x-group-item:focus,
.y-group-item:focus {
  position: relative;
  z-index: 1;
}

Please advise, thanks!

colors.css dependency not defined?

Hi there,

I'm bumping my bassplate from v7 to v8. I've updated package.json, removed and rebuilt node_modules with a new npm i

The error i'm getting is within the node_modules/basscss-addons/modules/colors/index.css file, it Failed to find 'colors.css/myth/variables' https://github.com/basscss/addons/blob/master/modules/colors/index.css#L3

I could manually install this dependency , but I'm wondering how and where this should have been installed?

Cheers!

Does basscss-forms assume .border-box?

The styles in basscss-forms seem to only play nice with margin and padding rules of the parent if each input is also given a .border-box class. Without it all .input elements are too wider for their container. .textarea and .select are also affected.

Am I missing something or should the forms module be setting border-box for us?

Can rem sizing units be changed to pixel sizing?

https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-reference-pixel/

I'm not entirely sure what the existing argument behind using rem sizing is.

It

• makes it unnecessarily hard to reason about what the actual space between elements are
• is not compatible with older browsers
• requires some non standard choice of percentage on the html element... (do you put 100%? 62.5%?)

Other points:

• Users are more than capable of changing their font size via zooming (which almost every browser supports)
• Pixels work with screen readers
• If the user changes their system font, pixels will also reflect that. Pixels are accessible.

This is basically one of those trends that while well intended (mostly under the guise of accessibility) is mostly irrelevant in modern web development. 99.9% of people using rem sizing will do so using a percentage on the html element and leave it alone there.

I'm currently looking into pulling some of these addons down and customizing them (including changing the pixel sizes) but I think the standard distribution of the library that people use.... the rems really should be pixels.

Naming convention?

Is there a naming convention for Basscss modules?

I noticed basscss-border vs. basscss-background-images (singular vs. plural)

forms CDN missing

There is no scripts.prepublish in this module's package.json

.all-revert is missing from `all` module

See https://www.w3.org/TR/css-cascade-4/#valdef-all-revert

[Responsive type scale] .h0 and .h00 classes

Hello,

There seems to be 2 extra header sizes added (--h0 and --h00). However these are only available at 640px up. It would be useful if .h0 and .h00 were defined outside of a breakpoint so devices under 640 can use them too. I'm happy to submit a PR for this.

Thanks

@import must precede all other statements (besides @charset)

When loading addons via postcss-importer it fails to load modules which have the @import statement located after other lines ( eg: border-colors ).

Example:
Project File

@import 'basscss';
@import 'basscss-btn';
@import 'basscss-btn-primary';
@import 'basscss-border-colors';

html {
  font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Helvetica Neue,Helvetica,sans-serif
}

package.json

"dependencies": {
    "basscss": "^8.0.0-beta5",
    "basscss-border-colors": "^1.1.2",
    "basscss-btn": "^1.0.5",
    "basscss-btn-primary": "^1.0.2"
}

Error:

WARNING in ./~/css-loader!./~/postcss-loader!./src/style/index.css
postcss-import: node_modules/basscss-border-colors/index.css:33:1: @import must precede all other statements (besides @charset)

Setup:
I am using webpack with postcss-loader + postcss-import plugin.

The root cause is from postcss-import/parse-statement:83

Can we patch basscss/addons to have @imports always on the top while this constraint from postcss-import remains?

Thanks.

colors module, add `fill` property to affect svg elements

Hi, would you consider adding the fill property on the colors module so we can apply those selectors on svg elements too?

A common thing, at least for me, is that I always tend to extend those class selectors, the reason for this is because I commonly use svg sprites for my icons and it is pretty easy to just add one of those classes to change its color.

This is an example of the use case I am referring to: https://jsfiddle.net/gqm2gq32/