Screenshot

?

I assume this makes the comment headers just use the standard (non-blue) header color, right?

@fregante @SunsetTechuila thanks for the PR and merge!

@SunsetTechuila Why was the fallback fixing the transparent header problem reverted?

• 917f531

@karlhorky #8809 (comment) #8809 (comment) #8809 (comment)

That's I don't like for sure

@SunsetTechuila what do you mean? That it starts out as black and then changes to blue on hydration? Maybe the fallback can be applied differently, to avoid the FOUC? Eg. via JS or something.

Can html:not([rgh-OFF-show-names]) be used here?

But I suppose manually adding a class in that feature could also work. 👌

Or maybe adding a class, as fregante mentioned?

Or maybe adding a class, as fregante mentioned?

That's what I'm planning to do: add this class and use it to disable sticky-comment-header if show-names is disabled

Maybe we could do it in such a way that the feature doesn't get disabled, but instead degraded? (graceful degradation). Black/grey background is fine in that case.

Then the notice about the show-names could also probably be removed.

Maybe we could do it in such a way that the feature doesn't get disabled, but instead degraded? (graceful degradation).

I couldn't. Maybe you can

Ok, how about this? rgh-own-comments feature that simply adds .rgh-own-comment to your own comments. It would be a silent, non-disableable feature that can be used by others. This way we drop the inter-feature dependency (show-names) and can be used by more features in the future if helpful.

@SunsetTechuila what do you think of this approach with the non-disableable rgh-own-comments feature? Do you think that you could do this? Or should I give it a shot?

Maybe there are already several helper features like this in RGH, but if not, then I'd rather stop trying to keep sticky-comment-header CSS-only. Keeping it CSS-only has caused way more hassle than ~10 lines of simple JS code ever could

@fregante is it a requirement to keep it CSS-only? Or would a short JS feature like what @SunsetTechuila is proposing also be acceptable?

I already gave my suggestion

Ok, so the non-disableable rgh-own-comments feature is the path forward then.

@SunsetTechuila if you think you would do this, then great! Otherwise, I can take a shot at it.

For future reference: Note how much this "small feature" had to be discussed and tweaked and bugfixed for months. This should help understand why I'm hesitant to accept certain features and why I might drop this one.

I empathize with the back and forth of the discussion sapping of focus away from other work - it's unfortunate that GitHub's DOM, tech stack and framework integration makes for a less stable foundation upon which to build a browser extension (on the other hand, luckily, there has been no shifting in the relevant parts of that foundation since this feature was first implemented).

However, aside from the back and forth in discussions and the technical requirements, I'm not sure I agree that the amount of total implementation work that has gone into this feature is overly blown-up (also as I mentioned in my comment in October - most of the work was done before then): the first versions and fixes have been developed pretty quickly by @SunsetTechuila (also taking into account browser compatibility).

Maybe with looser requirements like not having the CSS-only rule and not having the dependency on other features it could have gone a bit faster - but probably also not worlds apart.

Ok, how about this? rgh-own-comments feature that simply adds .rgh-own-comment to your own comments. It would be a silent, non-disableable feature that can be used by others.

Maybe there are already several helper features like this in RGH, but if not, then I'd rather stop trying to keep sticky-comment-header CSS-only.

@SunsetTechuila if you think you would do this, then great! Otherwise, I can take a shot at it.

@karlhorky I didn't look thoroughly, but I couldn't find any other helper features like that. So if you want to implement it, you'll have to do it yourself.

When you do, please also change [class^='ReviewThreadComment-module'] to [class*='ReviewThreadComment'] - GitHub added a similar component with a different name, InlineReviewThread. Test url: refined-github/sandbox@7becc26#r174065194