The planned budget investments redesign includes using icons in some
tables, so we might as well use them everywhere.
The original design used Foundation to show the tooltips. We're using
CSS in order to keep the ERB/HTML code simple. One advantage of using
CSS is we can show the tooltip on focus as well, just like accessibility
guidelines recommend [1]. On the other hand, Foundation tooltips appear
on the sides when the link is at the bottom of the page, making sure
they're visible in this case, while CSS tooltips do not. Neither CSS
tooltips nor Foundation tooltips are dismissable, which might be an
accessibility issue.
Note we aren't changing any ERB files in order to replace links with
icons; we're only changing CSS and one line of Ruby code.
[1] https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus
Note the CSS could probably be improved to avoid duplication with other
button style definitions. However, that's fine because we're going to
change the style of the links soon.
For the same reason, I haven't bothered to style every single link the
way it was until now.
There are a dozen ways to add an icon used for decoration. Each of them
offers advantages and disadvantages regarding these topics:
* Accessibility
* Ease of use for developers
* Ease of customization for CONSUL installations
* Maintainability
* Resulting file size
* Number of HTTP requests
* Browser support
* Robustness
We were using one of the most common ones: icon fonts. This technique
shines in many of these aspects. However, it misses the most important
one: accessibility. Users who configure their browser to display a
custom font would see "missing character" icons where our icons should
be displayed. Some users have pointed out they use a custom font because
they're dyslexic and webs using icon fonts make it extremely painful for
them [1].
Screen reader users might also be affected, since screen readers might
try to read the UTF-8 character used by the icon (even if it uses a UTF
Private Use Area) and will react to it in inconsistent ways. Since right
now browser support for different techniques to prevent it with CSS
ranges from non-existant (CSS speech module) to limited (use an
alternative text in the `content` property [2]), we've been adding an
HTML element with an `aria-hidden` attribute. However, by doing so the
ease of customizations for CONSUL installations is reduced, since
customizing ERB files is harder than customizing CSS.
Finally, font icons are infamous for not being that robust and
conflicting with UTF settings in certain browsers/devices. Recently Font
Awesome had a bug [3] because they added icons out of the Private Use
Area, and those icons could conflict with other UTF characters.
So, instead of loading Font Awesome icons with a font, we can add them
using their SVG files. There are several ways to do so, and all of them
solve the accessibility and robustness issues we've mentioned, so that
point won't be mentioned from now on.
All these techniques imply having to manually download Font Awesome
icons every time we upgrade Font Awesome, since the `font-awesome-sass`
gem doesn't include the `sprites/` and `svgs/` folders Font Awesome
includes in every release. So, from the maintenance poing of view,
they're all pretty lacking.
Method 1: SVG sprites with inline HTML
We can use SVG files where template icons are defined, like so:
<svg>
<use xlink:href="solid.svg#search"></use>
</svg>
This technique has great browser support and it only generates one HTTP
request for all icons. However, it requires adding <svg> tags in many
views, making it harder to customize for CONSUL installations. For
developers we could reduce the burden by adding a helper for these
icons.
Downloading all the icons just to use one (or a few) might also be
inconvenient, since the total file size of these icons will be up to a
megabyte. To reduce the impact of this issue, we could either minimize
the SVG file, compress it, or generate a file with just the icons we
use. However, generating that custom file would be harder to maintain.
Method 2: CSS with one SVG icon per file
We can use the separate SVG files provided by Font Awesome, like so:
background: url("solid/search.svg");
Or, if we want to add a color to the icon:
backgound: blue;
mask-image: url("solid/search.svg");
Using this technique will result in one HTTP request per icon, which
might affect performance. Browser support is also limited to browsers
supporting mask-image, which at the time of writing is 95% of the
browsers, with the notable exception of Internet Explorer 11.
On the plus side, using CSS makes it easy to customize and (IMHO) easy
to work with on a daily basis.
Method 3: CSS with SVG sprites
We can use the aforementioned sprites provided by Font Awesome and use
them with CSS:
backgound: blue;
mask-image: url("solid.svg#search");
The number of HTTP requests and file size are similar to Method 1, while
browser support, ease of customization and ease of use are similar to
Method 2.
There's one extra gotcha: this method requires doing minor changes to
the files provided by Font Awesome, which means this solution is harder
to maintain, since we'll have to do the same changes every time we
upgrade Font Awesome. Mainly we need to add these changes to every
sprite file:
- <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
+<!--
+This is a modified version of Font Awesome Free regular sprite file.
The icons are exactly as they originally were; the only changes are:
+
+* <symbol> tags have been replaced with <svg> tags and a <style> tag
has been added
+* A <style> tag has been added
+* The style="display:none" attribute of the main <svg> tag has been
removed
+-->
+<svg xmlns="http://www.w3.org/2000/svg">
+ <style>
+ svg svg { display: none }
+ svg svg:target { display: inline }
+ </style>
And then replace every <symbol> tag with a <svg> tag.
Method 4: CSS with Data URI
Finally, we can write the icons directly in the CSS:
backgound: blue;
mask-image: url('data:image/svg+xml;utf8,<svg...');
This method does not generate any extra HTTP requests and only downloads
the icons we need. However, maintaining it is really hard, since we need
to manually copy all the <svg> code for every icon we use, and do it
again every time we upgrade Font Awesome.
In this commit, we implement Method 2. To improve browser support, we're
falling back to font icons on browsers which don't support mask images.
So 5% of the browsers might still conflict with users changing the fonts
or with screen readers trying to announce the icon character. We believe
this is acceptable; the other option for these browsers would be to show
those icons as a background image, meaning the icons would always be
black, meaning users of these browsers would have trouble to distinguish
them if the background was dark as well.
Since we aren't sure whether the performance hit of having one HTTP
request per icon is overcome by only requesting the icons we actually
use, we aren't taking this factor into account when choosing between
methods 2 and 3. We believe this method will be the less painful one to
maintain and customize. Generating SVG sprites with just the icons we
use would increase performance, but it would make it harder for existing
CONSUL installations to use icons we haven't included in the sprites.
[1] https://speakerdeck.com/ninjanails/death-to-icon-fonts
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/content#Browser_compatibility
[3] https://blog.fontawesome.com/fixing-a-unicode-bug-in-5-14-0/
We were using `display: inline` assuming that's the way elements will be
displayed by default when shown. However, those elements could be
displayed in a different way (inline-flex, for instance). So we avoid
any possible conflicts by using the `display: none` rule when we want to
hide the elements.
Besides, the code is now symmetrical and IMHO easier to follow.
Even if "r" is shorter, "regular" is easier to understand, and we're
going to store these icons in a folder named "regular", which is the
convention Font Awesome uses.
In the past we were using some <div> tags surrounding table action
links in order to guarantee these links wouldn't be wider that their
cell's space and wouldn't expand over two lines.
However, while these links didn't expand over two lines, at certain
resolutions the width of their text exceeded the width of the links,
causing part of the text to be outside their borders.
This behavior was also inconsistent: some tables had these <div> tags,
and some tables didn't.
Since we've now introduced the table actions component, the code is more
consistent and we're getting rid of these <div> tags. So now we're again
facing the issue where links could expand over two lines.
Using a flex layout solves this issue and considerably improves the
layout at lower resolutions.
Instead of having a header with a bottom margin followed by an element
with a negative margin, it makes more sense to have no margin on either
element.
On high-resolution screens where neither the menu nor the main content
were filling the screen, there was a blank space at the bottom which
looked weird.
The <main> tag was including the navigation, and now we use the same
flex layout, making it more accessible for mobile phone users.
I'm not sure the <main> tag should actually include the account info and
the flash message. I'm keeping it like this in order to keep the layout
the way it was.
While Foundations's off-canvas menu allows us to forget about writing
CSS, it also leads to complicated HTML.
Ideally Foundation would provide an easy way to simplify what we're
doing, but I haven't found anything in the documentation.
We could simplify the HTML a bit more if we used a CSS grid layout
instead of a flex one, but old browsers have better support for the
latter.
Note we're using `breakpoint(medium)` so we can group the CSS for small
screens and follow SCSS-Lint rules at the same time.
Also note behavior of the main area when the menu appears on small
screens is slightly different: it doesn't move the main content to the
right. I've done it this way so we don't have any overflow issues,
unlike the previous version.
There's a small issue using a label and a checkbox to enable/disable the
menu: sighted keyboard users with a small screen might not be able to
enable the menu. So we're adding the `:focus-within` pseudoclass so the
menu can be normally navigated using the keyboard. Even if old browsers
don't support this pseudoclass, we believe the probability of a sighted
user using a small screen, navigating with the keyboard and using an old
browser is really low, particularly in the admin area.
We're also adding the `aria-hidden` attribute on the label, since the
menu is never hidden for screen readers and so having a control to show
it could be confusing. Since the label is not focusable, we're complying
with the fourth ARIA rule:
> Do not use role="presentation" or aria-hidden="true" on a focusable
> element .
>
> Using either of these on a focusable element will result in some users
> focusing on 'nothing'.
It was removed in commit 128a8164 because we hadn't reviewed it nor
tested it properly. We're now adding it again, fixing the issues we've
found while reviewing.
This way we can simplify the HTML and easily apply font awesome icons to
any element.
Note the mixin uses `extend`, which we generally try to avoid. It's OK
in this case, since `fa-` classes only have one rule, affecting the
content of its `::before` pseudo-element. Unfortunately we can't use
`include fa-content($fa-var-#{$icon})` because it's not valid SCSS. We
could make the mixin accept an icon instead of an icon name, and call it
using `has-fa-icon(r, $fa-var-plus-square)`. However, IMHO that would
make the code a bit more complex with no real benefit.
According to the jQuery upgrade guide:
> It is almost always a mistake to use .removeAttr("checked") on a DOM
> element. The only time it might be useful is if the DOM is later going
> to be serialized back to an HTML string. In all other cases,
> .prop("checked", false) should be used instead.
It worked differently after upgrading to jQuery 3. According to the
jQuery upgrade guide:
> It is almost always a mistake to use .removeAttr("checked") on a DOM
> element. The only time it might be useful is if the DOM is later going
> to be serialized back to an HTML string. In all other cases,
> .prop("checked", false) should be used instead.
We've had to add a couple of hacks in order to make jQuery UI datepicker
work with Turbolinks, and one of our tests is failing because the
datepicker changes its height when changing from a month with 5 weeks to
a month with 6 weeks.
We could add a workaround so the test still passes (jQuery UI doesn't
provide a configuration option to always displays 6 weeks in the
datepicker), but I think it's easier to just use the HTML5 native date
input field, which also allows us to simplify the code a bit and IMHO it
improves the user experience, particularly when using mobile phones.
Since date fields are not supported in Safari and Internet Explorer,
we're still using the jQuery UI datepicker on those browsers (and on any
other browser not supporting date fields).
Due to these changes, we're moving the tests checking datepicker's
behaviour to the dashboard. I've choosing not to change the public pages
because I'm not 100% sure everybody would like this change (some people
prefer the datepicker because we can configure the way it looks).
When Foundation initializes a page that has any sticky element, it
loads a window scroll listener into window object to handle the sticky
element positioning when scrolling. This works great until user moves
to a page without sticky elements and the window listeners remain
attached to the window object on this new page too when there is no
need to run the scrollListener and there is no sticky elements so the
window scroll listener cannot find the sticky object on that page a lot
of errors are thrown when user scrolls.
With this approach we are destroying sticky elements before leaving
the page which also remove the Sticky scrollListener from the window
object.
I do not know how to write a test to demonstrate this fix, but at least
there is some steps to reproduce this behavior:
0. Undo this commit
1. Go to any proposal page
2. Click on any link (with Turbolinks enabled)
3. Scroll the page
4. Check the console log. Yo will find as error occurrences as pixels you scrolled.
It's known that Foundation Sticky causes some renderization problems
when rendering sticky elements in anchored position.
The problem seems to be that Foundation Sticky is showing the
support box on medium and up devices overlapped with "Share" and
"Community" sidebar boxes when loading proposal page through
Turbolinks and when restoring the page from brwoser history.
Foundation seems to be doing some top property dynamic calculation
(javascript) and is setting top property to `206px` when it should be
`0px`. Notice that this do not happen on page first load (without
Turbolinks). Check foundation/foundation-sites issue 11098.
Another workaround could be to remove sticky feature for bigger that
small devices (medium large xlarge xxlarge).
Check foundation/foundation-sites issue 9892.
The JavaScript involved wasn't working since we removed the disable-date
attribute in commit 73ff6881.
We're also improving the JavaScript in two ways:
First, we trigger the `change` event immediately, so when the page loads
date fields are disabled when phases are disabled.
And second, we don't remove the selected dates when disabling a phase,
so disabling it and enabling it again will keep the selected values.
We were using a <label> tag with no associated field where a <legend>
tag was more appropriate. With a fieldset, we also make it obvious these
fields are related.
After updating foundation-rails in commit 58071fd6, the orbit slider
stopped working properly. That's because the `.orbit-slide` elements now
use a `position: absolute` rule, and so our rule for `.orbit-container`
elements making their height 100% (which we added in order to be able to
add images with different heights) makes them have a height of 0px,
since now the `.orbit-slide` elements are not part of the document flow
anymore.
Making the `.orbit-slide` elements have relative position fixes this
issue, but introduces a different one, producing a really bad-looking
animation when changing a slide.
So we're disabling the animation as well in order to avoid this jump.
This change also fixes another issue introduced in commit 58071fd6 which
caused slide controls to stop working when changing slides back and
forth.
Banners created through the admin form were getting the default color.
However, banners created by other means (like the `db:dev_seed` rake
task) were not getting these default values.
This feature was originally implemented when we were using Rails 4.
With Rails 5, we can provide default values to all new banners and
simplify the code at the same time thanks to its `attribute` method.
Now, when creating a new banner, instead of getting a blank space, we
get an empty line with the banner's default background color, which most
users won't know what it's about until they fill in the banner's title.
So we're not displaying the content of the banner when it's empty,
thanks to the `:empty` CSS pseudoclass.
In some sections we had negative top margins to compensate the header
bottom margin. However, when adding a banner between the header and
those sections, the negative margin caused the content of those sections
to overlap with the content of the banner.
Removing the negative margins when a banner is present solves the issue.
When a user recovers a page from browser history where placed a
marker in different map pane (visible map layer) marker was
successfully added to the map but the map center is the one
defined at Settings map properties so the marker was not visible
to the user.
Now when map_location form has valid coordinates we use them
instead of default map center settings. This will avoid the user to
have to rellocate the marker (or find the correct pane where the
marker was added) if already placed.
When using an editable map is better to load marker latitude, longitude and
map zoom from form fields so we can show the marker at latest position defined
by user when the page was restored from browser history.
To reproduce this behavior:
0. Undo this commit
1. Go to new proposal page
2. Place the proposal map marker
3. Go away to any other page
4. Restore new proposal page from browser history.
At this point you should not see the recently placed marker.
The same thing happens when editing a proposal.
If we do not do this a map could be initialized twice times or more
when restoring a page with a map causing weird UI effects and
loading some map layers also twice times or more.
Need to add a maps array to be able to store all initialized
(visible) maps so we can destroy them when needed. Notice that
we are destroying maps also when admin settings tabs changes
(only visible ones), this is again to avoid to re-initialize map more
than once when users navigate through settings tabs, another
option to the settings issue could be to detect if the map was
already initialized to skip uneeded initialization.
It was being duplicated when restoring a page by using browser
history. With this solution we will avoid to have screen readers
descriptions more than once inside any sociual share button.
We need to use page body event delegation so it will work with any
element even with the ones added through ajax, in this case the
annotation comments box form. By doing this way we do not need
this code on the server response anymore.
Furthermore JS events defined at ajax responses are not part of
application javascript and are lost when restoring a page from
browser cache, you can try to apply the same event delegation
technique to the `erb` file and it wont work just because events
added dinamically are not treated the same than `application.js`
code.
To reproduce the error:
1. Load an annotatable draft version
2. Move to any other page
3. Go back
Now "Publish comment" button wont work.
If we do not destroy annotator app before storing the page at
browser cache we will unnecesarily initialize annotations twice (or
more) duplicating Annotator HTML markup and causing
unexpected errors.
Without this commit you will find an error when restoring a page with
annotator, you can click on any annotation and you will see the annotation
comments are being loaded twice.
IMO this is an idempotency issue within Annotator JS library.
Patch extracted from here the comments on turbolinks issue 253 and
converted to vanilla javascript.
The hide action over datepickers ensures us that opened datepickers
will be closed before leving the page. Previously if you open any
datepicker and then move to previous page you will keep seeing the
datepicker in the restored page.
Turbolinks 5 handles page caching differently; it saves the current HTML
and, when the page is restored using the browser's back button, it
copies it and triggers the `turbolinks:load` event, which, in our case,
triggers our `initialize_modules` function.
This isn't a problem regarding event handlers, since they're removed
when caching the page (except fot the ones attached to the `document`).
However, it is a problem for functions that, once the document is ready,
scan the DOM and add certain elements. In this case, an element might be
added a second time when the page is restored.
So we need to either check an item has already been added before adding
it or remove it before caching the page. Since this is going to be a
common pattern, we're adding a function to handle these non-idempotent
parts of the application, so it mirrors our `initialize_modules`
function.
We're also moving the `destroy` function definition after the
`initialize` function definition, which makes more sense since we
initialize things before destroying them.
This is the reason why this feature was implemented in the first
place: it's easy to open the editor, make some changes, close it, and
continue without realizing the changes have not been saved.
In the rest of the forms, this functionality is quite lacking. For
starters, some forms warn if there are unsaved changes, while some forms
don't, which is highly inconsistent and disorients users.
Furthermore, we were having problems with this feature after upgrading
Turbolinks, particularly in forms using CKEditor. In these cases, a lot
of hacking needs to be done in order to make this feature work properly,
since CKEditor adds some formatting automatically, and if this is done
after the form is serialized, we'll get some unexpected behavior. On the
other hand, comparing the value of a textarea against its `defaultValue`
property will work on every edge case, including using the browser's
back button or reloading the page.
Finally, users are used to the way web forms work, and aren't used to be
asked for confirmation when they change their mind and decide to leave
the page without saving the changes. Asking them for confirmation will
be annoying in most cases. Besides that, if they accidentally leave the
page, they can use the browser's back button and they'll recover the
unsaved changes.
It's true this won't happen it they accidentally close the browser's
window, but our WatchFormChanges functionality didn't work in this case
either. Using the "beforeunload" event adds more problems than it
solves, since it doesn't support custom messages (or, to be more
precise, modern browsers ignore custom messages), and it doesn't get
along with turbolinks.
Co-Authored-By: Senén Rodero Rodríguez <senenrodero@gmail.com>
