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.
Not all the colors initialjs uses by default provide enough contrast
against a white text. The default initialjs colors are:
["#1abc9c", "#16a085", "#f1c40f", "#f39c12", "#2ecc71", "#27ae60",
"#e67e22", "#d35400", "#3498db", "#2980b9", "#e74c3c", "#c0392b",
"#9b59b6", "#8e44ad", "#bdc3c7", "#34495e", "#2c3e50", "#95a5a6",
"#7f8c8d", "#ec87bf", "#d870ad", "#f69785", "#9ba37e", "#b49255",
"#b49255", "#a94136"]
We're replacing them with colors containing less luminosity when
necessary in order to get a 4,5:1 contrast (it could be argued that a
3:1 contrast is enough when the icons are big, but that isn't always the
case and more contrast doesn't hurt):
["#16836d", "#12826c", "#896f06", "#a06608", "#1e8549", "#1e8549",
"#b35e14", "#c75000", "#207ab6", "#2779b0", "#de2f1b", "#c0392b",
"#9b59b6", "#8e44ad", "#6c767f", "#34495e", "#2c3e50", "#66797a",
"#697677", "#d82286", "#c93b8e", "#db310f", "#727755", "#8a6f3d",
"#8a6f3d", "#a94136"]
Since initialjs doesn't provide a way to change these colors using
JavaScript, we're changing them in Ruby, following the same algorithm
used by initialjs.
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.
As far as possible I think the code is clearer if we use CRUD actions
rather than custom actions. This will make it easier to add the action
to remove votes in the next commit.
Note that we are adding this line as we need to validate it that a vote
can be created on a comment by the current user:
```authorize! :create, Vote.new(voter: current_user, votable: @comment)```
We have done it this way and not with the following code as you might
expect, as this way two votes are created instead of one.
```load_and_authorize_resource through: :comment, through_association: :votes_for```
This line tries to load the resource @comment and through the association
"votes_for" it tries to create a new vote associated to that debate.
Therefore a vote is created when trying to authorise the resource and
then another one in the create action, when calling @comment.vote.
As far as possible I think the code is clearer if we use CRUD actions
rather than custom actions. This will make it easier to add the action
to remove votes in the next commit.
Note that we are adding this line as we need to validate it that a vote
can be created on a debate by the current user:
```authorize! :create, Vote.new(voter: current_user, votable: @debate)```
We have done it this way and not with the following code as you might
expect, as this way two votes are created instead of one.
```load_and_authorize_resource through: :debate, through_association: :votes_for```
This line tries to load the resource @debate and through the association
"votes_for" it tries to create a new vote associated to that debate.
Therefore a vote is created when trying to authorise the resource and
then another one in the create action, when calling @debate.vote_by (which
is called by @debate.register_vote).
In this commit, we have performed a refactoring to enhance code organization.
Several partials that were solely responsible for rendering components have been removed.
Instead, we are now directly rendering the components within the views where these
partials were previously used.
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
Previously the condition was needed because _without it_ the Admin::Poll::Questions::Answers::ImagesController would have resulted in settings? evaluating to true. This was undesired because that controller was scoped under Polls, so only polls? should have evaluated to true. Now that we have moved the images link to the customization menu, this check is not necessary anymore.
There were already some menu items to customization pages under the "Site content" menu. It therefore makes sense to move "Custom images" and "Custom content blocks" (which were previously
located under "Settings") to "Site content" as well.
This syntax has been added in Ruby 3.1.
Not using a variable name might not be very descriptive, but it's just
as descriptive as using "block" as a variable name. Using just `&` we
get the same amount of information than using `&block`: that we're
passing a block.
We're still using `&action` in `around_action` methods because here we
aren't using a generic name for the variable, so (at least for now) we
aren't running this cop on controllers using `around_action`.
We were getting a warning since upgrading to Rails 6.1:
DEPRECATION WARNING: Calling `delete` to an ActiveModel::Errors messages
hash is deprecated. Please call `ActiveModel::Errors#delete` instead.
So we're deleting the error instead of deleting the message.
We were getting a warning in one of the tests:
DEPRECATION WARNING: Rendering actions with '.' in the name is
deprecated: application/nonExistentJavaScript.js
I haven't found a case where the behavior on production environments is
different due to this change; the application seems to behave the same
way as it used to. So I'm not adding tests for this change.
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.
This rule was added in rubocop 1.44.0. It's useful to avoid accidental
`unless !condition` clauses.
Note we aren't replacing `unless zero?` with `if nonzero?` because we
never use `nonzero?`; using it sounds like `if !zero?`.
Replacing `unless any?` with `if none?` is only consistent if we also replace
`unless present?` with `if blank?`, so we're also adding this case. For
consistency, we're also replacing `unless blank?` with `if present?`.
We're also simplifying code dealing with `> 0` conditions in order to
make the code (hopefully) easier to understand.
Also for consistency, we're enabling the `Style/InverseMethods` rule,
which follows a similar idea.
We originally added the `cached_votes_up > 0` in commit 4ce95e273
because back then `cached_votes_up` was used in the denominator. That's
no longer the case, and it doesn't make sense to mark a debate with 1
vote and 10 flags as conflictive but not doing it when the debate has no
votes and 1000 flags.
We're fixing the bug right now because we're about to change the
affected line in order to apply a new rubocop rule.
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
