redyoshi49q

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.

@tech I’m testing to see whether including the Lemmy community @ in a reply will cause that @ to appear in the text of the reply.

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;
}

}