Allow multiple border colors to display on post thumbnails

[ToksT]

(Former title: "Allow black deleted post border to take precedence over green parent border")

It already takes precedence over the child border, so this would be more consistent.

[MyrMindservant]

This would be more consistent and even more convenient in some cases, true. But at the same time it would create additional problems when viewing multiple deleted posts that are linked. If parent post is deleted as well as (part of) its child posts, then you won't be able to tell which post is the parent without manually checking all of them.

[ToksT]

That's true. It would be better if it somehow displayed all applicable borders instead of just one.

[RaisingK]

We have parent, child, and one of deleted/flagged/pending (can pending posts be flagged?). We need the power set of those three groups. Use the CSS styles border-right, border-left, border-top, and border-bottom.

If all three groups, give deleted/flagged/pending two sides. If two groups, give two sides to each.

[ghostrigger]

(can pending posts be flagged?)

not possible in the web, at least for basic members and builders. but i was able to flag a pending post through api post #1396914

[Type-kun]

Use the CSS styles border-right, border-left, border-top, and border-bottom.

Are there selectors for combination of classes? If not, we'd have to involve some "!important" magic to properly override those.

[ToksT]

Are there selectors for combination of classes? If not, we'd have to involve some "!important" magic to properly override those.

I tried doing this with !important but got lost due to the number of combinations.

I think that a better way of doing it may be to use the combined class selectors like .post-preview.post-status-has-children.post-status-has-parent, and also use the :not selector like .post-preview.post-status-has-children:not(.post-status-has-parent). It's probably going to look pretty messy, though.

[MyrMindservant]

Instead of dividing the border into differently colored sections, it would be better to be able to display more than one border at a time. One around the other.
I'm not sure if this is possible or how hard it is to implement, though.

[ToksT]

@MyrMindservant I think you would need to create pseudo-elements around each thumbnail, one for each border, and apply the borders to those.
But multiple borders would take up extra space, and I have the feeling it wouldn't look good.

[kotarou3]

Another possible solution would be to have multiple colours in a single border, but that probably will need to involve a bit of javascript hacking and using css gradients

[Type-kun]

@kotarou3
I have a feeling that would be REALLY bad for browser compatibility.

...incidentally, it seems that status classes are applied through javascript. I have to wonder why.

UPD: that's how "flagged image with children" would look like with divided borders:

And that's multiple "borders":

(actually that's border + outline, which wouldn't work for IE6-7 and has overlap problems)
Also I had a height problem when trying to wrap span elements around img, presumably from line-height, but I never got it to work even after completely turning it off at CSS listing. I have a feeling that danbooru markup needs some clean-up.

[Lightforger]

Divided borders looks decent.
Multiple borders is quite hard to see, the red & green seem to blur together.

I feel like this trying to push too much information into borders though, it becomes somewhat messy on color images (like, when the image itself already has a border - red_border). Perhaps it would be easier on the eyes if the border was 1-2px thicker.

Edge case for divided borders: the sides on wide_image, are very short, it would become hard to see. same for tall_image.

The css for divided borders could be done like this (untested);
Parent/child would be:

border: 2px solid -color-;
border-right: 2px solid -color-!important;
border-left: 2px solid -color-!important;

While deleted/pending/flagged gets:

border: 2px solid -color-;
border-top: 2px solid -color-!important;
border-bottom: 2px solid -color-!important;

Ps. span is a inline element, it won't properly wrap around a block element like img.

[Type-kun]

Ps. span is a inline element, it won't properly wrap around a block element like img

Gah. I keep thinking of img element as inline, while it actually behaves like inline-block. Thanks for reminder.

Edge case for divided borders: the sides on wide_image, are very short, it would become hard to see. same for tall_image.

Unless I'm mistaken, we got rid of grandchildren relationship? Then we can basically have 2 groups, (parent/children) and (pending/flagged/deleted). Then we could just go like this, top-right+bottom-left:

The css for divided borders could be done like this (untested);

Should work (untested as well :3), but wouldn't "!important" parameters mess with user styles? We pretty much have 6 combinations: (parent|child).(pending|flagged|deleted), would just placing them in order get us necessary overrides?

Perhaps it would be easier on the eyes if the border was 1-2px thicker.

Not really, IMO. images themselves have borders of variable width, so it'll still be a pain. Maybe padding before a border would work:

the red & green seem to blur together.

Might be puu.sh compressing issue, should've turned it off.

[ToksT]

Unless I'm mistaken, we got rid of grandchildren relationship?

That did happen, but it appears they were added back. Though I didn't even realize this until earlier today, and I haven't a clue when it actually happened.

[Type-kun]

Hm. Then maybe going with multiple borders isn't that bad, after all:

(this time no compression and properly wrapped spans around). Note: this requires expanding preview article element width. 3 borders require 24 px(!)

[ToksT]

Note: this requires expanding preview article element width.

Even if it's only 4 pixels on each side, that would add up to be quite a bit for all previews combined for users with many posts per page. On my screen, it loses me a column of posts.

[Type-kun]

Well, there's also an option to resize IMG element instead, but that could turn out to be hack-ish.

[r888888888]

There are other options besides borders. Perhaps a small icon could be overlayed on top of the image, at least for some statuses.

[ghostrigger]

a small icon could be overlayed on top of the image

i think this is a decent idea, but would it require recreating the thumbnail every time the status/relationship changes? how about superimposing text/icon/small image on mouse hover?

[r888888888]

That's what i meant. It would be more CSS/JS code however.

[Type-kun]

Icon is pretty intrusive, it will either obscure part of thumbnail or be hard to notice. But thinking outside image borders, we could show status in a line above/under image (separate element with border-bottom), and reserve borders for parent/child:
- flagged image having children and a parent. This also won't stretch article element width, thus not breaking column count; height can be expanded without consequences.

[Type-kun]

Also, is there really a need to apply borders with javascript? We can do it directly in post presenter.

[Lightforger]

ToksT commented
That did happen, but it appears they were added back. Though I didn't even realize this until earlier today, and I haven't a clue when it actually happened.

Was it actually added back, or "there exist posts with both parent/child"? I remember reading posts with both parent & child were because of a bug.

If there are only 2 possible combinations - (parent|child).(pending|flagged|deleted) - then i think Divided borders + 1-2px padding looks best so far.
At 3 or 4 combinations (future-proofing?), it's probably better to start looking into something else then borders. I quite like the "line under image to show status" for 3 combinations.
At 4+, icons is probably the only way to go. A normal-sized icon would be about.. 16x16 pixels.

This css also works (tested), without !important - http://pastebin.com/xnxZR1YD

Type-kun commented
Also, is there really a need to apply borders with javascript? We can do it directly in post presenter.

Less work for the server?

[ToksT]

Was it actually added back, or "there exist posts with both parent/child"? I remember reading posts with both parent & child were because of a bug.

At first, it was made impossible to add a post to a grandchild-like relationship, but the existing ones weren't removed.

But currently, you can add new ones again, is what I meant. In other words, the original D1 behavior has been restored. Which is probably a good thing, as I was repeatedly running into issues due to that change.

[r888888888]

The grandfathering change was reverted because you couldn't update posts with grandfathers. It was just annoying to deal with and I didn't think the advantages outweighed the disadvantages.

[ghostrigger]

somewhat a modification of suggestions above, how about we replace the borders entirely of small squares maybe 4x as thick as the current border, aligned to the right, and below the post?

the parent/child and status (flagged, deleted, pending) will be represented by one square each inline below the post, maybe 1 or 2 pixel/s apart, just enough space to distinguish one from the other. this will eliminate superimposing the symbols on the thumbnails and offers more visibility.

this will also easily show the relationships on extremely long or wide posts whose thumbnails are almost 1 pixel in one dimension as the relationships have enough breathing space no matter what the thumbnail looks like.

it can also accommodate future statuses in case we think of something new as the one inline section below the post is long enough (horizontally). maybe we can set a new color for banned posts?

and personally, i think it's more economical and not overcrowding the thumbnails with much information as the statuses and relationships are concentrated in one location.

additionally, the current max squares i can think of the moment is only three: a post can both be a parent and a child, and either of flagged, pending, or deleted. the order of precedence will also not be an issue, i think, because it doesn't matter which one comes first unlike the borders.

[Type-kun]

I had some ideas with squares too, but your suggestion seems more decent. A few corrections/suggestions, though:

1. We should place them at top. Image listing is vertically aligned to the top, so I can imagine square sets "jumping around" as being hard to see.
2. I think, we should horizontally center them. Because imagine how right-aligned square set would look like for a tall image, with thumbnail only a few pixels wide.

I'll try to implement it now and provide some screenshots.

[Type-kun]

Okay, here's what I got: http://puu.sh/2HAXw.png

[ToksT]

Okay, here's what I got: http://puu.sh/2HAXw.png

I think that could work. But maybe it would be more visually appealing if we used icons instead of solid blocks? Example. (Icons arbitrarily chosen from the JQuery UI set)

Although they're a bit difficult to notice in my image, so the colors or sizes would need tweaking.

[Lightforger]

Icons would be nice, but they would take up more space to be equally visible.

How about placing a white letter in the blocks? "C" for child ("this post is a child" mouseover) - P for parent/pending - etc.
I'd also place the blocks closer to the image - leaving only 1-2 px spacing.

For visibly issues, we can always make the blocks/icons wider, plenty of space.

[r888888888]

I don't like that solution. In my opinion it adds visual clutter for something most users don't care about. Can you just make it a userscript?

[kittey]

Here's how a version with icon overlays could look like:

Search: {{id:429714,131269,781716,1402596,1402890,1404003,1404084,1404595,1404633,1404672,1404674,1404720 status:any}}

Code and CSS available for tinkering via my userscript if anyone's interested. Tweak must be enabled first.

[ghostrigger]

uhm, how about we still maintain the borders with statuses have higher precedence (flagged, deleted, pending; arranged from highest to lowest) over relationships?

relationships in turn, a child post has higher precedence over the parent.

with this, there will be only one border color or none at all for a particular post.

then, how about we utilize the suggestions to use solid block squares or fancy icons on mouse over? with this, the results page will not be too intimidating, only when the user points to it? as the default site behavior?

and how about enable the icons/squares to appear in all posts on a results page via a userscript?

[kittey]

I like the idea of keeping the borders and using mouseover. I extended that idea and now exclude the status that's already shown by the border from the list of icons. A pending child post will have the "pending" border and a "child post" icon. This keeps the visual effects down because not too many posts have two or more statuses of interest, but it still shows all information.

(Mouseover disabled for the screenshot; bottom left one is by a banned artist.)

Search: {{id:429714,131269,781716,1377341,1394001,1402596,1402890,1404003,1404084,1404595,1404633,1404672,1404674,1404720 status:any}}

I figured out the following priority order for borders. Please correct me if I got it wrong.
pending/flagged > parent > deleted > child > banned (thumbnails have no appeal information)

Userscript updated to try it out.

and how about enable the icons/squares to appear in all posts on a results page via a userscript?

Sorry, I'm not sure what you're suggesting. Disabling the mouseover effect via a userscript to show all icons? My version uses CSS hover, so you could just add this as custom CSS to always show all icons: .post-preview span.status-icon-overlay { visibility:visible !important; }

[ghostrigger]

Sorry, I'm not sure what you're suggesting. Disabling the mouseover effect via a userscript to show all icons?

ah, i was suggesting that the default site behavior should adapt the suggestions above of using borders and solid squares/icons on mouse hover. personally, i find them a really nice feature for d2.

the userscript should be, yes, able to display all icons on all posts on the results page. maybe it will be better in a custom css instead? the user modified userscript or css can alter the default site behavior like the squares/icons position (e.g. center, above, right, bottom, superimposed or combinations); the order of precedence of borders; disabling the hover effect; etc.

[RaisingK]

Icons and mouseovers and blocks oh my. Miscellaneous Tweaks is just going to go the border-right, border-left, border-top, border-bottom route.

Quite a lively discussion here.

[ToksT]

Went with RaisingK's suggestion of using different border colors for different sides. We might want to do something else with them later, but for now this solves the issue at hand.

And credits to @RaisingK for his script, which I heavily based the code on.

[Lightforger]

I quite prefer this look over the top/bottom:

So, may i suggest this code instead:
with status: $img.css("border-color", border_colors[0] + " " + border_colors[1] + " " + border_colors[2] + " " + border_colors[2]);

without status: $img.css("border-color", border_colors[0] + " " + border_colors[1] + " " + border_colors[1] + " " + border_colors[0]);

[ToksT]

I thought it might look better the other way, but don't feel too strongly about it. Any other opinions before I change it?

[MyrMindservant]

I agree with Lightforger, side-bottom+side-top looks better than parallel borders. And it also would work better with very wide or tall images, that's why it was proposed in the first place.

And I want to add that from other, more advanced/complex, suggestions made in this issue I liked the idea of reserving border for parent/child and displaying status with separate bar below the image. This one: