This way we fix a bug we mentioned in commit 930bb753c which caused
links to documents to be broken when editing their title because the
title was used to generate the URL of the document.
Note we're still using Paperclip to render cached attachments because
this is the only case where we store files with just Paperclip and not
Active Storage.
With Active Storage, we render attachments just like any other resource,
using `polymorphic_path`. Paperclip included the `url` method in the
model; since the model doesn't have access to the request parameters
(like the host), this was inconvenient because it wasn't possible to
generate absolute URLs with Paperclip.
In order to simplify the code and make it similar to the way we used
Paperclip, we're adding a `variant` method accepting the name of a
variant and returning the variant.
We were using the same logic six times regarding when we should show a
"participation not allowed" message. Since we're going to change the
current behavior, we're unifying the logic in one place so the changes
will be easier.
The "Sign in" or "My account" links and the main navigation are
different elements, and they're in different places on medium and large
screens. Now we're also separating them on small screens.
Since the `.vertical` class in the menu added quite a few styles and it
was difficult to overwrite them, we're simply removing this class from
this element. This way we're also removing the huge space between the
menu button and the first element of the navigation.
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.
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 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 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
Using `<a>` tags with no `href` means these elements cannot be activated
by keyboard users, so we're replacing them with buttons.
In the future we probably want to add more consistency so all toggle
buttons use the same code. We might also add styles depending on the
`aria-expanded` property.
This help page can only be accessed from either the help page or the forms.
There is no button in the navigation bar related to this page.
For this reason we do not mark any section of the navigation bar as active
when we are on this page..
We were using a custom icon because in the past social-share-button
didn't have support for whatsapp. But now that it does, we can remove
our custom icon.
Note we're using the `_app` suffix because that's the name of the icon
meant for mobile devices.
Note this rule does still allow us to add new lines after opening tags;
it just makes sure that if we do, we also add it in closing tags.
Likewise, if we don't add it in the opening tag, it forces us not to add
it in the closing tag either.
I don't have a strong preference about either style; in these cases I've
chosen the latter because it seemed more common in our code.
On commit 1a902a96 we removed this helper to make use of polymorphic
routes but when it's called for Legislation::Proposal fails as the
namespace does not match the model namespace.
Now we recover the removed helper but only the parts that do not work
with polymorphic_url helper.
Co-Authored-By: Javi Martín <javim@elretirao.net>
When a proposal had geozones, it was a bit strange to have a list of
tags, then a list of SDGs, and then another list of tags. So we're
changing the order a bit.
This way we'll be able to add targets as well. Besides, having two
classes in the CSS selector will allows to overwrite styles such as
`.debate-show ul li`.
On the other hand, we need to add a stylesheet for the filters as well.
This way we won't have to add the `inline-block` and `no-bullet` classes
to other elements and we can define the styles in one place.
Note we're using the `ul.tags` selector instead of just `.tags` to avoid
conflicts with a `div.tags` selector which is used to select tags in a
form. Renaming the selector to `.tag-list` would be better, but we
aren't doing so because it would break custom stylesheets using that
selector.
Also note we're keeping the %tags placeholder selector in `.tags`
selector in the participation.scss file. This is so styles are not
overwritten by selectors like `.debate-show ul li`, which has the same
specifity as `ul.tags li`.
Now the banner component accepts either a banner or a section and loads
the banner if it's a section, so we don't have to add the `@banners`
variable in several controllers.
We can use the current path as URL instead of passing it every time.
Passing the `page: 1` parameter is also redundant since by default the
index goes to the first page and the search form does not send any page
parameter.
We're using the translation fallbacks for the icons, just like we do for
texts.
Note we use the `render?` method provided by view_component to make sure
the component will not be rendered when certain features are disabled.
Also note the `find_asset` method works differently in development and
production, and so we use different approaches here.
We forgot to make this change when we started using "resolve" to
generate polymorphic nested resources.
The taggables_path method can be replaced with the polymorphic_path of a
class. It even works with nested resources, given the current page
already has the nested resources params (in this case, `budget_id` for
investments).
The main obstacle to extract this partial was probably the paths for the
flag and unflag actions.
Now that we use Rails 5.1 `resolve` method to handle nested resources,
we can use `polymorphic_path`.
Also note the code is a bit ugly because comments render a divider. We
should probably use a CSS border instead.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
The number of errors in a form includes several errors for the same
field. For example, if a title is mandatory and has to have at least 5
characters, leaving the title blank will result in two errors. So users
will be invited to look for two errors, but they'll only find one field
with errors.
So it's a bit more intuitive to show as many errors as fields having
errors.
Note we're excluding errors on `:base`, which is a bit of a hack for
errors in association fields. For example, if the title of one
translation is not present, `resource.errors.messages` will contain two
elements: one for the translation's title, and one for the `base` field.
This resulted in the count of errors being 2 when there was only one.
Also note I haven't found a way to count errors on all `has_many`
relations. That is, if two translations have a missing title field, only
one error will be mentioned in the message (as it did before this
commit).
Using `sanitize` we make sure the `href` attribute does not execute any
dangerous code. The possibility of a banner pointing to a dangerous URL
was very reduced, though, since only administrators can edit this
attribute.
