Before the Tailwind 4 migration, checkboxes behaved as follows:
Light mode
checked → cyan bg + white checkmark
unchecked → white bg
Dark mode
checked → cyan bg + white checkmark
unchecked → dark bg
In the last commit, we fixed white-on-white, but because we removed
dark:bg-... as well, unchecked boxes in dark mode regressed to white,
standing out like a sore thumb against the dark background.
The current commit adds back the pre-migration behavior; it's not
actually a value-judgement on it other than "it was at least functioning".
(this non-value-judgement is directed at "do I really like cyan bg + white
checkmark in dark mode... I might not)
Fix#225
After upgrading to Tailwind 4, the styled checkbox showed no checkmark when
checked. DevTools inspection showed a white-on-white rendering: the checkmark
SVG was filled white while the background was also white. Removing the
bg-white class restores the intended text-* color, making the checkmark
visible again.
The class bg-white was added in 4c8fb20daa i.e. in our first attempt
to get a non-ugly checkbox styling; whether it was "ever needed for realz"
is of historic interest mostly.
Fix#225
Tailwind 3 -> 4 migration renamed `ring` -> `ring-3`, but colors like
`ring-cyan-200` were also changed to `ring-3-cyan-200` which doesn't
actually exist.
broken in ac8e2e8cd6
See #225 (the present commit is related, but not a full fix)
This more exactly expresses semantics by itself, and is also in preparation of
creating releases through the API (which have no triggering event)
See #146
"In principle" setting `SCRIPT_NAME` is enough. The way we do this is [1] using
`FORCE_SCRIPT_NAME` (which does not depend on messing with reverse proxy
settings and [2] by deducing the correct value from `BASE_URL` (which must be
set anyway) automatically.
By works I mean: `reverse` and `{% url` pick it up from there.
However, there are subtleties / extra work:
* `STATIC_URL` is needed too b/c https://code.djangoproject.com/ticket/34028
* in many pre-existing code I just created a path manually in the html. Such
hrefs are obviously not magically fixed for script_name. Rather than doing
the "full rewrite" (into `{% url`) this commit just prepends the
`script_name` in those cases. That's the way forward that will least likely
break and it gives us something to grep for if we ever want to 'do it
right'.
* `LOGIN_REDIRECT_URL` and `LOGIN_URL` needed to use a view-name for this to
work (using a view-name gets revolved using the thing that introduces
`script_name`)
Checked, no work needed:
* views (`redirect` and `HttpResponseRedirect`)
* html uses of action="..."
Fix#93
in the correct timezone, with smaller milis
According to the spec, this should work because:
> The timestamp of the breadcrumb. Recommended. A timestamp representing when
> the breadcrumb occurred. The format is either a string as defined in [RFC
> 3339](https://tools.ietf.org/html/rfc3339) or a numeric (integer or float)
> value representing the number of seconds that have elapsed since the [Unix
> epoch](https://en.wikipedia.org/wiki/Unix_time). Breadcrumbs are most useful
> when they include a timestamp, as it creates a timeline leading up to an
> event.
* The "collapse" etc. buttons get shown below the search box and < << >> > from
a certain width downwards.
* similar stacking for the date/type/value and the buttons at an even smaller width.
See #120
