Until now, overwriting the styles for a certain tenant was a very
tedious task. For example, if we wanted to use a different brand color
for a tenant, we had to manually overwrite the styles for every element
using that color.
It isn't possible to use different SCSS variables per tenant unless we
generate a different stylesheet per tenant. However, doing so would make
the CSS compilation take way too long on installations with more than a
couple of tenants, and it wouldn't allow to get the colors dynamically
from the database, which we intend to support in the future.
So we're using CSS variables instead. These variables are supported by
97% of the browsers (as of October 2022), and for the other 3% of the
browsers we're using the default colors (SCSS variables) instead.
CSS variables have some limitations: for instance, it isn't possible to
use functions like `lighten`, `darken` or `scale-color` with CSS
variables, so the application might behave in a strange way when we use
these functions.
It also isn't possible to automatically get whether black or white text
makes a better contrast with a certain background color. To overcome
this limitation, we're providing variables ending with `-contrast`. For
instance, since the default `$brand` color is a dark one, when assigning
a light color to `--brand`, we probably want to assign
`--brand-contrast: #{$black}` as well, so the text is still readable.
Until now, we didn't have specific variables for the headers and were
using the brand colors instead. Now we maintain the brand colors as
default values, but allow overwriting them.
For the navigation and footer, we didn't even have variables.
Back in commit 5dbd69486, I said:
> I'm choosing to use the same color for solid and hollow buttons
> because these elements are usually isolated and so from the UX
> perspective they are similar; links, on the other hand, are often in
> the middle of some text.
However, I made a mistake. The crucial factor is that solid buttons
might have a light background if we choose the brand color to be a light
one, and in this case they automatically get black text. However, hollow
buttons always have a light background and so we can't use a light color
for the text and border of these buttons.
We were using each one half the time, while they both had the same value
by default. It was impossible to know when me meant "use a dark color
here" or "use the secondary brand color" here.
So now we're only using one variable, so it's easy it'll be easy to add
CSS custom properties to overwrite this variable. We're choosing
`brand-secondary` because its name makes it less problematic to use a
light color.
This is consistent with the usage of `$body-background`. This way
Foundation elements using `$body-font-color`, like the `<body>` tag,
will be changed when changing this variable, which wouldn't happen when
using `$text`.
The variables `$anchor-color` and `$anchor-color-hover` are the ones
Foundation uses internally; by using them, we make sure every link will
use the colors we define.
Now we can simplify the default styles for the `<a>` tags, since by
default they already use these variables.
This way we simplify the code a bit.
Note we're only using this function when variables for background colors
are already defined, since that means customizing the variable using the
background color will automatically change the color of the text.
Customization isn't easier when using raw colors.
We were defining (for instance) white text against the `$brand`
background. That meant that, if somebody customized the `$brand` color
so it used a light color, they had to customize the text color as well
in order to guarantee proper contrast between text and background
colors.
So we're using `color-pick-contrast` instead, which means we don't have
to manually calculate whether white or black will be the color which
makes the text more readable.
We were using `#fff` in some places and `$white` in others. We're
choosing `#fff` because it has a better contrast against the lighter SDG
colors and because it's the one officially used by the United Nations.
This way we can simplify the code a bit since Foundation automatically
chooses the text color of the caption so there's enough contrast with
the background color defined in `$orbit-caption-background`.
This way it's easier to customize colors, particularly when links use
the same colors as the text surrounding them.
Note that the `markdown-editor-header` isn't displayed since commit
76b7f66fb, which was probably an unintended side-effect. So we're
modifying the colors here as well instead of removing the element; we
might display it again in the future.
Also note the change in `.supported` only affects the proposals section;
budget investments use a different color for the `.supported` sucess
message. Not sure whether this was originally intended or done by
accident.
These elements were already using these colors because they inherited
them from their parent elements or Foundation already defined them.
Note that the only contents of `.comment-info` are: `.user-name` and
`.is-author`, `.is-association`, `.level-1`, ... and the link to the
comment. All of these elements were overwriting the `$text-medium`
color, so there's no need to set it. That means we can use the default
text color for `.user-name` without specifically setting it.
Doing so will help to immediately identify which administration you're
managing when using multitenant applications.
We might revert this change if we detect it causes usability issues in
the admin section.
Should hollow buttons use the same color as links do or the same color
as solid buttons do? In the default scenario, it doesn't matter, since
links and solid buttons use the same color. However, it matters when
people customize the application so links and solid buttons don't use
the same color.
I'm choosing to use the same color for solid and hollow buttons because
these elements are usually isolated and so from the UX perspective they
are similar; links, on the other hand, are often in the middle of some
text.
Note we're talking about links and buttons while many of the "buttons"
we use in the application are actually links styled as buttons. Here,
"buttons" means "things that look like buttons".
We were overwriting the color of the links, but not the color of the
links on hover.
Note we're removing the `!important` rule from the author link; after
testing it, it looks like it wasn't necessary.
We were using the wrong color since commit e2d540d20 because, by using
`@extend`, the compiled CSS had the styles for `.ui-state-hover` appear
before the styles for `.ui-state-default`.
This mixin was being called twice for the `.budget-investment-show`
selector; once in the CSS including this code for all the "Show
participation" pages, and once in the CSS for budget investments.
By using the Rails `button_to` helper (which generates a form), and adapting the
response to `html` and `js` formats, the feature works with or without javascript
enabled.
Apply new structure in the section that shows the comments icon together
with the number of comments so that it is easier to unify them into one
component.
Please note that we updated the comment-number class to comments-count
in order to simplify the css in the new component in the next commit.
This was the only place in the application where the comments icon was
included without the span with the class "icon-comments".
We unified with the rest of the application and removed the
"comments-count" class which is no longer needed.
Remove unnecessary span class "debate-comments".
We take advantage of this commit to also unify the format of the date
that appears next to the comments with the rest of the application. The
format that we removed is being used on the same page in the
"Participation phases" tab (I guess that was the reason for putting it
the same) but I think it makes more sense to use the date format that is
used in this kind section in the rest of the application.
Apply new structure in the section that shows the comments icon together
with the number of comments so that it is easier to unify them into one
component.
In this case we make only the text clickable and not the icon as in the
rest of the application. We're keeping the color and text-decoration so
it looks the same way it has looked until now, but we might change it
in the future.
Foundation was using `!global` for non-existing variables, which
generated a warning on our current version of Sass.
This is (mostly) fixed on the latest version of Foundation. However,
this latest version isn't included in the `foundation-rails` gem, so we
can't upgrade yet.
So we're defining these variables before Foundation does so.
See issue 12080 in the foundation/foundation-sites repository for more
information.
While reviewing commit 7702b551e, I forgot to test whether selecting
text in the budget header or clicking its link worked properly.
The negative index (-5) meant it was impossible to select its text or
click on its link.
The good news is the pseudoelement with a negative index (-1) is
considered a child of the .budget-header element, so having a negative
index will cause the pseudoelement to be render behind the content of
the .budget-header element but in front of the background of the
.budget-header element.
This is exactly what we want.
Originally, we didn't have a z-index in the .budget-header element,
meaning the pseudoelement was rendered behind the background of the
.budget-header element, meaning both backgrounds were visible. This was
OK when the background was a plain color, but it wasn't when the
background was an image.
To stress the fact that the budget header is only affected when we use
an image, I'm also moving the code inside the `.with-background-image`
selector, although it would be interesting to check whether it's a good
idea to add `z-index: 0` to the `full-width-background` mixin.
