This way screen reader users will know which record they're going to
access when focusing on a link to a certain action. Otherwise they'd
hear something like "Edit, link", and they wouldn't know which record
they'll end up editing if they follow the link.
This way it will be easier to change the behavior of all table actions,
like adding ARIA attributes. In the past, when we changed the behavior
of the `link_to` method, we had to change all table action classes.
Styles on keyboard focus are essential for keyboard navigation; without
them, keyboard users wouldn't see which element they're currently
interacting with. That's why we use an `outline` on elements having the
current keyboard focus.
However, this is sometimes annoying for mouse/touchscreen users, since
clicking/touching an element also gives it keyboard focus.
When clicking on a button performing some kind of action through
JavaScript, keeping the outline on the button after clicking it is
distracting.
Even after clicking a link, for some users having the outline present
while they wait for the next page to load is annoying.
That's why modern browsers (at the time of writing, 74%) implement the
`:focus-visible` pseudoclass, which selects elements which have received
focus using the keyboard, but not elements which have been
clicked/tapped on. We can use it to provide focus styles for keyboard
users without getting in the way of mouse/touchscreen users.
Usually we wouldn't use a feature which isn't supported in more than 96%
of the browsers out there. However, in this case we've got a solid
fallback: we just use the `:focus` pseudoclass. Since the `@support` CSS
condition doesn't accept pseudoclasses as parameters, we're disabling
`:focus` styles only on browsers supporting the `:focus-visible`
pseudoclass using the `:focus:not(:focus-visible)` selector, which will
be ignored by browsers without support for `:focus-visible`.
Since now users receive less feedback when clicking/touching a link or a
button, we're adding styles for the `:active` pseudoclass. This way
users will know which item they're clicking/tapping on. I'm not sure the
outline is a good option for this case, though; I think for touchscreen
users a better solution would be to apply the styles we apply on hover.
We might change it in the future.
Note grouping styles together like this would *not* work:
```
&:focus,
&:focus-visible {
// Styles here
}
```
Browsers not supporting the `:focus-visible` pseudoclass would ignore
this statement completely, meaning they wouldn't apply the styles on
`:focus` either.
We lost focus styles on certain controls in commit 4dad04ae3, since we
were applying a border with a rule which had more precedence than the
rule of border on focus.
We were using a focus outline on links, but weren't doing the same for
buttons. Since sometimes browsers use a default outline which is barely
visible, this was very disorienting when browsing using the keyboard; we
were navigating through links that clearly indicated where the keyboard
focus was, and when reaching a button suddenly we had this almost
imperceptible feedback. Even if I'm used to it, my first reaction is
always "where did the focus go?" until I realize it's now on a button.
This is even more confusing because we've got buttons looking like links
and links looking like buttons.
Note that in the rules for the `:focus` styles we're including buttons
and the `[type="button"]` attribute. This seems redundant since those
styles are already covered by the `button` selector. However, Foundation
adds styles to buttons with the `[type]` attribute. Since the attribute
selector has precedence over the tag selector, we need to use the
attribute selector as well in order to override Foundation's styles.
There were no elements matching this selector since commit d679c1eb7 and
these styles were completely ignored. I'm re-adding the ones with make
sense in my humble opinion. I'm not adding top and bottom paddings since
they affect the way the height of the element is calculated, and am not
sure about the intention behind setting the height property.
The "Sign in" or "My account" links and the main navigation are
different elements, and they're in different places on medium and large
screens. Now we're also separating them on small screens.
Since the `.vertical` class in the menu added quite a few styles and it
was difficult to overwrite them, we're simply removing this class from
this element. This way we're also removing the huge space between the
menu button and the first element of the navigation.
On small screens, the "Sign in", "Register", "My content", "My account"
and "Sign out" links didn't have much padding nor space between them,
and it was easy to accidentally click the wrong link.
This change also positively affects the menu on medium and large
screens. When one of the options (like "SDG content") had a text
spanning over two lines (like it happens in Swedish), there was barely
any space between those two lines. So we're using `line-height: inherit`
instead and adjusting the padding accordingly.
It was broken since we fixed issues with other image fields in commit
394a94cbf, because there we added a fieldset for the image fields, and
so they inherited the styles in budget phases fields (these styles were
added before it was possible to attach an image to a phase).
In commit 55c3c7987 we updated the admin layout header to use
`class="dropdown menu" data-dropdown-menu` instead of `class="menu"
data-responsive-menu="medium-dropdown"`.
Then, in commit dcec003d0, we updated the public layout header to use
`class="menu" data-responsive-menu="medium-dropdown"` instead of
`class="dropdown menu" data-dropdown-menu`.
Now we're applying the same classes to both, hoping we can get some
consistent styles.
I'm choosing to keep the ones in the public layout because using it I
had less problems when trying to improve the styles of this navigation.
When, on small screens, a navigation element had a very long text
causing it to span over multiple lines, the space between each line was
the same as the space between elements. This made it hard to see where
elements started and ended.
Using a padding to separate the contents of one element and the contents
of the next one solves the issue.
When users see a label saying "With the text" and an input field, they
don't usually need a placeholder saying "Write the text". On the
contrary, this text adds noise and is hard to read due to the low
contrast between the color of the placeholder and the color of the
field, making the text an unnecessary distraction.
User testing has shown this filter isn't really useful and sometimes
makes users wonder what it's about. This is particularly true in CONSUL
installations which don't change the default values (most of them),
since users will see a filter with options like "Official position 1".
We were using helper methods inside the model; we might as well include
them in the model and use them from anywhere else.
Note we're using a different logic for images and documents methods.
That's because for images the logic was defined in the helper methods,
but for documents the logic is defined in the Documentable concern. In
the past, different documentable classes allowed different content
types, while imageable classes have always allowed the same content
types.
I'm not sure which method is better; for now, I'm leaving it the way it
was (except for the fact that we're removing the helper methods).
The same way it's done for images.
We were converting the number of megabytes to bytes and then converting
it to megabytes again. Instead, we can leave it as it is and only
convert it to bytes when necessary (only one place).
The `sign_in(nil)` method was a bit hard to understand IMHO. After all,
in controller and system tests we don't have to specify no user is
signed in; that's the default behavior.
So we're making it the default behavior for component tests as well.
The chances of an unpublished proposal appearing on the homepage was
very low because only the proposals with the most votes appear there and
unpublished proposals don't have any votes. However, it was technically
possible on new sites where only a few proposals had been created.
Users were unable to reset a translation to its original value after
updating it because we weren't storing anything in the database in that
case.
I've considered deleting the existing translation when this happens. I'm
not sure about which approach is the better one, so I'm using the less
destructive one.
I think we could have already done so when upgrading Ruby to version
2.6.x (which also included the Bundler gem), but since we didn't, now
that we've upgraded to Bundler 2.x it's probably a good moment.
