As mentioned in commit 5214d89c8, there are several issues with
submitting a form when a `<select>` tag changes. In particular, keyboard
users might accidentally fire the event while browsing the options, and
screen reader users will find a form with no obvious way to submit it.
In this case, there's an extra problem: in commit be8a0dbe8 we added a
second `<select>` field to this form, which also submitted on change.
Sometimes users changed one of the values and wanted to change the other
value as well before submitting the form. However, it wasn't possible,
because we would submit it before they had a chance to change the second
value.
So now we don't submit the form on change and add a submit button. This
is similar to what we do in the "Advanced filters" we use in several
places.
Using `inherit` is IMHO more expressive since it means "use the color of
the parent element".
This is particularly useful for CONSUL installations using custom
styles. Consider the following code:
```
h2 {
color: $white;
a {
color: $white;
}
}
```
If we'd like to customize the way headings look, we'd have to override
two colors:
```
h2 {
color: $red;
a {
color: $red;
}
}
```
Consider the scenario where we use `inherit`:
```
h2 {
color: $white;
a {
color: inherit;
}
}
```
Now we only need to override one color to change the styles:
```
h2 {
color: $red;
}
```
Using the same color as text made it impossible to visually recognize
the link. Users might click the link accidentally while trying to select
the text of that link.
Furthermore, sighted keyboard users would be surprised when tabbing
through the interface and realizing some apparently normal text is
really a link.
Since commit dcec003d0 we're only using the menu-text class in the admin
layouts. So instead of defining styles for menu-text and then
overwriting them in the admin section, we can define them just in the
admin section.
Since we don't have <img> tags in the menu-text element in the admin
section, we can remove their styles. And we can also remove the styles
we were overriding twice (like `line-height`).
These styles aren't necessary since commit aabf8493f. Now the "Go back"
link in the budgets section can use the same color as in the other
sections, while the other texts inherit the usual colors.
Now that we load this file before loading the `_settings.scss` file, we
can safely use the `!default` flag.
This makes it easier to override these variables by adding a new file
and loading it before `_consul_settings.scss` is loaded. For instance,
we've got this code related to the `$brand` variable:
```
$brand: #004a83 !default;
$brand-secondary: darken($brand, 10%) !default;
$dark: $brand-secondary !default;
$link: $brand !default;
$debates: $brand !default;
$tooltip-background-color: $brand !default;
```
If we override `$brand` in `_custom_settings.scss`, variables like
`$link` won't be affected by this change. In order to do so, we'd need
to load `_custom_settings.scss` before loading `_consul_settings.scss`.
So why aren't we loading `_custom_settings.scss` first, just like we
load `_consul_settings.scss` before loading `_settings.scss`? Mainly,
compatibility reasons. Some people might have this code in their
`_custom_settings.scss` file:
```
$dark: darken($brand, 30%);
```
If we load this file before loading `_consul_settings.scss`, we'll get
an error because `$brand` isn't defined at this point.
So we're introducing a new file where variables can be overriden before
they are defined while keeping the option to override them after they
are defined.
We're updating the comments in these files to define the new behavior,
and removing the links (which point to places which don't exist since
commit 392d633d2) in order to make it easier to read the comments.
We were overriding these values because the `$body-font-family` and
`$global-radius` variables were defined after the values in the
`_settings.scss` file had been computed.
Now these values are defined before the values in the `_settings.scss`
are computed, so we don't need to override the values which depend on
them anymore.
We were loading all Foundation variables and then overriding them. This
is problematic because we were overriding variables after using them.
For instance, we had this code in `_settings.scss`:
```
$black: #0a0a0a;
$white: #fefefe;
$body-background: $white;
$body-font-color: $black;
```
That meant we were setting `$body-background` to `#fefefe`, and
`$body-font-color` to `#0a0a0a`. Even if we changed the values of
`$black` and `$white` later, `$body-background` and `$body-font-color`
were not affected by this change.
So now we're overriding `$black` and `$white` before setting
`$body-background` and `$body-font-color`. In order to keep our custom
values instead of overriding them, we're using the `!default` flag in
the `_settings.scss` file.
This way of defining variables in the `_settings.scss` file with the
`!default` flag is recommended in the documentation regarding the
settings file [1].
There's also a disadvantage to this approach. Now that we're loading the
`_consul_settings.scss` file first, we can no longer use Foundation
variables inside the `_consul_settings.scss` file unless we define them
in this file as well.
[1] https://get.foundation/sites/docs/sass.html#the-settings-file
Since we were using `position: absolute` to position the button to the
right, we were assuming there was enough screen space on the left so
other elements (mainly, order selector links) could be there.
However, that wasn't always the case. In some languages, the texts
appearing on the left of the button were much larger than in English,
meaning their text and the button text could overlap. Even in English,
users could experience the same issue depending on their font size
preferences and the size of their screens.
The easiest solution is to move the button to its own line, so its text
doesn't overlap.
Since forms are landmarks, screen reader users might navigate to the
form. But then they were going to find an empty form with no way to
toggle it.
Moving the button inside the form means screen reader users navigating
to the form will find the button to toggle it.
It also helps us simplifying the code; there's no need to use
data-attributes to communicate whether the form should be visible since
now we can easily use the button `aria-expanded` attribute.
We could further simplify the JavaScript if we used a CSS rule to
show/hide the form fields based on the toggle button `aria-expanded`
attribute. However, implementing the "slide" animation we use when
toggling the form with CSS is difficult and unreliable.
We were using the form and then showing it with JavaScript when advanced
search terms were present. Now we hide it with JavaScript when no
advanced search are present. This means users without JavaScript
(including users with JavaScript enabled but bad internet connections
preventing the JavaScript to load) can now access the form.
The other main difference between the two versions is the way the form
flashes while JavaScript is loading.
Previously, the form would always be hidden when no terms had been
introduced. However, when these terms were present, after submitting the
form it would briefly be hidden and then shown again.
Now the opposite happens. When advanced search terms are present, the
form is shown at all times. However, when they aren't, the form is
briefly shown before it disappears.
Here the previous behavior is arguably better because most of the time
these terms will not be present.
So basically we're significantly improving the experience of some users
at the cost of slightly worsen the experience of other users.
We're also hiding the button to show the form when JavaScript is
disabled, since in this scenario it's useless. We're using the `hidden`
attribute so hidden buttons can be detected in CSS.
I guess it was there to make a contrast with the CSS used for the
version for medium and large screens. However, it isn't necessary and
the absence of this property already makes a contrast with the presence
of the property for medium and large screens.
Users (particularly, screen reader users) usually identify links with
things that take you somewhere, and buttons with things that either send
forms or change things on the page.
Using a button we can also use the `aria-expanded` attribute, meaning
screen reader users will know that the button has two states ("expanded"
and "collapsed"), the current state of the button, and will get
immediate feedback when clicking the button because the new state of the
button will be announced.
Thanks to this change, we can also slightly simplify the code; we
obviously have to remove the (useless) `href` attribute, and we don't
have to prevent the default event in JavaScript since there's no default
event for buttons with `type="button"`.
Add link_url presence validation only when link_text is provided only for header cards.
In this case it makes sense to allow creating a "header card" without link_url, since
we can show the header without link text and without link url and it still does its
function.
Currently it is not necessary to include the link_url field.
When we display these cards without link_url, they create an empty link that
redirects to the same page. I understand that this is not a desired behavior, so I
think it is better to add a validation in this case and force administrators to add a
link_url when creating a card.
As mentioned in the previous commits, a `<select>` field which submits
its form on change causes many accessibility and usability issues, so
we're replacing it with the order links we use everywhere else.
Since the links "Id" and "Title" by themselves don't have enough
information to let users know they're used to sort by ID or title, we
have to update them somehow. We could add a "Sort by:" prefix before the
list of links (and associate it with the `aria-labelledby` attribute);
however, we don't do this anywhere else and might look weird depending
on the screen size.
So we're simply adding "Sort by" before each link.
Now that we don't use the `wide_order_selector` partial anymore, we can
remove it alongside the styles for the `select-order` class.
