We don't need any row classes anymore because the <body> already has a
maximum width. As for columns, we only have one column in this form, so
we don't need them either. Besides, the form's parent element already
has a padding.
We forgot to include this property when replacing our use of `%fa-icon`,
and it was causing the admin menu to have a blank space at the bottom.
So we're including it again to make sure nothing else breaks because of
this omition.
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.
So other institutions customizing CONSUL can organize their custom code
as they wish to.
We're also updating the comments in the `custom.scss` file, since it was
referencing files which no longer exist.
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.
Now it's easier to change the investments filter. Previously we had to
go back to the budget index page, change the filter there, and then
select one heading.
Now the links to change the current filter in the budget index page
aren't needed anymore.
This way we won't have to add the `inline-block` and `no-bullet` classes
to other elements and we can define the styles in one place.
Note we're using the `ul.tags` selector instead of just `.tags` to avoid
conflicts with a `div.tags` selector which is used to select tags in a
form. Renaming the selector to `.tag-list` would be better, but we
aren't doing so because it would break custom stylesheets using that
selector.
Also note we're keeping the %tags placeholder selector in `.tags`
selector in the participation.scss file. This is so styles are not
overwritten by selectors like `.debate-show ul li`, which has the same
specifity as `ul.tags li`.
This component allows you to add Goals and Targets in a single
input to relate it to any resource.
We use the new added library to render them as tags.
These cards will be displayed in the SDG homepage.
Note there seems to be a strange behavior in cancancan. If we define
these rules:
can :manage, Widget::Card, page_type: "SDG::Phase"
can :manage, Widget::Card
The expected behavior is the first rule will always be ignored because
the second one overwrites it. However, when creating a new card with
`load_and_authorize_resource` will automatically add `page_type:
"SDG::Phase"`.
Similarly, if we do something like:
can :manage, Widget::Card, id: 3
can :manage, Widget::Card
Then the new card will have `3` as an ID.
Maybe upgrading cancancan solves the issue; we haven't tried it. For now
we're defining a different rule when creating widget cards.
In the past we were using some <div> tags surrounding table action
links in order to guarantee these links wouldn't be wider that their
cell's space and wouldn't expand over two lines.
However, while these links didn't expand over two lines, at certain
resolutions the width of their text exceeded the width of the links,
causing part of the text to be outside their borders.
This behavior was also inconsistent: some tables had these <div> tags,
and some tables didn't.
Since we've now introduced the table actions component, the code is more
consistent and we're getting rid of these <div> tags. So now we're again
facing the issue where links could expand over two lines.
Using a flex layout solves this issue and considerably improves the
layout at lower resolutions.
It's known that Foundation Sticky causes some renderization problems
when rendering sticky elements in anchored position.
The problem seems to be that Foundation Sticky is showing the
support box on medium and up devices overlapped with "Share" and
"Community" sidebar boxes when loading proposal page through
Turbolinks and when restoring the page from brwoser history.
Foundation seems to be doing some top property dynamic calculation
(javascript) and is setting top property to `206px` when it should be
`0px`. Notice that this do not happen on page first load (without
Turbolinks). Check foundation/foundation-sites issue 11098.
Another workaround could be to remove sticky feature for bigger that
small devices (medium large xlarge xxlarge).
Check foundation/foundation-sites issue 9892.
We were using a <label> tag with no associated field where a <legend>
tag was more appropriate. With a fieldset, we also make it obvious these
fields are related.
