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.
