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.
This option was originally added in issue #1747. But only ~350 users
ever disabled autocomplete, only ~120 of these were seen in the last
year, and only 9 new users who signed up in the last year disabled it.
Users wishing to disable autocomplete can use this CSS:
.ui-autocomplete { display: none !important: }
or this Javascript:
$("[data-autocomplete]").autocomplete("disable");
Remove the enable_post_navigation option. This option was originally
added to disable the next/prev post navbar beneath posts. It was later
repurposed to disable keyboard shortcuts.
Users who don't want keyboard shortcuts are advised to not press random
buttons on the keyboard like a caveman.
Only ~1200 users disabled this option and only ~600 were seen in the
last year.
Refactor the post preview html to use the ViewComponent framework. This
lets us encapsulate all the HTML, CSS, and helper methods for a UI
component in a single place.
See https://viewcomponent.org.
Add a Restricted user level. Restricted users are level 10, below
Members. New users start out as Restricted if they sign up from a proxy
or an IP recently used by another user.
Restricted users can't update or edit any public content on the site
until they verify their email address, at which point they're promoted
to Member. Restricted users are only allowed to do personal actions
like keep favorites, keep favgroups and saved searches, mark dmails as
read or deleted, or mark forum posts as read.
The restricted state already existed before, the only change here is
that now it's an actual user level instead of a hidden state. Before it
was based on two hidden flags on the user, the `requires_verification`
flag (set when a user signs up from a proxy, etc), and the `is_verified`
flag (set after the user verifies their email). Making it a user level
means that now the Restricted status will be shown publicly.
Introducing a new level below Member means that we have to change every
`is_member?` check to `!is_anonymous` for every place where we used
`is_member?` to check that the current user is logged in.
