Note we require extra <span> tags because the <progress> tag is an empty
tag (like <img>), and so it can't have ::before or ::after
pseudo-elements. There's a workaround for that, but currently it only
works on Chrome.
For some reason, the text seems to be slightly misaligned vertically in
all implementations I've tried. So the `top: -0.1rem` rule is a hack to
align it properly.
The selector `nth-child(even)` didn't need specific rules, and it's
easier to understand the code for the selector `nth-child(odd)` if all
breakpoints are grouped together.
According to the HTML specification:
> The default value is the minimum plus half the difference between the
> minimum and the maximum, unless the maximum is less than the minimum,
> in which case the default value is the minimum.
So for new progress bars, we had a numeric value of `nil` and a range
value of `50`, meaning the input fields weren't in sync.
Manually triggering the event on the progress, while not an ideal
solution (ideally we would be able to define `0` as default), sets the
value of the numeric field.
Show information about longitude and latitude in a budget heading
Show information about custom content in a budget heading
Fix render of map (zoom scrollable and points clickable)
Fix typo in app/models/map_location.rb
If we enabled the locale and then added an option, the "add option" link
added the partial which was generated before enabling the translation,
and so it generated a field where the translation was disabled.
Enabling the translation after inserting each field solves the issue.
Updating it required reorganizing the form so translatable fields are
together.
We also needed to add a `hint` option to the form label and input
methods so the hint wouldn't show up for every language.
Finally, the markdown editor needed to use the same globalize attributes
as inputs, labels and hints, which adds a bit of duplication.
This change forces us to use nested attributes for translations, instead
of using the more convenient `:"title_#{locale}"` methods.
On the other hand, we can use Rails' native `_destroy` attribute to
remove existing translations, so we don't have to use our custom
`delete_translations`, which was a bit buggy since it didn't consider
failed updates.
