Multi-column mode

[drfiresign]

Hi, I was wondering if it was possible to include a multi-column option in your extension.

This would allow someone with a wider monitor to read several columns of text at once. So instead of having a large amount of space on either side of the text, or having to track very long lines of text across the page, the user could read lines of reasonable text width across multiple columns allowing them to see most of the page at once.

I'm sure there's a better way to do this but I found some CSS that I was able to add to the built-in Reader Mode which added multiple columns and this was the relevant section from it. The rest was all making the color style match the Reader Mode page.

.container {
    margin: 25px 25px 25px 25px !important;
    max-width: 2400px !important;
    column-width: 550px !important;
    column-gap: 20px !important;
    column-count: 4 !important;
}

I'm sure this feature would require much more than just adding a couple of rules where appropriate of course. There would likely need to be a way to enable and disable the option for those who don't want it or perhaps it would auto break into columns if the page width hits a certain threshold. I wouldn't presume to know how best to implement it, but maybe you'd find this an interesting addition to your extension?

In any case, thank you for taking the time to read my idea!

[ushnisha]

Thanks for the issue/suggestion.

I took a look at the multi-column css features and it should be easy to add a user controlled option to select the number of columns in which the transformed text is rendered.

I am hesitant to automatically break the text into columns because that would change default behavior; the user can always set up the number of columns they want manually (based on their screen width) and adjust that along with the "reading width" option that already allows them to limit the width of the text on their screen (as a % of the total browser window width).

As you mention there are a few other things to take care of (the heading, if any and the original url link at the top, any navigation related links at the bottom will not respect the columns and will still need to be shown spanning all columns). Images will also need to be resized based on the column width -- otherwise, that will affect readability.

Since the extension supports printing to a pdf, this multi-column layout will by default reflect in the printed page (which might be A4 or letter). That may not always be desirable -- which will require another user controlled option to preserve (or not preserve) the multi-column appearance while printing to pdf. Maybe the first version should simply print in a single column and then based on how many readers like this feature and want it during printing, another option can be added later.

There are also several other column related style options and supporting all of them through user options is not feasible. So, I will not attempt to do that -- already the number of options for customization is large and that adds its own usability/maintainability challenges.

Leaving the technical issues aside, I have a question for you....

I have personally found multi-column documents difficult to read unless the entire document fits within the screen height (no scrolling required). Otherwise, one would have to scroll down to finish reading the first column; then scroll all the way up to get to the start of the second column and then scroll back down; and so on. Do you have any thoughts on how this should work from a readability/usability stand and why the advantages of multi-column text out-weigh the scrolling related problem I mention above?

[drfiresign]

Shoot, I should have known better than to only test it on the material I was interested in reading 😅 You're completely right, a much longer page is much more frustrating to read that way. Maybe not more frustrating per se, but definitely a different kind of frustration in itself. Personally, I would use this feature on shorter pages where I can reasonably expect the text to fit into one screenfull, like newspaper or magazine article pages. There's a very surprising amount of padding and repetition in those kinds of pages and I find the bare text is much shorter than I expect it to be.

However, for a longer text like the Emacs user manual as a single HTML page I think the usability could be solved if one could redirect the page down key to advance to the side by a whole frame and the user could be guaranteed they would land at the beginning edge of a column, not in the middle of one. How feasible that is, I'm not sure.

A perhaps more complicated solution would be to create a frame which matches the window width and only display as much text as fits into that frame. If you could take all the text and break it into segments and then hide or show each subsequent segment with a next page button (or use the page down key) to advance to the next portion of text.

I hadn't considered how to handle PDFs though. I think that a user wouldn't want a multi-column layout to translate onto a PDF as they might be used most for printing to a physical page which is already a reasonable width. Unless the print itself is particularly small—which I think would be resolved by the printing utility's option to break into columns–so to me it seems reasonable to leave it behind for a first release.

The advantages that I see are that I can keep more of the screen on the page at once, so if I'm reading through something so I can I continue to reference it, I can quickly reference sections which are further away from one another than I can with a single column. Even I needed 2 or 3 screenfulls to get all the text in the window, that's still easier to through than something which has 10 page sections I would otherwise navigate through with the page up/down keys.

[ushnisha]

Thanks for the detailed feedback!

On the scrolling issue, maybe things are not so bad in the sense that using the "Home" key will take us back to the top of the page; so getting to the next column is not multiple page-ups or multiple scroll wheel rotations. This may be an easier option that me trying to split the text and adding additional navigation buttons (or overrides to page-up/page-down) for multi-column layouts.

On the PDF issue, the interesting thing is that the printed PDF with multiple pages is laid out correctly; that is the text flow across columns is one page at a time and so once you are done with a page, you can move on to the next without needing to scroll back to the earlier page -- so whoever did the PDF printing/layout (or any underlying library code) has though though all of these cases this quite well! But I will stick to single column printing for now.

The good news is that the people managing the CSS standards are aware of this scrolling issue and may address this sometime in the future.

w3c/csswg-drafts#2923

https://every-layout.dev/blog/multi-column-manipulation/

So, it might be easier for me to simply implement multi-column support for now (with users using say the "home" key to get to the top for the next column to minimize scrolling). When the css standards support automatic vertical scrolling/pagination and that is implemented, incorporating this will be trivial in the form of adding another css column styling property when I set/update the column-count.

[drfiresign]

Excellent! That's great thinking about the Home key. Let me know if there's anything I can do to help out along the way!

[ushnisha]

I've already made the changes and submitted version 3.0.24. It has been approved and you should see the update notification soon.

A single new option is added to set the column-count style property in the extension settings/options page.

I will leave this issue open for a couple of weeks so that you have some time to test it out as part of your regular use. If there are any glaring problems, we can use this issue to address them. If everything seems to work fine in that period, I will close the issue.

Thanks again for the suggestion and feedback.

[ushnisha]

Closing issue... assuming user has tested it and is satisfied with the fix.

[drfiresign]

Yes, sorry about the radio silence. User is very satisfied 😄 Thanks very much for your work and incredibly quick implementation!