and its relation with the SDG goal model.
Add comparable module be able to sort collections of targets
by code attribute.
Co-Authored-By: Javi Martín <35156+javierm@users.noreply.github.com>
We were repeating the same code over and over (with a few variants) to
setup tests which require an administrator. We can use a tag and
simplify the code.
Similar to what we do with settings, only for settings we return the
value of the setting (which is what we're going to need most of the
time), and here we return the object.
This way we'll be able to apply it to the SDG icon, which is not
included in font-awesome.
Note we're adding a font-icon selector so it's defined before the
admin-menu-icon selector and so in case of conflicting rules the ones in
the admin-menu-icon selector are used.
Since data for this model (title and description) is not generated in
CONSUL but by the United Nations, we aren't storing it in the database
but in our YAML translation files.
The reasoning is as follows. Suppose that, a few months after CONSUL
gets SDG support, a new language is added to CONSUL.
With YAML files, getting the texts in the new language would mean
updating CONSUL to include the new language.
But if we store these texts in the database, it means we have to update
the databases of all existing CONSUL installations, either each
installation by themselves (duplicating efforts) or running a rake task
(which we would have to write each time).
So we believe using translations works better in this case.
We're still storing records in the database with the code, so they can
be easily referenced via `has_many` or `has_many :through` associations.
This way we simplify the HTML and generating similar menus will be
easier. We also improve the experience for screen reader users, who
might have been hearing the icons as text because we weren't using the
`aria-hidden` attribute.
We're still keeping the "icon-" classes for compatibility with CONSUL
installations which might have changed this code.
From a semantic point of view, there's no reason to add a strong
emphasis to the menu items.
Besides, using CSS simplifies the code and is less error-prone. For
instance, the "stats" section didn't have a <strong> tag, and so it was
the only one which wasn't bold.
Now that there's no naming confict with the helper method used in the
ProposalsDashboardHelper, we can easily simplify the view, moving the
logic to the Ruby class.
The HTML `class` attribute was declared twice and so the second one was
being ignored.
In the case of messages, it was "working" properly because the
`class=is-active` part is not used on `<li>` tags when they've got a
`<ul>` inside them.
We no longer need to use the `menu_` prefix, since now these methods
aren't helper methods anymore, and so their names won't collide with
other helpers.
A <header> tag is the natural place to have headings.
Since we already had the logo there, IMHO it makes sense to merge both
the <h1> tag and the logo together. We were already doing so in the
devise layout.
From the sceen reader users' point of view, having a link with the text
"CONSUL logo" is a bit confusing, since it seems to imply the link will
get us to the CONSUL logo. Using the organization name as the text of
the link makes more sense.
One thing changes, though. Before this commit, the first thing on the
page a screen reader user would hear about would be the organization
name. Now the language selector and the top links are announced before
the organization name is read. That's fine, since the actual first thing
these users will hear is the content of the <title> tag, which contains
the organization name as well.
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.
