When render the investment list component with the link "see all
investments", now we redirect to groups index page when a budget has
multiple headings.
The budget header was supposed to be huge, but only in the participatory
budgets index or show actions. It was still huge, with plenty of empty
space, when there was no budget, or in the "submit my ballot" and
"select a heading" pages.
The imageable/documentable object is always the object the form builder
is based on; since we're already passing the form builder, we don't have
to pass the object as well.
The only exception are the poll answers. In this case, we're passing a
new answer as the object. That's OK; the same hack that we're using to
send the data to the answer URL without displaying existing attachments
causes the form to keep working the same way.
In commit 49b406199 we added an extra `<span>` element just so we could
add an icon to the right while maintaining both the title and subtitle
on the left.
We can do the same thing without the extra `<span>` element, absolutely
positioning the element and leaving enough padding.
We had an additional `<div>` just to add a background color, when we can
do it by applying the background color to the whole `<main>` element and
then the body background color to the optional fields.
However, I've decided not to do so. The main purpose of changing the
background color is to highlight the required fields. The benefits of
changing the background color of the header as well are unclear. When in
doubt, we're using the solution which requires less code.
Now the padding is only applied in two places (administration forms) so
we can apply it just there instead of applying it everywhere and then
removing it in most places. We're using the `column` class here because
it's what's used in the rest of the fields of these forms and because we
haven't defined (yet) general margin/padding rules for the
administration views.
We don't need any row classes anymore because the <body> already has a
maximum width. As for columns, we only have one column in this form, so
we don't need them either. Besides, the form's parent element already
has a padding.
So they follow the same convention used in proposals.
Note the styles are for elements which appear in the "new" view but not
in the "edit" view, so we only have to include them in one place.
Since now categories are loaded in both the investment form component
and proposal form component, and their controllers are the only
"commentable" controllers using the `@categories` instance variable, we
can remove the `load_categories` call in `CommentableActions` affecting
the create and update actions.
One of them was less wide than the other one.
We're still only adding the heading to the form for the new investment,
just like in the original budgets redesign.
Using `flex` instead of a fixed width for the navigation, the elements
take all the available space when the search form isn't present. That
wasn't the case before and produced a strange effect on medium-sized
screens.
This way we also align the search to the right.
Since the top-bar already includes a layout positioning the elements,
these classes are redundant and actually confusing, since the element
floating to the right was on the left.
This solves a problem where the outline wasn't correctly displayed when
focusing on the logo using the keyboard. Firefox was displaying two
vertical lines together above the logo, while recent Chrome versions
displayed the outline to the right of the logo.
In the case of the public layout, the row element was originally there
so the content of the top links had a maximum width. Since now the body
has that maximum width, we no longer need the row element.
In the other layouts I guess the row elements were added because there
were float elements inside them. We can use a flexbox layout instead and
these elements are no longer necessary. This also makes the layout more
robust when there isn't enough space on one line for both the language
selector and the external links.
Note we're using `flex-grow: 1` to make one element appear on the left
of the screen and the other one on the right. It would be easier to use
`justify-content: space-between`. However, there's a bug in Internet
Explorer and old versions of Firefox; they include the
absolutely-positioned `::before` element we use to set the full width
background when calculating where to position the elements. The bug was
fixed in Firefox 52 (released in 2017).
These element had no columns inside and the row classes had only been
added to give them a maximum width. That's no longer necessary since now
the body has that maximum width.
Note that in order to simplify the component tests (which for some
reason seem to be whitespace-sensitive), we have to omit whitespace
characters inside the `<option>` tags.
Also note we're simplifying the test with a missing language name; since
a component test doesn't involve a whole request, we don't need a
complex setup (I'm not sure we even need it in system tests).
The `<optgroup>` doesn't make much sense if all options are inside one
group. And the information provided was redundant: when using a select
field having "Language" as a label, it's obvious that the options are
the available languages.
Now that, since now the `<select>` field is smaller, we need to add an
extra padding so the icon doesn't overlap the text.
The language attribute is present in all layouts since commit 025923ac4,
so there's no need to use the language selector locale. Besides, it
wouldn't work if there's only one locale and the language selector isn't
shown.
As mentioned in commit 5214d89c8, using a `<select>` tag which
automatically submits a form on change has a few accessibility issues,
particularly for keyboard users who might accidentally submit the form
while browsing the options.
So we're adding a submit button and removing the "submit on change"
behavior.
Note that, while `<select>` tags have their own usability issues,
alternatives in this case are not obvious because the number of existing
polls could be very low (zero, for instance) or very high (dozens, if
the application has been used for years).
I thought of using a `<datalist>` tag with a regular text input. The
problem here is we don't want to send the name of the poll to the server
(as we would with a `<datalist>` tag); we want to send the ID of the
poll.
Maybe we could add an automplete field instead, providing a similar
funcionality. However, for now we're keeping it simple. This poll
questions page isn't even accessible through the admin menu since commit
83e8d603, so right now anything we change here will be pretty much
useless.
The `include_all` parameter was always used, and the option was
redundant because we already had a prompt offering the same
functionality.
I guess one possible reason was users would want to filter by all polls,
and having to click on "select a poll" to do so wasn't that intuitive.
So we're using "All" as the prompt instead.
When we see a list of, let's say, banners, and each one has a link to
edit them, the word "banner" in the text "edit banner" is redundant and
adds noise; even for users with cognitive disabilities, it's obvious
that the "edit" link refers to the banner.
As mentioned in the previous commits, a `<select>` field which submits
its form on change causes many accessibility and usability issues, so
we're replacing it with the order links we use everywhere else.
Since the links "Id" and "Title" by themselves don't have enough
information to let users know they're used to sort by ID or title, we
have to update them somehow. We could add a "Sort by:" prefix before the
list of links (and associate it with the `aria-labelledby` attribute);
however, we don't do this anywhere else and might look weird depending
on the screen size.
So we're simply adding "Sort by" before each link.
Now that we don't use the `wide_order_selector` partial anymore, we can
remove it alongside the styles for the `select-order` class.
A `<select>` tag here might make more sense than in other similar places
since there are 5 options to choose among, and using links might take
too much screen space.
However, as mentioned in the previous commits, `<select>` tags which
automatically submit a form have many accessibility and usability
issues.
An alternative would be to create a dropdown menu with a button and a
list of links (similar to what Foundation does). I'm keeping the links
for simplicity and because the interface looks a bit more consistent
with the rest of the sections. Before these changes, we had a heading,
then a `<select>` field to choose the filter, and then a button to print
the page. We never use a similar interface, and some people might think
the "Print" button is related to the same form as the `<select>` field.
Now that we don't use the `order_selector` partial anywhere anymore, we
can remove it.
We had five almost-identical views. Now we've removed most of the
duplication, although the tables are still similar. We might refactor
them in the future.
In keys like `hide_debates`, the suffix part is redundant when that key
is part of an absoulte key starting with `moderation.debates`.
This change will make it easier to remove duplication in moderation
views.
It was a bit frustrating to click on one of the order elements or the
link to the next page and having to scroll down again until reaching the
comments.
We use order links in many places in the web. However, in the comments
section and the list of community topics, we were displaying a
`<select>` element, and changing the location when users select an
option.
This has several disadvantages.
First, and most important, it's terrible for keyboard users. `<select>`
fields allow using the arrow keys to navigate through their options, and
typing a letter will select the first option starting with that letter.
This will trigger the "change" event and so users will navigate through
a new page while they were probably just checking the available options
[1]. For these reasons, WCAG Success Criterion 3.2.2 [2] states:
> Changing the setting of any user interface component does not
> automatically cause a change of context unless the user has been
> advised of the behavior before using the component.
Second, the form didn't have a submit button. This might confuse screen
reader users, who might not know how that form is supposed to be
submitted.
Finally, dropdowns have usability issues of their own [3], particularly
on mobile phones [4]
The easiest solution is to use the same links we generally use to allow
users select an order, so using them here we make the user experience
more consistent. They offer one disadvantage, though; on small screens
and certain languages, these links might take too much space and not
look that great. This issue affects pretty much every place where we use
order or filter links, so we might revisit it in the future.
Note we're moving the links to order comments after the form to add a
new comment. In my opinion, having an element such as a form to add a
new comment between the element to select the desired order of the
comments and the comments themselves is a bit confusing.
[1] https://webaim.org/techniques/forms/controls#javascript
[2] https://www.w3.org/WAI/WCAG21/Understanding/on-input.html
[3] https://www.youtube.com/watch?v=CUkMCQR4TpY
[4] https://www.lukew.com/ff/entry.asp?1950
