Trouble Overriding CSS Variables in Sanity.io - sanity

I am attempting to change the styling of Sanity Studio as noted here in the docs: https://www.sanity.io/docs/styling#d7f9b5cc2adb
As such, I have created a file with the following css variables:
#import "part:#sanity/base/theme/variables/gray-colors-style";
:root {
--fieldset-border: none;
--fieldset-bg: var(--gray-darker);
}
Now, this works as I want for --fieldset-border, but it does not work for --fieldset-bg. I even tried hard-coding the value of --fieldset-bg as follows: --fieldset-bg: #454545; -- it still did not work.
So, I am wondering, why does --fieldset-border work and --fieldset-bg not work. More importantly, what do I have to do so that I can change the background color of fieldsets in sanity studio?

I have a hunch that the specific --fieldset-bg variable got silently deprecated recently (the move from #sanity/components to #sanity/ui). IF that's the case, opening a bug report issue in sanity-io/sanity repository would be great!
Regardless if that's the case, I'd suggest overwriting the css with a global selector in your variableOverrides.css file:
div[class^="DefaultFieldset_root"] {
background: papayawhip;
}
Hope this helps 🙌

Related

how often do bootstrap variables change

Switching from "bootstrap": "~4.0.0-beta.2" to "bootstrap": "^4.0.0" added new variables in the _variables.scss. Boostrap classnames only change when there is a major version upgrade (AFAIK), but does the same apply to _variables.scss too?
It would change how we share the _variables.scss accross our application.
Does variable names change between releases?
The variable names shouldn't change as Bootstrap 4 is now in "real" release (out of beta).
The variables are there for a good reason: Your CSS shouldn't break when you upgrade. (not counting major versions of course).
Of course new variables can be added, as those shouldn't break your CSS.
If you are in any way unsure before upgrading, you can always check the changelogs. Those should tell about any breaking changes.
Using variables in SCSS
When you have set up your build tools, and created your SCSS file (let's say custom.scss), you can import Bootstrap and override any variable you want (you'll find them in _variables.scss in the Bootstrap source code):
//Your variable overrides
//Let us change the primary color which is set in the primary variable
$primary: #ce40c5;
//In this case we are importing everything
//Here we are using NodeJS with NPM, so your files should be here
#import "node_modules/bootstrap/scss/bootstrap";
Some things to note:
If you aren't using NodeJS, then just make sure that the import path directs to the bootstrap.scss file (don't put .scss in the import)
If you have checked the source code of Bootstrap 4, you may have seen !default after every variable. Don't include that in your override. It just tells Sass that the variable can be replaced
There's a bunch of good information about this in the docs, so feel free to check there if you are missing anything (or ask).

Importing a file with LESS won't see the #filename var

I'm trying to load an .less file into my main theme, this is my filestructure:
main.less
themes/pink.less
themes/yellow.less
themes/blue.less
I'm using this mixin to retrieve the selected theme:
.theme(#filename){
#import 'themes/#{filename}.less';
}
.theme('pink');
It doesn't work and I get this error:
SyntaxError: variable #filename is undefined
.theme('pink');
I'm used to do the same with background images without getting errors, where I'm wrong?
Unfortunately Less.js throws the error you describe with imports for .less files (it works fine with imports for .css files), if you define the variable in in the mixin parameter/attribute, but it works if you define the variable directly inside (localy) or outside the mixin (globaly). For example, this should work:
#filename: 'pink';
.theme(){
#import 'themes/#{filename}.less';
}
.theme();
Here is a link to a discussion where the plan of implementing this has been discussed a while ago, and it seems that the longterm goal is to have your version working as well, it just hasn't happened yet completely ^_^
However, if you just want to load a theme according to the variable, you can do it without the mixin. just by doing something like this:
#theme: 'pink';
#import 'themes/#{theme}.less';

LESS #import & Web Essentials 2012

In my web project I have split my CSS into separate LESS files for maintenance reasons. I have a file called config.less acting as a master file that imports the other less files, using #import directives.
The problem with this setup seems to be that I get a lot of "Undeclared variable" & "Undeclared mixin" while editing my LESS files, for instance while adding a property variable called #textColor in base.less, that is declared in another less file called variables.less. Is there any way of making web essentials aware of variables and mixins being defined in external less files?
Another thing that seems to be tripping up Web Essentials is when I'm using the nested media query feature of LESS:
.some-selector {
background: #000;
#media only screen and (max-width: 800px) {
background: #fff;
}
}
The nested #media declaration gets a red underline, and on hover it says "Unexpected '#' block in the style rule". Hovering the nested background property shows a "Validation: 'color' isn't a valid HTML tag.
I cannot give an answer regarding the #media issue with Web Essentials, but I can give advice on the variables and mixins issue.
Basically, change your config.less file to have the variables.less and any other mixin files to be #import-once, then also add #import-once 'variables.less into each file that uses variables from it (do the same for any mixin files used).
What this does is imports the file if you are working on it (like your base.less), but when all the files are compiled by config.less, it will only import the variables.less once, and not again for each file that also references the variables.less.

Loading custom font in Windows 8 Metro App

I found this link on how to embed custom fonts in XAML apps. Is there some way I can achieve the same while building using JS? The following method did not work.
#font-face {
font-family: "MimicRoman";
src: url("/fonts/MimicRoman.otf") format('opentype');
}
Looks ok to me, that's how it should work. You are sure the path to the font file is correct and you did also actually use the font-face somewhere? For instance,
body {
font-family: MimicRoman;
}
Also, you are sure there are no other font-family declarations taking precedence over the declaration you've made? (this can be seen quite easily with the DOM Explorer).
If nothing else works, you might want to test some other font file, just in case that file is corrupt or something (some working examples from here, for instance).

HAML & SASS/COMPASS: Is it possible to share variables between?

I'm getting used to working with compass and Haml now and it's pretty awesome. However, it would be great if the two could work more closely together. It seems not possible, however I might have overlooked it or didn't search properly.
I guess I mean something like this:
general variable file:
$container-id = "container"
$primary-column-id = "navbar"
Haml file:
!!! 5
%html(lang="en")
%head
%title
%body
#{$container-id}
%section#{$primary-column-id}
Compass file:
#{$container-id} {
width: 900px;
}
#{$primary-column-id} {
width: 400px;
}
From my research and usage, this is currently not supported (without some sort of custom outside solution). I agree that it would be an awesome feature in theory, but I assume it doesn't exist because of separation of concerns.
For example, specific Haml files would have to be aware of linkage to other specific Sass files when compiled, and pick up declared variables. This does happen Sass <- -> Sass, via partials. However, with the idea above -> the markup (Haml) is blending somewhat with the styling (Sass/Scss). Though they reference one another - they have different purposes. e.g. An ID in the DOM is an attribute of the object, whereas in the stylesheet the ID is the selector of the object.
A framework (such as Compass) could theoretically achieve something like this because it looks at projects - but it might be more appropriate to have a unified project wide config file (neither Sass nor Haml) for your variable declarations or something.
This'd be a great question to get Chris Eppstein's opinion on: https://stackoverflow.com/users/41221/chriseppstein