While people using screen readers already have keyboard shortcuts to
jump to the <main> tag, there are people who navigate the page with the
keyboard using just the tab key, and for them, this link provides a way
to save time and start reading the main content instead of having to
manually go through all the navigation links every time a new page is
loaded.
Note that we had to add an additional `width: 0` rule because
Foundation's `element-invisible` would apply `1px` and the test checking
for `visible: :hidden` would faile.
Many pages had this tag, but many other didn't, which made navigation
inconsistent for people using screen readers.
Note that there are slight changes in two pages:
* The homepage now includes the banner and the content of the
`shared/header` element inside the <main> tag
* The budgets index now includes the banner inside the <main> tag
I see both potential advantages and disadvantages of this approach,
since banners aren't necessarily related to the main content of a page
but on the other hand they aren't the same across pages and people using
screen readers might accidentally skip them if they jump to the <main>
tag.
So I'm choosing the option that is easier to implement.
Note we're adding a `public-content` class to the <main> element in the
application layout. This might be redundat because the element could
already be accessed through the `.public main` selector, but this is
consistent with the `admin-content` class used in the admin section, and
without it the <main> element would sometimes have an empty class
attribute and we'd have to use `if content_for?(:main_class)` or
`tag.main` which IMHO makes the code less consistent.
The Capybara::DSL monkey-patch is only done on the `visit` method
because it's the only reliable one. Other methods like `click_link`
generate AJAX requests, so `expect(page).to have_css "main", count: 1`
might be executed before the AJAX request is finished, meaning it
wouldn't properly test anything.
Out of the usability issues I've experienced when using Consul
Democracy, the biggest one has arguably been the fact that the link to
edit a proposal opens in a new tab. I guess the reasoning behind it is
that the page to edit a proposal is not part of the proposals dashboard,
but what the hell! Imagine if every link to edit something opened in a
new tab...
So we're reducing the impact of this nonsense by opening most dashboard
links in the same window; for now, we're still opening in a new window
links to download files and links that might point to external websites.
We'll address those ones in the future.
This way we make it easier to modify.
Note that, since the title of the page is "Administration" and it's in
the "Admin" section, we're adding an option to the `header` method in
order to avoid having a confusing title like "Administration - Admin".
Also note that, by removing the `title` HTML class, we avoid inheriting
styles from the `dashboard.scss` stylesheet, and now the heading is
displayed in the position it was meant to.
Finally, the concept of using a `main-class` for the current page comes
from a branch (currently in development) which will replace the <div>
tag with the `admin-content` class with a `main` tag.
Internet Explorer 8 was released in 2009 and people using it already
know that most web pages look broken on it, so we don't need to warn
them.
Removing it makes our application layout file much easier to read and
modify.
Just like we did for budgets, we're doing the same thing in all the
places where we render background images attached by either regular
users or administrators.
This way we correctly render background images with characters like
brackets or quotes.
We were using partials to render components in order to ease the
transition of custom code from earlier versions of Consul. However,
that was back in Consul 1.4, and now these views looked a bit messy
since they sometimes rendered components and sometimes they
rendered partials.
We were using the same code for the button in both the public and admin
headers, so we're removing the duplication.
Since the menu and the button must go together, and the contents of the
menu are different for different layouts, we're passing these contents
using a block.
Note the ID of the menu was `responsive-menu` in the public section but
`responsive_menu` in the admin section. Since we usually use underscores
for IDs and dashes for classes, we're keeping the one with the
underscore.
We're changing the order of the elements in the HTML so the menu button
appears next to the menu it opens, with no logo between them, which IMHO
makes sense and makes it easier to understand the layout for people
using screen readers.
A small advantage of this approach is that on very narrow screens or
Consul applications having a very long word for "Menu", the menu button
appeared on top, the logo appeared below it, and the contents of the
menu appeared below the logo. Now the logo appears on top, the menu
button appears below it, and the contents of the menu appear below the
menu button.
The menu didn't look properly on these screens since commit dcec003d0.
On small screens with enough horizontal space to show the menu button,
the logo, and the contents of the menu, all three elements were shown on
the same row, which looked broken.
Now the contents of the menu are shown below the menu button.
Note that, to force this, we're making the contents of the menu 100%
wide. That means links would take the 100% of the space, which would
make it easy to click on a link while trying to scroll when using
touchscreens. So we're making the links as wide as their text, which
also has a disadvantage: it's harder to click on narrow links like
"SDG".
This class was only there in order to use Foundation's styles, but
the amount of styles we were using was equal to the amount of
styles we were overwriting.
This way it'll be easier to decide when they should be rendered.
In order to be consistent, we're using the `Layout` module for both
components; previously, the navigation partial was in the `shared`
folder while the footer partial was in the `layout` folder, which IMHO
didn't make much sense.
This way we remove the duplication in the layouts which had these links.
Since we're now passing the `current_user` option to partials in all
cases, IMHO the code is easier to follow if we use the
`Layout::NotificationItemComponent` instead of its partial.
This way it's easier to refactor it.
Note we're using `with_request_url` in the tests because the component
renders the locale switcher, which needs a URL in order to work. This
doesn't affect whether we're in the management section or not.
We forgot to do so in commit d827768c0. In order to avoid the same
mistake in the future, we're extracting a method to get these
attributes. We're also adding tests, since we didn't have any tests to
check that the `dir` attribute was properly set.
We were getting some deprecation warnings:
DEPRECATION WARNING: `Module#parent` has been renamed to
`module_parent`. `parent` is deprecated and will be removed in Rails
6.1.
DEPRECATION WARNING: `Module#parents` has been renamed to
`module_parents`. `parents` is deprecated and will be removed in Rails
6.1.
Apparently the dashboard branch wasn't updated after we extracted a
common head for all layouts in commit 6e4f697ce, so when said branch was
merged we reintroduced the duplication. Furthermore, we forgot to add to
the dashboard layout the changes we were applying to the common head
partial.
See foundation/foundation-sites issue 12167, which was fixed in
Foundation 6.7.1. However, since Foundation 6.7 requires Node 12 and the
foundation-rails gem hasn't been maintained for a year and a half, we're
not updating for now.
We forgot to remove it in commit f28a5cc49.
The generated HTML was invalid, with the error:
> Element meta is missing one or more of the following attributes:
> content, property.
Now that we also have the "go back to CONSUL" link, the layouts are so
similar that it isn't worth it maintaining both of them separately.
With this change, people using small screens also get the "menu" button
in the management section, just like they do everywhere else.
We're adding the `namespace != "management"` condition so the menu still
shows up in the officing namespace.
Originally there was a link pointing to the FAQ page but it was removed
in commit e14b7b67fb because by default the FAQ page in CONSUL only
contains a placeholder text.
We aren't sure where this link should point:
* FAQ page, only if the FAQ page is published
* Help page, only when the help feature is enabled
* CONSUL technical documentation page
So, for now, we're choosing the easiest solution which is removing the
text completely.
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.
This way, when the language is written form right-to-left, elements
using Foundation mixins/classes will float to the opposite direction as
they do in left-to-right languages. The same will apply to text
alignment.
To offer full support for RTL languages, we need to change every single
reference to `float: left`, `float: right`, `text-align: left`,
`text-align: right`, and possible adjust other properties like `left`,
`margin-left`, `padding-left` or `border-left`. In the meantime, we at
least partially support these languages.
Replacing `float` with `flex` when possible would also improve RTL
support.
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.
Since the top-bar already includes a layout positioning the elements,
these classes are redundant and actually confusing, since the element
floating to the right was on the left.
This solves a problem where the outline wasn't correctly displayed when
focusing on the logo using the keyboard. Firefox was displaying two
vertical lines together above the logo, while recent Chrome versions
displayed the outline to the right of the logo.
In the case of the public layout, the row element was originally there
so the content of the top links had a maximum width. Since now the body
has that maximum width, we no longer need the row element.
In the other layouts I guess the row elements were added because there
were float elements inside them. We can use a flexbox layout instead and
these elements are no longer necessary. This also makes the layout more
robust when there isn't enough space on one line for both the language
selector and the external links.
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`. 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).
These element had no columns inside and the row classes had only been
added to give them a maximum width. That's no longer necessary since now
the body has that maximum width.
Some users might not be able to touch the icon due to a motor
disability. Other users might think the "Menu" text is part of the
button and try to touch it instead.
Making the "Menu" text part of the button makes it easier to show/hide
this menu. Besides, it lets screen reader users with a small screen hear
the word "Menu" associated to the button.
We could simplify the HTML a bit more but Foundation's `hamburger` mixin
uses the `::after` element with `position: absolute`, so we can't apply
it directly to the button without making the CSS more complex.
Using `currentcolor` and `color: inherit` is IMHO more expressive (we're
saying we want to use the same color as the text) and makes it easier to
customize these colors in other CONSUL installations. We also remove
duplication as we can use the same styles for both the admin and the
public layouts.
Using `<a>` tags with no `href` means these elements cannot be activated
by keyboard users, so we're replacing them with buttons.
In the future we probably want to add more consistency so all toggle
buttons use the same code. We might also add styles depending on the
`aria-expanded` property.
We were doing it manually, but Capybara offers an option which does the
exact same thing.
This way we also apply the NoJavascriptTagHelper ERB rule, which
reported one error in the `disable_animations_in_tests` partial.
