This stylelint-scss rule is useful because we were inconsistent when
using calc(); sometimes we added interpolation to Sass variables, and
sometimes we didn't. The reason why we originally added interpolation
was that it was necessary until we migrated to Dart Sass in commit
d54971e53. Since then, we can omit the interpolation, which is also what
the Sass documentation recommends [1].
[1] https://sass-lang.com/documentation/values/calculations/
The division operator `/` from Sass is deprecated because `/` is used in
CSS for uses other than dividing numbers. That's why we were getting
many warnings like:
```
Deprecation Warning: Using / for division outside of calc() is
deprecated and will be removed in Dart Sass 2.0.0.
Recommendation: math.div($line-height, 2) or calc($line-height / 2)
More info and automated migrator: https://sass-lang.com/d/slash-div
margin-top: $line-height / 2;
```
Since using math.div makes the code harder to read and `calc` is
universally supported by all browsers (although the implementation in
Internet Explorer doesn't work in certain cases), we're using `calc`
when assigning the value to a CSS property.
However, we're also using divisions when assigning Sass variables, and
in those cases using `calc` is trickier because sometimes these
variables are used in other operations. We'll handle these cases in the
next commit.
So we don't add the same lines to pretty much every stylesheet we
create.
Eventually we'll remove this code and add a padding to every <main>
element, or (even better) to the <body> element itself.
We can give the padding to the whole page instead of giving it to
individual elements.
On the minus side, now padding in the SDG pages is not the same as the
padding in the homepage, so we need to add an extra padding to the
participation feeds in only one of these cases.
We were using these rules in order to set the maximum width of an
element to `$global-width`. However, since we now do so in the <body>
element, there's no need to apply these rules to "rows".
Note we're adding `overflow: hidden` to the budget subheader. That's
because it only contains `float` element inside, and we're now missing
the `.row::before` and `.row::after` rules which make sure float
elements are rendered properly.
We're also using a percentage to separate the icons, since using the
viewport width causes strange result on screens where the element
max-width (which is based in rem) is much smaller than the size of the
window.
We were using the classic approach of adding a margin-right property to
all elements except the last one. This works great when all icons are
displayed in one row.
However, when they're displayed in several rows, there could be a
scenario where the last row has more elements:
element1 <margin> element2 <margin>
element3 <margin> element4 <margin> element5
In the example above, `element3` does not fit in the first row because
it's got a margin to its right. However, `element5` fits in the second
row because the last element has now right margin.
One option to fix this issue it using CSS `gap` property. However, at
the time of writing, it's only supported by 70% of the browsers.
So we're emulating the gap by giving a negative margin to the list
equivalent to the margin of the first element.
This idea is based on:
https://coryrylan.com/blog/css-gap-space-with-flexbox
The exception is the index page. Here the list of icons is centered with
`margin: auto`, and so we cannot use negative margins. We're using the
classic approach instead, which is fine because we define there are 6
icons per row.
This way we generate the same HTML as we generate everywhere where we
manually generate lists of links. Having a blank space betwwen tags
results in a space being introduced when the elements are displayed
inline (or with `inline-block`).
So in places where we don't want that space between the elements we have
to use a flex layout.
