We were using each one half the time, while they both had the same value
by default. It was impossible to know when me meant "use a dark color
here" or "use the secondary brand color" here.
So now we're only using one variable, so it's easy it'll be easy to add
CSS custom properties to overwrite this variable. We're choosing
`brand-secondary` because its name makes it less problematic to use a
light color.
This is consistent with the usage of `$body-background`. This way
Foundation elements using `$body-font-color`, like the `<body>` tag,
will be changed when changing this variable, which wouldn't happen when
using `$text`.
The variables `$anchor-color` and `$anchor-color-hover` are the ones
Foundation uses internally; by using them, we make sure every link will
use the colors we define.
Now we can simplify the default styles for the `<a>` tags, since by
default they already use these variables.
This way we simplify the code a bit.
Note we're only using this function when variables for background colors
are already defined, since that means customizing the variable using the
background color will automatically change the color of the text.
Customization isn't easier when using raw colors.
We were defining (for instance) white text against the `$brand`
background. That meant that, if somebody customized the `$brand` color
so it used a light color, they had to customize the text color as well
in order to guarantee proper contrast between text and background
colors.
So we're using `color-pick-contrast` instead, which means we don't have
to manually calculate whether white or black will be the color which
makes the text more readable.
This way it's easier to customize colors, particularly when links use
the same colors as the text surrounding them.
Note that the `markdown-editor-header` isn't displayed since commit
76b7f66fb, which was probably an unintended side-effect. So we're
modifying the colors here as well instead of removing the element; we
might display it again in the future.
Also note the change in `.supported` only affects the proposals section;
budget investments use a different color for the `.supported` sucess
message. Not sure whether this was originally intended or done by
accident.
These elements were already using these colors because they inherited
them from their parent elements or Foundation already defined them.
Note that the only contents of `.comment-info` are: `.user-name` and
`.is-author`, `.is-association`, `.level-1`, ... and the link to the
comment. All of these elements were overwriting the `$text-medium`
color, so there's no need to set it. That means we can use the default
text color for `.user-name` without specifically setting it.
Should hollow buttons use the same color as links do or the same color
as solid buttons do? In the default scenario, it doesn't matter, since
links and solid buttons use the same color. However, it matters when
people customize the application so links and solid buttons don't use
the same color.
I'm choosing to use the same color for solid and hollow buttons because
these elements are usually isolated and so from the UX perspective they
are similar; links, on the other hand, are often in the middle of some
text.
Note we're talking about links and buttons while many of the "buttons"
we use in the application are actually links styled as buttons. Here,
"buttons" means "things that look like buttons".
We were overwriting the color of the links, but not the color of the
links on hover.
Note we're removing the `!important` rule from the author link; after
testing it, it looks like it wasn't necessary.
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 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.
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).
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 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.
Note that in proposal notifications we're writing the call to
render the component in the same line as the <div class="reply">
definition in order to be able to use the `:empty` selector when the
component renders nothing. No browser matches whitespace with the
`:empty` selector, so we can't add newline characters inside the tag. A
more elegant solution would be extracting the proposal notification
actions to a component and only rendering it if the moderation actions
component is rendered.
A <div> can't be a direct child of a <ul>. In this case the <ul> tag
didn't make much sense because there isn't a list; just a map.
Note the `z-index` rule which was added in commit 25e1afea48 is ignored
because the map element is statically positioned. I'm not sure why it
was added; can't reproduce the rendering problem both that commit and
commit c5a749212 mention. Maybe back then the element had a `position:
relative` rule or similar somewhere.
This way the curve will still work as intended on very large screens.
We're not taking into account the padding of the <main> element in the
SDG goals index for simplicity, since adding it barely has any effect.
On very large screens, the admin menu had a lot of blank space for
languages where all sections had short names (like English). This was
inconvenient because the icon to open a submenu was far from its
associated menu item.
Using the `max-content` value for the `max-width` property, we reduce
the amount of blank space in these cases.
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 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.
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.
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.
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.
When render the investment list component with the link "see all
investments", now we redirect to groups index page when a budget has
multiple headings.
So we don't add the same lines to pretty much every stylesheet we
create.
Eventually we'll remove this code and add a padding to every <main>
element, or (even better) to the <body> element itself.
We can give the padding to the whole page instead of giving it to
individual elements.
On the minus side, now padding in the SDG pages is not the same as the
padding in the homepage, so we need to add an extra padding to the
participation feeds in only one of these cases.
Instead of adding the padding to each individual element inside the
container, why not adding padding to the container itself? The answer is
"because we want the background of the children elements to take the
width of the whole screen". But this generates either HTML cluttered
with elements to add padding or repetitive padding definitions in the
CSS.
So now we only define the padding once, and when an element requires a
full width background or border, we use the `full-width-background`
mixin.
In this case the code is a bit more complex because the header is also
used in the dashboard and admin layouts:
* In the public layout, the body has a margin, so we include the mixin
to take margin into account
* In the dashboard layout, the header itself has a margin, so we include
the same mixin
* In the admin layout, the headet doesn't have a margin but gets the
whole width, so in this case we include the mixin which dosen't take
the margin into account
In the future, the idea is to apply this principle to the <body>
element and remove the `@include grid-column-gutter` in the CSS as well
as the `small-12 column` classes in the HTML.
Note we use the `calc()` function inside the mixin instead of using it
in the `$full-width-margin` variable. That way we avoid nested `calc()`
operations, which don't work in Internet Explorer.
Also note we're using `flex-grow: 1` to make one element appear on the
left of the screen and the other one on the right. It would be easier to
use `justify-content: space-between` (which is actually the default for
the top-bar element). However, there's a bug in Internet Explorer and
old versions of Firefox; they include the absolutely-positioned
`::before` element we use to set the full width background when
calculating where to position the elements. The bug was fixed in Firefox
52 (released in 2017).
Finally, we're removing the padding from our logo. In order to allow
logos like the new one and at the same time provide backwards
compatibility to logos in existing CONSUL installations, we're relaxing
the validation rule for the logo width.
Using `flex` instead of a fixed width for the navigation, the elements
take all the available space when the search form isn't present. That
wasn't the case before and produced a strange effect on medium-sized
screens.
This way we also align the search to the right.
