I am working on a website hosted on GitHub pages using the Minimal Mistakes Jekyll theme. I am working on some basic customization - still trying to learn - so am starting out by practicing with some simple theme changes. I am starting out by reading through the Stylesheet portion of the documentation.
Here, I decided to start out with one of the first examples listed on this page, by trying to override the theme default for the link-color. Here I am having a bit of trouble however.
I started out by following the recommendations outline on this page. I made sure to navigate to the main.scss file in my website's repo and then add the line link-color: red; at the top of the file (making sure to add it above any of the #import statements). However, after adding this line, nothing seemed to change and the default link-color for the website still displayed as a light blue.
Not sure what I am doing wrong here. I have read a few things online which have suggested similar issues and provided varying degrees of advice/solutions with varying levels of complexity. I am very new to Jekyll themes and was just trying this out as a good first intro into more complex customization.
Does anyone have any idea what I might be doing wrong here or have any links to helpful examples, tutorials, or resources?
Also, here is the link to the Minimal Mistakes repo on GitHub and my forked version of the repo here.
This took me some time to find out :)
Reason:
You set a color and it gets always overwritten by $info-color because the !default flag is missing in https://github.com/eolesinski/eolesinski.github.io/blob/master/_sass/_variables.scss:
$info-color : #52adc8;
$link-color : $info-color;
From css-tricks:
!default is a Sass flag that indicates conditional assignment to a variable — it assigns a value only if the variable was previously undefined or null.
Solution:
Add !default after $info-color inside the $link-color definition to be able to overwrite $link-color on top of the main css file. New entry: $link-color: $info-color !default;
Or, change the link color directly in the _variables.scss file.
Default colors in Visual studio code:
Overwrite and result:
Details on how the theme works:
Your cloned version differs from the official repository. It also does not support skins. Not sure what else is missing. You cannot follow the docs in any case. You could update it to the official version.
The original repo imports the following sass files:
#import "minimal-mistakes/skins/{{ site.minimal_mistakes_skin | default: 'default' }}"; // skin
#import "minimal-mistakes"; // main partials
This results in the following import order (skipped irrelevant imports):
skin
variable (#import "minimal-mistakes/variables";)
reset (#import "minimal-mistakes/reset";)
The _config.yml file defines a skin (default by default, no color set):
minimal_mistakes_skin: "default"
Other skins (such as skins/_air.scss) define their own link color:
$link-color: #393e46 !default;
The variable CSS file (_sass/minimal-mistakes/_variables.scss) defines the default link color by using the $info-color (if not overwritten manually or by the skin before):
$link-color: mix(#000, $info-color, 20%) !default;
The reset CSS file (_sass/minimal-mistakes/_reset.scss) defines that links should use the variable:
a {
color: $link-color;
The <a> elements on the website's homepage (about.md) has inline style style="color:#4196ce". Inline style is considered the highest CSS specificity and is the value that will always be used over what is found in the stylesheets.
Note: !important is an exception to this rule and can override inline style.
To learn more see CSS Specificity by MDN https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
If you decide to remove the inline styles, you would have to add $link-color: red; after the line #import "variables"; where $link-color is first defined. Putting your custom style before #import "variables"; will result in $link-color value being taken from _sass/_variables.scss.
Related
I need to share some sass/scss variables for several webcomponents. For that we created a very usefull "_variables.scss" on an npm package.
The thing is we use two ground of colors :
what i would call "real colors" : ($blue-unicorn,
$pink-butterfly)
and theme colors : ($brand-color, $secondary-color)
and we only want to share the theme color variables
the theme colors are made this way : $brand-color : $blue-unicorn;
if the DA suddenly decide to use a $grey-grave and a $black-shadow colors we will just have to update the npm package and won't have to change variable names all other the code on the various web components.
If you wanna know more about this usage you can take a look on this article about palette colors and theme colors http://blog.magmalabs.io/2018/04/17/nice-way-handle-sass-color-variables.html.
the original file with our variables.scss is this one :
#import 'variables/_colors';
$brand-color: $blue-unicorn;
$secondary-color: $pink-butterfly;
and we use scss-bundle npm package to obtain that for clients of our package
$blue-unicorn: #0081EB;
$pink-butterfly: #F62880;
$brand-color: $blue-unicorn;
$secondary-color: $pink-butterfly;
we don't want users to access the real colors
what would be the proper way to obtain that ?
$brand-color: #0081EB;
$secondary-color: #F62880;
If your users should use the scss files then the only option is the new module system that is as of now only supported by the Dart Sass compiler. You'd nee to replace the #import directives with #use and prefix all private variables with a - as this makes them private and they won't be shared.
Again, this is only supported in Dart Sass of now.
For more infos see the documentation.
I am working on a Symfony 4 application and using Symfony's Webpack wrapper Encore.
The application will be used to run multiple sites on one db, each one with a different theme. The themes will be versions of bootstrap 4 that have their primary variables set to a certain colour. i.e theme1 red, theme2 blue.
What is the optimum way to achieve this?
I have though about multiple CSS output files, i.e theme1.css, theme2.css and dynamically referencing these from the HTML.
I am also wondering if Encore/Webpack has the option to pass in a variable to an SCSS file i.e:
.addStyleEntry('theme1', './scss/main.scss, red) // THIS WOULD OUTPUT theme1.css (RED)
.addStyleEntry('theme2', './scss/main.scss, blue) // THIS WOULD OUTPUT theme1.css (BLUE)
The main.scss uses various mixins to overide the primary colours in Bootstrap, but I was wondering if a variable could be passed into main.scss.
Create a SCSS for each theme. This way more changes can be added and maintained easily.
// scss/theme1.scss
$primary-color: red;
#import 'main';
and
// scss/theme2.scss
$primary-color: blue;
#import 'main';
Pack them with
.addStyleEntry(theme1, './scss/theme1.scss')
.addStyleEntry(theme2, './scss/theme2.scss')
and you are done.
Though there is a way to set SCSS variables with Webpack/Encore by prefixing all sass-entries with a string, I would not recommend this approach:
.enableSassLoader((config) => { config.data = '$primary-color: green;' })
All entries will have the same prefix $primary-color: green; and you are polluting with styling information that should be placed in style-sheets when possible.
I'm new to Sass and I'm having some trouble with workflow.
For instance, I've tried to position nav section a little bit lower. I managed that by creating new _style.scss and importing it in app.scss. This is the code from new file:
//* _style.scss
.top-bar-section {
padding-top: 1.1875rem;
}
It works, but when I try other things, I cannot override values from _top-bar.scss (there was no padding for .top-bar-section).
Clearly I'm doing something wrong. Could I (should I) make the changes in _settings.scss? Trouble is, I can't find the corresponding variable.
And if I understand correctly, I can't make changes in /bower_components.
OK, it turns out Foundation has dedicated app.scss for this.
So, you edit in settings.scss (here you make changes to what's already been styled) and app.scss (here you make your own additional styling).
Okay, so I'm working on a Wordpress theme and I'm using Sass with Grunt. The problem is that although in my primary SCSS file I have a loud comment like this, the compressed output still doesn't include it.
/*!
Theme Name: Theme Name
Theme URI: http://theme.com
Description: Theme Description.
Version: 1.0.0
Author: Me
Author URI: http://me.com
*/
/* Global config */
#import "config/variables"; // Your custom variables
#import "config/colors"; // Your custom color scheme
#import "config/settings"; // Default settings file. Uncomment each setting you need to change
/* Foundation 5 */
#import "foundation"; // Foundation 5 by Zurb
/* Site structure */
#import "site/structure"; // Your site structure
I've tried changing the outputStyle to nested in Gruntfile and the comments are showing this way but obviously I don't want to do that on the live site. Any idea what's causing this?
Edit: here's the theme I'm working with https://github.com/olefredrik/foundationpress/
With the !, your multi-line comments should be preserved regardless of the output style you're compiling to (nested, expanded, compact or compressed). Thus something outside of Sass compilation must be stripping the comments - probably somewhere in the Grunt compilation.
I have couple of sass files:
_common.sass - everything that is used globally, including variables, mixins etc.
partials/_partial.sass - partial styles
homepage.sass - homepage specific
Now the problem:
If I import _common.sass into the partial/_partial.sass and then import partials/_partial.sass into the homepage.sass, well, _common.sass gets compiled twice. Bad.
The whole point is that the homepage.sass has to reference the _common.sass, so it could extend global class definitions and use mixins and os on, as well as the _partial.sass has to have access to global things from _common.sass. But _partial.sass itself has to be imported into the homepage.sass.
Sounds something very simple and unworthy, but Im having hard times solving that puzzle.
Edit (to clear things out):
// _common.sass
.sprite
background: url(sprite.png)
// _partial.sass
#import "common"
.link
#extend .sprite
// homepage.sass
#import "common"
.social
#extend .sprite
#import "partials/partial"
As you can see that both homepage and partial extend global class .sprite. This is what I'm trying to achieve. But in the end, homepage gets the whole content of _common.sass compiled per nested import (2 times, in particular example)
Layout of a 'master' SASS file
The way I normally do this is include the file at the start of my site.scss file.
site.scss
// variables, mixins, etc. at beginning
#import "common/_variables"
#import "common/_mixins"
#import "common/_sizes"
// ...
// your styles that use the variables, mixins, etc.
#import "modules/_blah"
// ...
Note that if the file contains only mixins, variables etc. then it is OK to include it multiple times as no output would result. For some text editors/IDEs you will need to do this for intellisense to kick in.
The _filename standard
SASS has a standard naming convention that a file that begins with an underscore _ isn't meant to be compiled, only used as a partial file for other files. Using this naming convention may stop compilation errors depending on what tools you're using.
I'll suggest the following: simply create a file that will add _common.scss initially.
// index.scss
#import "common"
#import "homepage"
// inside homepage
#import "partials/partial";
If you do so, I think that the things in common will be available for homepage and for partial, because they are imported above them. I.e. you don't need to import common inside homepage or partial.