Topic: Comment Count on Post listing Removed

Posted under Site Bug Reports & Feature Requests

Recently the UI for the listing layout was updated, and I think it’s a good change. However, I noticed that after the change you can no longer see the comment count for any given post. Was this intentional? Is there a CSS I can use to bring it back?

the comment count's still there, it's just that it tends to get pushed off the edge, especially if you're using the small thumbnail size.

the svg icons next to the numbers are a bit larger horizontally than the old Unicode characters that were used previously, and/or there's more padding between the numbers than there was before. also the way that the post rating is displayed has an effect as well.

I'm confused by all the people saying that, comment count shows up perfectly fine for me on mobile. It seems to at least try to show up for all thumbnail sizes, though it does get cut off on small.

Yeah I find it annoying. It shows me the comment count only if I hold the phone horizontally.

I like to check comments on my post, it sucks that I can't do it at a glance like I used to. It's just a UI downgrade for no reason. I'd rather see comments than likes or favorites.

ponporio said:
I like to check comments on my post

For comments on your posts, it's usually better and faster to go to your profile and click on the Comments button (to the right of "0 Rejected"). But yeah, if you're only interested in comments on the latest few posts, the new UI isn't convenient on mobile.

ponporio said:
Yeah I find it annoying. It shows me the comment count only if I hold the phone horizontally.

I like to check comments on my post, it sucks that I can't do it at a glance like I used to. It's just a UI downgrade for no reason. I'd rather see comments than likes or favorites.

you could try ponporio order:comment or ponporio order:comment_bumped. comment is whenever a post gets a comment, comment_bumped stops pushing the post up after the 40th comment.

or as the person above said, use the comment search; either for posts you uploaded or for your artist tag.

donovan_dmc said:
It doesn't display when the screen is narrower than 400px
Or in other words, it doesn't show up in portrait, only in landscape

this is what it looks like in the final css stylesheet:

current CSS
@media (max-width: 400px) {
  body[data-st-size="s"] article.thumbnail .thm-desc .thm-comments,
  article.thumbnail .thm-desc .thm-comments {
    display: none;
  }
}
@media (max-width: 400px) {
  body:not([data-st-size="l"]) article.thumbnail .thm-desc .thm-comments {
    display: none;
  }
}

these rules are very strange, I imagine that there's got to be some wires crossed or something.

the first selector specifies the thumbnail size being set to small, and then right afterward it overwrites that with the same exact selector sans that requirement, and then directly following there's a near identical rule that selects the same element but when the thumbnail size is not large, which is entirely redundant.

it's like:

  • if your screen width is <400px
    • hide the comment count element...
      • when the thumbnail size is small
      • oh, and in all other cases too
  • and also, if your screen width is <400px
    • hide the comment count element...
      • when the thumbnail size is NOT large

I'm going to guess that the first rule is supposed to be 800px rather than 400px, and the second selector was a mistake.

essentially: hide the comment count of small thumbnails on mobile, and also hide it on medium thumbs too if the screen's really small.

...

in any case, I'm not sure I agree with hiding the count when the thumb/screen size is too small in general, I feel like shrinking or hiding the icons instead would be less intrusive.

Ya I really would love the comment count back. I keep a tab open with a querie related to my characters/artist tag and the lack of comment count means I can miss replies if it's to the most recently bumped item.

gyro said:
Ya I really would love the comment count back. I keep a tab open with a querie related to my characters/artist tag and the lack of comment count means I can miss replies if it's to the most recently bumped item.

did a bit of messing around and this is what I think looks alright

/*always show comment count in thumb desc*/
.thm-comments { display: flex; }

/*make thumb desc icons slightly a smaller on mobile*/
@media (max-width: 50rem) {
  .thm-desc-m svg {
    width: 1em;
    stroke-width: 3; 
  }
  .thm-desc-m.thm-score svg {
    margin-right: -.125rem;
  }
  .thm-desc {
    grid-template-columns: auto .8rem; 
  }
  .thm-desc-b {
    padding-top: .25rem;
    padding-left: .175rem;
  }
}

YMMV with this diffrent fonts might be wider or thinner, and stuff like that, but this looks alright with Roboto for me.[it's all, Roboto I guess.] also, if you have CSS that increases the font-size of thumb descriptions or something, that'll obviously cause it to look different and probably overflow more.

stuff with high score/favcount will probably still have stuff not display good, but, uhh... waddayagonnado.

Updated

gyro said:
Ya I really would love the comment count back. I keep a tab open with a querie related to my characters/artist tag and the lack of comment count means I can miss replies if it's to the most recently bumped item.

You can use re621 to subscribe to searches & I believe comment sections; probably a better experience than that anyways. If you're on mobile, FireFox supports the use of the extensions needed for it, although mobile Chrome doesn't.

Huh, the fav star is now visible, unless you have the post faved. Comment count seems to be gone (if you don't use css to fix it)

snpthecat said:
Huh, the fav star is now visible, unless you have the post faved. Comment count seems to be gone (if you don't use css to fix it)

current CSS
@media (max-width: 500px) {
  body:not([data-st-size=l]) article.thumbnail .thm-desc {
    grid-template-columns:auto .75rem
  }
  body:not([data-st-size=l]) article.thumbnail .thm-desc .thm-comments{
    display:none
  }
}

the threshold was raised to now include everything smaller than 500px when it was previously only screen widths smaller than 400px. the exception for large thumbnails now actually functions, though.

I still don't think this is an at-all good solution. especially when you don't know how wide the contents of the thumb description actually is and, because of this, a lot of the time the user just has stuff hidden from them because ???; this really only ""helps"" for posts with over 1k score and favcount and even then the comment count only gets a little cut off when it's more than two digits. and again, you could do other stuff to save on real estate before just nuking the comment count element.

it's also not communicated to the user at all, which is real bad. at least when there's text overflow that you can see you can maybe think to raise the thumbnail size to see the stuff that's getting truncated.

I think it was yesterday or day before on mobile, I could set the thumbnail size to medium and still see the comment counter, now I have to use the large one to see it, very strange changes

alatreonspaws said:
I think it was yesterday or day before on mobile, I could set the thumbnail size to medium and still see the comment counter, now I have to use the large one to see it, very strange changes

before today the threshold for hiding the comments was a viewport width of smaller than 400px, now it's widths smaller than 500px. before today there wasn't anything that made it show or hide based on the thumbnail size (other than the text just not overflowing the box).

dfn-451 said:
it's also not communicated to the user at all, which is real bad. at least when there's text overflow that you can see you can maybe think to raise the thumbnail size to see the stuff that's getting truncated.

Why would we want to show overflow? We're trying to prevent overflow.

I'd like a more dynamic styling system that better scales based on the actual rendered sizes, but that's both highly demanding to make & would either rely heavily on JavaScript or require drastic reworking of how we handle sizing. I've been looking into container queries, & I think they have a lot of potential to be helpful here, but afaik none of us developers (including the one who handles most front-end UI stuff) are familiar with it, so we'd have to both spend the time to learn how it works & implement it. Not that I'm against it (if I had the time I'd do it right now), but that's a big time commitment & we're in the middle of updating our frameworks & toolsets (we upgraded Rails again, we switched from Webpacker to Vite).

I'm not Cinder, & idk what he's got cooking up (he might very well be working on this), but in case this doesn't advance for some time, I just want it to be known that it's not from a lack of motivation, it's a lack of resources, specifically time. There's only 4 of us, & at least 3 of us aren't paid for this & for the remaining dev, if they are paid, it's not enough for them to not have to work a different job; there's a lot to do, & time comes at a premium. If no one beats me to it, I'll take a crack at it myself; I just can't make promises about when that will happen.

aacafah said:
Why would we want to show overflow? We're trying to prevent overflow.

I'm saying "preventing overflow" just shouldn't be a priority, and it certainly shouldn't be a priority over the functional utility of showing the user information. especially when it's, honestly like, the one number under the thumbnail that anyone would actually be interested in seeing it change. trying to improve aesthetics to the detriment of utility is just a net negative.

the user dosn't know that it's not there because they don't know that it's not there. the people who have read this thread know what's going on, the maybe two dozen people who know what the gear button above the search box is for and regularly switch back and forth between large and medium might as well, but nearly all of the users who visit this site on their phones exclusively* will now just think "Well I guess they're just not showing comment counts anymore. That's kinda lame." because, for them, that's the only thing that's changed.

...

and it doesn't even prevent overflow in 99.98%** of cases, it's just removing information for _no reason_. the solution caused more issue than it solved, it would have been better to just let the existing issue sit until a proper solution could be formated.

*unless their phone is, like, a Blackberry Passport, since those are the only smartphones I'm finding with a viewport width of >500px.

**for me at least the issue only happens on medium thumb size when there are more than ten total digits, i.e. when favcount is >10k or the favcont and score are >1k and the comments are >100: 1- (658+200)/5230013= 0.999836.

aacafah said:
[...]I've been looking into container queries, & I think they have a lot of potential to be helpful here[...]

it might, although you already have a rough idea what the width of the element is going to be based on the viewport width and thumb size since it's just a little bit less than 100vw over 4, 3, or 2. the real unknown is the text width; even if you know the amount of characters, diffrent fonts will have different average character width and, since it's not monospaced, diffrent character widths between and everything.

but we really shouldn't even be entirely hiding elements for this.

container query would probably be more useful for stuff that have extremely variable sizes, like comments that are really long, or comments that quote other comments that are really long.

I'm at work, so I'll just quickly clarify that as I said, I'm planning on dynamically scaling elements, not hiding them. As for the font? Yeah, every font is different, but we control the font. If someone wants to change it with custom CSS, that's their business, but we're perfectly capable of handling sizing correctly for a predetermined font.

In the interest of recording thoughts for me (or anyone else if they want to contribute), for a shorter-term change, I'd probably just make the thing a flex box & let people choose the flex-wrap value of nowrap or wrap.

aacafah said:
I'm at work, so I'll just quickly clarify that as I said, I'm planning on dynamically scaling elements, not hiding them. As for the font? Yeah, every font is different, but we control the font. If someone wants to change it with custom CSS, that's their business, but we're perfectly capable of handling sizing correctly for a predetermined font.

well, you can but, uhh...

oh, huh, I thought it was just defaulting to using Roboto, since that happens when using Android for most of the stuff on the rest of the site when you have the font set to something that the site isn't providing. I guess that those elements just-- use Roboto?

dfn-451 said:
did a bit of messing around and this is what I think looks alright

/*always show comment count in thumb desc*/
.thm-comments { display: flex; }

/*make thumb desc icons slightly a smaller on mobile*/
@media (max-width: 50rem) {
  .thm-desc-m svg {
    width: 1em;
    stroke-width: 3; 
  }
  .thm-desc-m.thm-score svg {
    margin-right: -.125rem;
  }
  .thm-desc {
    grid-template-columns: auto .8rem; 
  }
  .thm-desc-b {
    padding-top: .25rem;
    padding-left: .175rem;
  }
}

YMMV with this diffrent fonts might be wider or thinner, and stuff like that, but this looks alright with Roboto for me.[it's all, Roboto I guess.] also, if you have CSS that increases the font-size of thumb descriptions or something, that'll obviously cause it to look different and probably overflow more.

stuff with high score/favcount will probably still have stuff not display good, but, uhh... waddayagonnado.

That works, thank you!

Original page: https://e621.net/forum_topics/60320?page=1