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
Note we're adding a `name` property to the geozones investments sidebar
map even if we don't render the geozones in the map, in order to
simplify the JavaScript function `geozoneLayers`.
We're reworking the format validation to correctly interpret feature
collection, feature, and geometry, according to RFC 7946 [1].
Since Leaflet interprets GeoJSON format, we're rendering the GeoJSON as
a layer instead of as a set of points. For that, we're normalizing the
GeoJSON to make sure it contains either a Feature or a
FeatureCollection. We're also adding the Leaflet images to the assets
path so the markers used for point geometries are rendered correctly.
Note we no longer allow a GeoJSON containing a geometry but not a
defined type. Since there might be invalid GeoJSON in existing Consul
Democracy databases, we're normalizing these existing geometry objects
to be part of a feature object.
We're also wrapping the outline points in a FeatureCollection object
because most of the large GIS systems eg ArcGIS, QGIS export geojson as
a complete FeatureCollection.
[1] https://datatracker.ietf.org/doc/html/rfc7946
Co-authored-by: Javi Martín <javim@elretirao.net>
It looks like not all screen readers identify SVG images with empty aria
labels as a decorative image, as reported by the Axe accessibility
engine.
So we're using `aria-hidden` instead, since we don't want the text of
the SVG to be read by screen readers. We're using `aria-hidden` instead
of the `presentation` role for the reasons mentioned in commit
35659d441.
We're using the `aria-label` attribute instead of a label because this
is a page where only one field is rendered and the text of the label is
the same as the text of the <h1> tag.
We're using `aria-label` instead of `aria-labelledby` because the former
is supported by Capybara.
In order for this attribute to be applied, due to the syntax of the
`select` method, it should be in a separate hash.
We're removing it instead of correctly applying it because we never use
the `tabindex` attribute with a positive value, since it might break
keyboard navigation.
We were using one label for both date selectors, but it wasn't
associated with any of them.
So we're now rendering one label per control and, just like we only show
one of these date selectors at a time, we're only showing one label at a
time.
The default `date_select` used in fields presents an accessibility
issue, because in generates three select controls but only one label.
That means that there are two controls without a label.
So we're using a date field instead. This type is field is supported by
about 99% of the browsers, and we've already got JavaScript code
converting this field to a jQuery UI datepicker in case the browser
doesn't support date fields.
Note that, since we no longer need to parse the three date fields into
one, we can simplify the code in both the models and the tests.
Another slight improvement is that, previously, we couldn't restrict the
month and day controls in order to set the minimum date, so the maximum
selectable date was always the 31st of December of the year set by the
minimum age setting. As seen in the component test, now that we use only
one field, we can set a specific date as the maximum one.
We reduce code duplication thanks to that, and make it easier
to change this field.
Note that there was one place where the "16.years" value was
hardcoded. We're moving the test for this case to the
component and changing it so the test doesn't use the default
age.
We're also removing the redundant helper method that had the
same code as a method in the User class which is called
everywhere else.
Note that adding the labels broke the layout because the button was no
longer aligned with the fields, so we're now using a flex layout.
Since we're using labels, we no longer need a placeholder (which wasn't
very informative, by the way) in the text field.
The `clear` class isn't needed since commit c9f31b8e1, when we moved
this button above the regular search fields.
We're also moving the `float` property to the CSS file.
The text for the unfeasible checkbox wasn't correctly defined as a
label, while the fields to search investments and select the heading
weren't intuitive since their purpose wasn't obvious.
With a 50% width on medium and large screens, depending on the size of
the text and the size of the screen, the label could unnecessarily use
two rows, looking broken.
Since the main stats index loads this JavaScript using
`"data-turbolinks-track" => "reload"`, going from the stats index to a
section that doesn't include this JavaScript did the strange effect
Turbolinks does in these situations: it first loaded the page using an
AJAX request and, after getting the contents of the page, it reloaded it
in order to apply the changes in the included JavaScript.
This behavior was a bit confusing, particularly when browsing to a
section of the admin stats, clicking the browser's back button to go
back to the stats index, the going to another section, ...
One of the admin stats tests was failing sometimes with this message:
```
1) Stats Budget investments Supporting phase Number of users and
supports in investment projects
Failure/Error: raise ex, cause: cause
Selenium::WebDriver::Error::UnknownError:
unknown error: unhandled inspector error:
{"code":-32000,"message":"Node with given id does not belong to the document"}
(Session info: chrome=129.0.6668.89)
```
This was probably caused by the mentioned Turbolinks behavior that loads
the page twice. It's possible that Selenium was somehow checking the
node related to the first request when the second request had finished.
Avoiding that double request solves the issue.
This way it'll be easier for people using screen readers to know which
element the checkbox is related to.
Note that we're using the `aria-label` attribute because it makes
testing with Capybara easier than using the `aria-labelledby` attribute.
The only exception are the comments, since comments don't have a title
and there isn't a proper label for them. In this case, we're using the
title of the associated commentable as the label; we might change it in
the future since there might be many comments for the same commentable.
