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.
Using the name instead of using the name and the price is IMHO more
consistent with the rest of the application, particularly for screen
reader users. Writing texts clicking those links is also easier.
I think the main reason why we used the price as part of the link was so
the clickable area was bigger. We can accomplish the same result with
CSS.
Using flex we don't have to rely on JavaScript to equalize the item.
Besides, we've had problems with JavaScript in the past.
We're also adjusting the width of the elements; previously, even though
we defined a width of 16.666% for each element, only five elements would
be on the same row. It happenend because these elements were styled with
inline-block and the generated HTML contained a newline character
between <li> tags, meaning a space character was introduced between
elements. The width of the mentioned space character wasn't being taken
into account when calculating the width.
Using flex, there's no space character between items and we have to
define the margin between them. We're taking this margin into account
when calculating the width.
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.
Since we were using an icon font with no text, screen readers were
announcing things like "Enabled, L", trying to read the icon generated
with CSS.
Using text and replacing it with CSS with an icon solves the problem.
We could also use aria-label, but I prefer using "Yes/No" so the text
can be shown/hidden with CSS. Also useful when using
`save_and_open_page` during tests, since the displayed page will not
have any CSS rules applied.
Out of several existing techniques to hide text [1], we're setting the
font size to 1px in combination with moving the content off-screen
because that way we can override it in the `::before` element.
Just moving the content off-screen has the inconvenient of the content
still being taken into account when calculating the text indentation.
And just using a 1px font would make a 1px-sized square appear when
selecting text, which could confuse users.
[1] https://webaim.org/techniques/css/invisiblecontent/
Using 10000px means content will be visible on screens with ultra-high
resolution (although I don't think they exist nor will exist anytime
soon).
Having screens in the future with a width of 1000rem is less likely,
since a line with 1000 characters would be pretty much impossible to
read.
There were some issues using `.budget.expanded`, like a link having that
class which would force us to a `:not(.button)` selector or similar,
making the CSS more complex.
This makes the table easier to identify when writing tests and using
screen readers.
Since we do not render any other table captions anywhere else, we're
making the caption invisible so only screen reader users will be
affected by this change.
In this page we will render a list of clickable Goals icons that will show their
targets and related local targets
Co-authored-by: Senen <senenrodero@gmail.com>
This component was rendered on different pages so there were no conflicts
with static id's.
Now in the SDG help page we are going to render them all at once, so we
convert the static identifiers to dynamic.
Previously the draft mode was a phase of the PB, but that had some
limitations.
Now the phase drafting disappears and therefore the PB can have the
status published or not published (in draft mode).
That will give more flexibility in order to navigate through the
different phases and see how it looks for administrators before
publishing the PB and everybody can see.
By default, the PB is always created in draft mode, so it gives you
the flexibility to adjust and modify anything before publishing it.
We're going to add help content here and having a floating button would
make the button disappear when creating content for mobile phones.
I'm not sure having the link in the <header> tag is semantically
correct, but is consistent to what we did to create local targets in the
SDG content section.
Note we're changing the style of the link to create local targets so
it's consistent with the link to create budgets/groups/headings.
The color #fff provides higher contrast, which can cause problems to
users who experience migraines with bright colors or dyslexic users who
might see some kind of shadows around the text because of the bright
color.
So even if it isn't a big improvement, we're slighty reducing the
contrast in order to slightly reduce this problem.
It was hard to know where the numbers were coming from; they depended on
the padding of the link and the size of the notification icon size. So
we're using variables to make it more explicit.
However, the code is now too complex, so we'll probably have to simplify
it in the future.
Other than simplifying the view, we can write tests using `click_link`,
which makes the tests more robust. Clicking the `.icon-notification`
element was causing some tests to fail when defining a window height of
750 pixels in the `admin_budgets` branch.
Hopefully now it's a bit more obvious that SDGs can be selected by
clicking on them and that the field to select goals and the field to
select targets/goals are related (since they're now part of the same
fieldset).
We were using list items with the checkbox role. This is probably
confusing since list items have a listitem role, and so we were
basically using a list with no listitem.
We could add a `<span role="checkbox">` tag inside the list item, but
using real checkboxes is probably easier. We're also adding a test to
verify the checkboxes native behavior is compatible with our code.
Note we're using the "enter" key to toggle the "checked" status of the
SDG. This is probably not intuitive for screen reader users who might
try to submit the form using the "enter" key after selecting a goal.
However, the alternative would be even less intuitive for sighted
keyboard users, since for them these icons look like links or buttons
and they would accidentally submit the form when trying to select a
goal.
Since we haven't come up with a better interface yet, for now we're
following the principle of least damage; we consider submitting the form
against a user's will is less annoying than forcing users to move to a
different field before being able to submit the form.
Also note we can't write `check` in the tests because Capybara will try
to click the checkbox, which is hidden by the image in the label.
These styles were broken in commit 2614de79c, since there we only
considered scenarios where the `tags` element is a list. In these forms, however, the `tags` element is a regular <div> tag.
Since we've changed the facebook and twitter login icons, it makes sense
to use the same icons in social share links.
Besides, using font-awesome simplifies the code and prevents problems
with screen readers announcing the value of the `content:` CSS property.