Add spacing and font size variables

This is just another opinion, but for me at least, it would read the best if the variables would be defined as

--font-size
--font-size-root
--line-height-size

Anyone else has any thoughts on this? I just wanted to express what I thought when I saw the patch and I'm not too keen to any particular pattern if people feel something else would be better.

The cases you mentioned are a really-really basic and should't be used in a component IMHO. Even if an input uses the Davy's grey for it's default border color, we should provide variable for the input border since it may change later and it's easier to change the variable of the input border than process the form--text.css, form--checkbox-radio.css etc.

I tried to apply [type[-element]]-[property[-state]] until now.

Examples:

• The border color of a disabled input element was --color-input-border-disabled
• The active item of a jQuery ui dropdown would be --color-jui-dropdown-bg-active

Could you please agree on a variable pattern that cover these as well?

The problem with providing variables for example for the border color of input is that the variable isn't reusable since it is created for a single purpose. If the components design gets updated, you would likely make other changes to the styles as well, so editing the CSS file directly shouldn't be a problem. If you want to update all of the instances of the color --color-absolutezero to another, you would perform simple search and replace from --color-absolutezero to --color-absoluteten.

I think we have to find a middle ground to get the best of using variables. We shouldn't be creating a single file that can control all aspects of the theme since that makes maintenance harder and abolishes all the benefits we get from using variables.

Color variables are usually the hardest to name. In my experience, the best approach is to try to come up with a name for every color and use that as a variable name, and then reference variables named after the color name directly from CSS.

+++ b/css/src/base/variables.css
@@ -28,10 +28,28 @@
+  --size-font: 1rem; /* 16px if font root is 100% ands browser defaults are used. */
...
+  --rhythm: 1rem; /* 1 * 16px = 16px */

How about defining those values more precisely by adding -base at the end ?

+1 for the use of space (or spacer ?) instead of rhythm

@Laurii, I don't agree with you. We already have some interesting issues like the outline color change.

Let me describe with input focus outline color:

If you handle it as a component-specific var, you just had to change the --color-input-focus. (I don't know how we can handle it as a color var right from the color palette because it had an opacity as well, but ignore this for now.) If you use it as a component-specific variable like --input-focus-color, you can change it from var(--color-absolutezero) to var(--color-newfocuscolor) without any extra efforst.
This can be done easily for radios-checkboxes. And it would be hard if we don't use component-specific variables.

I'm not sure if I understand how it would be easier to make the change when using variables created in a single file compared to having them in multiple files. I don't think people are able to make this kind of changes blindly in the variables file, because they have to see the context associated with the variable. Maybe in a well-established framework, this might make sense - but AFAIK we're not trying to build that. I know there are very popular libraries that are doing this so I assume there are some people who like this approach. I've worked in projects that have used a similar approach and I've always found it as extra complexity without bringing much value. Does anyone else have a different point of view on this?

+++ b/css/src/base/elements.css
@@ -2,10 +2,12 @@
+  font: normal 100%/var(--lineheight) var(--font-family);

+++ b/css/src/base/variables.css
@@ -28,10 +28,25 @@
+  --lineheight: 1.5;

One more nitpick on this one; this variable should probably be --line-height- instead.

Thank you everyone!