feat: add Classic Footer

[AprilSylph]

Description

• resolves New Feature: "Classic Footer" #1901

Adds a new feature, Classic Footer, to the list of usable features. This feature styles the post footer on processable posts to remove the per-type engagement counts and right-align all the control buttons, and adds a working old-style (pre-bubbleisation) note count button to the bottom-left corner of posts.

Screen.Recording.2025-10-07.at.2.20.39.pm.mov

This is the minimum viable product; the following possible enhancements are intentionally omitted for this iteration:

• Language-matching for the note count label (tumblr.languageData does not expose plural forms of strings 😩)
• Option to modify the Reblog button to link directly to the reblog form
• Option to hide "0 notes"
• Option to restore the Edit/Delete buttons

Oh, and this changes the icon colour of Classic Search to the 2013 Tumblr dashboard blue, to match this feature's icon. I think branding our "Classic" features with classic colours fits quite nicely.

Before	After

Testing steps

1. Load the modified addon
2. Enable the Classic Footer feature
   • Expected result: Control buttons in post footers are right-aligned and reordered
   • Expected result: Total note counts are added to post footers, on the left
3. Make sure nothing in the post footer is broken in this state
   • Expected result: Clicking the note count opens/closes the post's notes (defaulting to replies)
   • Expected result: Clicking the Share button opens/closes the share sheet
   • Expected result: Clicking the Reply button opens/closes the post's notes (defaulting to replies)
   • Expected result: Clicking the Reblog button opens/closes the post's reblog menu
   • Expected result: Clicking the Like button likes/unlikes the post
4. Find a post of your own that can be Blazed
   • Expected result: The Blaze button is positioned correctly
   • Expected result: Clicking the Blaze button opens the Blaze modal

[marcustyphoon]

We could also include footer:has(/* whatever */) { container-type: unset; } because it's not like we're going to be making use of any container-specific Tumblr styles (so now we don't have to test them) and because it would fix #1876, but we need to fix #1876 when this isn't enabled, anyway, so it's arguably pointless.

[marcustyphoon]

Maybe it's easier to just put xkit-controls-row before the actual footer, I dunno. Kind of semantically awkward and the aria-label is kind of wrong, but.

[AprilSylph]

Maybe it's easier to just put xkit-controls-row before the actual footer, I dunno. Kind of semantically awkward and the aria-label is kind of wrong, but.

I mean, my mental model is that tags are part of the footer too, but that's factually false. The footer doesn't have multiple rows. So if, visually, we're inserting a row above the footer... that's how we should be doing it from a DOM perspective as well.

[AprilSylph]

Ready for re-review!

My latest changes also tweak our control buttons CSS to make our inserted buttons align with Tumblr's buttons by default, with Classic Footer tweaking that CSS further to match the styles it applies to the footer.

Classic Footer disabled	Classic Footer enabled

[marcustyphoon]

How much bikeshedding am I supposed to be doing over style? The widened xkit-controls-row separating line looks worse to me, but like, eh.

[AprilSylph]

Pointing things out isn't bikeshedding. Now that I see it, it's bothering me too... third try's the charm? One moment.

[AprilSylph]

Hmm, this one is annoying. No such thing as negative padding to offset the needed increased margin... I guess I could use a pseudo-element to draw the border instead?

[marcustyphoon]

Oh, whoops, I had assumed it was intentional because I hadn't realized that it's from the new footer, not the changes you just made :D Hm, that is kind of a pain.

[AprilSylph]

Pseudo-element seems to work fine, and I don't think the changes mess with anything else...? I'll push what I've got so you can test for yourself.

---

Classic Footer disabled	Classic Footer enabled

[marcustyphoon]

It used to be 16px; do you think 12px or 16px looks better?

(Are we bikeshedding now? :3)

[AprilSylph]

Classic Footer disabled	Classic Footer enabled

[marcustyphoon]

My brain so wants to believe the control buttons are still misaligned. But ${postOwnerControlsSelector} > * { outline: 1px solid green; outline-offset: -8px; border-radius: 0; } definitely shows they're not; I guess it's all down to the icon art.

[AprilSylph]

Yeah. Maybe we should move to using Tumblr icons for our control buttons... 😏

(Not in this PR, obviously.)

[marcustyphoon]

This notably does leave in changes to xkit-controls-row, which won't get used unless Tumblr makes another change or a future feature (say that ten times fast) inserts a button into a non-editable post. Removing the canEdit && from Quick Tags and Trim Reblogs to get a quick look, they're a) relatively fine, though b) missing the now-removed "make the gap zero if classic footer is enabled" css.

We could leave this as is, carefully tweak them to be pixel-perfect even though they're unused, revert the changes so this PR does not have an unused diff, or possibly straight up remove the whole thing in this PR if we want to have no fallback (but I kind of want the fallback).

[AprilSylph]

This notably does leave in changes to xkit-controls-row, which won't get used unless Tumblr makes another change or a future feature (say that ten times fast) inserts a button into a non-editable post. Removing the canEdit && from Quick Tags and Trim Reblogs to get a quick look, they're a) relatively fine, though b) missing the now-removed "make the gap zero if classic footer is enabled" css.

We could leave this as is, carefully tweak them to be pixel-perfect even though they're unused, revert the changes so this PR does not have an unused diff, or possibly straight up remove the whole thing in this PR if we want to have no fallback (but I kind of want the fallback).

I want to keep it in as a fallback, too. This leaves us with three options:

• OK fallback (revert changes made in this PR; achieve minimal diff)
• Better fallback (keep changes as they are)
• Perfect fallback (work further to make it pixel-perfect)

I don't think further work is warranted for a might-never-be-used fallback, but given that we already tested and verified the changes before the thing became a fallback, reverting them doesn't achieve anything except make the fallback worse on purpose. So, I vote we just leave them as-is.

[marcustyphoon]

*chanting* M-V-P! M-V-P!

It's a little less cool in software development than in sports. But still.

[marcustyphoon]

I was wondering if the opposite was true and if we could sneak a fast review by having our old place in the queue apply to the new version if we released this really fast.

Replies to my message asking about this can be summarized as a) you probably keep your place in the queue if you push a second release, probably maybe at least according to an educated guess by one person who knows, and b) request from the team that you do push a second release in that case to reduce overhead; did not directly answer question.

[marcustyphoon]

Minor bug; acceptable, I think, for the MVP:

• open the notes on a narrow post (e.g. https://www.tumblr.com/explore/trending or https://www.tumblr.com/april + masonry view)
• change tabs
• click the notes count
• notes do not close

Going to be annoying to fix. Now you're thinking with portals!

edit: wait now they do. what

edit: wow if you alternate between clicking the replies button and note count, the modal flickers. no idea at present how that would happen!

[AprilSylph]

I was wondering if the opposite was true and if we could sneak a fast review by having our old place in the queue apply to the new version if we released this really fast.

Replies to my message asking about this can be summarized as a) you probably keep your place in the queue if you push a second release, probably maybe at least according to an educated guess by one person who knows, and b) request from the team that you do push a second release in that case to reduce overhead; did not directly answer question.

Hmm. I guess I would be willing to publish a release and just see what happens. The recent announcement about version rollbacks gives me hope that even if our submissions are approved out of order that I would be able to fix the wrong-version-marked-as-latest problem, if they haven't already fixed that themselves.

[marcustyphoon]

I believe if you have two versions in the queue the earlier one gets auto disabled and the reviewer sees a combined diff.

[AprilSylph]

Minor bug; acceptable, I think, for the MVP:

* open the notes on a narrow post (e.g. [www.tumblr.com/april](http://www.tumblr.com/april) + masonry view)

* change tabs

* click the notes count

* notes do not close

Going to be annoying to fix. Now you're thinking with portals!

edit: wait now they do. what

It's a race condition, I think? The notes floatie gets closed by any outside click occurring on the page—I guess if that happens first and our click handler happens second, the notes get closed and then immediately re-opened.

[AprilSylph]

Only after I push a fix do I realise there's an extra layer: there are two click events! The original one from actually clicking the notes button, and the one we perform by triggering a click to the Reply button. By stopping propagation, the document body only sees one click (in the bubbling phase, at least). Seems to fix the issue, either way.

[marcustyphoon]

Opening the floatie with the reply button and then pressing notes to close, or vice versa, still flicks it back up for me, but I didn't look at all closely why, and it's quite minor.

edit: Have now "looked at all closely." Conclusion: no idea.

[marcustyphoon]

I'd love to center the position of the reblog modal (i.e. change from bottom-start to bottom) as a follow-up, but I don't see a way to do it in CSS that doesn't potentially mess with the automatic repositioning or a way to poke it in react either.

edit: Nope, I'm a liar.

[marcustyphoon]

Option to modify the Reblog button to link directly to the reblog form

Huh. Problem I just noticed with this: Quick Reblog users who don't want to use the classic with-note-counts footer should be able to access it. But if we...

• put it in Quick Reblog, it's not discoverable from Classic Footer (where most people will look)
• put it in Classic Footer, we'll also have to make the current Classic Footer functionality an (on-by-default, please) checkbox, which makes the feature description wrong and also makes it not discoverable from Quick Reblog (where it's obviously quite relevant)
• put it in Tweaks, it's not discoverable from either Classic Footer or Quick Reblog, and also everything in Tweaks has a discoverability problem inherently, because, you know, Tweaks
• put it in Classic Footer and Quick Reblog, our extension framework doesn't really allow for that unless the whole thing was in a util and both features used an iframe preference, which, uh.

edit: anyway here's wonderwall

const modalReblogButtonSelector = `${keyToCss('menuItemsWrapper')} > a[href^="/reblog/"]:has(use[href="#managed-icon__ds-pencil-outline-24"])`;
const modalReblogButtonObserver = new MutationObserver(mutations =>
  mutations
    .flatMap(({ addedNodes }) => [...addedNodes])
    .filter(addedNode => addedNode.querySelector?.(modalReblogButtonSelector))
    .forEach(addedNode => {
      addedNode.setAttribute('hidden', '');
      setTimeout(() => addedNode.removeAttribute('hidden'), 500);
      addedNode.querySelector(modalReblogButtonSelector).click();
    })
);

/* if (preference) */ modalReblogButtonObserver.observe(document.body, { childList: true });

[AprilSylph]

Reverting how the reblog button works when clicked is categorically a Classic Footer problem to solve. Quick Reblog is for adding the on-hover menu and nothing else.

I also don't see "people who do want the spread-out button layout, but don't want the new on-click reblog menu" as a demographic that actually exists.

[marcustyphoon]

In practice that's likely true, yeah. Logically I don't think it makes as much sense; Quick Reblog cleanly replaces almost the entire functionality of the reblog menu*, and Classic Footer removes the split note counts, which is a sidegrade.

*Except opening the post notes to the reblogs view, which in a hypothetical case without Classic Footer but with the menu removed takes the same number of clicks—two—but is done in an illogical way, by first clicking on the replies button; this kind of illogical situation is one we have historically avoided creating and could be another reasonable argument against allowing the menu to be removed independently of Classic Footer.