I think you're referring to the black bar below comments that are too long which can be clicked to expand the comment?
That has nothing to do with KES's collapsible comments feature as someone else brought up. It's a native kbin feature.
KES actually has a feature that addresses this by automatically clicking that bar, but it seems to only apply to thread bodies, not comments, currently. If you're interested in having it apply to comments too, try filing a new issue on Github requesting the feature. The mod in question is "Always expand post bodies" in the Threads category. This should be fairly easy to add.
Thank you. For me it shows up as a grey bar with an arrow in it (it then becomes two bars when pressed); that might be based on color scheme. But, yes, toggling various KES mods didn't affect it the issue, so it's very likely that it's a Kbin issue. Surprised no one else has mentioned it, if that's the case! It seems to just block out the last couple of lines afaik
I wasn't able to reproduce the issue on a default kbin setup with KES either on off. The "always expand post bodies" feature of KES only applies to bodies, but I could extend it to support comments as well so that they auto-expand. What I didn't observe was any situations where the expansion bar obscures the text. Do you have a screenshot of that?
I know what they mean, because I have the same issue on my work pc (but not at home). I forgot it happens because the personal userstyle I'm using includes CSS to fix this issue entirely.
@speck get yourself Stylus if you don't have it already and try this CSS which works perfectly for me:
div.more:not(:nth-child(1 of .more)) {
display: none;
}
Can't guarantee it works with kbin's built in custom CSS functionality, as that one seems to filter out some selectors (no logic behind which).
@shazbot
Basically, what happens without that CSS is that
Clicking the bar once scrolls me down a bit but otherwise does absolutely nothing.
Clicking the bar again turns the arrow upwards and spawns a new bar above the existing one.
Clicking the upper bar repeats step 1.
Clicking the upper bar again turns the arrow upwards but doesn't spawn another bar, nor does it do anything else.
Clicking the lower bar removes the upper one again and turns the arrow back downwards.
At no point is the comment ever expanded. When OP says it obscures text, that's just the default state where only x lines of the comment are shown and the bar covers the last line(s). The issue is the comment can't be expanded, so it keeps obscuring the text even when clicked as nothing actually moves.
Looking at the HTML source, I can see five instances of the bar existing at once on the same comment.
I tested just now to turn off my scripts one by one and KES was the culprit. Disabling it fixed the issue. I'll try checking which feature is causing it.
For me, the culprit is the collapsible comments mod (or the standalone script if you're using that one).
edit: The root cause seems to be lines 182 to 190. But the actual troublemaker appears to be on kbin's side, not KES. When the mod's main function finishes, the comment still only has only one .more element like when it began.
I've disabled all other mods and userscripts, so it's not one of those. Also just tried to disable KES (and even the monkey) entirely, running the script from the console instead. No change either, it's still happening.
The code fragment in question copies the comment into a new children container. I'm thinking this probably makes some part of kbin confused, leading to the issues we're seeing.
It might be best to just include the userstyle I'm using in the CSS added by the mod.
This is the code between lines 182 and 190, removing which prevents the issue:
let children = previousComment.querySelector('.children');
if (!children) {
// If not, create one
children = document.createElement('div');
children.className = 'children';
previousComment.appendChild(children);
}
// Insert comment into children container
children.prepend(comment);
Thanks for looking into this. I've been meaning to audit this mod, but was a bit busy this week. In light of this report, this seems like as good a time as any.
Unfortunately, the mod is no longer maintained by the original author, so I'll have to inherit it and refactor it. I feel it is overengineered for what it attempts to do, so it should be streamlined and the aforementioned issues fixed. I am also aware of the issue that the mod fails to unset itself properly when turned off. I am really not satisfied with its current functionality.
Root cause analysis and solutions are described in a subsequent comment
I have completed an audit of the mod and observed the following issues:
Does not properly unset classes and restore the page to an intact state when turned off: this was having the side effect of making the threaded lines look incorrect when toggling on/off in place. The mod should not leave dangling containers around after it is toggled off. The mod creates an outer container so that the "expando" lines flow all the way down through the child elements, but when turned off, these child elements need to be moved back out of the container to be adjacent to each other and the container removed. => Fixed locally.
Does not properly unset event listeners attached to nested comments. Same as above, tends to leave dangling listeners and does not unset itself cleanly. => In progress.
Because it physically manipulates the DOM and moves sub-comments into their own container down the tree, triggers an event (likely a bug) on Kbin's side whereby any time the DOM is updated for that element, Kbin appends a more element (text expansion button) if the text overflows a certain length, even if a more element is already present. You can test this by creating a dummy div above or below a long comment and then moving the long comment before or after that div. Simply moving its position in the DOM will trigger the creation of another more element inside. And because the mod puts each comment into its own container for the purposes of threading nested chains of comments, this will trigger the creation of as many mores as there are indendation levels. So for a comment chain 5 replies deep, there will be 5 mores. This is further exacerbated when toggling the mod on and off, since these mores are not getting wiped and will just keep getting stacked up. Since this is also an upstream issue, our only alternative here is to walk through the tree and remove the extraneous more elements after nesting occurs. This is similar to your CSS solution, but instead of masking them, physically deletes them, otherwise we will have a constantly growing tree of mores every time nesting happens. I guess this should also be reported upstream as well. Kbin seems to expect no DOM manipulation to occur, which is reasonable, I suppose, but might be better if the callback doesn't insert the more element at all if it's already present. => Easy fix on the Kbin side, in progress.
I have resolved the aforementioned issues with a hotfix on the testing branch; please test when time permits. Executive summary:
The mod fully restores the DOM tree to its original state when toggled off. It is now possible to toggle the mod on and off on the same page without reloading, and changes will behave as expected.
For reasons of security, the mod no longer allows clicking the post headers or post body as a means of collapsing/expanding comments. This was attaching unnecessary listeners to elements on the page, with no way of clearing them when toggled off (besides hard refreshing). Now the only approved way of expanding/collapsing is to use the +/- icon or colored bars.
The mod erroneously modified the CSS of profile pictures to give them rounded borders, which was unspecified by its intended behavior and documented nowhere in the description. Now they conform to the standard square format.
The superfluous mores are being removed now for comments with overflow text. What I thought would be a quick fix turned into hours, and I thought I was losing my marbles over this one for a long time, since the tree clearly showed numerous duplicate mores, but only one per comment was being shown at runtime of the script. At first, I did not seriously think that the mod was completing its runtime cycle prior to the duplicate mores being spawned, but indeed this is what was happening. For now, I have added a 20ms sleep before clearing the extra mores, and this seems to suffice to let them propagate before the mod can continue with the cleanup phase. This seems satisfactory for now, short of attaching observers to wait for the duplicate mores to appear.
I believe that covers everything. It should be possible to switch the mod on and off at will now and see no adverse effect.
Teardown isn't working for me, tried multiple devices and turned my custom styling off.
After teardown this is how the site looks like to me. Also, it seems you need to remove the mores on teardown too. The more issue is now fixed when the mod is active, but appears again after teardown.
That code snippet seems to work I'm new to stylus, but I think I did it correctly and it allowed me to expand and read your two longer comments here. Thank you for that!
It may have something to do with the bug mentioned here:
The improved collapsible comments add-on, part of the original KES collection in version 1.0.0, has some conflicts with kbin's own implementation of collapsible comments. I am cleaning this up, but it may take some time
I'm not sure what KES is but if I just scroll a bit then what u want to read or what I am writing is clear of the arrow. I don't use the arrow and am indifferent to it but I imagine others may like it. I use the PWA.
Progressive web app. You install it from your browser, and it runs from your browser, but you get a special icon to launch it. Probably more To it than that, but that's the most I think I know enough to say haha!
It's definitely not ideal at all currently. You've already found out how to do it currently, but I'd like to point you towards some alternatives that currently exist to make this easier until ernest adds something official.
Here's the userscripts I know of, each approaches the task a bit differently:
Improved Channel Select Menu adds your subscriptions and collections to the select channel menu. It's the one with the 3 dots and lines next to your username. This one is the only one that currently supports collections I think.
Floating Subs List adds a new (collapsible) sidebar to the left which contains your subscribed magazines.
Choose whichever sounds like more your thing, or try each and go with which works best for you.
If you're not familiar with userscripts: just get yourself either Greasemonkey, Tampermonkey, or Violentmonkey from your browser's extension/addon store, then head to the script's greasyfork page (I linked you to them above) and click the big green button. For KES it's a bit special but just as simple, just use this link, it should bring up an installation page. After installing KES, you're looking for a wrench next to the user button to access its options and turn the feature on.
@Ernest is the process for approving an ownership request done manually by you? I requested ownership of a magazine a few weeks ago and it hasn't gone through. I know you've been busy with running/improving the site so it might be worth making the process either automatic or give permission to someone you trust to approve/deny. Hope you are having a good one!
You can go to "Settings" or "Profile" and you'll find a subscriptions tab.
Alternatively, you can install a userscript that adds a faster way of accessing them. Here's one I recently made and one made by raltsm4k.
I've attached a screenshot of what I see when I go to my profile. Maybe I'm just blind, but I can't find a "subscribed" list for magazines. There's the one for threads, but posts from more obscure communities are difficult to navigate to.
Edit: I found it. I need to click on the rightward-arrow next to "Followers" under my banner in order to reveal "Subscribed".
Thank you for pointing me in the right direction.
I just wanted to let you know, since you mentioned it, I figured out what was wrong, and the latest version should fix the updating problem. You'll still have to reinstall one last time though, unfortunately.
The first request would definitely be a nice setting to have.
As for the second one, I think microblog posts are pretty easy to distinguish from threads already, as everything's organized completely differently. There's no title, the avatar is in a different spot with a different shape, the upvote button is in a different spot, there's no downvote button, etc. I think changing the color would just be visually jarring more than anything.
That makes sense. I’m actually not used to microblogs, and I never actually got into Twitter, so the distinguishing characteristics don’t really stand out to me as much. I think the color variation would help me better process what I’m looking at.
I think the color variation would help me better process what I’m looking at.
You can change the color yourself btw. The traditional method is to install the Stylus extension/addon, but I think kbin now lets you define your own styling in your profile settings, though I haven't tried it. (tried it now and this doesn't really seem possible there, has the same selector deletion issues as magazine css)
In the HTML code, microblog posts and threads are represented differently. Posts are blockquote, while threads are article. This makes it easy to restyle them via userstyles.
The images I'm using here probably won't work as embeds, but opening them as links should work.
Depending on if you use Firefox or a Chromium-based browser (Chrome, Edge, and almost all the others), get yourself the Stylus extension (chromium) or addon (firefox).
Give the style a name to the left and hit the yellow "Save" button. The site will update in real time, you shouldn't even need to reload it for the changes to take effect after saving. In fact, after saving it once, you don't even have to keep saving it after every change in my experience.
I've changed the above code a bit to also cover the replies to posts, that's what the .comments stuff is about.
This will give you a very red background. I just chose this for the example to make the change obvious to see at a glance. You can replace the red with another color name, or an RGB or HSL value for a more granular choice.
I recommend using HSL if you want to tweak the color later without having to open up a color picker. You just choose a base color, how saturated it should be, and how light you want it. And optionally the transparency.
The HSL equivalent for red is hsl(0,100%,50%).
If you just want microblog posts to be a bit lighter or darker (depending on your theme) than threads, you can use hsla(0,0%,100%,0.15) (this makes them lighter, change the 100% to 0% for darker). Tweak the transparency (the last value) to change the intensity of the color change.
Besides the background color, you can also change other CSS properties. Just add additional lines in the pattern property: value;.
For example, you can set a border using border: 1px red solid;, which creates a red solid border of 1 pixel width.
I like to use this site as a reference myself for what properties exist and how they're used.
Thanks, this is the best implementation idea for this I've seen yet imo, will definitely be using this from now on.
I haven't found any bugs yet, but I'd like to request two future improvements:
Changing the order of magazines and collections
::: spoiler Details
I have like three collections and a ton of magazines, so having to scroll through all the magazines to reach the collections is a bit of a pain. It's still much easier than before this script, but it would be even better if I could move the collections above the magazines.
On the other hand, someone else might have the opposite situation and would prefer it the way it currently is, so unlike the other user I'm not asking you to just swap the order.
I think the ideal solution would be adding a setting somewhere to determine which comes first. So every user can tailor the functionality to their needs.
:::
Support for turbo mode
::: spoiler Details
Ernest added turbo as an optional mode in the past months (you can find it in the sidebar options). It turns the site into a single page experience, which means kbin.social links don't open the website anew entirely but rather replace the page content, including the changes your script makes. This cuts down on loading time, but it also causes scripts to break.
It would be great if the script were to support turbo mode eventually, especially if Ernest makes it the standard in the future (it is marked as experimental currently, so that's probably the eventual intention).
To do so, you'd have to attach a MutationListener to the body element like I did here. But that will run many times more than just on navigation, so you'd also have to ensure your code does support being run multiple times without breaking.
:::
kbinMeta
Najnowsze
Magazyn ze zdalnego serwera może być niekompletny. Zobacz więcej na oryginalnej instancji.