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.
We've deprecated the "icons" font since we started using Font Awesome
two years ago and using it caused some screen readers to announce an "l"
before the content of every list item.
Since we're going to reuse this pattern in other forms, we shouldn't
rely on the header having just one element. There could be a subtitle.
So we're changing the CSS to be less dependent on a very specific HTML
structure.
Regarding the subtitle, the original idea was to have both an <h1> and
an <h2> element inside the header. However, the W3C advices against it
[1]:
> h1–h6 elements must not be used to markup subheadings, subtitles,
> alternative titles and taglines unless intended to be the heading for
> a new section or subsection.
So we ended up including the subtitle inside he <h1>. We could also add
it in a separate <p> tag. However, in this case I think it's better to
include it in the <h1> (and in the <title> tag) because it helps to
uniquely identify the current page from other pages.
Due to some rounding issues in Firefox, we're manually moving the polygon
6px so there isn't a blank space between it and the icon on the right.
And due to rounding issues in Chrome, we're adding one extra pixel to
the bottom of the polygon defining the clip-path.
[1] https://www.w3.org/TR/html52/common-idioms-without-dedicated-elements.html#common-idioms-without-dedicated-elements
So we don't add the same lines to pretty much every stylesheet we
create.
Eventually we'll remove this code and add a padding to every <main>
element, or (even better) to the <body> element itself.
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.
The `icon-budget` hasn't been used in this context for a long time;
maybe since commit d0b8fef6b.
The `document-form` class was removed in commit 6c1d828a6.
Finally, the `topic-new` and `topic-form` were removed in commit
c887cb736.
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.
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.
Although most CONSUL installation don't enable the translation
interface, we're adding some code to take this case into account.
