We're also using a percentage to separate the icons, since using the
viewport width causes strange result on screens where the element
max-width (which is based in rem) is much smaller than the size of the
window.
We were using the classic approach of adding a margin-right property to
all elements except the last one. This works great when all icons are
displayed in one row.
However, when they're displayed in several rows, there could be a
scenario where the last row has more elements:
element1 <margin> element2 <margin>
element3 <margin> element4 <margin> element5
In the example above, `element3` does not fit in the first row because
it's got a margin to its right. However, `element5` fits in the second
row because the last element has now right margin.
One option to fix this issue it using CSS `gap` property. However, at
the time of writing, it's only supported by 70% of the browsers.
So we're emulating the gap by giving a negative margin to the list
equivalent to the margin of the first element.
This idea is based on:
https://coryrylan.com/blog/css-gap-space-with-flexbox
The exception is the index page. Here the list of icons is centered with
`margin: auto`, and so we cannot use negative margins. We're using the
classic approach instead, which is fine because we define there are 6
icons per row.
These icons share page with the social media icons (eg: ssb-twitter)
in both the index and the show pages
We believe we gain consistency if all the icons that appear are the
same size.
Pull request 4101 will use this width in social media icons as well.
Note we're using both the `hidden` and `disabled` properties to
guarantee compatibility with user agents which might still display the
option even when using the `hidden` attribute or hiding it with
`display: none`. We could also use `hide()` and `show()` instead of the
`hidden` property, but since we're using the `disabled` property, I
thought the code would be easier to read if we used properties in both
cases.
Also note users will no longer be able to get, let's say, debates which
are related to goal 1 and target 2.1. We think this use case is highly
unlikely and there's no need to take it into account.
We were doing the same tests three times to test the advanced search
feature. I'm grouping them in one place and shuffling the sections
around to remove duplication and make the test suite faster.
We're going to add some JavaScript which affect this component, and IMHO
it will be easier to know the JavaScript affects this form if both have
their own separate file.
When a proposal had geozones, it was a bit strange to have a list of
tags, then a list of SDGs, and then another list of tags. So we're
changing the order a bit.
This way we'll be able to add targets as well. Besides, having two
classes in the CSS selector will allows to overwrite styles such as
`.debate-show ul li`.
On the other hand, we need to add a stylesheet for the filters as well.
This way we generate the same HTML as we generate everywhere where we
manually generate lists of links. Having a blank space betwwen tags
results in a space being introduced when the elements are displayed
inline (or with `inline-block`).
So in places where we don't want that space between the elements we have
to use a flex layout.
In the spec we added in system/sdg/goals_spec.rb we couldn't use
either click_link or find_link, because the link to show/hide the
long description doesn't have the href attribute.
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`.
Having the date at the beginning makes it less weird to select a custom
date now that we don't have enough space to display the "from" and "to"
date selectors in different columns.
This is similar to what we do with investments, which belong to a heading
but also belong to a budget. In our case, the reason is we've been asked
to add local targets which belong to a goal but are not related to any
existing target.
Even though we're not implementing that case right now, we're adding the
relation so we don't have to add data migrations in the future.
