After moving to Dart Sass, we were getting warnings like:
```
Deprecation Warning: $saturation: Passing a number without unit % (78)
is deprecated
Deprecation Warning: $lightness: Passing a number without unit % (93) is
deprecated
```
So we're passing percentages to the hsla function instead of passing
numbers without units.
In the previous commit, we used the `calc` function when assiging CSS
properties in order to avoid 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($global-width, 2) or calc($global-width / 2)
```
In cases like dividing by two, there's a third alternative: multiplying
by 0.5. We're applying this principle to all variable assignments where
we were using divisions, since using the `calc` function here would
sometimes result in errors due to these variables being used in
arithmetical operations. We aren't using `math.div` because it makes the
code harder to read.
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.
This way we've been able to detect a bug where we were assigning a value
to the `$global-left` variable instead of assigning it to either the
`left` or `right` properties. This, however, was the right behavior,
since adding a `left` indentation to the link wasn't correct because its
parent element already had padding on the sides.
SCSS Lint was based on Ruby Sass, which has been deprecated since 2018
and doesn't support some of the latest features in Dart Sass.
Since we're going to migrate to Dart Sass, we're also migrating to
Stylelint. In order to provide all the funcionality SCSS Lint had, we
also need to install a few Stylelint plugins. We also need to install
the `postcss-scss` package so Stylelint can read SCSS files.
We're still getting the linting errors we used to get in
`legislation_process.scss` because of the `max-nesting-depth` and
`selector-max-compound-selectors` rules, as well as the warnings we used
to get in `layout.scss` because the `ssb-whatsapp_app` HTML class
contains undescores in their name.
We're also getting a couple of new linting errors, which could be false
positives:
* The `scss/no-unused-private-members` rule reports errors in
`_consul_settings.scss` because of the `$-zf-*` variables, but I'm not
too worried about this one because these lines won't be necessary after
updating Foundation.
* The `scss/selector-no-redundant-nesting-selector` reports an error in
`datepicker_overrides.scss`, but removing the unnecessary nesting
selector would make it harder to understand the code (assuming it'd
work in the first place).
We've changed some files due to few differences between SCSS Lint rules
and their Stylelint equivalents:
* The `@stylistic/string-quotes` rule detects a case in `admin.scss`
that StringQuotes didn't detect.
* The `function-url-quotes` rule detects a case in `mixins/icons.scss`
that UrlQuotes didn't detect.
* The `@stylistic/declaration-bang-space-before` rule detects a case in
`sdg/goals/show.scss` that BangFormat didn't detect.
There are also a couple of rules that don't behave exactly like they
used to:
* The equivalents of SpaceBetweenParens and SpaceAfterComma don't cover
parenthesis or commas in mixin parameters; we haven't found rules that
detect these cases.
* DisableLinterReason probably has an equivalent that behaves
differently but, since we never disable linters inline, we aren't
adding its equivalent rule.
Note we're removing the SpaceAfterVariableColon rule because its
equivalent, `scss/dollar-variable-colon-space-after`, reports cases
where we add spaces to indent several variable assignments (which we do
a lot in the `_consul_settings.scss` file). We might add this rule again
if we stop aligning consecutive assignments.
We're also removing the QualifyingElement rule because its equivalent,
`selector-no-qualifying-type: true`, behaves differently. For example,
in this code:
```
a.qualifying {
color: inherit;
}
p {
&.qualifying {
color: inherit;
}
}
```
With the QualifyingElement from SCSS Lint, the first rule is incorrect
but the second one is correct. With the selector-no-qualifying-type rule
from Stylelint, on the other hand, both rules are incorrect.
Personally, I never liked the QualifyingElement rule, and we were
working around it anyway, so we aren't applying
selector-no-qualifying-type.
For reference, here's a full list of the SCSS Lint rules we had enabled
and their Stylelint equivalents.
BangFormat
"@stylistic/declaration-bang-space-after": "never"
"@stylistic/declaration-bang-space-before": "always"
BorderZero
declaration-property-value-disallowed-list:
border:
- none
ColorKeyword
color-named: "never"
DebugStatement
at-rule-disallowed-list:
- debug
DeclarationOrder
order/order:
- dollar-variables
- custom-properties
- type: at-rule
name: extend
- type: at-rule
name: include
hasBlock: false
- declarations
- type: at-rule
name: include
hasBlock: true
- rules
ElsePlacement # Apparently replaced by the combination of:
scss/at-else-closing-brace-space-after: always-intermediate
scss/at-else-empty-line-before: never
scss/at-if-closing-brace-space-after: always-intermediate
scss/at-if-closing-brace-newline-after: always-last-in-chain
EmptyLineBetweenBlocks:
ignore_single_line_blocks: true
rule-empty-line-before:
- "always-multi-line"
- ignore:
- after-comment
- first-nested
EmptyRule:
block-no-empty: true
FinalNewline
"@stylistic/no-missing-end-of-source-newline": true
HexLength
color-hex-length: "short"
HexNotation
@stylistic/color-hex-case: "lower"
HexValidation
color-no-invalid-hex: true
IdSelector
selector-max-id: 0
ImportPath
scss/load-no-partial-leading-underscore: true
scss/at-import-partial-extension: never
Indentation
"@stylistic/indentation": 2
LeadingZero
@stylistic/number-leading-zero: "always"
NameFormat
scss/at-function-pattern: "^(-?[a-z][a-z0-9]*)(-[a-z0-9]+)*$"
scss/at-mixin-pattern: "^(-?[a-z][a-z0-9]*)(-[a-z0-9]+)*$"
scss/dollar-variable-pattern: "^(-?[a-z][a-z0-9]*)(-[a-z0-9]+)*$"
scss/percent-placeholder-pattern: "^(-?[a-z][a-z0-9]*)(-[a-z0-9]+)*$"
NestingDepth
max-nesting-depth: 4
PlaceholderInExtend
scss/at-extend-no-missing-placeholder: true
PrivateNamingConvention
scss/no-unused-private-members: true
PropertySpelling
property-no-unknown: true
PseudoElement
selector-pseudo-element-colon-notation: "double"
selector-pseudo-element-no-unknown: true
SelectorDepth
selector-max-compound-selectors: 5
SelectorFormat # Not always followed; ssb-whatsapp_app
custom-property-pattern: "^([a-z][a-z0-9]*)(-[a-z0-9]+)*$"
selector-class-pattern: "^([a-z][a-z0-9]*)(-[a-z0-9]+)*$"
Shorthand
shorthand-property-no-redundant-values: true
SingleLinePerProperty
"@stylistic/declaration-block-semicolon-newline-after": always-multi-line
SingleLinePerSelector
@stylistic/selector-list-comma-newline-after": always
SpaceAfterComma
"@stylistic/value-list-comma-space-after": always
SpaceAfterPropertyColon
"@stylistic/declaration-colon-space-after": always-single-line
SpaceAfterPropertyName
"@stylistic/declaration-colon-space-before": never
SpaceAfterVariableName
scss/dollar-variable-colon-space-before: never
SpaceAroundOperator
scss/operator-no-unspaced: true
SpaceBeforeBrace
@stylistic/block-opening-brace-space-before: always
SpaceBetweenParens
"@stylistic/function-parentheses-space-inside": never
"@stylistic/selector-attribute-brackets-space-inside": never
"@stylistic/selector-pseudo-class-parentheses-space-inside": never
"@stylistic/media-feature-parentheses-space-inside": never
StringQuotes
"@stylistic/string-quotes": double
TrailingSemicolon
"@stylistic/declaration-block-trailing-semicolon": always
TrailingWhitespace # Note it was enabled by the gem and not by us
"@stylistic/no-eol-whitespace": true
TrailingZero
"@stylistic/number-no-trailing-zeros": true
UnnecessaryMantissa
"@stylistic/number-no-trailing-zeros": true
UnnecessaryParentReference
scss/selector-no-redundant-nesting-selector: true
UrlQuotes
function-url-quotes: always
VendorPrefixes
value-no-vendor-prefix: true
selector-no-vendor-prefix: true
property-no-vendor-prefix: true
at-rule-no-vendor-prefix: true
media-feature-name-no-vendor-prefix: true
ZeroUnit:
length-zero-no-unit: true
Although the gem is called jquery-fileupload-rails, the node package is
called blueimp-file-upload.
Note we're using the same version as provided by the gem.
The jquery-fileupload gem provided a `basic.js` file (which we were
requiring), which had the following content:
```
//= require jquery-fileupload/vendor/jquery.ui.widget
//= require jquery-fileupload/jquery.iframe-transport
//= require jquery-fileupload/jquery.fileupload
``
This file isn't available in the Node.js package, so we're adapting its
contents in our application.js file. Since we're already requiring
jQuery UI widget, we're omitting that line.
These browsers are very old, we don't support them, and, combined, their
usage is about 0.1%. We're still supporting IE 11 through the "last 1
version" option and many versions of Android and ios through the "last 7
years" option.
Thanks to this change, we no longer generate prefixes in flexbox
properties, making debugging in the browser easier. There are no
significant differences in the size of the compiled CSS in production
environments, though (with these changes, the file is about 2% smaller).
We're upgrading to this version in order because it's the first version
that works with our current version of execjs when running the
`autoprefixer:info` task. Since it's been such a long time since the
last time we upgraded autoprefixer-rails (version 8.2.0, which is the
version we were using, was released on March 2018), and we're getting a
warning when compiling the assets with the latest version, we're going
to do it gradually; version 10.2.5.1 was released on May 2021, so it
also seems like a reasonable middlepoint.
Note we're moving the `browserlist` file to `.browserlistrc` because
that's the expected locations in new versions of autoprefixer-rails.
Also note that we're changing this file so we support browsers released
in the last 7 years, so we still support more or less the same browsers
we supported before this change (about 98% of the browsers out there).
We might reduce it to 5 years in the future.
Bumps [autoprefixer-rails](https://github.com/ai/autoprefixer-rails) from 8.2.0 to 10.2.5.1
- [Changelog](https://github.com/ai/autoprefixer-rails/blob/master/CHANGELOG.md)
- [Commits](https://github.com/ai/autoprefixer-rails/compare/8.2.0...10.2.5.1
Since Foundation hasn't released a new gem for years, we haven't been
able to upgrade Foundation to its most recent version.
Thanks to this change, we'll be able to do so.
Note we're using motion-ui version 2.0.3 because version 2.0.5 (the
latest at the moment) requires Dart Sass.
While people using screen readers already have keyboard shortcuts to
jump to the <main> tag, there are people who navigate the page with the
keyboard using just the tab key, and for them, this link provides a way
to save time and start reading the main content instead of having to
manually go through all the navigation links every time a new page is
loaded.
Note that we had to add an additional `width: 0` rule because
Foundation's `element-invisible` would apply `1px` and the test checking
for `visible: :hidden` would faile.
We were displaying documents in five places, and in five different ways.
Sometimes with the metadata in parenthesis after the title, sometimes
with the metadata below the title, sometimes without metadata, sometimes
with an icon in front of the document, and sometimes with a separate
link to download the file.
So we're now displaying the same thing everywhere. Not sure whether this
is the best solution, but at least it's consistent.
We aren't unifying the way we display a list of documents, though, since
different sections look pretty different and I'm not sure whether the
same style would look well everywhere.
Note that we're renaming the `document` HTML class in the documents
table to `document-row` so the styles for the `document` class don't
apply here.
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
Using the `document` or `documents` classes meant styles defined for the
public list of documents conflict with these ones.
So now we're using HTML classes that match the name of the Ruby
component classes, as we usually do.
We added the feature to undo a vote and made it obvious for people using
screen readers using the `aria-pressed` attribute. However, for sighted
people, the only way to know a button can be unpressed is to try to
press it again and see what happens.
The most obvious way to indicate it would be to add a text indicating
that you can undo your vote. However, that'd require changing the design
quite a bit.
So, after trying a few techniques, we're using a classic approach
browsers have used by default for years: using an inset border for
pressed buttons and an outset border for unpressed ones. It might now be
enough, though; we haven't done usability tests to confirm this point.
Since icons to like/unlike comments don't have a border, I'm not sure
what to do in this case; the icons are small and that makes it hard to
style them in a distinct way. So for now we're not changing these icons.
Since we were styling pressed buttons the same way as buttons on hover,
a person hovering on the button and then clicking it wouldn't notice
that the buttons had been pressed unless they noticed that the number
and percentages of votes had changes. They wouldn't notice the changes
when unpressing the buttons either, since, after clicking the button,
the cursor would still be over it, and so the hover styles would apply.
Furthermore, it was hard for mouse users to realize that a button could
be unpressed, since the style of pressed buttons didn't change on hover.
So we're now changing the icons on hover without changing the
background. This way all four states (unpressed, unpressed on hover,
pressed, pressed on hover) are styled in a different way.
The colors we were using (gray for unpressed buttons and green or red
for pressed buttons) didn't contrast well against a white background, so
we're now using darker colors.
However, with darker colors, using solid icons for the unpressed buttons
makes it harder to differentiate when a button is pressed and when it
isn't, particularly for color-blind people.
So we're now using regular icons for the unpressed buttons and solid
icons for the pressed ones.
We were using the same selectors three times. Since we're going to
change that part of the code, we're simplifying it so we don't have to
do the same changes three times.
Other packages depend on jQuery, so that's why these are the first one
we move from the Gemfile to the package.json file.
This way we can also test whether dependabot correctly opens pull
requests to update Node packages.
I've tried several configuration options for the asset pipeline in order
to be able to include images referenced in jQuery UI CSS files. So far,
adding the `node_modules/jquery-ui/themes/base` folder to the assets
paths is the only way I've found to make it work. Hopefully we can find
a better solution in the future so we don't have to study the internals
of every Node package in order to integrate it with the assets pipeline.
This way we make it easier to modify.
Note that, since the title of the page is "Administration" and it's in
the "Admin" section, we're adding an option to the `header` method in
order to avoid having a confusing title like "Administration - Admin".
Also note that, by removing the `title` HTML class, we avoid inheriting
styles from the `dashboard.scss` stylesheet, and now the heading is
displayed in the position it was meant to.
Finally, the concept of using a `main-class` for the current page comes
from a branch (currently in development) which will replace the <div>
tag with the `admin-content` class with a `main` tag.
We were displaying the alt text using the same color as the background
color, which made it impossible to read it when the logo didn't load
(for whatever reason).
Using the same color as the text, like done in the admin section, solves
the issue.
The color we were using didn't have enough contrast against a white
background, which made it harder to read texts like "Remove map marker"
or "Erase my account".
Since the new color is almost identical to the color we were using on
hover and for the border, we're changing the color on hover as well,
while IMHO it's no longer necessary to use a different color for the
border.
The Web Content Accessibility Guidelines version 2.1 added a success
criterion called Non-text Contrast [1], which mentions that the focus
indicator must contrast with the background, and version 2.2 introduced
a specific one regarding focus appearance [2]. According to that
criterion, the focus indicator:
* is at least as large as the area of a 2 CSS pixel thick perimeter of
the unfocused component or sub-component
* has a contrast ratio of at least 3:1 between the same pixels in the
focused and unfocused states.
Our current solution for highlighting elements on focus has a couple of
issues:
* It doesn't offer enough contrast against the default white background
(1.6:1)
* It offers even less contrast against other backgrounds, like the
homepage banner or the featured proposals/debates
Making the color of the outline darker would increase the contrast
against these backgrounds, but it would reduce the contrast against
other backgrounds like our default brand color.
For this reason, most modern browsers use a special double outline with
two different colors [3], and we're choosing to combine an outline and a
box shadow to emulate it, using the brand color as the second color.
However, this double-colored outline doesn't work so well when focusing
on dark buttons surrounded by a light background, so instead we're using
a triple outline, which works well on any color combination [4]. Since I
feel that making the third outline 2px wide makes the overall outline
too wide, I'm making the inner outline just 1px wide since that's enough
to prevent edge cases.
Note that Foundation adds a transition for the `box-shadow` property on
`select` controls, which gets in the way of the focus we use on the
language selector. So we're removing the transition.
Also note that the box-shadow style didn't work properly with the
box-shadow we added on the `:hover` status on cards, so we're changing
the code in order to cover this case.
Finally, note that the box-shadow isn't displayed properly on multiline
links (in Chrome, not even with `box-decoration-break: clone`), like the
ones in debates/proposals/polls/investments/processes titles, so we're
changing the style of these links to `inline-block`.
[1] https://www.w3.org/TR/WCAG21/#non-text-contrast
[2] https://www.w3.org/TR/WCAG22/#focus-appearance
[3] https://www.sarasoueidan.com/blog/focus-indicators/#examining-(current)-browser-focus-indicators-against-wcag-requirements
[4] https://www.erikkroes.nl/blog/the-universal-focus-state/
In some cases, like SDG icons and the proposals map, the image was
bigger than the link containing it, resulting in a funny-looking outline
on focus.
For reasons I don't understand, using `&:active,&:focus:active` didn't
compile to the CSS I was expecting, so I'm repeating the same code for
these two separate cases.
The outline was invisible when we had the link containing block
elements, and I didn't manage to fix it, so the easiest solution is to
use an inline link and style the card with CSS.
This way it's going to be easier to style the link on focus, since
styles like `box-shadow` weren't working properly when we had an inline
link with block elements inside, and adding the `display: inline-block`
element to the link didn't play well with the layout we were using for
the recommendations.
We're also fixing the focus outline on recommendations, which didn't
look properly because of the border added with:
```
.recommended-index {
// (...)
@include full-width-border(top, 1px solid #fafafa);
}
```
The border was on top of the outline, breaking it. Increasing the
`z-index` of the element containing the outline solves the issue.
In a similar way, we're making sure the button to hide recommendations
stays visible so it's easier to click it.
In order to reduce the code used to add styles to the buttons,
we removed the classes that had been added and handled it with
the new aria-pressed attribute
Internet Explorer 8 was released in 2009 and people using it already
know that most web pages look broken on it, so we don't need to warn
them.
Removing it makes our application layout file much easier to read and
modify.
It was obvious which project the comment was about. Also, no point
having a TODO referencing what to do after upgrading to Rails 5.1, since
we did it years ago.
