You're welcome to version bump this and add yourself as an author, by the way; you participated quite a bit in this process.
(The character limit of Mastodon has been a little bit cozy for this extended exchange, hence why I finally decided to just make and link a gist.)
It took me a bit to realize as much, but it seems that you edited the script based on another commenter's suggestion to make parts of it run on /every/ page (with the expectation of only changing anything on Lemmy pages). That's... probably fine; the CSS is pretty specific.
https://gist.github.com/redyoshi49q/f1b2d1da0a8f7536aba1f8c3110d2dd8 <- I made an update that cleans up a few things and re-adds the functionality that I originally intended for the stars to have (using houses instead) with commented out CSS.
There's three lists of domains at play here:
* The domains in the first @-moz-document are domains where hearts and stars appear at all.
* The domains in that section's a.text-info block are the domains that get hearts.
* The domains in the second @-moz-document are the domains where the stars are overridden by hearts.
This lets you always have hearts on an instance, even if you're already on that instance, while also letting you have stars show native accounts elsewhere.
Try this:
@-moz-document domain("pawb.social"), domain("yiffit.net") {
a.text-info[href*="/u/"][href$="@pawb.fun"] span::before,
a.text-info[href*="/u/"][href$="@furry.engineer"] span::before {
content: "❤ ";
color: red;
}
a.text-info[href*="/u/"]:not([href*="@"]) span::before {
content: "★ ";
color: yellow;
}
}
@-moz-document domain("pawb.social") {
a.text-info[href*="/u/"]:not([href*="@"]) span::before {
content: "❤ " !important;
color: red !important;
}
}
(Also, you would not believe how often I've had to write user CSS to unbreak the broken CSS of websites.
A classic example is when the CSS defines dark text color without defining a background color. The browser I use derives color defaults from the OS, which uses light text on a dark background, and the page renders in dark text on a dark background, generally becoming nearly unreadable.
I've also (ab)used "display: none !important;" to snip out annoying "improvements" to pages.)
I can confirm both that my original version has the bug you described and that your fix does not produce that bug.
I don't actually have a native Lemmy account, so I didn't realize that upvoting would cause the upvote count to gain a CSS class that I used in my selector.
(Thankfully, the DOM changed to reflect given/taken upvotes in spite of me not being logged into the Lemmy server at all; I only got a "Not logged in." error each time.)
The first part prepends a red heart to usernames from a particular remote server (and variants of the CSS selector can be copy/pasted into a comma delimited list to allow the rule to apply to other servers as well).
The second part prepends a yellow star to usernames from the local server... by crudely assuming that they won't contain any periods (CSS selectors aren't flexible enough for anything more elegant). The selector can instead be applied to the first rule to make those hearts as well.
I whipped up a proof-of-concept user CSS that does this (and should automatically adapt to entries shifting down).
**********
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("pawb.social") {
a.text-info[title$="@lemmy.blahaj.zone"] span::before {
content: "❤ ";
color: red !important;
}
a.text-info:not([title*="."]) span::before {
content: "★ ";
color: yellow !important;
}
}
My understanding is this:
* Following a Lemmy community will add that community's posts and replies to your Mastodon feed.
* Replying to a Lemmy community post or reply comment from Mastodon will generate a corresponding Lemmy reply comment.
* (if I'm not mistaken) Making a non-reply Mastodon post that contains the handle of a Lemmy communtiy will make a Lemmy post within the associated community.
I'm open to being corrected about any of the above.