Using the name instead of using the name and the price is IMHO more
consistent with the rest of the application, particularly for screen
reader users. Writing texts clicking those links is also easier.
I think the main reason why we used the price as part of the link was so
the clickable area was bigger. We can accomplish the same result with
CSS.
Using flex we don't have to rely on JavaScript to equalize the item.
Besides, we've had problems with JavaScript in the past.
We're also adjusting the width of the elements; previously, even though
we defined a width of 16.666% for each element, only five elements would
be on the same row. It happenend because these elements were styled with
inline-block and the generated HTML contained a newline character
between <li> tags, meaning a space character was introduced between
elements. The width of the mentioned space character wasn't being taken
into account when calculating the width.
Using flex, there's no space character between items and we have to
define the margin between them. We're taking this margin into account
when calculating the width.
Now it's easier to change the investments filter. Previously we had to
go back to the budget index page, change the filter there, and then
select one heading.
Now the links to change the current filter in the budget index page
aren't needed anymore.
Since this PR (Refactor participatory budgets in draft mode #4369) budgets
have a new field "published" to manage whether they are displayed or not. We
update this field in dev_seeds to be able to display budgets on the public page
budgets.
We weren't using the "Feasible" filter anywhere in the
application, and it's hard for users to know the difference between
"Feasible" and "Not unfeasible".
Apart from 'balloting', there are more phases between
'publishing_prices' and 'finished'. So, it doesn't make sense that the
filter 'selected' is only applied to those two. With this change the
filter will be applied as follow:
'not_unfeasible' for phases:
- informing
- accepting
- reviewing
- selecting
- valuating
selected for phases:
- publishing_prices
- balloting
- reviewing_ballots
winners for phases:
- finished
We were defining the same filters in three different controllers. We
were also adding a method in the ApplicationController which only made
sense in the same three controllers.
Since we were using an icon font with no text, screen readers were
announcing things like "Enabled, L", trying to read the icon generated
with CSS.
Using text and replacing it with CSS with an icon solves the problem.
We could also use aria-label, but I prefer using "Yes/No" so the text
can be shown/hidden with CSS. Also useful when using
`save_and_open_page` during tests, since the displayed page will not
have any CSS rules applied.
Out of several existing techniques to hide text [1], we're setting the
font size to 1px in combination with moving the content off-screen
because that way we can override it in the `::before` element.
Just moving the content off-screen has the inconvenient of the content
still being taken into account when calculating the text indentation.
And just using a 1px font would make a 1px-sized square appear when
selecting text, which could confuse users.
[1] https://webaim.org/techniques/css/invisiblecontent/
Using 10000px means content will be visible on screens with ultra-high
resolution (although I don't think they exist nor will exist anytime
soon).
Having screens in the future with a width of 1000rem is less likely,
since a line with 1000 characters would be pretty much impossible to
read.
We're going to change it a bit, and using a component allows us to use
the `header` method and easily add a title to this page, which lacked
the `<title>` tag.
There was duplication between the index and the show views, and when we
changed the design of the phases in the index we forgot to change the
subheader in the other page as well.
There were some issues using `.budget.expanded`, like a link having that
class which would force us to a `:not(.button)` selector or similar,
making the CSS more complex.
Currently this change is barely beneficial (if at all), but it doesn't
harm and might be useful in some cases. For instance, the `datetime`
attributes generates a date containing time zone information, which the
text shown on the screen does not, and styling dates with CSS is now
easier.
This makes the table easier to identify when writing tests and using
screen readers.
Since we do not render any other table captions anywhere else, we're
making the caption invisible so only screen reader users will be
affected by this change.
Even if the test checked all possibilities, it was hard to understand.
Using `have_table with_cols:` to test the order of the rows and testing
one phase is enabled and has a link to edit it es enough IMHO.
Pronto is an external tool which is use to check code conventions and is
not needed to run the application, just like rubocop or scss-lint.
Loading it caused a couple of issues. First, it loaded BetterHtml, and
we had to disable it in order to avoid crashes in the development
environment.
Second, it loaded ruby-progressbar, which loads the ProgressBar class,
which conflicts with our own ProgressBar class. This made the
application crash whenever the ProgressBar class was used.
These lines were added when we were trying the pronto-eslint_npm gem,
which isn't maintained anymore and is not compatible with the latest
Pronto version.
Since we're now using the pronto-eslint gem, and this gem depends on the
eslintrb gem (which includes ESLint), we don't need these lines anymore.
The pronto-eslint gem depends on the eslintrb gem, which uses a very old
version of ESLint which doesn't support some of the rules we use.
The most useful rules here were no-tabs and func-call-spacing. It's a
shame they were added to ESLint just one month after eslintrb stopped
being maintained.
pronto-eslint depends on eslintrb, which expects the `.eslintrc` file
in JSON format. So we're migrating the `.eslintrc.yml` file to JSON and
introducing a symbolic link so the `.eslintrc` file points to
`.eslintrc.json`.
We could also use pronto-eslint_npm, but unfortunately it's not
maintained anymore and the latest version is not compatible with Pronto
0.11.
