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.
There were some issues using `.budget.expanded`, like a link having that
class which would force us to a `:not(.button)` selector or similar,
making the CSS more complex.
Since we've changed the facebook and twitter login icons, it makes sense
to use the same icons in social share links.
Besides, using font-awesome simplifies the code and prevents problems
with screen readers announcing the value of the `content:` CSS property.
We were using the icon for google plus, which was confusing since google
plus no longer exists.
Note this change requires changing the font for these icons, since the
google icon is not present in the "icons" font. On the plus side, using
the font awesome icons we can simplify the code a little bit.
We were using a custom icon because in the past social-share-button
didn't have support for whatsapp. But now that it does, we can remove
our custom icon.
Note we're using the `_app` suffix because that's the name of the icon
meant for mobile devices.
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.
There are no links inside a figure-card, so these styles didn't affect
any elements.
There are also no elements with `.title`, and the h3 inherits the white
color automatically form the figcaption.
On the other hand, the .see-all link is not inside an element with a
`card` class since commit fae52274a.
The default behavior for headings is to inherit the color, even in the
`:hover` style, and IMHO we can keep it this way, particularly in the
cards, which is the main place where we use headings inside links.
We're using the translation fallbacks for the icons, just like we do for
texts.
Note we use the `render?` method provided by view_component to make sure
the component will not be rendered when certain features are disabled.
Also note the `find_asset` method works differently in development and
production, and so we use different approaches here.
We were jumping from h1 to h3 and some of these sections (cards and
processes) had h3 tags inside them.
My best guess is we were using h3 so the titles were smaller. So I'm
adding a CSS mixin to easily use a font size of a different heading tag.
They were all following the same format.
Note we need to group the `see_all` translation keys together (the same
way it's done with the `most_active` keys) so we don't have an unused
translation warning.
We're also moving the "see all" link in processes outside the feed
content; the same way it's done in debates and proposals and removing
unnecessary classes in the processes feed: the column class is causing
the processes not to be aligned with the debates above them, and the
margin bottom is not needed because the margin of the footer is already
enough.
The <header> tag is a standard HTML tag which can be used in any section
of the page. We were adding the main header styles to all <header> tags
because in the past it was in only <header> tag we used.
That's not the case anymore, so instead of overwriting these styles on
every other <header> tag, modifying the rule so it only selects the main
header makes the code easier to maintain.
We were using a "push" div in order to force the footer to the bottom,
and were using a wrapper with a minimum height and negative margins.
The same thing can be accomplished using flex and making the wrapper
fill the empty space, which in my humble opinion simplifies the code and
makes it easier to follow.
We could further simplify the code by removing the wrapper div or the
footer wrapper, although I'm not sure the benefits overcome potential
inconveniences caused to other institutions who might have custom styles
based on the existence of these wrappers.
In commit a8537f7e1 we added a `height: 100%` rule on links inside
cards, which is great for cards in the "Featured" section of the
homepage. However, the card in the "Open processes" section of the
homepage has as many links inside as open processes, causing its height
to be 300% if there are three processes and so expanding below the
footer.
There are a dozen ways to add an icon used for decoration. Each of them
offers advantages and disadvantages regarding these topics:
* Accessibility
* Ease of use for developers
* Ease of customization for CONSUL installations
* Maintainability
* Resulting file size
* Number of HTTP requests
* Browser support
* Robustness
We were using one of the most common ones: icon fonts. This technique
shines in many of these aspects. However, it misses the most important
one: accessibility. Users who configure their browser to display a
custom font would see "missing character" icons where our icons should
be displayed. Some users have pointed out they use a custom font because
they're dyslexic and webs using icon fonts make it extremely painful for
them [1].
Screen reader users might also be affected, since screen readers might
try to read the UTF-8 character used by the icon (even if it uses a UTF
Private Use Area) and will react to it in inconsistent ways. Since right
now browser support for different techniques to prevent it with CSS
ranges from non-existant (CSS speech module) to limited (use an
alternative text in the `content` property [2]), we've been adding an
HTML element with an `aria-hidden` attribute. However, by doing so the
ease of customizations for CONSUL installations is reduced, since
customizing ERB files is harder than customizing CSS.
Finally, font icons are infamous for not being that robust and
conflicting with UTF settings in certain browsers/devices. Recently Font
Awesome had a bug [3] because they added icons out of the Private Use
Area, and those icons could conflict with other UTF characters.
So, instead of loading Font Awesome icons with a font, we can add them
using their SVG files. There are several ways to do so, and all of them
solve the accessibility and robustness issues we've mentioned, so that
point won't be mentioned from now on.
All these techniques imply having to manually download Font Awesome
icons every time we upgrade Font Awesome, since the `font-awesome-sass`
gem doesn't include the `sprites/` and `svgs/` folders Font Awesome
includes in every release. So, from the maintenance poing of view,
they're all pretty lacking.
Method 1: SVG sprites with inline HTML
We can use SVG files where template icons are defined, like so:
<svg>
<use xlink:href="solid.svg#search"></use>
</svg>
This technique has great browser support and it only generates one HTTP
request for all icons. However, it requires adding <svg> tags in many
views, making it harder to customize for CONSUL installations. For
developers we could reduce the burden by adding a helper for these
icons.
Downloading all the icons just to use one (or a few) might also be
inconvenient, since the total file size of these icons will be up to a
megabyte. To reduce the impact of this issue, we could either minimize
the SVG file, compress it, or generate a file with just the icons we
use. However, generating that custom file would be harder to maintain.
Method 2: CSS with one SVG icon per file
We can use the separate SVG files provided by Font Awesome, like so:
background: url("solid/search.svg");
Or, if we want to add a color to the icon:
backgound: blue;
mask-image: url("solid/search.svg");
Using this technique will result in one HTTP request per icon, which
might affect performance. Browser support is also limited to browsers
supporting mask-image, which at the time of writing is 95% of the
browsers, with the notable exception of Internet Explorer 11.
On the plus side, using CSS makes it easy to customize and (IMHO) easy
to work with on a daily basis.
Method 3: CSS with SVG sprites
We can use the aforementioned sprites provided by Font Awesome and use
them with CSS:
backgound: blue;
mask-image: url("solid.svg#search");
The number of HTTP requests and file size are similar to Method 1, while
browser support, ease of customization and ease of use are similar to
Method 2.
There's one extra gotcha: this method requires doing minor changes to
the files provided by Font Awesome, which means this solution is harder
to maintain, since we'll have to do the same changes every time we
upgrade Font Awesome. Mainly we need to add these changes to every
sprite file:
- <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
+<!--
+This is a modified version of Font Awesome Free regular sprite file.
The icons are exactly as they originally were; the only changes are:
+
+* <symbol> tags have been replaced with <svg> tags and a <style> tag
has been added
+* A <style> tag has been added
+* The style="display:none" attribute of the main <svg> tag has been
removed
+-->
+<svg xmlns="http://www.w3.org/2000/svg">
+ <style>
+ svg svg { display: none }
+ svg svg:target { display: inline }
+ </style>
And then replace every <symbol> tag with a <svg> tag.
Method 4: CSS with Data URI
Finally, we can write the icons directly in the CSS:
backgound: blue;
mask-image: url('data:image/svg+xml;utf8,<svg...');
This method does not generate any extra HTTP requests and only downloads
the icons we need. However, maintaining it is really hard, since we need
to manually copy all the <svg> code for every icon we use, and do it
again every time we upgrade Font Awesome.
In this commit, we implement Method 2. To improve browser support, we're
falling back to font icons on browsers which don't support mask images.
So 5% of the browsers might still conflict with users changing the fonts
or with screen readers trying to announce the icon character. We believe
this is acceptable; the other option for these browsers would be to show
those icons as a background image, meaning the icons would always be
black, meaning users of these browsers would have trouble to distinguish
them if the background was dark as well.
Since we aren't sure whether the performance hit of having one HTTP
request per icon is overcome by only requesting the icons we actually
use, we aren't taking this factor into account when choosing between
methods 2 and 3. We believe this method will be the less painful one to
maintain and customize. Generating SVG sprites with just the icons we
use would increase performance, but it would make it harder for existing
CONSUL installations to use icons we haven't included in the sprites.
[1] https://speakerdeck.com/ninjanails/death-to-icon-fonts
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/content#Browser_compatibility
[3] https://blog.fontawesome.com/fixing-a-unicode-bug-in-5-14-0/
We were using `display: inline` assuming that's the way elements will be
displayed by default when shown. However, those elements could be
displayed in a different way (inline-flex, for instance). So we avoid
any possible conflicts by using the `display: none` rule when we want to
hide the elements.
Besides, the code is now symmetrical and IMHO easier to follow.
Even if "r" is shorter, "regular" is easier to understand, and we're
going to store these icons in a folder named "regular", which is the
convention Font Awesome uses.
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'.
This way we can simplify the HTML and easily apply font awesome icons to
any element.
Note the mixin uses `extend`, which we generally try to avoid. It's OK
in this case, since `fa-` classes only have one rule, affecting the
content of its `::before` pseudo-element. Unfortunately we can't use
`include fa-content($fa-var-#{$icon})` because it's not valid SCSS. We
could make the mixin accept an icon instead of an icon name, and call it
using `has-fa-icon(r, $fa-var-plus-square)`. However, IMHO that would
make the code a bit more complex with no real benefit.
The JavaScript involved wasn't working since we removed the disable-date
attribute in commit 73ff6881.
We're also improving the JavaScript in two ways:
First, we trigger the `change` event immediately, so when the page loads
date fields are disabled when phases are disabled.
And second, we don't remove the selected dates when disabling a phase,
so disabling it and enabling it again will keep the selected values.
Banners created through the admin form were getting the default color.
However, banners created by other means (like the `db:dev_seed` rake
task) were not getting these default values.
This feature was originally implemented when we were using Rails 4.
With Rails 5, we can provide default values to all new banners and
simplify the code at the same time thanks to its `attribute` method.
Now, when creating a new banner, instead of getting a blank space, we
get an empty line with the banner's default background color, which most
users won't know what it's about until they fill in the banner's title.
So we're not displaying the content of the banner when it's empty,
thanks to the `:empty` CSS pseudoclass.
In some sections we had negative top margins to compensate the header
bottom margin. However, when adding a banner between the header and
those sections, the negative margin caused the content of those sections
to overlap with the content of the banner.
Removing the negative margins when a banner is present solves the issue.
