With this change, on my browser, reloading a page in development after
changing a CSS file is about 25% faster than simply splitting the CSS
code between `application.css` and `vendored.css`. Compared to using
only one `application.css` file containing everything, reloading a page
in development is about 35% faster.
The combined size of all the generated stylesheets is now about 0.5%
bigger. Not sure why (maybe placeholder selectors?), but the difference
is negligible.
Note that we could load the `administration.css` file only in the admin
area, reducing the size of the page for people accessing the public
area. However, the size of this stylesheet (compressed) is 28K, which is
less than 3% of the overall size of a page and, on the other hand,
there's a risk of some styles no longer being applied because we might
have overlooked the fact that some styles in the `administration.css`
are also applied to the public area.
So, for now, we're still loading the administration styles in the public
area. We might reconsider in the future.
With this change, on my browser, reloading a page in development after
changing a CSS file is about 10%-15% faster.
On the minus side, this change results in an extra request when browsing
the page; AFAIK it isn't that big of a deal, even when the server isn't
using HTTP/2.
The text for the unfeasible checkbox wasn't correctly defined as a
label, while the fields to search investments and select the heading
weren't intuitive since their purpose wasn't obvious.
Note that, since the button now generates a `form` tag, we need to
adjust the styles of this section.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Note we're simplifying the `table .button` margin rules because the
`.button` class already defines `0` for all its margins except the
bottom margin. Otherwise, the margins defined by the `flex-with-gap`
mixin would be overwritten by the margins defined in the `table .button`
class.
This is consistent with the way we've got partials to render debates,
proposals and legislation processes on their index pages.
Note that, while adding the tests for the status icon, we're keeping one
system test because it also tests the process of voting. We're adding a
new, similar component test, where the voter is created in the database,
so all possible statuses are tested in the component.
We had an inconsistency where most stylesheets associated to a component
would have the same relative path as their component, so if we had a
component in `app/components/admin/whatever`, its associated stylesheet
would be in `app/assets/stylesheets/admin/whatever`.
There was one exception to this rule: stylesheets for components in
`app/components/shared/` were placed in `app/assets/stylesheets/`. The
reason was that we thought "well... if they're in the root folder,
they're shared". However, this is confusing because in the root folder
there are also stylesheets that aren't associated to a component.
So we're creating the `app/assets/stylesheets/shared/` folder. This also
means we don't have to manually add every stylesheet in this folder the
the `application.scss` file.
We aren't the same for JavaScript files because with JavaScript we still
don't have a clear association between JavaScript files and components.
Only a couple of them (`advanced_search.js` and `check_all_none.js`)
would be good candidates, and the one for the advanced search form
doesn't even use the `.advanced-search-form` selector that we use in the
CSS file.
Since we don't usually style HTML classes starting with `js-`, we're
renaming it, so it's consistent with the `CheckAllNone` name used in the
`check_all_none.js` file.
The initialjs-rails gem hasn't been maintained for years, and it
currently requires `railties < 7.0`, meaning we can't upgrade to Rails 7
while we depend on it.
Since the code in the gem is simple, and we were already rewriting its
most complex part (generating a background color), we can implement the
same code, only we're using Ruby instead of JavaScript. This way, the
avatars will be shown on browsers without JavaScript as well. Since
we're adding a component test that checks SVG images are displayed even
without JavaScript, we no longer need the test that checked images were
displayed after AJAX requests.
Now the tests show the user experience better; people don't care about
the internal name used to select the initial (which is what we were
checking); they care about the initial actually displayed.
Note initialjs generated an <img> tag using a `src="data:image/svg+xml;`
attribute. We're generating an <svg> tag instead, because it's easier.
For this reason, we need to change the code slightly, giving the <svg>
tag the `img` role and using `aria-label` so its contents won't be read
aloud by screen readers. We could give it a `presentation` role instead
and forget about `aria-label`, but then screen readers would read the
text anyway (or, at least, some of them would).
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
Other packages depend on jQuery, so that's why these are the first one
we move from the Gemfile to the package.json file.
This way we can also test whether dependabot correctly opens pull
requests to update Node packages.
I've tried several configuration options for the asset pipeline in order
to be able to include images referenced in jQuery UI CSS files. So far,
adding the `node_modules/jquery-ui/themes/base` folder to the assets
paths is the only way I've found to make it work. Hopefully we can find
a better solution in the future so we don't have to study the internals
of every Node package in order to integrate it with the assets pipeline.
We were using similar code in four different places; six, if we count
the welcome pages seeds. Reducing duplication in the pages seeds is a
bit tricky because administrators are supposed to edit their content and
might remove the HTML class we use to define styles. However, we can
share the code everywhere else.
Note that there's a bug in the application since we show that level 2
users cannot vote for budget projects but we give them permission to do
so in the abilities model. We're keeping the same behavior after this
refactoring but we might change it in the future.
Just like we did with SCSS variables, we use the `--main-header` CSS
variable and, if it isn't defined, we use the `--brand` CSS variable
instead.
Note that we're still using the `inverted-selection` mixin based on the
default `$main-header` color, so it's possible that we get the inverted
selection in the main header when using a dark color with `$main-header`
but a light color with `--main-header`, which doesn't make much sense.
Not sure whether there's anything we can do about it.
Since we've already got a banner component, we follow the convention of
using one CSS file per component. We also reduce the number of lines in
the huge layout.scss file.
Now the sections in layout.scss from "17" to "19", just like they jump
from "08" to "10".
We were using very similar code for proposals, debates and investments,
so we might as well share the code between them.
Note we're using the `proposals.index.search_results` key even for
debates and investments. This will still work because the translations
shared the same text, but IMHO we should rename the key to something
like `shared.search_results_summary`. We aren't doing so because we'd
lose all the existing translations.
We were using the same code to render links to agree and disagree, so we
can extract a new component for this code.
We're also adding component tests to make it easier to test whether
we're breaking anything while refactoring, although the code is probably
already covered by system tests.
Since the votes mixin was only used in one place, we're removing it and
moving most of its code to a new CSS file for the shared component.
The user can access this page without being logged in.
We identify the user through the "subscriptions_token" parameter and
show a list of the notifications that can be enable/disable.
We will return a 404 error in case someone accesses the page with a
non-existent token.
We also control the case that some anonymous user tries to access the
page without any token, by returning the CanCan::AccessDenied exception.
We're continuing to replace links with buttons, for the reasons
explained in commit 5311daadf.
Since we're using the admin action component, we can also simplify the
logic handling the confirmation message.
In order to avoid duplicate IDs when generating buttons to block the
same author more than once in a page, we're including the record dom_id
in the ID of the button to block an author.
Having proper headers makes it more accessible.
We're also using the table actions component because we're going to add
another action. Since table actions use a flex layout, we have to tweak
the styles a little bit. For that, I'm adding a <main> element which
will make it possible to style just this table while also providing an
extra shortcut for people using screen readers.
As mentioned in commit bc0f04075, a <select> field which submits its
form on change causes many accessibility and usability issues. In this
case there was also an incompatibility with the advanced search filter
which caused a bug solved in commit 541a5fa89.
So the question is where to position the filters and how to display
them. One factor to take into the account is how relevant these filters
are, particularly compared to the links to select the prefered order,
since we don't usually give users the choice of both filters and orders.
Our filters don't really make sense until the valuation phase starts,
since before that phase investments aren't selected nor their
feasibility is decided.
After that phase, the only phase where citizens are really involved
is the final voting; the rest of the phases are done by valuators and
administrators. In the final voting, citizens can only vote on selected
projects, and that's the default filter during that phase.
So these filters are mainly there for information purposes, and not to
help citizens in the phases where they're actually involved (accepting
projects, selecting projects and balloting).
Orders, on the other hand, play a crucial role during the final voting
phase. Since citizens might have already voted for a few projects and
have, let's say, 100,000€ left, ordering by price allows them to find
which projects are within their remaining budget.
In conclusion, orders are more important than filters, and so they
should have a more prominent place.
For consistency with the proposals section, where we've got some links
in the sidebar (bottom part of the page on small screens) providing a
similar funcionality, like accessing selected proposals or archived or
retired proposals, we're moving the investments filters to the sidebar
(bottom part of the page on small screens) as well.
This way the code is easier to follow; the code checking whether the
list has contents is in the partial rendering the list.
We also remove some duplication setting up related content in the
controllers.
For some reason, we have to manually ignore i18n keys which were
automatically ignored when the code was in the view.
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.
