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.
I do think some preemptive measure is warranted; it could be in the form of a block, a mute, or something else of that nature.
I'm a bit skeptical of Facebook/Meta's tactic; it feels like the start of an embrace/extend/extinguish campaign (to get people fleeing Twitter onto a Facebook-controlled service, and subsequently remove the ability to federate/migrate accounts from their instance in order to try and lock people into their own service rather than let them find their way to the Fediverse). Arguably, they (and Google) did the same thing with XMPP by breaking federation in their own implementations.
@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.
It's possible that the word "major" as a qualifier means that the assessment is excluding 4chan and similar image board sites.
Done.
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.)
A CSS script could do that... if the :has() selector is supported.
With that said, I've recently run into issues with that selector not being supported (due to it being recent CSS spec) in two different (but not recently updated) user style extensions that I've tried it with (in one, it is entirely unrecognized; in the other, you get errors when trying to do nontrivial things in the :has() ).
I could copy/paste some example user CSS for you if you'd like to see if you can get it working.
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;
}
}
@Wander A more quality (but more labor intensive) solution would be to have an account setting that toggles a short CSS file containing overriding CSS for the adult image blur. This way, users could choose to have or not have that blur regardless of which theme they chose (without having to have two separate copies of each main CSS theme to achieve that).