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.
Allow enabling from settings admin section.
Note that we set the z-index to 20 in order to will be greater than
the others z-index elements in the application like <header> on
mobile devices.
With this change, on my browser, reloading a page in development after
changing a CSS file is about 25% faster than simply splitting the CSS
code between `application.css` and `vendored.css`. Compared to using
only one `application.css` file containing everything, reloading a page
in development is about 35% faster.
The combined size of all the generated stylesheets is now about 0.5%
bigger. Not sure why (maybe placeholder selectors?), but the difference
is negligible.
Note that we could load the `administration.css` file only in the admin
area, reducing the size of the page for people accessing the public
area. However, the size of this stylesheet (compressed) is 28K, which is
less than 3% of the overall size of a page and, on the other hand,
there's a risk of some styles no longer being applied because we might
have overlooked the fact that some styles in the `administration.css`
are also applied to the public area.
So, for now, we're still loading the administration styles in the public
area. We might reconsider in the future.
With this change, on my browser, reloading a page in development after
changing a CSS file is about 10%-15% faster.
On the minus side, this change results in an extra request when browsing
the page; AFAIK it isn't that big of a deal, even when the server isn't
using HTTP/2.
We're using the `aria-label` attribute instead of a label because this
is a page where only one field is rendered and the text of the label is
the same as the text of the <h1> tag.
We're using `aria-label` instead of `aria-labelledby` because the former
is supported by Capybara.
In order for this attribute to be applied, due to the syntax of the
`select` method, it should be in a separate hash.
We're removing it instead of correctly applying it because we never use
the `tabindex` attribute with a positive value, since it might break
keyboard navigation.
We reduce code duplication thanks to that, and make it easier
to change this field.
Note that there was one place where the "16.years" value was
hardcoded. We're moving the test for this case to the
component and changing it so the test doesn't use the default
age.
We're also removing the redundant helper method that had the
same code as a method in the User class which is called
everywhere else.
Since the main stats index loads this JavaScript using
`"data-turbolinks-track" => "reload"`, going from the stats index to a
section that doesn't include this JavaScript did the strange effect
Turbolinks does in these situations: it first loaded the page using an
AJAX request and, after getting the contents of the page, it reloaded it
in order to apply the changes in the included JavaScript.
This behavior was a bit confusing, particularly when browsing to a
section of the admin stats, clicking the browser's back button to go
back to the stats index, the going to another section, ...
One of the admin stats tests was failing sometimes with this message:
```
1) Stats Budget investments Supporting phase Number of users and
supports in investment projects
Failure/Error: raise ex, cause: cause
Selenium::WebDriver::Error::UnknownError:
unknown error: unhandled inspector error:
{"code":-32000,"message":"Node with given id does not belong to the document"}
(Session info: chrome=129.0.6668.89)
```
This was probably caused by the mentioned Turbolinks behavior that loads
the page twice. It's possible that Selenium was somehow checking the
node related to the first request when the second request had finished.
Avoiding that double request solves the issue.
This way it'll be easier for people using screen readers to know which
element the checkbox is related to.
Note that we're using the `aria-label` attribute because it makes
testing with Capybara easier than using the `aria-labelledby` attribute.
The only exception are the comments, since comments don't have a title
and there isn't a proper label for them. In this case, we're using the
title of the associated commentable as the label; we might change it in
the future since there might be many comments for the same commentable.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Since we're adding styles for this button, we're also adding the
`font-size` property instead of using the `small` class. We'll deal with
the `float-right` property in the next commit.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commit,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Note that we're changing the component so it uses `polymorphic_path`;
that way we don't have to pass the `@budget` variable to the component.
We could also use `budget_investment_path investment.budget, investment`
instead.
Using a checkbox wasn't very intuitive because checkboxes are
checked/unchecked when clicked on even if there's an error in the
request. Usually, when checkboxes appear on a form, they don't send any
information to the server unless we click a button to send the form.
So we're using a switch instead of a checkbox, like we did to
enable/disable phases in commit 46d8bc4f0.
Note that, since we've got two switches that match the default
`dom_id(record) .toggle-switch` selector, we need to find a way to
differentiate them. We're adding the `form_class` option for that.
Also note that we're now using a separate action and removing the
JavaScript in the `update` action which assumed that AJAX requests to
this action were always related to updating the `visible_to_valuators`
attribute.
Just like it happened with proposals, the button to select/deselect an
investment wasn't very intuitive; for example, it wasn't obvious that
pressing a button saying "selected" would deselect the investment.
So we're using a switch control, like we do to enable/disable features
since commit fabe97e50.
Note that we're making the text of the switch smaller than in other
places because the text in the investments table it is also smaller
(we're using `font-size: inherit` for that purpose). That made the
button look weird because we were using rems instead of ems for the
width of the button, so we're adjusting that as well.
Also note we're changing the width of the switch to `6em` instead of
`6.25em` (which would be 100px if 1em is 16px). We're doing so because
we used 100 for the minimum width because it's a round number, so
now we're using another round number.
We don't need to replace the whole row, since the changes only affect
the button. Therefore, we don't need to depend on an `inserted` event to
decide which columns to render in that row.
