Having it in _base.scss was breaking the mobile layout because it ended
up affecting the text-topic excerpts. This should be safer, since it was
really only intended to affect the new <details> blocks possible inside
user text anyway.
This was previously being done a bit manually in the JS and HTML, but
CSS can handle it like this, which simplifies some things (and also
takes the +/- out of the DOM, which is probably good in this case).
The base Spectre.css style for tables only has borders between rows, but
that can look pretty weird in larger tables. This is more of a normal
table styling.
Adds a couple of new utility functions, and replaces all the previous
checks that were based on lightness() with checks against
perceived-brightness() instead.
In the end, the only actual changes this makes to the CSS is flipping
the foreground color of error chips (topic tags with invalid characters)
in the Black and Atom One Dark themes.
Previously I've been using the built-in SASS lightness function, but
that doesn't necessarily always line up with how light we perceive a
color to be. This function seems to do a better job of matching up with
the "expected" result for a color.
If a user tries to post a link topic that's been posted before, this
will add a warning below the form with info about the previous posts and
ask them to confirm that they want to re-post. Currently, this doesn't
have any sort of time/group/etc. restrictions and will just find
previous topics from all time.
The method for doing this is a big ugly to be able to handle both the
no-JS and with-JS posting methods, but it's not too bad.
Previously, logging in would always send you to the home page. Now the
user will be sent back to whichever page they clicked the "Log in" link
from. Note that the destination is not validated, other than ensuring
that it starts with a "/" to prevent redirects to different sites.
Having this set to "auto" may be contributing to the layout shift while
the page is loading, since it doesn't know the size until the content is
loaded.
Chrome is showing a brief flash of the page rearranging while loading,
where it initially has the sidebar hidden but then it "pops in" and
moves the page to the left. I believe this is due to the HTML ordering
(the sidebar is after the main content) combined with it being hidden by
default, which prevents it from being included in the layout while the
main content is still being loaded.
This should hopefully resolve it, but may need some more changes still.
I haven't gone through the base stylelint rules yet, but this was from a
full look through all of the stylelint-scss ones, enabling all of the
ones that suit the SCSS style and doing the necessary fixups to the
code. Not many fixes were necessary, most was related to redundant "& >"
selectors that I didn't realize were unnecessary.
This is always weird when it wraps (especially on mobile, where it's
fairly common). You end up with weird cases like having "(500" after the
title and "words) on the next line.
This was too small - lists weren't really indented so they were a little
weird to read. The smaller margin for the nested ones is good though, so
this will leave that.
This replaces all the Solarized colors that were still left in the white
theme (except in syntax-highlighting), and tries to improve some of the
contrast. It can probably still use some work, but should be better
overall.
Now that we have the Edit/Preview tabs, having another line of text
above that feels pretty excessive. There are still some awkward uses of
this though, and the field should probably have a <label> element
regardless, so this will likely need some revisiting.
Previously the styling was just based on the <header> element, but that
ends up inadvertently styling any other <header>s inside comments, which
we don't necessarily want.
Previously, the flattening was starting at a very low threshold (above
depth 4) on all screen sizes. This changes it to be responsive, where
larger screens (generally) won't flatten until higher depth levels. On
desktop-size resolutions, it will probably be extremely rare to ever see
any flattened threads, since it will only happen at depth 20+.
These thresholds were picked pretty arbitrarily, but seemed decent from
some testing. I also kept the indentation size smaller until a larger
screen size, since the sidebar's appearance actually reduces the comment
tree space by a lot, and the indents are excessive until the screen is
quite large.
So far the most confusing aspect of the flattened single replies is when
there are sibling comments on the same level. For example, if a comment
has 2 replies (A and B) and A has one reply (C), the flattening would
put all of A, B, and C on the same indentation level as A C B. This was
confusing and made it hard to recognize where a subtree ended and it
went back to sibling comments.
This change makes it so that the flattening will only happen when there
are no siblings. This will reduce how often the flattening is applicable
somewhat, but also eliminates this confusing case entirely.
Deimos
deing
Jerome Leclanche
wirelyre
Petr Stastny