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.
As mentioned in commit 5214d89c8, using a `<select>` tag which
automatically submits a form on change has a few accessibility issues,
particularly for keyboard users who might accidentally submit the form
while browsing the options.
So we're adding a submit button and removing the "submit on change"
behavior.
Note that, while `<select>` tags have their own usability issues,
alternatives in this case are not obvious because the number of existing
polls could be very low (zero, for instance) or very high (dozens, if
the application has been used for years).
I thought of using a `<datalist>` tag with a regular text input. The
problem here is we don't want to send the name of the poll to the server
(as we would with a `<datalist>` tag); we want to send the ID of the
poll.
Maybe we could add an automplete field instead, providing a similar
funcionality. However, for now we're keeping it simple. This poll
questions page isn't even accessible through the admin menu since commit
83e8d603, so right now anything we change here will be pretty much
useless.
There are two bugs in Internet Explorer which caused our footer to be
rendered incorrectly.
First, the `flex: 1` property doesn't work so well when `flex-direction`
is set to `column`. We're replacing it with `flex-grow: 1`. No need to
set other `flex-basis` nor `flex-shrink` in this case since in this case
the default values will work just fine.
Second, it didn't handle the body height being set to `100%` so well,
and the footer was rendered after that 100% point, even if the content
still continued.
So we're using `min-height` instead, which is actually a bit more
accurate (since the body is usually taller than the document root
element). This causes a different issue since on IE the `flex-grow: 1`
property becomes useless. This will only affect IE users with very large
screens, though, and it's way better than rendering the footer
overlapping the main content, so we can live with that. The page won't
look as great as in other browser, but it will still be usable.
This way it's possible to customize these colors by just changing a
variable.
The code is now quite a bit hacky; since I'm not an expert in color
design, I didn't want to change the colors we were using in case it made
the application have less appeal.
If slightly changing these colors isn't a problem, we could use
Foundation's defaults to simplify the code, maybe just changing the
`$table-color-scale` variable.
We're using `background: #fff` and `background: $white` in many places.
Sometimes we mean "use the same background as the body", which means if
we change the body background so it's, let's say, dark, we'll also have
to change all these places.
So now we're using `$body-background` in more places, so changing the
general background color is easier.
There are still some places where we use `#fff` or `$white`. Sometimes
it's hard to tell whether the intention is "use a white background here"
or "use the same background as the body here". When in doubt, I've left
it the way it was.
Just for testing purposes, I've tested locally how things would look
like if we added this code to `_consul_custom_overrides.scss`:
```
$body-background: #fea;
$card-background: $body-background;
$tab-background: $body-background;
$tab-content-background: $body-background;
$table-background: $body-background;
```
Or:
```
$body-background: #333;
$text: #fcfcfc;
$body-font-color: $text;
$card-background: $body-background;
$tab-background: $body-background;
$tab-content-background: $body-background;
$table-background: $body-background;
```
Testing shows we've still got a long way to go to make it easy to add
custom color themes, since there are many custom colors in the code.
Hopefully these changes bring us one step closer.
These elements already inherit these background colors form their parent
elements. Defining them explicitly makes it harder to change them and it
also makes it harder to customize the styles in other CONSUL
installations.
The `include_all` parameter was always used, and the option was
redundant because we already had a prompt offering the same
functionality.
I guess one possible reason was users would want to filter by all polls,
and having to click on "select a poll" to do so wasn't that intuitive.
So we're using "All" as the prompt instead.
We were using Font Awesome fonts and selectors to support the browsers
which don't support mask images (at the time of writing, about 5% of the
browsers). However, we were only importing the selectors in order to
extend them. This resulted in our compiled CSS including styles for
every Font Awesome icon (currenty, more than a thousand), even if we
only use a few of them.
So we're using Font Awesome variables instead of using the selectors it
provides. Since variables are only compiled in the CSS if they're
actually used, this reduces the size of our compiled CSS considerably.
In production environments, the size is reduced from 539KB to 475KB,
meaning we reduce its size in about 12%.
The downside here is we can't easily use Font Awesome variables in our
Sass mixins because we can't use interpolation in variable names (that
is, we can't use `$fa-var-#{icon}`). So we're using a map containing all
Font Awesome variables in order to access it in the mixin.
Note installations using `.fa-*` selectors will now have to add extra
`@import` clauses.
We were defining campaigns with `let`. That meant they weren't created
until these methods were used in the tests.
For the test "Do not track erroneous track_ids", that meant the line
`expect(page).not_to have_content campaign2.name.to_s` wasn't really
testing anything, since before this line is executed, the campaign2
wasn't in the database at all, and so obviously its name wouldn't be on
the stats page.
For the test "Track email templates", it meant we were creating the
campaign2 record after visiting the campaign1 page with the browser.
Creating records in the tests after starting the browser might be the
reason why this test has recenty failed in our CI [1]:
1) Email campaigns Track email templates
Failure/Error: ds.add params[:event].titleize, Ahoy::Event.where(
name: params[:event]).group_by_day(:time).count
ActiveRecord::StatementInvalid:
PG::ProtocolViolation: ERROR: bind message supplies 0
parameters, but prepared statement "" requires 1
# ./app/controllers/admin/api/stats_controller.rb:13:in `show'
Using `let!` to create the campaings before the browser starts improves
the situation.
[1] https://github.com/consul/consul/runs/2952333023
The word "budget" in the "Preview budget" link is redundant.
On the other hand, the words "Manage", Edit" and "Admin" are not
really necessary in my humble opinion. Just like in the admin
navigation menu we use "Participatory budgets" instead of "Manage
Participatory budgets", the fact that we're going to manage or
admin or edit something can be deduced from the fact that we're in
the admin section.
Besides, it isn't clear to me why we use "Manage" for projects,
"Edit" for heading groups and "Admin" for ballots. The differences
between these three concepts might be too subtle for me.
The previous paragraphs haven't been corroborated with real users,
though, so I might be mistaken and we might need to revisit these
links in the future.
These actions still take quite a lot of space. Maybe in the future we
could remove the "delete" icon, at least on budgets which cannot be
deleted.
When we see a list of, let's say, banners, and each one has a link to
edit them, the word "banner" in the text "edit banner" is redundant and
adds noise; even for users with cognitive disabilities, it's obvious
that the "edit" link refers to the banner.
In commit 9794ffbbf, we replaced "buttons" with icons in order to make
the admin interface consistent with the planned budget investments
redesign.
However, using icons has some issues. For once, icons like a trash for
the "delete" action might be obvious, but other icons like "confirm
moderation" or "send pending" might be a bit confusing.
It's true that we were adding tooltips on hover. We tried two
approaches: using Foundation's tooltips and using CSS tooltips.
Foundation tooltips are not activated on focus (only on hover), while
CSS tooltips always appear below the icon, which might be a problem when
the icons are at the bottom of the screen (one of our milestone tests
was failing because of that and we can now run it with JavaScript
enabled).
Both Foundation and CSS tooltips have other issues:
* They force users to make an extra step and move the mouse over the
link just to know what the link is about
* They aren't available on touch screens, so these users will have to
memorize what each icon does
* They are not hoverable, and making them hoverable would cause a
different issue because the tooltip might cover links below it, making
it impossible to click these links without moving the mouse away
first
* They are not dismissable, which is considered an accessibility issue
and a requirement in the Web Content Accessibility Guidelines [1]
For all these reasons, we're using both texts and icons. As Thomas
Byttebier said "The best icon is a text label [2]". Heydon Pickering
also makes a point towards providing text alongside icons in his book
"Inclusive Components" [3].
Note that, since we're now adding text and some of the colors we use for
actions are hard to read against a white/gray background, we're making a
few colors darker.
With these changes, actions take more space in the admin table compared
to the space they took in version 1.3, but they are more usable and
accessible while they still take less space than they did in version
1.2.
[1] https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus
[2] https://thomasbyttebier.be/blog/the-best-icon-is-a-text-label
[3] https://inclusive-components.design/tooltips-toggletips/
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 `currentcolor` is IMHO more expressive, since it shows the
intention of styling the border with the same color as the text.
This is particularly useful for CONSUL installations using custom
styles. Consider the following code:
```
.is-active {
border: 1px solid $brand;
color: $brand;
}
```
If we'd like to customize the way active items look, we'd have to
override two colors:
```
.is-active {
border: 1px solid $brand-secondary;
color: $brand-secondary;
}
```
Consider the scenario where we use `currentcolor` (which is the default
border color):
```
.is-active {
border: 1px solid;
color: $brand;
}
```
Now we only need to override one color to change the styles:
```
.is-active {
color: $brand-secondary;
}
```
Since we are using the same color as the text color in both the public
and admin areas, we can omit the border color completely. Since now
admin elements get the exact same border, we can remove this border so
they'll inherit the same border as used in the public area.
Since we're only changing the style of the border in one case and the
color in the other case, we don't have to duplicate the code for every
property.
This makes it easier for other CONSUL installations to customize these
borders.
By default Foundation uses a `#1779ba transparent transparent`
transparent border. We were overriding the whole border, when we only
needed to override the top border. Furthermore, we were overriding it
twice: once in the public area and once in the admin area. However, if
we use `currentcolor`, we only have to override it once, and in both
cases the border will have the same color as the text surrounding it
(white in the public area and black in the admin area).
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.
