We were using `#fff` in some places and `$white` in others. We're
choosing `#fff` because it has a better contrast against the lighter SDG
colors and because it's the one officially used by the United Nations.
This way we can simplify the code a bit since Foundation automatically
chooses the text color of the caption so there's enough contrast with
the background color defined in `$orbit-caption-background`.
Foundation was using `!global` for non-existing variables, which
generated a warning on our current version of Sass.
This is (mostly) fixed on the latest version of Foundation. However,
this latest version isn't included in the `foundation-rails` gem, so we
can't upgrade yet.
So we're defining these variables before Foundation does so.
See issue 12080 in the foundation/foundation-sites repository for more
information.
When running `scss-lint`, we were getting the following message:
DEPRECATION WARNING: #{} interpolation near operators will be simplified
in a future version of Sass. To preserve the current behavior, use
quotes:
unquote("#{$global-width / 2} - 50vw")
The icons were a bit hard to click on small screens, even for people
without any motion disabilities.
We might increase the size or the space between icons again in the
future; right now it's hard for users with certain motion disabilities
to click on the right icon.
Coincidentally, the minimum size of the icon is now barely over the 44px
established as minimum required size by the WCAG guideline 2.5.5 (level
AAA) [1].
Also coincidentally, at a screen 320px wide (the minimum screen size we
support), six icons appear on each row, just like in the UN logo.
[1] https://www.w3.org/TR/WCAG21/#target-size
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.
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.
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.
Using pixels to define font sizes has an important problem: it ignores
user settings. No matter whether users set their font size to 16px (the
default font size in most browsers), to 18px (like I do) or to 32 px
(like users with huge screens or with a visual disability); the size
will not change.
Even if most browsers can zoom to somehow overcome this issue, it's
still annoying. And, in our case, we use relative units most of the time
but absolute units in some places. This leads to situations where some
of the text gets larger when users increase their font size while some
of the text remains the same. Sometimes this results in titles having a
smaller size than regular text below it.
The solution is using relative units everywhere. Quoting the Web
Accessibility Initiative guide for styles [1]:
> The user needs to be able to resize the text to 200% of its size
> anywhere on the page, without the text being cut off or overlapping
> other text. The font size should be defined in relative units, such as
> percentages, em or rem. It is not possible to zoom text set in pixels
> independently from the rest of the page in some browsers.
[1] https://www.w3.org/WAI/tutorials/page-structure/styling/
Using 10000px means content will be visible on screens with ultra-high
resolution (although I don't think they exist nor will exist anytime
soon).
Having screens in the future with a width of 1000rem is less likely,
since a line with 1000 characters would be pretty much impossible to
read.
The color #fff provides higher contrast, which can cause problems to
users who experience migraines with bright colors or dyslexic users who
might see some kind of shadows around the text because of the bright
color.
So even if it isn't a big improvement, we're slighty reducing the
contrast in order to slightly reduce this problem.
These icons share page with the social media icons (eg: ssb-twitter)
in both the index and the show pages
We believe we gain consistency if all the icons that appear are the
same size.
Pull request 4101 will use this width in social media icons as well.
Render the tags under the input. This way the input is not moved down
when a tag is added.
Render icons under the label. As you can add tags by clicking on the icons,
in this way the input is more related to the icons.
- When we click on an icon we add a new tag with the Goal related to the input or
we remove the tag when that label already exists.
- Manage goals icons status when add or remove related targets:
Whenever there is a tag related to Goal, either the Goal itself or a Target, the icon
will be "checked".
When there is no related Goal or Target it will no longer be marked as checked.
The planned budget investments redesign includes using icons in some
tables, so we might as well use them everywhere.
The original design used Foundation to show the tooltips. We're using
CSS in order to keep the ERB/HTML code simple. One advantage of using
CSS is we can show the tooltip on focus as well, just like accessibility
guidelines recommend [1]. On the other hand, Foundation tooltips appear
on the sides when the link is at the bottom of the page, making sure
they're visible in this case, while CSS tooltips do not. Neither CSS
tooltips nor Foundation tooltips are dismissable, which might be an
accessibility issue.
Note we aren't changing any ERB files in order to replace links with
icons; we're only changing CSS and one line of Ruby code.
[1] https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus
- Added two temporal variables for colors. (Deciding how to call these new variables)
- Replaced hexadecimal with variable
- Remove white space in the html
