We were using the wrong color since commit e2d540d20 because, by using
`@extend`, the compiled CSS had the styles for `.ui-state-hover` appear
before the styles for `.ui-state-default`.
This mixin was being called twice for the `.budget-investment-show`
selector; once in the CSS including this code for all the "Show
participation" pages, and once in the CSS for budget investments.
By using the Rails `button_to` helper (which generates a form), and adapting the
response to `html` and `js` formats, the feature works with or without javascript
enabled.
Apply new structure in the section that shows the comments icon together
with the number of comments so that it is easier to unify them into one
component.
Please note that we updated the comment-number class to comments-count
in order to simplify the css in the new component in the next commit.
This was the only place in the application where the comments icon was
included without the span with the class "icon-comments".
We unified with the rest of the application and removed the
"comments-count" class which is no longer needed.
Remove unnecessary span class "debate-comments".
We take advantage of this commit to also unify the format of the date
that appears next to the comments with the rest of the application. The
format that we removed is being used on the same page in the
"Participation phases" tab (I guess that was the reason for putting it
the same) but I think it makes more sense to use the date format that is
used in this kind section in the rest of the application.
Apply new structure in the section that shows the comments icon together
with the number of comments so that it is easier to unify them into one
component.
In this case we make only the text clickable and not the icon as in the
rest of the application. We're keeping the color and text-decoration so
it looks the same way it has looked until now, but we might change it
in the future.
Foundation was using `!global` for non-existing variables, which
generated a warning on our current version of Sass.
This is (mostly) fixed on the latest version of Foundation. However,
this latest version isn't included in the `foundation-rails` gem, so we
can't upgrade yet.
So we're defining these variables before Foundation does so.
See issue 12080 in the foundation/foundation-sites repository for more
information.
While reviewing commit 7702b551e, I forgot to test whether selecting
text in the budget header or clicking its link worked properly.
The negative index (-5) meant it was impossible to select its text or
click on its link.
The good news is the pseudoelement with a negative index (-1) is
considered a child of the .budget-header element, so having a negative
index will cause the pseudoelement to be render behind the content of
the .budget-header element but in front of the background of the
.budget-header element.
This is exactly what we want.
Originally, we didn't have a z-index in the .budget-header element,
meaning the pseudoelement was rendered behind the background of the
.budget-header element, meaning both backgrounds were visible. This was
OK when the background was a plain color, but it wasn't when the
background was an image.
To stress the fact that the budget header is only affected when we use
an image, I'm also moving the code inside the `.with-background-image`
selector, although it would be interesting to check whether it's a good
idea to add `z-index: 0` to the `full-width-background` mixin.
After upgrading to Chrome/Chromium 101, the test "Cross-Site Scripting
protection banner URL" was failing with the message:
Element <a>...</a> is not clickable (...) Other element would receive
the click: <div class="banner" style="background-color:#FF0000;">...</
div>
The reason was that, when using the structure of a link with one <h2>
and one <h3> inside, previous versions of Chrome/Chromium considered the
margin between the <h2> and the <h3> part of the link. Version 101 does
the same thing Firefox does and so clicking on the space between the
<h2> and the <h3> doesn't result in clicking the link.
In order to keep the previous behavior, we're adding a `display: block`
tag to a link.
Note that, in the future, we might change the structure of the banner,
since using <h3> as a subheading is discouraged by the W3C, and we
aren't sure about the usability of making the whole banner clickable.
But, for now, we're just fixing the issue so our test suite is green
again.
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".
Add a help text on admin budget show page and improve text from Admin::Budgets::HelpComponent in order to
clarify its functionality when we are using the wizard.
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 are use a display: block style for labels containing check boxes inside
them, and the label has a width of 100%.
This means that clicking on the blank space on the right of the label text
will check/uncheck the checkbox. To avoid this behaviour we modify the
"display" attribute of the labels.
In order to prevent unexpected behaviour in terms_of_service form labels,
we add specific css for this case when define a checkbox within the
.actions class.
Defining a behavior on hover means making it different for people using
a keyboard or a touchscreen (most of the population, nowadays).
In this case, we had an accessibility issue where the message wouldn't
disappear once it appeared. That meant that, after tabbing through all
the links and buttons in, for instance, the debates index, the page
would be filled with "participation not allowed" messages, and in order
to see the information about how many people have voted, reloading the
page was required.
For touchscreen users the behavior was similar to what we get on hover,
although we've found some inconsistencies when trying to support several
elements on the same page.
We think in proposals it makes sense to hide the "support" button when
users click on it, and the same applies to the buttonsto support and
vote investment projects. However, we aren't hiding the buttons to
agree/disagree with a debate in order to keep the information about the
current number of people agreeing and disagreeing visible.
Note we're removing some support spec methods because after these
changes the duplication isn't as obvious as it was in the past.
Hovering over the votes showed a "participation not allowed" message
which was annoying when scrolling with the browser or simply moving the
mouse around the page. Furthermore, it hid the information about the
number of votes, links to show/collapse replies, ...
We're planning to change the behavior of all the "participation not
allowed" messages in order to show them on click instead of showing them
on hover (just like it's done on touchscreens). In the case of comments,
supports, however, there's very limited space in the part showing the
number of supports for comments, so adding this message without breaking
the layout is challenging.
So, for now, we're simply redirecting unauthenticated users to the login
page. If find an easy way to implement a better user interface in the
future to display the "participation not allowed" message, we might
change this behaviour.
This message is only shown in the `show` action, so it's shown at most
once in the whole page, so it doesn't take up too much space and it
isn't as overwhelming as if we were showing it on the index page, once
per debate.
We're only showing it when there are closed options, though, since
there's already a message to sign in to comment when the question
accepts open answers.
Note we're using the in-favor HTML class instead of the in_favor class
so we're consistent with our conventions for HTML classes and because we
use the in-favor class in similar places.
Also note the styles of the legislation process annotations/comments
buttons is now similar to the styles in the other sections. Previously,
the colors didn't have enough contrast and there was a very strange
margin between the "thumbs up" icon and the number of people agreeing
(that margin wasn't present between the "thumbs down" icon and the
number of people disagreeing).
Using the `flex-with-gap` mixin we avoid the left margin in the second
element when the screen space isn't wide enough to show both buttons.
Setting the margins with CSS also allows as to simplify the view and
makes it easier to customize styles.
Having buttons (previously links) with the text "I agree 75%" is
confusing; people might believe they're saying they only partially agree
with the content. Besides, the results percentages is a different piece
of information which shouldn't be related to whether one person
agrees/disagrees with the content.
This problem might be solved for people using screen readers since we
added the aria-label attribute. However, for sighted keyboard users, the
percentage was being outlined on focus as part of the button, which
might be confusing.
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.
When there isn't a current user, the links can't be clicked, so there's
no real point in them being links.
When there's a current user and they cannot vote (for example, an
organization), having a link/button to an action they can't perform
isn't that useful IMHO. They get a message saying they aren't allowed to
vote but the message doesn't say why. However, in this case, many people
might try to click/touch the link/button and will wonder why nothing
happens, so we'll revisit this issue when we change the way we display
the "participation not allowed" messages.
Now the behavior is more similar to the one we get when voting
proposals/debates.
The action and the views were almost identical, with the supports
progress and the HTML classes of the success message element being the
only exceptions; we can use CSS for the styles instead.
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.
In commit 905ac48bb we mentioned:
> Since we don't use `asset_path` to reference assets in the public
> folder, we can safely disable the `unknown_asset_fallback` option.
However, `asset_path` is used by the wicked_pdf gem when calling the
`wicked_pdf_stylesheet_link_tag` method. This method also checks the CSS
files, searching for `url()` calls and converting any relative URLs
referenced there to absolute URLs.
However, when compiling assets on production, our `application.css` file
contains the following line imported from Leaflet which says:
```
behavior: url(#default#VML);
```
When passing this URL to `asset_path` (which is something the wicked_pdf
gem does automatically), it doesn't find the URL, and so this call
crashes unless we enable then `unknown_asset_fallback` option.
Since the dashboard poster is a feature we might remove in the future,
we're avoiding changing a Rails global configuration just for this
feature. So, instead of enabling the `unknown_asset_fallback` option,
we're changing the `poster.pdf` view so it doesn't load all the CSS of
the application but only the CSS it needs.
Note we aren't adding a test case because this bug is only present on
production environments when assets have been precompiled.
