So now it uses the same interface and styles as the main layout. On
small screens, it's easier to play with the menu when the button is on
the left because the menu it opens is aligned to the left.
Note that now we can get rid of the title-bar class; we didn't use the
styles in the public area since commit dcec003d0, and we were overriding
all the Foundation styles in the admin area with the exception of the
padding, which we no longer need.
We're going to change these styles in order to fix a bug, and the
Foundation styles were getting in the way. Besides, we were overwriting
some rules and so now we're removing 6 properties while we're also
adding 6, so it isn't like the Foundation styles were helping us.
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 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
While Foundations's off-canvas menu allows us to forget about writing
CSS, it also leads to complicated HTML.
Ideally Foundation would provide an easy way to simplify what we're
doing, but I haven't found anything in the documentation.
We could simplify the HTML a bit more if we used a CSS grid layout
instead of a flex one, but old browsers have better support for the
latter.
Note we're using `breakpoint(medium)` so we can group the CSS for small
screens and follow SCSS-Lint rules at the same time.
Also note behavior of the main area when the menu appears on small
screens is slightly different: it doesn't move the main content to the
right. I've done it this way so we don't have any overflow issues,
unlike the previous version.
There's a small issue using a label and a checkbox to enable/disable the
menu: sighted keyboard users with a small screen might not be able to
enable the menu. So we're adding the `:focus-within` pseudoclass so the
menu can be normally navigated using the keyboard. Even if old browsers
don't support this pseudoclass, we believe the probability of a sighted
user using a small screen, navigating with the keyboard and using an old
browser is really low, particularly in the admin area.
We're also adding the `aria-hidden` attribute on the label, since the
menu is never hidden for screen readers and so having a control to show
it could be confusing. Since the label is not focusable, we're complying
with the fourth ARIA rule:
> Do not use role="presentation" or aria-hidden="true" on a focusable
> element .
>
> Using either of these on a focusable element will result in some users
> focusing on 'nothing'.
