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.
Since the top-bar already includes a layout positioning the elements,
these classes are redundant and actually confusing, since the element
floating to the right was on the left.
This solves a problem where the outline wasn't correctly displayed when
focusing on the logo using the keyboard. Firefox was displaying two
vertical lines together above the logo, while recent Chrome versions
displayed the outline to the right of the logo.
The elements were given a minimum width of `rem-calc(240)` (that is,
15rem). Considering one element is double the width of the other one,
that means that in screens between 40rem and 45rem there would be a
horizontal scrollbar.
Adding a `flex-wrap: wrap` property fixes the problem. We're also using
`flex-basis` to guarantee a minimum width and make one element be double
the size of the other one when they're on the same line. No need to add
breakpoint rules due.
Finally, we're adding an artifitial gap between flex elements so we can
remove the `@include grid-col` rules.
In the case of the public layout, the row element was originally there
so the content of the top links had a maximum width. Since now the body
has that maximum width, we no longer need the row element.
In the other layouts I guess the row elements were added because there
were float elements inside them. We can use a flexbox layout instead and
these elements are no longer necessary. This also makes the layout more
robust when there isn't enough space on one line for both the language
selector and the external links.
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`. 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).
These element had no columns inside and the row classes had only been
added to give them a maximum width. That's no longer necessary since now
the body has that maximum width.
We were using these rules in order to set the maximum width of an
element to `$global-width`. However, since we now do so in the <body>
element, there's no need to apply these rules to "rows".
Note we're adding `overflow: hidden` to the budget subheader. That's
because it only contains `float` element inside, and we're now missing
the `.row::before` and `.row::after` rules which make sure float
elements are rendered properly.
We weren't using a global maximum width for the <body> element because
we wanted the background of some elements to cover the whole screen. If
the body didn't cover the whole screen, then we would have to find a way
to extend the background beyond the limits of the body.
Elements can take the whole screen width using a width of 100 viewport
width (vw) units, which weren't as widely supported when CONSUL
development started as they are today.
However, there's a gotcha will vw units; they don't take into account
the vertical scrollbars browsers add when scroll is needed. That means
that an element with a width of 100vw would cause a *horizontal*
scrollbar when the vertical scrollbar appears on the screen. So
approaches like this one wouldn't work:
```
body {
margin-left: auto;
margin-right: auto;
max-width: $global-width;
}
@mixin full-background-width {
&::before {
margin-left: calc(50% - 50vw);
margin-right: calc(50% - 50vw);
}
}
```
We could add `overflow-x: hidden` to the body to avoid the horizontal
scrollbar. However, on certain screens sizes that could cause some
content to disappear if there isn't enough horizontal space for all the
elements.
If we tried some other solution based on using `max-width` with `margin:
auto` on the <body> element, it would result in a body having a fixed
width and a variable margin (depending on whether there's a scrollbar).
So it wouldn't be possible to set a negative margin on child elements
based on the margin of the body, because that margin would be different
depending on the existence of a scrollbar.
So, instead, we're adding a fixed margin to the body, which depends on
the viewport width and the font size of the <html> element. With this
approach, when a vertical scrollbar appears, the margin of the <body> is
still the same; what changes is its width. That means we can set a
negative margin on child elements based on the margin of the <body>. No
horizontal scrollbar will appear.
Note we're slightly duplicating the code by using two variables
(`$body-margin` and `$full-width-margin`) to do the same thing. We could
simply use `$body-margin` and then use `calc(-1 * #{$body-margin})` in
our `full-width-background` mixin. We aren't doing so because some old
versions of the Android browser and Internet Explorer can't handle this
operation. Since our whole layout is based on these properties, in this
case supporting old browsers is quite important.
For similar reasons we're using a breakpoint instead of using the
`max()` function like: `Max(0px, calc(50vw - #{$global-width / 2}))`. At
the time of writing, `max()` is only supported in about 91% of the
browsers.
With this change, we no longer need to add `row` elements to make sure
we don't exceed the maximum width; the <body> element takes care of
that.
Also note banners sometimes have a full background and sometimes they
don't, depending on which page they appear. We're adding specific rules
for them.
Finally, the code for full width borders is a bit brittle; sometimes we
want the border to cover an element, and sometimes we don't. For
example, we had to slightly change the way the border of the "tabs" in
legislation processes is rendered. Without these changes, the borders
wouldn't overlap as we intended. We also had to add a `z-index` to
navigation links so their bottom outline is visible when they're
focused. The recommendations have a border with the same color as the
background so it's painted on top of the border of the `help-header`
section.
As mentioned in commit 5214d89c8, using the `change` event of a `select`
field to automatically change location is really annoying for keyboard
users, since the event will trigger when pressing the down key to
navigate through the options or when typing a key to start searching for
an option. This might cause a lot of frustration.
Most multilanguage CONSUL sites enable between 2 and 4 languages. In
these cases, it's easier to just display the list of languages to
simplify the selection.
This way in this situation we also make it clear which languages are
available. If we use a `<select>` tag, users will have to open it in
order to check whether the site is available in their preferred
language.
This is also useful when the current language uses characters users
don't recognize; users will recognize their own language in the list of
available languages, while it might be harder to recognize the language
selector allows them to switch to a different language.
In this case, we're also hiding the label because a list of links with
language names is usually self explanatory for sighted users. We're
still providing it for screen reader users so they immediately know the
list allows them to change the language and if they don't need to do so
they can quickly skip it.
I'm not sure screen readers recognize this attribute inside `<option>`
tags, but if they do, it'll probably be helpful. And if they don't, no
harm will be done.
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).
Since we're simplifying the main method, we can use a view file instead
of the `call` method. This way we make the code more consistent with the
rest of our components, since we always use a separate file.
Doing so generates an extra newline at the end of the generated HTML, so
we need to change a couple of tests a little bit.
This way it's easier to refactor it and/or change it.
Back in commit c156621a4 I wrote:
> Generally speaking, I'm not a big fan of helpers, but there are
> methods which IMHO qualify as helpers when (...) many Rails helpers,
> like `tag`, follow these principles.
It's time to modify these criteria a little bit. In some situations,
it's great to have a helper method so it can be easily used in view
(like `link_to`). However, from the maintenance point of view, helper
methods are usually messy because extracting methods requires making
sure there isn't another helper method with that name.
So we can use the best part of these worlds and provide a helper so it
can be easily called from the view, but internally make that helper
render a component and enjoy the advantages associated with using an
isolated Ruby class.
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.
Back in commit 925f04e3f3 from pull request #4206 we wrote about our way
to load SVG icons:
> Using this technique will result in one HTTP request per icon, which
> might affect performance
We considered using CSS with Data URIs, and wrote:
> This method does not generate any extra HTTP requests and only
> downloads the icons we need. However, maintaining it is really hard,
> since we need to manually copy all the <svg> code for every icon we
> use, and do it again every time we upgrade Font Awesome.
Back when I wrote that, I didn't know Sass had a function named
`asset-data-url` which generated Data URIs automatically given a
filename. I searched for it, but somehow I only found Compass helpers
doing a similar thing.
Note we're using CSS variables to reduce the size of the generated CSS.
If we used `mask-image: asset-data-url(...)`, the generated CSS would
include the value returned by `asset-data-url` twice: once for the
`mask-image` property and once for the `-webkit-image` property.
The percentage of browsers supporting `mask-image` and not supporting
CSS variables is really small (less than 1%), so in that regard things
remain more or less the same and unsupported browsers will render the
icons using the `font-family: "Font Awesome 5 Free` property.
After these changes, the size of the generated CSS increases from 475KB
to 533KB. If we didn't use CSS variables, the generated CSS would use
591KB.
We believe this is acceptable because the SVG icons we use are very
small files (about 1-1.5KB big) and, downloaded separately, they also
amount to about 45KB, which is similar to the CSS file increase we get.
Using `asset-data-url` we download them in one request instead of having
one request per file (about 35 extra requests).
We forgot to include this property when replacing our use of `%fa-icon`,
and it was causing the admin menu to have a blank space at the bottom.
So we're including it again to make sure nothing else breaks because of
this omition.
In commit 4d49ec8ef we replaced an `@extend .fa-` clause with a
`content: fa-content()` clause.
With the `@extend` clause, the `content:` property appeared wherever the
`.fa-` selector was defined, so we later overwrote it in our `%svg-icon`
selector, which was defined later in the generated CSS.
Defining the property with `content: fa-content()`, on the other hand,
caused the `content:` property to appear wherever we used the mixin with
`@include has-fa-icon`. That meant our `%svg-icon` selector would appear
before it, and would not overwrite it.
We could modify a few things and make the code more complicate in order
to avoid that. In this case, however, it's easier to add an `!important`
flag; after all, it is indeed important that SVG icons have no content
so screen readers don't try to announce illegible characters.
