I made a userscript (eventually converted into a userstyle) so I could go sightseeing across lemmy and spot all you animals out in the wild. pawb.social, pawb.fun, and furry.engineer are pre-filled already, but you can add other servers to track as well!

Edit: Special mention to redyoshi49q@furry.engineer for this post, whose techniques resulted in CSS to achieve parity with my userscript. My older userscript should not be used anymore, as the CSS will do the same thing but more efficiently.

Instructions:

  1. Install Stylus extension for firefox/chrome

  2. “Write new style” in the addon settings

  3. Copy paste the CSS code below in

  4. Modify the code around line ~11 in order to reflect your homeserver and any additional frendservers that you want to highlight. Currently it’s set to pawb.social and the mastodon servers that pawb.social also operates, but feel free to add some of the furry instances below as well (post in the comments if you’ve got a good furry instance to add here!):

  1. Modify the code around line ~19 to reflect your homeserver

  2. (Optional) If you’d like your homeserver buddies to have a different marker, uncomment the various sections around line ~27 through ~50 by removing the /* and */ bits

  3. (Optional) Play around with different markers and colors!

CSS/Userstyle: https://gist.github.com/redyoshi49q/f1b2d1da0a8f7536aba1f8c3110d2dd8

  • redyoshi49q@furry.engineer
    3·
    2 years ago

    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.)

    • redyoshi49q@furry.engineer
      3·
      2 years ago

      (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.)

      • Yote.zip@pawb.socialOPEnglish
        2·
        2 years ago

        I’ve ended up with a style like this:

        a.text-info[href*="/u/"][href$="@pawb.social"] span::before,
a.text-info[href*="/u/"][href$="@pawb.fun"] span::before,
a.text-info[href*="/u/"][href$="@furry.engineer"] span::before {
content: "❤ ";
color: red !important;
}

a.text-info[href*="/u/"]:not([href*="@"]) span::before {
content: "★ ";
color: yellow !important;
}

        Frustratingly, I can’t seem to check whether pawb.social is in the href of a relative href like /u/yote_zip. If I could do that, this could work on foreign instances, because I could add a qualifier that someone is not only a member of the instance I’m currently on, but also my specific homeserver. As-is, this can be limited to pawb.social and will work just fine.

        • redyoshi49q@furry.engineer
          2·
          2 years ago

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

          }

          • redyoshi49q@furry.engineer
            2·
            2 years ago

            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.

            • Yote.zip@pawb.socialOPEnglish
              1·
              2 years ago

              I’m unsure if this is what you mean exactly, but I was able to use your techniques to get parity with my script’s logic (star removed for simplicity at the moment):

              a.text-info[href*="/u/"][href$="@pawb.social"] span::before,
a.text-info[href*="/u/"][href$="@pawb.fun"] span::before,
a.text-info[href*="/u/"][href$="@furry.engineer"] span::before {
    content: "❤ ";
    color: red;
}
@-moz-document domain("pawb.social") {
    a.text-info[href*="/u/"]:not([href*="@"]) span::before {
        content: "❤ " !important;
        color: red !important;
    }
}

              This CSS is logically equivalent to what I was doing in my script:

              So it works on all sites and highlights users from the first 3 sites (first is a user’s homeserver). On pawb.social specifically, it detects native users and adds a heart to them. In practice, this means everyone from those 3 servers should always have a heart next to them no matter where you go in the lemmyverse.

              • redyoshi49q@furry.engineer
                2·
                2 years ago

                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.

                • redyoshi49q@furry.engineer
                  2·
                  2 years ago

                  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.)

                  • Yote.zip@pawb.socialOPEnglish
                    1·
                    2 years ago

                    Sure. just add me as an author on that gist and I’ll put it in the post instead. Posting raw code on lemmy is not ideal, especially because I can’t seem to color it based on the language.

                • Yote.zip@pawb.socialOPEnglish
                  1·
                  2 years ago

                  Yeah, I had the same concerns here: https://pawb.social/comment/121816. The CSS is specific enough that I don’t think it’s a problem, but it is slightly more of a concern with the CSS than the JS because the CSS doesn’t abort itself. With my userscript it also ran on every site but instantly aborted if it wasn’t actually a lemmy site.

                  As far as wildcard fediverse stuff goes, I still think this is quite acceptable. I just saw this addon which scans every word on every website (and every mutation?) for fediverse formatted links to convert to clickables, so on a scale of 1 to that monstrosity, this one’s at a 0.