Thank you!

Thank you for the suggestion.

I will look into it when I could add support for it sometime in June. It should be possible to run without difficulties, as also noted by CharlesW.

Thank you.

Thank you!

> I don't see an option to toggle dark mode

You must hover over your username, or login, link, in the bottom-left corner, and a pop-up window should appear with the option to switch to dark-mode.

> can you make it so the splitter bar allows resizing from the right or left?

Thanks. Can do.

> how do we know we can trust this extension?

The extension adheres to the best practices, and like you said requests only access to HN. Manifest v3 is designed such that should an extension change its permission requirements, it must engage the user to decide, thereby being obvious.

> I see no information about a privacy policy

Sorry for that. I can post one in the next weeks.

> Why are the last reviews from 2012 to 2014?

The comments are from v1 which was released back in 2010. Although it continue to worked, v1 was practically out-dated and probably didn't encourage anyone to comment.

v2 was released in February 2023.

Thank you for taking the time to answer the questions.

Thanks.

I submitted the extension to Firefox Add Ons store. Will post when it becomes available.

Could you please be more specific about your recommendation ? Which text groups ?

I'm calling the following a "text group":

1. A singular comment

2. For a text submission such as Ask HN, the post contents

A general readability recommendation is to limit your line lengths to be around 45-80 (e.g. [1]).

For websites that just have a singular main body of text (e.g. blog posts, articles), this is easy to do with css rules.

The text on HN comments page is of a bit different nature. Each child comment cascades, there's an indent. So to apply the typography rule of "not too many characters in a line, one would have to apply the css rules per text group*. Effectively a child comment is still getting wrapped with the same column width, not lower.

[1]: http://webtypography.net/2.1.2

Thanks I will reread your comment later. I actually agree with that.

Although not hard limit, if you open HN with the extension on, you can then adapt the window size, and the content width will be around that limit;

That's how I do it for now.

Did you get a chance to try it ? I do a lot of reading it too, and felt benefited from it.

Can I ask what specifically was hard to parse ?

I can also provide preferences for any recommendations you may have, that can benefit one. Will add the font-size change for example, as commented elsewhere.

Also, dark mode is more suitable for low light conditions, and does make reading much easier.

I did try it. Only for a few minutes, but I felt it was enough to get a sense of the typography/layout.

I think my main issue was font size and lack of whitespace. I'm typically reading 10-12pt fonts in docs, code, and body content on web pages. HN by default is close to that. I think I'm therefore used to that and find it the easiest size to scan content in – I'm not reading every word I'm skimming through quickly a lot of the time.

That's also where whitespace can help. When skimming I found the page to be a mess of text with little separation. More whitespace, more contrast between different types of text, etc, could do a lot to make the page more easily readable.

One thing that I do find annoying with HN is the long text lines. I'd love to be able to wrap paragraphs at a relatively small width – this typically aids reading and comprehension, and it's why most publishing websites limit content width even on wide monitors. This could also be related to the layout issues I have with this extension – My browser window is currently ~2000x1900px, and it seems the content expands continually with no limit. Maybe there could be a limit to aid readability?

I find content much harder to read in dark mode and don't use it. It strains my eyes with the contrast and I find it harder to focus. I appreciate some people like it but I think it's a personal thing and important to have both options.

Thank you. I will see how I could use your insights.

This extension only requests access to HN's known domains.

If one would try to request to a non white-listed domain it would trigger Access-Control-Allow-Origin error.

Also I think v3 makes it quite hard to use remote loaded code.

Any attempt to be malicious would probably be caught by store's review process eventually.

Yeah, I'm not saying this extension is doing anything nefarious. I am saying that Google's propaganda about MV3 isn't right, and it's obviously spilling out to other people. MV3 blocks one specific api call in OnBeforeRequest()...the one that's useful mostly to ad blockers. The remote loaded code restriction is laudable, but the review process is weak. It's fairly easy to get shady things approved.

Manifest V3 prohibits extensions from loading any remote code like JavaScript or Wasm files[1].

1. https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o...

Right, I acknowledged that in the comment you're replying to. But the review process is weak. And, I don't need to load external code to exfiltrate stuff. For example, I can load an image with a specific name/path, or hijack functionality already on the page, like Google Analytics code. Generally, non-trivial extensions cannot be both secure and useful at the same time.