I read through the Bootstrap 5 docs about typography and the files _variables.scss and _reboot.scss. I find that there is a SASS variable $font-family-sans-serif to set the font stack for sans serif text, but no corresponding $font-family-serif for serif text.
FWIW: It used to be present in _variables.scss for Bootstrap 3, but seems to missing from Bootstrap 4 as well.
Do I just declare it myself in my _variables_custom.css or is there a canonical way to do it?
Why was it omitted from the standard Bootstrap 5 set of varaibles?
Bootstrap (in its SCSS source format) is a framework - a stating point if you will - so it's expected that you add your own variables & elements and/or modify the existing ones. There is no $font-family-serif because its just not required for that core code.
As to how to customise - start with https://getbootstrap.com/docs/5.0/customize/sass
Why was it omitted? - Refactoring. Removing "dead code" (obsolete variables, parameters, fields, methods and/or class') is a very common "code cleaning" practice. A serif font is just not used, so it got deleted. (Not even in BS3 was it "used". It was declared, but not referenced in anything except the customizer.)
But that's the beauty of frameworks - you can just add/delete/change it yourself. :)
Related
I would like to do custom theme variations for my Vaadin 20 app. For that I am going to give custom values to Lumo CSS variables available, like --lumo-base-color and --lumo-primary-color. The problem is that I can't find an extensive list of variables that are available.
My questions are:
Where can I find a list of all the variables that are themeable?
Is there a good theme example with a lot of these variables set, that I could use as an example?
This is an excellent question, as it is often a best practice to start customization of the application on high level by redefining values of the Lumo CSS variables.
Take for example elements like ComboBox drop down button, text field clear icon, DatePicker popup button all use variable --lumo-contrast-60pct. It is easy to define its value in shared global css, and the new color will be consistently used by all the components. This is better approach than defining a custom css per component basis. See example below, where original graphite grey color has been changed to blue.
In the design system foundation documentation, each sub-section will list the available variables.
Additionally, if you inspect the <html> element in your browser development tools, you can see them listed there also.
In the Lumo theme editor demo you can change as many styles as you wish. It then lets you download a file that lists all the variables that you changed.
Another option is going to https://start.vaadin.com, where you can also customize some aspects of the theme, and the downloaded application will include those definitions.
In your running application, you could paste something like the following ugly snippet into your DevTools console to output all the Lumo custom variables and their current value:
[...document.styleSheets].forEach((sheet) =>
[...sheet.cssRules]
.filter((rule) => rule.type === 1)
.forEach((rule) =>
[...rule.style]
.filter((style) => style.startsWith("--lumo"))
.forEach((style) => console.log(style + ": " + rule.style.getPropertyValue(style)))
)
);
This will spam your console with something like
--lumo-border-radius-s: 1em
--lumo-base-color: hsl(214, 35%, 21%)
--lumo-tint-5pct: hsla(214, 65%, 85%, 0.06)
--lumo-tint-10pct: hsla(214, 60%, 80%, 0.14)
...
You might want to adjust the snippet to produce something more useful, depending on if you want to just use it as reference, or copy & paste into your theme.
I am busy making a sublime text plugin/package that will ease development of lua scripts in my workplace.
We have several lua files with different extensions depending on their purpose. I want ST3 to give the proper lua syntax to these files.
I know you can set ST3 to remember syntax for a specific file extension and this is saved as a (in my case) Lua.sublime-settings file in AppData\Roaming\Sublime Text 3\Packages\User
However, if I put this file in my new plugin's folder, it's ignored.
Am I doing something wrong or is what I want not possible?
This doesn't work because syntax specific settings are only loaded from the package that defines the syntax and from the User package (so the user can customize them).
The following is a quote from the official documentation on settings:
Settings files are consulted in this order:
1. Packages/Default/Preferences.sublime-settings
2. Packages/Default/Preferences (<platform>).sublime-settings
3. Packages/User/Preferences.sublime-settings
4. <Project Settings>
5. Packages/<syntax>/<syntax>.sublime-settings
6. Packages/User/<syntax>.sublime-settings
7. <Buffer Specific Settings>
The only places where <syntax> is referenced is from the package itself and from the user package.
If I had to guess, I would say that this is because outside of the original package author that defined the syntax, all other settings would be considered user customizations, and those settings need to be in the User package (specifically in the root of it) to ensure that they're loaded last.
A simple (but undesirable) solution would be to document for the user that they have to take this step manually.
Another approach would be to add some plugin code that extends the settings when your plugin is loaded:
def plugin_loaded():
settings = sublime.load_settings("Lua.sublime-settings")
extensions = settings.get("extensions", [])
if "blarb" not in extensions:
extensions.append("blarb")
settings.set("extensions", extensions)
sublime.save_settings("Lua.sublime-settings")
If you go this route you may want to include an extra sentinel setting somewhere (in settings specific to your package or some such) that says if you did this or not instead of just forcing the setting in as the example above does.
In practice you would then check if you've set that sentinel or not instead of forcing the extension in, so that if the user decides to use some other syntax for your files you're not forcing them into the Lua syntax.
It's also possible to define your own syntax that just embeds the standard Lua syntax, which allows this to Just Work™ without having to write any code or have the user do anything:
%YAML 1.2
---
name: Blarb
scope: source.lua
file_extensions:
- blarb
contexts:
main:
- include: scope:source.lua
When you do this, the scope in the file will still be source.lua because that's what the scope in the syntax file says. and the status line will set the syntax name to Blarb. You could modify either of those to change the top level scope or displayed name, if desired.
An example would be to change the scope to source.blarb so that you could create key bindings/snippets that only apply to Lua files of your specific variant.
A potential downside/feature of this is that since the name of the syntax specific settings comes from the name of the file that provides the syntax, if the user has any Lua specific settings, they won't apply to your Blarb files by default.
Similarly anything that's specific to Lua by checking for a scope of source.lua won't work in Blarb files for same reasons, which may or may not be an issue.
I have installed the less-rails gem as I am keen to use the colour manipulation LESS offers. I need to extract a colour from my database as my themes base colour, and build up from there.
I have the static CSS, and have renamed it styles.css.less to ensure that rails understands the less extension, which it appears to.
The next thing I tried was to also wrap the file as an erb, to hopefully allow ruby string literals to process before being sent to LESS, and eventually outputting as valid CSS (still with me?)
The file is now called style.css.less.erb. While the file simple contains valid CSS, the processing of the document works. As soon as I add a ruby string literal, it fails.
color: #{"#112233"};
In the chrome debugger, nothing after this line is getting processed.
What am I doing wrong, and how should I do what I am trying to do?
As Chowlett says in comments, you should use erb syntax: <%= "#112233" %>
Next step is get that value from db. If this color value is application-wide, probably you are looking for settings in db solution. I use rails-settings-cached gem for that. Your result code will looks like
color: <%= Setting.foo_color %>
If you are using assets on production, don't forget to recompile them after each setting change.
And if it's not a setting but probably something specific to each user then you can't use application-wide css files for that, but you can write inline css in views.
Intro:
I'm trying out LESS in an asp.net mvc environment.
I use dotless for server side processing (and I wouldn't want to use client side processing especially afer publishing the complete project).
I have to apply a design where there are different color schemes depending on different things (e.g. time of the day).
Less felt very powerful in this case as designing a parameterized css and only changing like 10 variables at the beginning of the file for every theme was really uplifting.
Problem:
But I would need to somehow change the color themes from an outside parameter.
Ideas:
First I thought that an URL parameter like style.less?theme=fuschia would be good, but I found no way to parse something like this.
Then I thought that making a very short blue.less, green.less, orange.less consisting only declared color variables, and including the main.less in every one of them would be a solid solution.
I had no chance to try out the second solution, but I thought this would be a good time to ask for advice on the most robust way of doing this.
The problem again is: I want to control some things in my less file from the outside.
Yes you can (because I implemented that feature for exactly that reason).
Dotless supports parameters from the outside via the querystring parameter.
<link rel="stylesheet" href="style.less?foo=bar" />
Will let you use the following less:
#foo = bar;
The parameter injection code is very simple. it just prepends the variable declarations to your normal less file, so anything that comes as a querystring parameter will follow the above syntax.
The code in question is very simple: https://github.com/dotless/dotless/blob/master/src/dotless.Core/Engine/ParameterDecorator.cs
AFAIK, you cannot pass parameters for dotnetless to use to do the compile.
As a suggestion, why not just call different less files? This would be fairly easy to do by using a Viewbag property.
To make the different less ones, You first create a less file with each set of colors in them. Then you import your base css file. dotnetless will merge the color definations in the parent file with the usages in the base file. So you have something like -
#baseGray: #ddd;
#baseGrayDark: darken(#baseGray, 15%);
#baseGrayLight: lighten(#baseGray, 10%);
#import "baseCss.less";
I just tested this on and MVC3 project and it works.
For some fonts, it's easy to replace the default font with something like: \renewcommand{\rmdefault}{somefont}.
However, some fonts, like BrushScriptX
want you to use a special command like \bsifamily to use the font. In the
\bsifamily is defined in /usr/share/texmf-texlive/tex/latex/brushscr/pbsi.sty:
\DeclareRobustCommand\bsifamily{\fontencoding{T1}\fontfamily{pbsi}%
\fontseries{xl}\fontshape{n}\selectfont}
In this case, I have a document that uses a cls stylesheet that I am editing. I'm using the standard includes to use this font:
\usepackage[T1]{fontenc}
\usepackage{pbsi}
If I try to use \renewcommand{\rmdefault}{bpsi} in my document's template, it fails with the error: Font shape `T1/pbsi/m/n' undefined
What might be the best way to replace the default roman font with BrushScriptX in a template, like \renewcommand{\rmdefault}{otherfont} would?
If you look inside pbsi.sty you'll find
\DeclareRobustCommand\bsifamily{\fontencoding{T1}\fontfamily{pbsi}%
\fontseries{xl}\fontshape{n}\selectfont}
Therefore, to set this font as the default — ugh :) — you'll need to write
\renewcommand\rmdefault{pbsi}
\renewcommand\mddefault{xl}
(\mddefault is the default "non-bold" series used in running text.)