Previously I was just using Jinja's built-in loop.depth0 to output
comment depth in HTML, but actually attaching a depth attribute to the
comments will allow it to be used elsewhere as well. It's possible this
should even be on the Comment model itself, since it never changes and
might be useful in other ways.
The post buttons (Reply, Delete, etc.) were converted to <button> quite
a while ago, and these ones should be switched over for the same reasons
as those were (accessibility, more semantic), as well as being able to
support the error messages from Intercooler.
This allows all users to edit their own topics' titles for 5 minutes
after posting, to be able to fix typos or other issues. Admins and
people with the specifically-granted permission can still edit titles
regardless of the topic's age.
Previously, error messages were only shown inside <form> elements. If a
button hit an error (such as a 403 when trying to vote on a comment that
was deleted after page load), the button simply wouldn't work with no
indication of why.
This adds the error message into the <menu> containing the buttons, and
involved some reworking of the relevant JS and CSS.
Since we're adding a prefix to the Solarized theme's "value" and CSS
class, we need to convert old values so that people using a Solarized
theme don't lose their setting. This changes it in two places:
* The value of the "theme" cookie, using the tween we already have for
dealing with that cookie.
* The user's default theme setting in the database.
Since the site originally launched with only the Solarized themes,
they've always just been referred to internally as "light" and "dark".
This changes them to solarized-light and solarized-dark respectively.
Previously, the "theme cookie tween" was setting the theme cookie on
every single GET request, in order to make sure that the domain was set
on it so that it would be accessible from the Blog and Docs sites. We've
been doing this for a long time now though, and almost every cookie
should have been set properly now.
Now, this tween will only set the cookie when it's actually necessary -
when the user is logged-in and has a default theme, but doesn't already
have a theme cookie.
I'm going to make some changes to this tween, so the metric will help me
keep an eye on how often it's triggering, which should make it easier to
be sure the changes are working as expected.
Previously the posted/edited times of comments wrapped very poorly on
small screens. This improves it somewhat, making it so they won't wrap
"internally" but the edited time will go underneath the posted time.
More improvements are still needed, especially with the Link/Parent nav
links, but this is definitely better.
Previously, subgroups were always included in topic queries. This meant
that, for example, it was impossible to subscribe to ~tildes without
always also having ~tildes.official topics in your home page as well.
This change makes it so that the home page now only includes topics from
groups that the user is actually subscribed to. When visiting a group
individually it still includes the subgroups.
As part of deploying this, I'll want to automatically add subscriptions
for users that were subscribed to ~tildes but not ~tildes.official so
they don't see a behavior change (and that's the only current subgroup).
The button will only appear when:
* User has the "mark new comments" setting enabled
* User has the "collapse old comments automatically" setting disabled
* The current topic has some new comments
marshmallow 3.0 is now released, after being in RC stage for quite a
long time. Tildes's usage of it will require a bunch of updates, so I'm
just going to pin it to a 2.x version for now.
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.
Deimos
Lugubris
Bauke
deing
Wes Cook
Josh Arrington