It's August 2025 and support for grid layout has been available in about
99% of the browsers for some time now. All major browsers added support
for grid layouts in 2017, which means our rule to support browsers that
are 7 years old allows us to start using `display: grid`.
Using a grid layout allows displaying a dynamic number of rows while
keepin all of them the same height, the same foundation's equalizer
does, by setting `grid-auto-rows: 1fr`.
And the `grid-template-columns` property lets us use dynamic columns for
all screen sizes, always filling the available space. No need to use
breakpoints.
The problem with "recommended" is that it had identical singular and
plural, which means it wasn't clear whether we were using it to refer to
an item of a collection or to refer to the collection itself.
We're also removing the padding in the (now called) followables element,
since it caused a gap on the right side of the border of the
`.menu.simple` element.
Note we aren't using flex-with-gap because currently (until we decide to
use the `gap` property) this mixin sets a negative margin that would
move the border of this element to the left.
This way we remove duplication in the HTML.
We're also adding a test checking what happens when users can vote in
order to test the `render?` method we've added.
Currently dependabot is failing to upgrade some gems that are part of
Rails. For example, when there's a security issue in ActiveRecord or
ActiveStorage, we get messages like:
```
Dependabot cannot update activestorage to a non-vulnerable version.
The latest possible version that can be installed is 7.1.5.1 because of
the following conflicting dependencies:
rails (7.1.5.1) requires activestorage (= 7.1.5.1) via actionmailbox (7.1.5.1)
rails (7.1.5.1) requires activestorage (= 7.1.5.1) via actiontext (7.1.5.1)
rails (7.1.5.1) requires activestorage (= 7.1.5.1)
The earliest fixed version is 7.1.5.2.
```
So we're relaxing the dependency in order to make it easier for
dependabot to upgrade gems that are part of Rails.
Note that, with this configuration, Dependabot wouldn't be able to
upgrade to Rails 7.1.6 if this releases fixed a security issues in a gem
that is part of Rails. We might still need to upgrade Rails manually in
this case.
This way polls look more similar to the way they did when the answers
were buttons instead of checkboxes or radio buttons.
Note the styling is tricky because we need to add a `float` property to
the legend so it's actually inside the fieldset. This forces us to add a
`::before` pseudo-element in order to add margin between the legend and
the first label. Another option would be:
```
legend {
&:has(+ label) {
margin-bottom: calc($line-height / 2);
}
+ label {
clear: $global-left;
}
}
```
But the `:has` pseudo-class isn't universally supported yet, and we'd
still have to add `margin-top` to the first label when it comes after a
`.help-text` element.
Due to the presence of the border, we're increasing the margin between
elements a little bit.
Note that adding a pseudoelement to the label is a consequence of adding
the `float` property to the legend, so we're changing the order of the
code so the styles for `legend` appear before the styles in `label`.
This could be the case when JavaScript is disabled.
Note that, in `Poll/WebVote` we're calling `given_answers` inside a
transaction. Putting this code before the transaction resulted in a test
failing sometimes, probably because of a bug that might be possible to
reproduce by doing simultaneous requests.
With the old interface, there wasn't a clear way to send a blank ballot.
But now that we've got a form, there's an easy way: clicking on "Vote"
while leaving the form blank.
Some of the code was in its own component, while some of the code
remained in the polls/show view.
Note that we're re-structuring the code a little bit, so it's clear that
the "already voted" messages are only shown when users can vote. Also
note that now the `can?` condition involves the existence of a
`current_user` and that the poll is not expired, so we can simplify the
`voted_in_web` condition.
This way it'll be easier to refactor it.
Note there was a system test which tested both the callout and the form
when unverified users visit a poll. We've split this system test in two
component tests.
Our original interface to vote in a poll had a few issues:
* Since there was no button to send the form, it wasn't clear that
selecting an option would automatically store it in the database.
* The interface was almost identical for single-choice questions and
multiple-choice questions, which made it hard to know which type of
question we were answering.
* Adding other type of questions, like open answers, was hard since we
would have to add a different submit button for each answer.
So we're now using radio buttons for single-choice questions and
checkboxes for multiple-choice questions, which are the native controls
designed for these purposes, and a button to send the whole form.
Since we don't have a database table for poll ballots like we have for
budget ballots, we're adding a new `Poll::WebVote` model to manage poll
ballots. We're using WebVote instead of Ballot or Vote because they
could be mistaken with other vote classes.
Note that browsers don't allow removing answers with radio buttons, so
once somebody has voted in a single-choice question, they can't remove
the vote unless they manually edit their HTML. This is the same behavior
we had before commit 7df0e9a96.
As mentioned in c2010f975, we're now adding the `ChangeByZero` rubocop
rule, since we've removed the test that used `and change`.
Until now, when writing `create(:poll_answer, option: option)`, the
`answer` field would take the title of a random option instead of taking
the title from the `option` variable.
So now, if we're given the option, the `answer` field will be taken from
the option itself.
Note that writing something like:
```
option { question.question_options.find_by(title: answer) }
answer { option.title }
```
Would create an infinite loop when creating a poll answer if we don't
pass the `option` and/or the `answer` attributes.
So, instead, we're making the `option` depend on the `answer` attribute
exclusively when we pass the `answer` attribute to the factory.
We used `margin-left` in commit b4eba055c, but when using right-to-left
layout, the property we should use is `margin-right`. So we're using
`margin-#{$global-left}` as usual.
We were using a `height: $line-height` property for this task. One of
the disadvantages of this approach is that things don't look so great
when the label expands over more than one line.
Back when we added that property, browser support for flex layouts
wasn't that great. Now there's universal support for it, so we can use
it instead.
This way changing it will be easier.
Note we're moving the `legislation-draft-versions-form` class into the
form component itself, which is wat we usually do in components.
This way changing it will be easier.
Note we're changing the name of the HTML class to follow our naming
conventions; the `edit_page` class wasn't used anywhere, so we don't
need to change anything else.
