We were using similar code and three places. And all of them used
`15rem`, which looked a lot like a magic number. So we're making it the
default value of a mixin, which means replacing it with a less arbitrary
value will be easier.
Note that, for the column gap, we're now using the standard
grid-column-gutter we use in most places. We were using `$line-height`
in a couple of places only because writing it is less verbose.
Since we're now, for the first time, using a very long mixin definition
that we need to split in several lines, we're adding the `param`
exception to the indentation rule. As far as I know, there's no way to
define a rule in Stylelint that requires parameters in multiple lines to
be aligned with the first parameter, which is what we define in Rubocop.
It's August 2025 and support for grid layout has been available in about
99% of the browsers for some time now. All major browsers added support
for grid layouts in 2017, which means our rule to support browsers that
are 7 years old allows us to start using `display: grid`.
Using a grid layout allows displaying a dynamic number of rows while
keepin all of them the same height, the same foundation's equalizer
does, by setting `grid-auto-rows: 1fr`.
And the `grid-template-columns` property lets us use dynamic columns for
all screen sizes, always filling the available space. No need to use
breakpoints.
We were using an <a> tag wrapping the whole content of the banner in
order to make the whole banner clickable. However, that made the text of
the link less concise, affecting people using screen readers. So,
instead, we're using the `card` mixin, which we introduced in commit
f285dfcba.
We're making this change now because the HTML5 Sanitizer that we're
about to enable in the next commit was handling the whitespace inside
the banner differently, causing one test to fail, and we didn't find a
different way to fix it.
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/
Note: Since we update to 1.80.1 deprecation warnings are appear when execute the assets:precompile command.
In order to silence this deprecation, we add silence_deprecation option in sass.rb initializer.
The code has also been updated to remove the deprecation warnings that appeared related to the function
darken(), lighten() and "Using / for division" instead of the function calc().
Bumps [sassc-embedded](https://github.com/sass-contrib/sassc-embedded-shim-ruby) from 1.70.1 to 1.80.1.
- [Commits](https://github.com/sass-contrib/sassc-embedded-shim-ruby/compare/v1.70.1...v1.80.1)
---
updated-dependencies:
- dependency-name: sassc-embedded
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
We hadn't added this rule before because there was no such rule in
scss-lint. Instead, we were following it without a linter, and so we
unintentionally broke it sometimes.
But now we're using Stylelint, so we can add the rule and let the linter
check we're still following it.
In commit 35659d441, we started using an <svg> tag instead of an <img>
tag to render avatars. That meant that the `vertical-align: middle` rule
we've got for images was no longer being applied.
So we're adding it back.
The only places where this icon wasn't rendered correctly were "my
account" and the show action in the users controller. The comments were
not affected because we've got a `float: left` rule for the
`comment-avatar svg` selector, which causes the browser to ignore the
value of the `vertical-align` propertly, and the avatars showing author
information were not affected because the `.author-photo` selector
already had a `vertical-align` rule.
We had an inconsistency where most stylesheets associated to a component
would have the same relative path as their component, so if we had a
component in `app/components/admin/whatever`, its associated stylesheet
would be in `app/assets/stylesheets/admin/whatever`.
There was one exception to this rule: stylesheets for components in
`app/components/shared/` were placed in `app/assets/stylesheets/`. The
reason was that we thought "well... if they're in the root folder,
they're shared". However, this is confusing because in the root folder
there are also stylesheets that aren't associated to a component.
So we're creating the `app/assets/stylesheets/shared/` folder. This also
means we don't have to manually add every stylesheet in this folder the
the `application.scss` file.
We aren't the same for JavaScript files because with JavaScript we still
don't have a clear association between JavaScript files and components.
Only a couple of them (`advanced_search.js` and `check_all_none.js`)
would be good candidates, and the one for the advanced search form
doesn't even use the `.advanced-search-form` selector that we use in the
CSS file.
