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.
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.
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 using an `@extend` selector inside a `@supports` condition,
which didn't generate the `@supports` clause as we intended to, so
browsers with no support for mask images were still applying properties
which were meant for browsers with support for mask images.
Note we're using an extra `<span>` element but we could use a CSS grid
layout instead. We're not using it because browser compatibility is only
94.56% at the time of writing.
Using the placeholder selector, we weren't overwriting the rules in the
mixin called with `@include` in some cases because in the generated CSS
the placeholder selector appeared before the code generated by the calls
to `@include`.
Since we were defining the selection to have the same text color and
background color as the element they were in, it resulted in the
selection being invisible.
It wasn't that noticeable because we were using this color combination
mainly in links and buttons, and selecting their text is not as common.
But we plan to use the `$brand` color on budget headers as well, and
this issue is more obvious there.
Browsers like Chrome weren't that affected because they automatically
make the selection semi-transparent and so the selected text still had a
slightly different color. In order to prevent this effect when the
selection is white, we're using a 0.99 opacity (in this case Chrome
ignores numbers higher that 0.998).
Setting the color to `$white` or `#fff` while setting the background to
`$brand` is a pattern we were using in many places. Since we're going to
edit it in order to fix the `::selection` behavior, we're defining the
pattern in one place.
One file was OK when we only had a couple of mixins, but recently we've
been adding quite a few.
We can now avoid a SCSS Lint warning by excluding just the file with the
affected mixin.
