topic #14111 made me think of this. Basically, would it be desired to have a permanent blacklist, i.e. images that you never want to see no matter what. There have been quite a few times where I'll get momentary glimpses of blacklisted images since it takes a while for the Javascript to load. It makes it a especially awkward if others are around and get glimpses of the blacklisted images themselves.
The idea would be to make your blacklist be implemented like Safebooru as opposed to using Javascript. One idea would be to have a separate list for these types of image blocks. Another idea would be to have a user selectable option that makes the blacklist behave one way or the other.
I like the idea of having a separate server-side blacklist, as I have some blacklisted tags that I never want to see and some that I unhide based on context, like guro (darn you, gruesome KanColle doujinshis).
The flickering would be possible to fix without requiring two types of blacklist. The problem is that thumbnails default to visible and are hidden later by Javascript. If this were reversed, so that thumbnails defaulted to hidden and nonblacklisted posts were unhidden by Javascript, then there would be no opportunity for flickering.
The drawback is the failure mode: if you have Javascript disabled, or if there's any kind of bug that prevents the Javascript from running, then everything would stay hidden.
The drawback is the failure mode: if you have Javascript disabled, or if there's any kind of bug that prevents the Javascript from running, then everything would stay hidden.
Could this be a user-selectable option...? Such an option would control which way posts start out... visible or non-visible. If it starts out defaulting to visible, then there would be no issue. Users would have to manually change it, and therefore manually accept what those changes entails... i.e. Javascript needs to be working.
evazion said:
Also, it should be noted that it's possible to hard blacklist tags in custom CSS: ....
It would be impossible to do complex blacklist strings with that method, e.g. nude -1girl -multiple_girls. Additionally, it would also hide any other tag that contains that term. Tag Search: *photo*
I just tried your CSS and for me it has the side effect of putting all parent/child thumbnails below each other instead of next to each other. Random example with parent: post #593574
It seems like most post previews are block elements, but the child/parent thumbnail previews are inline-block elements. So, I tested out setting all of the post-previews to inline-block, and didn't see any issues with it.
I believe I tested it out on all of the pages with thumbnails, but I might have missed some. If there are any issues with the above, let me know, and I'll create more specific selectors to set the display correctly.
The flickering would be possible to fix without requiring two types of blacklist. The problem is that thumbnails default to visible and are hidden later by Javascript. If this were reversed, so that thumbnails defaulted to hidden and nonblacklisted posts were unhidden by Javascript, then there would be no opportunity for flickering.
Perhaps the blacklist handling could be moved to server-side? The thumbnails could get appropriate classes during erb processing, and javascript could be used only to hide/unhide the thumbnails. It also removes the need to parse tag strings on client side.
The thumbnails could get appropriate classes during erb processing, and javascript could be used only to hide/unhide the thumbnails.
This would validate the existence of the "dab" cookie, as opposed to making it local/session storage. It doesn't make sense to have cookies if they're only used client-side. It's true that local/session storage doesn't have any expiration, but there's always ways around that, like what is currently being done with autocomplete. I wonder just how many of the cookies could be moved to local/session storage...?
It also removes the need to parse tag strings on client side.
Hopefully the tags will still be kept in. That would allow for Javascript programs with more than one blacklist, for instance.... (like the one I'm currently working on)...
I hope this isn't straying too far off topic, but this thread brought it to mind, and it can work with BrokenEagle98's CSS above.
This CSS will whitelist your own favorites. It feels a little kludgy, since the list of Blacklisted tags on the left side still thinks they're blacklisted, but it seems to work properly. Note that this CSS means your favorites will never be hidden by your blacklist; they'll always show up, no matter how much you toggle your blacklist on and off.
/*Whitelist own favorites*/
.post-preview[data-is-favorited="true"] {display: inline;}
To combine it with BrokenEagle98's CSS, it goes at the end:
Using the above CSS, your favorites will show up first, then the rest of the non-blacklisted pictures will show up. It's kind of like what normally happens with the blacklist, but in reverse. If you want everything to show up at the same time, the last line needs to be slightly different:
It seems like most post previews are block elements, but the child/parent thumbnail previews are inline-block elements. So, I tested out setting all of the post-previews to inline-block, and didn't see any issues with it.
I believe I tested it out on all of the pages with thumbnails, but I might have missed some. If there are any issues with the above, let me know, and I'll create more specific selectors to set the display correctly.
I'll be updating the CSS thread with the above.
It’s broken when viewing a user’s comments or the comment search results (I guess both are the same). Everything else seems to be working fine so far.
Are you talking about the missing Blacklist box...? I just noticed that, but it's not an issue with the above CSS, but the fact that Danbooru isn't including the correct HTML for the Javascript to run on. It's basically looking for the "#blacklist-box" and "#blacklist-list" entries, but since they don't exist, there's nothing for the Javascript create from. It still hides the posts, and the above CSS still prevents the flicker. Regardless, will create an issue about the above on GitHub.
No, I wasn’t talking about the missing blacklist box. I was talking about how some comments and thumbnails are put next to others instead of all below each other.
No, I wasn’t talking about the missing blacklist box. I was talking about how some comments and thumbnails are put next to others instead of all below each other.
Ok, I went back, and found that the inline value currently works in all places.
Post show (w/child and w/parent)
Sorry for undermining your efforts by finding more issues, but the “current image” border in the parent/child bars doesn’t play nicely with inline: example. The grey border should be all around the thumbnails, not just two small bars to the left and right.
Sorry for undermining your efforts by finding more issues, but the “current image” border in the parent/child bars doesn’t play nicely with inline: example. The grey border should be all around the thumbnails, not just two small bars to the left and right.
No worries...thanks for reporting all of these errors. I want to make it as error free as possible. This will probably require very specific selectors. I'll post something up by the end of the day PST.
1. Every image container was block format with the exception of parent/child containers, which were inline-block. 2. Included an implementation for full-size images, which was missing in the original. 3. Removed dependency on order by taking advantage of CSS priority calculations.
Edit:
(2017-07-11)
I updated the above with a fix in forum #132142. Basically, a recent change causes no posts to appear on pages without blacklist controls. The following code was used to address this on the pages found to have this problem.
