We had inconsistent indentation in many places. Now we're fixing them
and adding a linter to our CI so we don't accidentally introduce
inconsistent indentations again.
In some places, we accidentally opened the same tag twice instead of
closing it, while in some other places we closed a tag without opening
it in the first place.
We've detected these issues thanks to the HTML Beautifier gem, which
we're about to start using for indentation purposes.
Using an `if..else` block made the code harder to follow since the
opening tag was inside the block but the closing tag was outside it.
Moreover, it didn't work well with HTML Beautifier (a gem we're going to
introduce to manage ERB indentations).
This way we simplify the HTML, which had some `if...else` blocks that
were hard to follow because there were opening tags inside these blocks
while the closing tags were outside these blocks.
We're also making the CSS container-dependent instead of
window-dependent. Since there are between one and three elements inside
the panel, we accomplish this by making the element with the content
take its own line if the width of the panel is smaller than 35rem.
Note we're trying to keep the layout similar to what it was; since we're
no longer using negative margins (like the ones in the `.row` selector),
the votes element now gets a width of 22.5% instead of 25%.
Also note we're using the column-gap property for flexbox because the
`flex-with-gap` mixin doesn't work so well with elements that have
borders. Since the column-gap property for flexbox is now supperted by
more than 98% of the browsers (which wasn't the case when we started
using the `flex-with-gap` mixin), the `flex-with-gap` mixin has become
obsolete.
Finally, note we're removing the `max-width: 12rem` rule in the images.
I'm not sure why we introduced this rule in the first place, and it
didn't play so well to the new layout. I considered using code like
`max-width: min(100%, 12rem)`, but, since I'm not sure why `12rem` was
there in the first place, I'm not sure whether this approach was better,
and it sure made things more complex.
Not doing so made it trickier to define a flex layout, since the
icon-successful element is given a `position: absolute`, but only for
successful proposals, while for unsuccessful proposals it was taking
the standard `position: static` value.
We're also reusing the `successful?` method instead of rewriting it in
the view, and fixing a small issue where the icon wasn't displayed for
proposals having the exact needed votes (we were using `>` instead of
`>=` in the condition).
Note that legislation proposals use the method
`Proposal.votes_needed_for_success`, which is probaby a mistake caused
by copying the code from the proposal view. Fixing this issue is out of
the scope of this commit (and pull request), though.
With the multiline condition, HTML Beautifier (which we're about to
introduce in order to manage ERB indentation) gets confused. In this
context, a one-line condition is also more readable.
We had some duplication because the `css_for_process_header` was using
an instance variable, and so it couldn't be called from a partial where
this instance variable wasn't available.
Using a local variable and passing it as a parameter (as we should
always do) solves the issue and lets us simplify the code.
We now strongly recommend to upgrade one version at a time and to run
the tests before and after upgrading.
Note we use a `release` branch instead of an `upgrade` branch because
we've been mentioning the `release` branch in the release notes of every
release for years.
These initializers either don't contain any code at all or contain code
that we never use. Since this was the case in most Rails applications,
they're no longer generated in new Rails applications [1].
So we're removing them as well.
[1] See pull requests 42538 and 43237 in https://github.com/rails/rails
* The `gender-and-channel` class isn't use since commit e3063cd24f
* The `first-comment` class added in commit e5fb90f954 was never used
* The `additional-info` class added in commit d47ce39b37 was never used
* The `title-quote` class isn't use since commit f317514258
* The `big-number` class added in commit aa1ed87725 was never used
* The `big-number-stat` class isn't used since commit cf32dcd6d5
* The `budget-investment-amount` and `budget-investment-description`
classes added in commit 4ade8325d7 were never used
* The `debate-quiz` class isn't use since commit d679c1eb79
* The `enquiries-list` class isn't use since commit 6aa96c4471
* The `investment-project-content` class isn't use since commit d0b8fef6b3
* The `leave-comment` class isn't use since commit ff6285d114
* The `poll-question-show` class isn't use since commit 8277e3cc2b
* The `questions-callout` class isn't use since commit ddf8d5f811
* The `budget-investments-inner` class isn't used since commit c6a9ffc19
* The `map-attributtion` class isn't use since commit 5a09b79da4
* The `postfix` class isn't use since commit 3752f3a53b
* The `translation-locale` added in commit a6e8fecc16 was never used
* The `changes-link`, `comment-advice`, `show-comments` and `comment-votes-number`
classes aren't use since commit d679c1eb79
This script was removed from Rails in Rails 6.0 [1] because the
`bin/setup` script is now idempotent and can be used to update the
application as well.
[1] See https://github.com/rails/rails/commit/8927eba83c
In commit 64bcedc8b, we upgraded Sass from version 1.70 to version 1.80.
However, since then we've noticed a couple of inconvenient things.
First, we're getting some deprecation warnings when compiling the
assets, related to a usage of `map-has-key` in Foundation which is
deprecated since Sass 1.80. Even with the `quiet_deps` flag, these
warnings aren't silenced.
Second, version 1.79 changed the way color functions work [1]. In
particular, functions like `color.adjust` or `darken` would now generate
RGB colors that include float numbers [2]. Browser support for float values
in RGB colors is about 98% at the time of writing [3], meaning some
browsers that are at least 5 or 6 years old will not render these
colors, sometimes resulting in white text over a white background, which
is of course impossible to read.
Finally, we get some deprecation warnings in our code when we remove the
`quiet_deps` flag, caused by the breaking change in mixed declaration
[4] from version 1.77.7 [5]. This warning is tricky; consider the following
code:
```
@mixin normal-selection {
&::selection,
*::selection {
@include background-with-text-contrast($brand, brand, $check-invert-selection: false);
}
}
.button.hollow {
@include normal-selection;
border: 1px solid;
}
```
In this scenario, since normal-selection is a mixin that generates a
nested rule, we're doing a declaration after a nested rule, which is now
deprecated.
The situation gets even more complicated when we define mixins that have
both nested rules and rules that apply to the element itself. Currently,
we sometimes include a mixin and then override some of the properties
the mixin defines, but we wouldn't be able to do so if we can't define
properties after including the mixin.
Right now, the solution seems to be adding `& { }` selectors
after including a mixin, like this:
```
.button.hollow {
@include normal-selection;
& {
border: 1px solid;
}
}
```
Which is incredibly cumbersome.
So, for now, we're downgrading to version 1.77.5 (we would downgrade to
version 1.77.6, but the sass-embedded gem skipped that version). That
version was released in June 2024, so it isn't very old yet. In the
future, we'll see what to do about the issues mentioned above, since
we'll have to upgrade at some point.
Note we're removing the `silence_deprecations` flag because Sass 1.77
doesn't raise warnings about using `import`.
[1] https://sass-lang.com/documentation/breaking-changes/color-functions/
[2] https://sass-lang.com/documentation/modules/color/#adjust
[3] https://caniuse.com/mdn-css_types_color_rgb_float_values
[4] https://sass-lang.com/documentation/breaking-changes/mixed-decls/
[5] https://sass-lang.com/documentation/js-api/interfaces/deprecations/#mixed_decls
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/
We made a mistake when adding the `calc()` function in commit 6df813fdb,
since the `/` operator originally only affected the `$heading-icon-size`
part of the operation, but affected the whole operation after that
commit. This caused the icon to be positioned on top of another icon.
The interpolation of the rem-calc function made the code harder to read.
Besides, for new code we've already agreed upon using rem units instead
of `rem-calc`.
For instance, we had the following code:
```
width: calc(100% - #{2 * rem-calc(10)});
```
Now, `2 * rem-calc(10)` is the same as `rem-calc(20)`, but we were using
`2 *` to make it clear that this value was related to the value of the
`margin-left` property, which was `rem-calc(10)`.
IMHO using `0.625rem` for the margin and `2 * 0.625rem` for the width
the code is easier to read because there are no interpolation and no
complex operations involved.
We forgot to add the `calc()` function in commits 4c0b6455f, 390c749d2
and dc54fda71.
We were getting a warning when compiling the assets without the
`quiet_deps` option:
```
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, 3) or calc($line-height / 3)
More info and automated migrator: https://sass-lang.com/d/slash-div
```
