How do I customise?

[mstnorris]

I'm using webpack (Laravel Mix) within a Laravel 5.5 project.

In my default app.scss file where I import tachyons.scss, I would also like to define some other colours for example and have them be picked up and prefixed with bg- for background colours.

It would be good to have some more information around how to customise without touching the source files.

[ptrikutam]

@mstnorris I'm using this via npm in another project, and this is what my main.scss looks like:

@import 'variables'; // Must appear before tachyons.scss
@import '~tachyons-sass/tachyons.scss';

In the _variables.scss file, I override the variables present in the various partials in this project:

$red: #ff0000;

Hope this helps.

[ptrikutam]

That said, it doesn't have nearly as many customization options as tachyons-custom does: https://github.com/tachyons-css/tachyons-custom/blob/master/src/_variables.css

Might be worth looking into that repo if you intend to customize a lot of things.

[johno]

Thanks for the assist @ptrikutam!

I'm realizing right now that we should probably be transpiling tachyons-custom now rather than the base tachyons module so that one can have more customization available to them in Sass. Just opened up #26 to address this.

[ptrikutam]

For those who are newly arriving to this issue, as of #28 we can now adjust any of the variables that were available to tachyons-custom by using the variables present in: https://github.com/tachyons-css/tachyons-sass/blob/master/scss/_variables.scss

The same approach outlined in this comment applies.

[matthewmorek]

@ptrikutam, @johnotander What about adding more MQ breakpoints? We can currently override variables (and thus existing breakpoints), but there doesn't seem to be a way to generate a new breakpoint for all affected components, for example -xl.

Would you have any suggestions or pointers as to how this could be approach using this project?

[ptrikutam]

@matthewmorek Adding more MQ breakpoints wouldn't do anything by default, since these variables are specific to what various Tachyons classes depend on (-ns, -m, -l). Adding an -xl would require adding -xl suffixes to pretty much every single tachyons class, something which is not done in the master codebase right now, and may not be worth the effort for this project alone, since it depends on the Tachyons main codebase to transpile into Sass..

That said, totally makes sense that you'd want to do something like that. One approach to take is to create a separate file with your own custom Tachyons-inspired classes and add the -xl suffix to those. In projects I've done, I've followed this approach to add different atomic CSS classes, but also to add additional breakpoints that don't fit within the existing Tachyons ecosystem. You could use the approach in this comment, add a $breakpoint-extra-large variable to your _variables.scss override file, and then create classes that leverage that breakpoint.

Hopefully this makes sense. @johnotander can of course correct anything I'm saying above because he's far more qualified than I to be answering these questions :)

[matthewmorek]

(...) may not be worth the effort for this project alone, since it depends on the Tachyons main codebase to transpile into Sass.

I realise that this project depends on the main codebase, but I feel this isn't exactly useful. We use Sass/SCSS not only as a format, but also for its ability to compile different, sometimes very complex structures into solid CSS. Right now, this repo allows us to add Tachyons to our pipeline with cosmetic modifications to its variables, but without a pluggable ability to extend its use beyond defaults.

In this context would it not make more sense to have a Sass codebase of this particular project written in a way that automates generation of classes and prefixes/suffixes and is only kept feature-compliant with the main project? If left untouched, it would compile straight to what tachyons-css/tachyons looks like.

Just my 2 cents to the pot...

PS.: Since I use this project very often, I'd be keen to work on this and help shape/upkeep the project.

[johno]

In this context would it not make more sense to have a Sass codebase of this particular project written in a way that automates generation of classes and prefixes/suffixes and is only kept feature-compliant with the main project?

I'm all for implementing this project in a way that allows media queries to be more customizable. I do wonder if this is something that can still be achieved via transpiling from the source repo. Perhaps by stripping media queries and adding a Sass function to mq-ify on a per file basis (when media queries are detected)?

Regardless, this is definitely something we'd like to support so happy to look at a WIP PR or discuss potential solutions. And of course we'd be glad to have your help to shape and upkeep this project @matthewmorek 😸

[begrafx]

As I read this, @johno 's last comment is just shy of three years old. I am finding myself in a similar situation, where I would like to either add additional, or modify existing breakpoints. With three years worth of "water under the bridge", I'm curious if there has been any further progress on this issue?

[avidrucker]

I'd like to be able to add some new MQ enabled classes, such as .no-shadow, .no-shadow-ns, etc.. Seems like a common enough use case to justify enabling a way to do so without requiring SCSS transpiling. Perhaps I'm missing something though, and this is entirely possible with an existing workaround?