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.
We can give the padding to the whole page instead of giving it to
individual elements.
On the minus side, now padding in the SDG pages is not the same as the
padding in the homepage, so we need to add an extra padding to the
participation feeds in only one of these cases.
Instead of adding the padding to each individual element inside the
container, why not adding padding to the container itself? The answer is
"because we want the background of the children elements to take the
width of the whole screen". But this generates either HTML cluttered
with elements to add padding or repetitive padding definitions in the
CSS.
So now we only define the padding once, and when an element requires a
full width background or border, we use the `full-width-background`
mixin.
In this case the code is a bit more complex because the header is also
used in the dashboard and admin layouts:
* In the public layout, the body has a margin, so we include the mixin
to take margin into account
* In the dashboard layout, the header itself has a margin, so we include
the same mixin
* In the admin layout, the headet doesn't have a margin but gets the
whole width, so in this case we include the mixin which dosen't take
the margin into account
In the future, the idea is to apply this principle to the <body>
element and remove the `@include grid-column-gutter` in the CSS as well
as the `small-12 column` classes in the HTML.
Note we use the `calc()` function inside the mixin instead of using it
in the `$full-width-margin` variable. That way we avoid nested `calc()`
operations, which don't work in Internet Explorer.
Also 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` (which is actually the default for
the top-bar element). 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).
Finally, we're removing the padding from our logo. In order to allow
logos like the new one and at the same time provide backwards
compatibility to logos in existing CONSUL installations, we're relaxing
the validation rule for the logo width.
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.
