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.
The float property was removed in commit b71c61e40, but then it was
added again in commit 4a6313fed.
It might have been necessary to do so back then because we had a
`select` field instead of the links to set the order, but now, instead
of making them float on the left and then make the next element clear
the floats, we can do nothing and obtain the same results.
Note that, unlike what we did in the admin section we're opening links
to budget investments on the same tab. There are two reasons for it; the
first one is that, in this case, there are no filters in the moderation
section that are lost after editing an investment, and the second one is
that, in this context, administrators usually don't go to the investment
in order to edit it, so they can just check something and use the
browser's back button to go back.
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.
Sanitizing descriptions before saving a record has a few drawbacks:
1. It makes the application rely on data being safe in the database. If
somehow dangerous data enters the database, the application will be
vulnerable to XSS attacks
2. It makes the code complicated
3. It isn't backwards compatible; if we decide to disallow a certain
HTML tag in the future, we'd need to sanitize existing data.
On the other hand, sanitizing the data in the view means we don't need
to triple-check dangerous HTML has already been stripped when we see the
method `auto_link_already_sanitized_html`, since now every time we use
it we sanitize the text in the same line we call this method.
We could also sanitize the data twice, both when saving to the database
and when displaying values in the view. However, doing so wouldn't make
the application safer, since we sanitize text introduced through
textarea fields but we don't sanitize text introduced through input
fields.
Finally, we could also overwrite the `description` method so it
sanitizes the text. But we're already introducing Globalize which
overwrites that method, and overwriting it again is a bit too confusing
in my humble opinion. It can also lead to hard-to-debug behaviour.
