This way, when the language is written form right-to-left, elements
using Foundation mixins/classes will float to the opposite direction as
they do in left-to-right languages. The same will apply to text
alignment.
To offer full support for RTL languages, we need to change every single
reference to `float: left`, `float: right`, `text-align: left`,
`text-align: right`, and possible adjust other properties like `left`,
`margin-left`, `padding-left` or `border-left`. In the meantime, we at
least partially support these languages.
Replacing `float` with `flex` when possible would also improve RTL
support.
This way the code is easier to follow; the code checking whether the
list has contents is in the partial rendering the list.
We also remove some duplication setting up related content in the
controllers.
For some reason, we have to manually ignore i18n keys which were
automatically ignored when the code was in the view.
Note we're using the `call` method (which is equivalent to adding an ERB
file) because we were getting an error calling `render` from the `dates`
method:
```
ActionView::Base#lookup_context delegated to
view_renderer.lookup_context, but view_renderer is nil:
```
It might be because we aren't rendering the
`Adming::Budgets::DurationComponent` but just calling one method, and so
there's no view context in this case.
Since PostgreSQL doesn't guarantee the order of the records unless an
`ORDER BY` clause is used, the records sometimes had a different order.
This might cause records being present in more than one page.
One test was failing sometimes (when the record created first was
rendered after the record created last) because there seems to be a bug
in chrome/chromedriver 83 and later which causes links not to be clicked
when they're right at the edge of the screen (which was the case for the
notification appearing in the last place):
```
1) System Emails Preview Pending #moderate_pending
Failure/Error: click_on "Moderate notification send"
Selenium::WebDriver::Error::ElementNotInteractableError:
element not interactable: element has zero size
(Session info: headless chrome=91.0.4472.114)
```
We don't need to use `block_given?` since we specifically pass the block
parameter, particularly since we added the Style/ExplicitBlockArgument
rule in commit a102f3f0a.
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.
Our previous system to delete cached attachments didn't work for
documents because the `custom_hash_data` is different for files created
from a file and files created from cached attachments.
When creating a document attachment, the name of the file is taken into
account to calculate the hash. Let's say the original file name is
"logo.pdf", and the generated hash is "123456". The cached attachment
will be "123456.pdf", so the generated hash using the cached attachment
will be something different, like "28af3". So the file that will be
removed will be "28af3.pdf", and not "123456.pdf", which will still be
present.
Furthermore, there are times where users choose a file and then they
close the browser or go to a different page. In those cases, we weren't
deleting the cached attachments either.
So we're adding a rake task to delete these files once a day. This way
we can simplify the logic we were using to destroy cached attachments.
Note there's related a bug in documents: when editing a record (for
example, a proposal), if the title of the document changes, its hash
changes, and so it will be impossible to generate a link to that
document. Changing the way this hash is generated is not an option
because it would break links to existing files. We'll try to fix it when
moving to Active Storage.
In commit cc6f9391f we made the images and documents file inputs
invisible (instead of using `display: none`) in order to make it
possible to attach images and documents using the keyboard.
However, since the error messages associated to these inputs has the
same HTML class as the inputs, we were also hiding them (the `display:
none` didn't affect the error messages because they've also got the
`is-visible` class).
Using the `[type=file]` selector we make it more explicit that we only
want to style these inputs.
I'm not adding a test for this scenario because technically the text is
there and I'm not sure how to test for the presence of invisible
elements.
We introduced a bug in commit acbd1b023.
When editing a record and removing an existing image, we don't remove
the HTML fields associated with that image but simply hide them, and
then we add fields to create a new image when clicking on "Add image".
This is standard cocoon behavior. However, since in the case of images
there's a `has_one` relation, cocoon doesn't add unique identifiers to
the new fields, generating duplicate IDs, which is invalid HTML.
Since there's a duplicate file input ID, clicking on the "Choose image"
label we aren't clicking on the new input but on the old one. This means
we aren't correctly attaching an image. The tests passed because
Capybara uses the equivalent of a keyboard to select the field, and in
this case everything worked properly.
So we need to delete the existing elements before inserting new ones.
We're adding a test to check there aren't duplicate IDs.
We were hiding the file input and styling the label as a button instead.
Since clicking on a label has the same effect as clicking on the input,
the input worked properly for mouse and touch screen users.
However, hiding the input makes it inaccessible for keyboard users,
since labels don't get keyboard focus, but inputs do.
So we must not hide the input but make it invisible instead. But we
still need to hide the input (alongside the label) after a file has been
attached.
We could add some extra JavaScript to hide the input when we hide the
label. Since the JavaScript is already quite complex and my first few
attempts at changing it failed, I've opted to assume that the input (and
its label) must be hidden whenever there's already a file name, and
implement that rule with CSS.
Note we're using the `:focus-within` pseudoclass to style a label when
focus is on the input. This rule (at the time of writing) is only
supported by 93.5% of the browsers. Keyboard users without a screen
reader and using the other 6.5% of the browsers will still be able to
focus on the field but might not notice the field has received focus.
Since the percentage of affected users will decrease over time and until
now 100% of keyboard users were completely unable to focus on these
fields, for now we think this is a good-enough solution.
We were already defining the links with data-remote and data-method, so
instead of manually doing an AJAX request we can rely on Rails to
perform the request and then handle the `ajax:complete` event.
This way screen reader users will hear the name of the file before
hearing about the link to destroy it. We were already displaying it this
way visually by having the file name on the left and the destroy link on
the right.
Thanks to this change we can also simplify the code which dynamically
changed the layout.
Since elements are created and destroyed, we don't have to do any kind
of "reset" before destroying or creating them. We would have to do so if
we were just hiding the elements in order to show them again later, but
that's not the case.
Using `dom_id` means generating `new_document` as ID for new documents.
Since there might be more than one new document in the form, that means
duplicate IDs, which is invalid HTML.
Even though this issue doesn't affect image fields (because we don't
have many images on the same form), we're removing the ID there as well
for consistency.
These labels weren't associated with any fields, which is invalid HTML.
We're using a legend inside a fieldset instead, which is the natural way
to group form fields together.
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.
We were using long, unique names because these methods used to be helper
methods. Helper methods should have unique names because otherwise one
method would overwrite the other.
Now that we're using components, we can omit the `image_` and
`document_` prefixes.
