Make related tags use a single-column layout on mobile.
Related tags layout is still broken inside the tag edit dialog box, when
the dialog box is too small for multiple columns.
* Use -webkit-text-stroke instead of bold to indicate selected tags.
Bold causes the tag to change width, which is jarring and can cause
the tag to wrap around to a new line. -webkit-text-stroke doesn't
change the tag's width. Despite the name, this property is widely
supported.
* Don't wrap the checkbox in a label. In combination with flexbox, this
made the hitbox for the tag too big. You could click on empty space
outside the tag and it would still toggle the tag.
Instead of changing the background color of the entire page when you
change modes in the post mode menu (which was ugly, and not obvious what
the colors meant), show a notice and make it so that hovering a post
gives it a blue outline. This indicates that clicking the post will do
something different.
Fix issues with note sizing caused by the switch to `box-sizing: border-box`
in 19aea560. Note boxes have a 1px black border, which is counted as
part of the note box width when using border-box. This threw off sizing
and position calculations.
Also go back to 1px borders instead of 2px borders for unsaved and
selected notes. This also messed up note sizing.
* Standardize dialog box and tooltip box shadows.
* Add shadows behind all other floating elements, namely the
autocomplete menu and translation notes (except for embedded notes,
which are usually meant to be seamless).
Remove some rules intended to highlight the currently selected tag in
the autocomplete menu. The selected tag was supposed to be shown with
the tag hover color, but this didn't actually work because of CSS
specificity issues, and it possibly never worked to begin with, so it's
not worth fixing.
Partial revert of b9ea9d2f5. Go back to using a semi-transparent
background to indicate the selected parent/child post, but add more
padding and adjust the transparency to make it more legible.
In the related tags list, use checkboxes and bold to indicate selected
tags, instead of highlighting selected tags with a blue background.
This is so that you can see the colors of selected tags in the related
tags list, and in particular so you can see the artist tag.
Change the new, approved, pending, and rejected labels in the forum to
use an outlined pill style (like user levels in user tooltips) instead
of a filled background style. This is less obtrusive and more readable
in dark mode.
* Fix it so that all edit forms show an error banner if the form
has validation errors. Previously forms had to manually call
`error_messages_for`, which not all forms did.
* Fix it so that the full validation error message is shown next to each
input attribute that had errors. Also update the styling of these
error messages to look better.
* On the post show page, in the parent/child box, change it so that
currently selected post is more visible. Use a light blue outline
around the current post instead of a dark semi-transparent border.
* Fix it so that there's less empty space around thumbnails in the
parent/child box.
Add a new color palette and rework all site colors (both light mode and dark mode) to
use the new palette.
This ensures that colors are used consistently, from a carefully designed color palette,
instead of being chosen at random.
Before, colors in light mode were chosen on an ad-hoc basis, which resulted in a lot of
random colors and inconsistent design.
The new palette has 7 hues: red, orange, yellow, green, blue, azure (a lighter blue), and
purple. There's also a greyscale. Each hue has 10 shades of brightness, which (including
grey) gives us 80 total colors.
Colors are named like this:
var(--red-0); /* very light red */
var(--red-2); /* light red */
var(--red-5); /* medium red */
var(--red-7); /* dark red */
var(--red-9); /* very dark red */
var(--green-7); /* dark green */
var(--blue-5); /* medium blue */
var(--purple-3); /* light purple */
/* etc */
The color palette is designed to meet the following criteria:
* To have close equivalents to the main colors used in the old color scheme,
especially tag colors, so that changes to major colors are minimized.
* To produce a set of colors that can be used as as main text colors, as background
colors, and as accent colors, both in light mode and dark mode.
* To ensure that colors at the same brightness level have the same perceived brightness.
Green-4, blue-4, red-4, purple-4, etc should all have the same brightness and contrast
ratios. This way colors look balanced. This is actually a difficult problem, because human
color perception is non-linear, so you can't just scale brightness values linearly.
There's a color palette test page at https://danbooru.donmai/static/colors
Notable changes to colors in light mode:
* Username colors are the same as tag colors.
* Copyright tags are a deeper purple.
* Builders are a deeper purple (fixes#4626).
* Moderators are green.
* Gold users are orange.
* Parent borders are a darker green.
* Child borders are a darker orange.
* Unsaved notes have a thicker red border.
* Selected notes have a thicker blue (not green) border.
* Refactor the paginator into a ViewComponent.
* Fix inconsistent spacing between paginator items.
* Fix a bug where the sequential paginator generated the wrong next /
previous page links in the <link rel="{next|prev}"> tags in the <head>.
* Always include the final page as a hidden html element, so that it can
be unhidden with custom CSS.
* Make it easier to change the pagination window.
This makes it so that an element's width includes borders and padding,
so that borders or padding don't cause an element to exceed its
specified width. This is a standard part of most CSS resets.
https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing
Increase the font weight from 200 to 400 for the IBM Plex Mono font used
in notes. 400 is the standard weight we use for other fonts. 200 made
the font too thin and hard to read at normal font sizes.
Adjust input boxes to fit the screen better on mobile, and to use
consistent sizes throughout the site (no ad-hoc overrides to make
certain input boxes a bit bigger in random places).
On desktop, this makes most input boxes a bit taller and narrower. On
mobile, it makes input boxes the full width of the screen.
This most notably affects the tag edit box, the comment and forum
post box, the wiki page edit box, and the commentary box.
Refactor CSS to use standard Tailwind-style utility classes instead of
ad-hoc rules. This eliminates a lot of single-purpose rules for specific
UI elements and standardizes margins to be more consistent throughout
the site.
Utility classes are defined manually on an as-needed basis instead of
importing Tailwind as a whole. Naming conventions mostly follow
Tailwind's conventions, otherwise they follow Bootstrap.
* https://tailwindcss.com/docs/
* https://getbootstrap.com/docs/5.0/utilities/spacing/
Add the ability to restrict API keys so that they can only be used with
certain IP addresses or certain API endpoints.
Restricting your key is useful to limit damage in case it gets leaked or
stolen. For example, if your key is on a remote server and it gets
hacked, or if you accidentally check-in your key to Github.
Restricting your key's API permissions is useful if a third-party app or
script wants your key, but you don't want to give full access to your
account.
If you're an app or userscript developer, and your app needs an API key
from the user, you should only request a key with the minimum
permissions needed by your app.
If you have a privileged account, and you have scripts running under
your account, you are highly encouraged to restrict your key to limit
damage in case your key gets leaked or stolen.
* Add an explanation of what an API key is and how to use it.
* Make it possible for the site owner to view all API keys.
* Remove the requirement to re-enter your password before you can view
your API key (to be reworked).
* Move the API key controller from maintenance/user/api_keys_controller.rb
to a top level controller.
Regression caused by the upgrade to Webpacker 6.0 in 90cd3293e. This
caused various Javascript errors in old versions of Chrome, which
somehow resulted in the keyboard shortcut for visiting the next page
being triggered when you pressed any key.
Specifically, the mobx library (used by the TagCounter component) called
`Object.entries`, which isn't available in Chrome 49, and for some
unknown reason this triggered the buggy shortcut behavior.
`Object.entries` is supposed to be automatically polyfilled by Babel to
support old browsers, but something changed in Webpacker 6 that broke
this and I couldn't get it working again. The probable cause is that
Webpacker 6 no longer transpiles code inside ./node_modules by default,
which means that any libraries we use that use new Javascript features
won't get transpiled down to support old browsers, but even after fixing
that it still didn't work. The workaround is to just drop mobx and
preact entirely to avoid the issue.
On the post show page, define the next page / previous page keyboard
shortcuts in html using data-shortcut attributes instead of in
Javascript. This is consistent with how these shortcuts are defined on
the post index page.
* Factor out the post navbar into a component. The post navbar is the
part of the post containing the current search, the list of pools, and
the list of favgroups, along with next/prev navigation links.
* Change navbar markup: remove various unused CSS classes/IDs, change
pools to use same markup as favgroups, replace nested <div>'s with
flat <ul>/<li> list.
* Use CSS to truncate long searches/pool names/favgroup names if they're
too wide for the screen (especially on mobile).
Broken in 49bc2364 by the use of @extend.
Here's what happened. There are two CSS rules that both apply to pool links:
* a:link { color: var(--link-color); }
* .pool-category-series a { color: var(--series-pool-color); }
These rules have equal specificity (0-1-1). This means the rule that is
defined last takes priority. This means the order in which CSS files are
included matters. 49bc2364 used the @extend directive in a rule for
popup menus, which required an @import, which changed the order of the
CSS files, which made the a:link rule suddenly take priority over the
series pool rule.
The proper fix would be to use Sass's new @use directive instead of
@import, but that requires the latest version of Sass, which requires
the latest version of Webpacker, which we can't upgrade to yet because
of breaking changes.
The real moral of the story is: our CSS is very fragile because of
specificity rules. It's very important that rules are defined in a
certain order, otherwise our CSS will break.
* https://sass-lang.com/documentation/at-rules/use
* https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
Factor out FontAwesome icons into a set of helpers. This is so that it's
easier to keep track of which icons we're using and easier to change
icons globally.
Change [quote] styling to Reddit/Github style (greyed out, with a bar on
the left side) instead of traditional forum style (big grey box around
the quote).
Reasons for this change:
* Box style is bulkier, especially for short quotes in comments.
* Box style works poorly for deeply nested quotes.
* Box style looks bad on widescreen monitors, since the quote stretches
across the full width of the screen.
* Add comment scores.
* Rework voting buttons so that you can click the upvote/downvote
buttons to toggle votes.
* Hide the edit, delete, undelete, and report buttons behind a popup menu.
* Show the upvote/downvote/reply buttons to logged out users. Redirect
them to the login page instead.
Previously thresholded comments were hidden completely. You had to click
the "Show X hidden comments" button to unhide all hidden comments in a
thread. Now it works like this:
* When a comment is below your threshold, the comment text is hidden and
replaced by a `[hidden]` link, which you can click to unhide the comment.
* When a comment is at half your threshold (for example, your threshold
is -8 but the comment is at -4), then the comment is greyed out.
This means that comments aren't completely hidden, they're just
collapsed, so you can see the commenter and the score without unhiding
the comment. It also means you don't have to scroll back up to unhide a
comment, and threads aren't disrupted by comments being secretly
hidden (which is confusing when people are replying to hidden comments,
which forces you to go back up and unhide to find).
The normalization always ends up being less than a pixels difference,
and the clamp applied later on removes that difference. Before the
clamp was added, it had the effect of moving the box along it's angle
of rotation. Now it moves it along the x,y axis of the image itself,
which is probably more intuitive anyways.
It's still needed for the drag and drop though, otherwise, it displaces
by a certain amount making it impossible to accurately place.
