Starting a new rails project and we have a well-thought-out color palette, and want to capture that in one place. I have usually kept colors in the CSS, but I find I end up with all the same color in lots of different selectors, as it shows up as a background color, color, border color, etc. I also will occassionally need access to colors in the Javascript. It would be great to just define each color ONCE.
So I'd just like to define my color palette in a way that's re-usable in the CSS and Javascript, but I don't want to go all the way to SASS, abandoning CSS syntax completely.
Is there a rails plugin already made that allows this? I could patch together an ERB type solution, but I don't want to do it if someone else has something readily available.
There is a new project out called {less} that sounds like what you are looking for: http://lesscss.org/
LESS seems to have a rails plugin, and a more css like syntax.
There are several server side parsers like LESS and SASS, but if you want to use the palett mentality in straight CSS you have to revers your thinking. Define basic styles like colors, fonts etc. and apply multiple classes at the tag level.
[style]
.color1{color:red}
.color2{color:blue}
.color3{color:green}
.bcolor1{color:red}
.bcolor2{color:blue}
.bcolor3{color:green}
[/style]
[tag class="color1 bcolor2"]
This has worked very well for us.
Another (pure CSS) way may be to define each color once, and have the several selectors associated with that oe color definition, for example:
body,
p,
#foo,
.bar {color: #802369 }
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 currently in the process of migrating a Vaadin 8 application over to Vaadin 12. The look and feel should be used by the user and changed on Login or via a button press.
In Our Vaadin 8 application we had 2 themes (a dark and a light one), each with their own SASS/CSS and some shared properties. The user was able to switch it using the setTheme() Method. When a click to the switching button happened, the Look and Feel just changed. In Vaadin 12 the Theming follows a different approach and I am struggling to find a good way to implement this feature in Vaadin 12.
Let's say we don't want to create a whole new Theme and just want to use customized LUMO. I can set the Theme/Variant through the #Theme Annotation. The Downside: The Theme will be fixed at Runtime.
Also i could just write some code to apply variants to my application and components. (like in the dynamic styling chapter: https://vaadin.com/docs/flow/element-api/tutorial-dynamic-styling.html )
The Downside: It won't be very practicable to iterate through each element and apply the variant.
My question now:
What is the best way to achieve a switch between to themes at runtime? (customized light- and dark variants of Lumo or any other theme).
Would I just create 2 HTML Files (for compatibility) containing CSS and then somehow override the currently used File through a dynamic import?
I hope my question is clear and someone can point me to the right direction.
If you are only interested in toggling between light and dark, then you can just add/remove dark at a very high place in the DOM. E.g. the element of the UI is usually the body or at least very high up.
E.g.:
new Checkbox("Use Dark Theme").tap{
addValueChangeListener{ cb ->
getUI().ifPresent(){ ui ->
def themeList = ui.getElement().getThemeList()
if (cb.value) {
themeList.add(Lumo.DARK)
} else {
themeList.remove(Lumo.DARK)
}
}
}
}
edit
As asked in the comments of another answer:
To change the colors in a theme, you can override the used colors. This is the example how to change the text color for light and dark Lumo theme:
html {
--lumo-body-text-color: red;
}
[theme~="dark"] {
--lumo-body-text-color: yellow;
}
It's relatively easy to switch between two different variants of the same theme, e.g. the dark and light variants of Lumo. To do this, you only need to toggle the corresponding theme attribute on the <html> element. There's no direct access to that element from the server, but you can do it with a small snippet of JavaScript: ui.getPage().executeJavaScript("document.documentElement.setAttribute($0, $1)", "theme", "dark");
Depending on circumstances, you can or must apply the changes to the <body> element instead. In that case, you can either switch out .documentElement for .body in the JS snippet or directly use ui.getElement().setAttribute("theme", "dark") in Java.
Switching between two different base themes, e.g. Lumo vs Material is a much more complicated affair. For each component, there can only be one base theme loaded in the browser at the same time, and reloading the page is the only way of getting rid of the one that is already loaded. For each component that is used for Flow, the framework takes care of loading the right theme import in addition to the base import that doesn't have any styling. To make things even more complicated, the theme designated using #Theme is automatically included in the application's production bundle. To be able to use multiple base themes, you'd also have to somehow produce multiple different bundles and also somehow configure Flow to use the right bundle depending on circumstances.
So I would need to make static HTML pages in multiple languages and now I'm looking what way it would best to do. HTML of the pages stays same, as does images. Basically only text content changes from localisation to another. Page structure is something like this:
en/
../index.html (main/home page)
../catalogue.html
../video.html
../examples.html
de/
../index.html (main/home page)
../catalogue.html
../video.html
../examples.html
So layout (html, css and images) are same on all pages. Just text content changes. There are about 10 different languages. What tool would you use for the injecting text (from json file?) to each template and automatically building needed folders & files. Grunt + mustache?
This is pretty simple so I don't really want to use any CMS for this. For sass etc I will use Grunt already.
If you are going the grunt way here are some thoughts:
Take a look at grunt-dom-munger, it's designed to manipulate html's using standard selectors. You can replace text, elements, append new ones or remove existing, whatever you need.
If you also need to copy files from here to there after transforming them you may want to use grunt-contrib-copy.
Moreover, do not forget that the Gruntfile is plain javascript so you can write your own custom functions to do whatever manipulations or operations you may need.
Hope this helps you get started...
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.
I use Aloha theme in NetBeans 6.8, everything looks cool except these blue tags in HAML files, which are unreadable. How to find a place where this blue color could be changed?
P.S. I use that HAML plugin which seems to be unsupported and lacks features
Screenshot: http://img.leprosorium.com/846904 (sorry, new users can't embed images)
Lots of people would DIE for a decent Netbeans HAML plugin.
I suggest that we just PAY for someone to write it :
http://www.cofundos.org/project.php?id=181
Sad to say "that HAML plugin which seems to be unsupported and lacks features", is the only Haml plugin there is for netbeans. I don't know if there is source code for it out there either (never looked). If you look, the colours are all defined in a file called haml.nbs. You can find it by extracting the org.netbeans.haml.jar from the nbm you downloaded and then extracting the haml.nbs from that. Ubuntu's file-roller will cheerfully do this for you.
The contents of the file look like this:
COLOR:declaration: {
default_coloring: "comment";
foreground_color: "gray";
}
...
With a little fiddling you could probably change those values to suit your needs and put it back together. It should work.
Of course if there was source for the darn thing that would be even better.