Previously the collapsed <details> would match the width of their
content, but this made them a little harder to recognize, and were
difficult to click on in (unusual) cases such as using a link as the
<summary>. Having them full-width like this should be fine with the
border, and fix those issues.
Previews for large wiki pages were failing because their maximum length
is a lot longer than comments'. Basing it on a specific markdown
"location" isn't ideal, but wiki pages will almost certainly always be
the longest, so it's probably fine.
If a user has topic visit-tracking enabled, this makes it so that the
comments link will jump directly to the comments section when returning
to a topic that they've visited previously. This is mostly useful with
long text topics so you don't always have to scroll past all the text.
It might also be good to apply this to the title link for text topics,
but I'm not sure if many people click on that with the bright "(x new)"
drawing their attention.
Most tables have a created_time column, so this will be usable on most
models and is more convenient and readable than always needing to
subtract from utc_now().
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).
Eventually it might be a good idea to have these link to lists of pages
inside each folder (or maybe fall back to that if an index page doesn't
exist), but this is good for now.
Not needed for much yet, but should be used here anyway to prevent
"new_page" pages from being created inside folders (which isn't possible
yet anyway).
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.
Currently, there's no way for users to put pages inside folders, but
that can probably be added in the future. This will allow the
~tildes.official wiki to continue working even though some of the pages
have now been moved into folders to match up with the Docs site.
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.
This will break an install if people copy this file and don't set or
remove this, so it should probably be commented out by default and let
people un-comment if they actually want to use it.
<small> is a better element for doing "side comments" instead of having
people hijack <sup> for that purpose. It will have to be typed in
manually since there's no markdown syntax for it, but I think it's good
to allow.
Previously, either double or single tildes would work for strikethrough.
However, this had some strange edge cases, such as attempting to
strikethrough some words that contain a group reference. Since Tildes
uses single tildes for other purposes, it should be much less ambiguous
overall to just force double tildes for strikethrough like this.
This will affect a small number of past posts, in both good and bad
ways (getting rid of some strikethrough, but fixing some accidental
ones).
If you search while inside a group, it will now search only inside that
group. A note at the top of the results page will explain this, and
includes a link to search across all groups instead.
There are occasionally some data conflicts between the Embedly scraper
and the dedicated YouTube one (which uses their API). The Embedly
scraper has also recently started supplying "content" for YouTube
videos, which ends up with Tildes displaying a word count for it. That
doesn't make much sense.
Just leaving the YouTube-scraping to the API client should be fine.
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.
Someone has been spamming the donation form to test credit card info
lately, with a bunch of $1 charges that almost all get rejected by
Stripe.
They don't seem to change IP addresses most of the time, so this should
make a little harder for them to do, anyway.
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.
Josh Arrington
Deimos
deing
Bauke