We had inconsistent indentation in many places. Now we're fixing them
and adding a linter to our CI so we don't accidentally introduce
inconsistent indentations again.
In some places, we accidentally opened the same tag twice instead of
closing it, while in some other places we closed a tag without opening
it in the first place.
We've detected these issues thanks to the HTML Beautifier gem, which
we're about to start using for indentation purposes.
Using an `if..else` block made the code harder to follow since the
opening tag was inside the block but the closing tag was outside it.
Moreover, it didn't work well with HTML Beautifier (a gem we're going to
introduce to manage ERB indentations).
This way we simplify the HTML, which had some `if...else` blocks that
were hard to follow because there were opening tags inside these blocks
while the closing tags were outside these blocks.
We're also making the CSS container-dependent instead of
window-dependent. Since there are between one and three elements inside
the panel, we accomplish this by making the element with the content
take its own line if the width of the panel is smaller than 35rem.
Note we're trying to keep the layout similar to what it was; since we're
no longer using negative margins (like the ones in the `.row` selector),
the votes element now gets a width of 22.5% instead of 25%.
Also note we're using the column-gap property for flexbox because the
`flex-with-gap` mixin doesn't work so well with elements that have
borders. Since the column-gap property for flexbox is now supperted by
more than 98% of the browsers (which wasn't the case when we started
using the `flex-with-gap` mixin), the `flex-with-gap` mixin has become
obsolete.
Finally, note we're removing the `max-width: 12rem` rule in the images.
I'm not sure why we introduced this rule in the first place, and it
didn't play so well to the new layout. I considered using code like
`max-width: min(100%, 12rem)`, but, since I'm not sure why `12rem` was
there in the first place, I'm not sure whether this approach was better,
and it sure made things more complex.
Not doing so made it trickier to define a flex layout, since the
icon-successful element is given a `position: absolute`, but only for
successful proposals, while for unsuccessful proposals it was taking
the standard `position: static` value.
We're also reusing the `successful?` method instead of rewriting it in
the view, and fixing a small issue where the icon wasn't displayed for
proposals having the exact needed votes (we were using `>` instead of
`>=` in the condition).
Note that legislation proposals use the method
`Proposal.votes_needed_for_success`, which is probaby a mistake caused
by copying the code from the proposal view. Fixing this issue is out of
the scope of this commit (and pull request), though.
With the multiline condition, HTML Beautifier (which we're about to
introduce in order to manage ERB indentation) gets confused. In this
context, a one-line condition is also more readable.
We had some duplication because the `css_for_process_header` was using
an instance variable, and so it couldn't be called from a partial where
this instance variable wasn't available.
Using a local variable and passing it as a parameter (as we should
always do) solves the issue and lets us simplify the code.
* The `gender-and-channel` class isn't use since commit e3063cd24f
* The `first-comment` class added in commit e5fb90f954 was never used
* The `additional-info` class added in commit d47ce39b37 was never used
* The `title-quote` class isn't use since commit f317514258
* The `big-number` class added in commit aa1ed87725 was never used
* The `big-number-stat` class isn't used since commit cf32dcd6d5
* The `budget-investment-amount` and `budget-investment-description`
classes added in commit 4ade8325d7 were never used
* The `debate-quiz` class isn't use since commit d679c1eb79
* The `enquiries-list` class isn't use since commit 6aa96c4471
* The `investment-project-content` class isn't use since commit d0b8fef6b3
* The `leave-comment` class isn't use since commit ff6285d114
* The `poll-question-show` class isn't use since commit 8277e3cc2b
* The `questions-callout` class isn't use since commit ddf8d5f811
* The `budget-investments-inner` class isn't used since commit c6a9ffc19
* The `map-attributtion` class isn't use since commit 5a09b79da4
* The `postfix` class isn't use since commit 3752f3a53b
* The `translation-locale` added in commit a6e8fecc16 was never used
* The `changes-link`, `comment-advice`, `show-comments` and `comment-votes-number`
classes aren't use since commit d679c1eb79
This stylelint-scss rule is useful because we were inconsistent when
using calc(); sometimes we added interpolation to Sass variables, and
sometimes we didn't. The reason why we originally added interpolation
was that it was necessary until we migrated to Dart Sass in commit
d54971e53. Since then, we can omit the interpolation, which is also what
the Sass documentation recommends [1].
[1] https://sass-lang.com/documentation/values/calculations/
We made a mistake when adding the `calc()` function in commit 6df813fdb,
since the `/` operator originally only affected the `$heading-icon-size`
part of the operation, but affected the whole operation after that
commit. This caused the icon to be positioned on top of another icon.
The interpolation of the rem-calc function made the code harder to read.
Besides, for new code we've already agreed upon using rem units instead
of `rem-calc`.
For instance, we had the following code:
```
width: calc(100% - #{2 * rem-calc(10)});
```
Now, `2 * rem-calc(10)` is the same as `rem-calc(20)`, but we were using
`2 *` to make it clear that this value was related to the value of the
`margin-left` property, which was `rem-calc(10)`.
IMHO using `0.625rem` for the margin and `2 * 0.625rem` for the width
the code is easier to read because there are no interpolation and no
complex operations involved.
We forgot to add the `calc()` function in commits 4c0b6455f, 390c749d2
and dc54fda71.
We were getting a warning when compiling the assets without the
`quiet_deps` option:
```
DEPRECATION WARNING: Using / for division outside of calc() is
deprecated and will be removed in Dart Sass 2.0.0.
Recommendation: math.div($line-height, 3) or calc($line-height / 3)
More info and automated migrator: https://sass-lang.com/d/slash-div
```
Set cookie duration to 365 days based on the AEPD's cookie usage guidelines.
Note from the document: "Cookies with a duration of up to 24 months are
considered acceptable as long as they are periodically updated."
Reference: https://www.aepd.es/guias/guia-cookies.pdf
Create cookie consent "all" when accept all cookies
Set cookie duration to 365 days based on the AEPD's cookie usage guidelines.
Note from the document: "Cookies with a duration of up to 24 months are
considered acceptable as long as they are periodically updated."
Reference: https://www.aepd.es/guias/guia-cookies.pdf
Note that in order to avoid display duplicated vertical scroll when
render a modal, we are add an `overflow: unset` rule. This rule
overwrite a vendor rule both in the modal we are adding and in the
modal we already have when creating a budget in admin section.
Set cookie duration to 365 days based on the AEPD's cookie usage guidelines.
Note from the document: "Cookies with a duration of up to 24 months are
considered acceptable as long as they are periodically updated."
Reference: https://www.aepd.es/guias/guia-cookies.pdf
Allow enabling from settings admin section.
Note that we set the z-index to 20 in order to will be greater than
the others z-index elements in the application like <header> on
mobile devices.
With this change, on my browser, reloading a page in development after
changing a CSS file is about 25% faster than simply splitting the CSS
code between `application.css` and `vendored.css`. Compared to using
only one `application.css` file containing everything, reloading a page
in development is about 35% faster.
The combined size of all the generated stylesheets is now about 0.5%
bigger. Not sure why (maybe placeholder selectors?), but the difference
is negligible.
Note that we could load the `administration.css` file only in the admin
area, reducing the size of the page for people accessing the public
area. However, the size of this stylesheet (compressed) is 28K, which is
less than 3% of the overall size of a page and, on the other hand,
there's a risk of some styles no longer being applied because we might
have overlooked the fact that some styles in the `administration.css`
are also applied to the public area.
So, for now, we're still loading the administration styles in the public
area. We might reconsider in the future.
With this change, on my browser, reloading a page in development after
changing a CSS file is about 10%-15% faster.
On the minus side, this change results in an extra request when browsing
the page; AFAIK it isn't that big of a deal, even when the server isn't
using HTTP/2.
These styles are used in places other than the admin section. In
particular, the `.button.small.success` style is no longer used in the
admin section but only in the verified user form.
Note: I'm not sure whether the `table .callout` selector matches any
element, either in the admin or in the public section, so I'm leaving it
where it was.
It was only used once, and we can use a selector that makes it obvious
where it is used. Besides, the style for the no-margin-bottom class was
to remove the bottom margin, which was inconsistent with the style for
the no-margin-top class, which adds a negative margin to the element.
I'm not sure why we're removing the margin here, though, since it isn't
consistent with the rest of the forms in the application. For now, we're
keeping it the way it used to look.
* The `archived` class isn't used since commit cd982768f
* The `ignored` class isn't used since commit 343025872
* The `count-error` class isn't used since commit bddfee2b8
* The `edit-legislation-draft-version`, `edit-legislation-process` and
`legislation-questions-answers` classes aren't used since commit
d679c1eb7
* The `legislation-process-save`, `legislation-question-delete`,
`legislation-process-version` and `legislation-process-question`
classes aren't used since commit f8707a73cd
* The `is-featured` class isn't used since e60ffa3c0
* The `on-hover` and `on-hover-block` classes aren't used since commit
d91388b2b
* The `total-price` class isn't used since commit d0b8fef6b
* The `login-as` class was never used in the first place
According to the GeoJSON specification [1]:
> * A linear ring is a closed LineString with four or more positions.
> * The first and last positions are equivalent, and they MUST contain
> identical values; their representation SHOULD also be identical.
> (...)
> * For type "Polygon", the "coordinates" member MUST be an array of
> linear ring coordinate arrays.
Note that, for simplicity, right now we aren't checking whether the
coordinates are defined counterclockwise for exterior rings and
clockwise for interior rings, which is what the specification expects.
[1] https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.6
