Note that in Ruby files this rule allows vertical alignment, but doesn't
seem to do the same in ERB. Since we only used vertical alignment in one
place, and that place also had an unneeded extra space on every aligned
line, I've decided to change the code in that place and follow the rule.
This way we won't have to add the `inline-block` and `no-bullet` classes
to other elements and we can define the styles in one place.
Note we're using the `ul.tags` selector instead of just `.tags` to avoid
conflicts with a `div.tags` selector which is used to select tags in a
form. Renaming the selector to `.tag-list` would be better, but we
aren't doing so because it would break custom stylesheets using that
selector.
Also note we're keeping the %tags placeholder selector in `.tags`
selector in the participation.scss file. This is so styles are not
overwritten by selectors like `.debate-show ul li`, which has the same
specifity as `ul.tags li`.
We were writing the same code twice, with the only difference being the
text "Sign up" in the sign_up action, and "Sign in" in the sign_in
action.
Note we're renaming the `omniauth.info_*` I18n keys so we don't need to
add new exceptions to the `ignore_unused` list, and so it's consistent
with all the other keys under the `omniauth` key.
In most of the rest of the application the buttons are shown in this
way, we do this little adjustment to improve the consistency with the
rest of the application
Using the `_html` suffix in an i18n key is the same as using `html_safe`
on it, which means that translation could potentially be used for XSS
attacks.
Sometimes we're interpolating a link inside a translation, and marking
the whole translations as HTML safe.
However, some translations added by admins to the database or through
crowdin are not entirely under our control.
Although AFAIK crowdin checks for potential cross-site scripting
attacks, it's a good practice to sanitize parts of a string potentially
out of our control before marking the string as HTML safe.
Using the block syntax to generate the label with a <span> tag inside
isn't necessary after upgrading foundation_rails_helpers. Before the
upgrade, we couldn't do so because the <span> tag was escaped.
DEPRECATION WARNING: [Devise] `DeviseHelper.devise_error_messages!`
is deprecated and it will be removed in the next major version.
To customize the errors styles please run `rails g devise:views` and
modify the `devise/shared/error_messages` partial.
We will render the resource errors instead fo calling the deprecated method.
Dashboard routes have been refactored. Now instead of having resources
for dashboard and routes inside a dashboard namespace the proposal
routes contain a dashboar singleton containing everything related to it.
