#10626 closed enhancement (wontfix)
Limit the line length in paragraph text on the wiki pages
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | wiki system | Version: | 0.12.3 |
Severity: | normal | Keywords: | layout css patch review |
Cc: | leho@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Currently, Trac uses a mixed approach when it comes to limiting the width of text within its interface.
- The ticket page has clearly defined max-width, with several wontfix-tickets (#669, #3126, #7158) strongly supporting this limiting of width is by design.
- The report and query pages use liquid layout, utilizing all available space, which is of course optimal for viewing tables.
- The wiki pages are also liquid, even though in certain cases this can lead to overly long lines of text.
I doubt long lines on wiki pages are useful. With sufficiently long lines, eye motion is not enough to read text, and one has to turn their head.
Different studies (which can be found elsewhere on the web) suggest different lengths, from 45 characters per line to 75 cpl, or even up to 100 or 120. Anyway, if I maximize my browser window on my 1920×1600 screen, line length on Trac 0.12 wiki (stock CSS) is around 250 cpl.
One can argue that it's useless to make the browser window that big. However, this can be really useful for the aforementioned report viewing.
At the same time, wiki pages can contain not only text paragraphs, but also tables, code excerpts and other stuff that is better viewed without width limitations.
Therefore, I suggest to limit not the wiki page container's width, but widths of p
, ul
and so on. Thus text lines will have limited widths, while tables and pre
s will be liquid.
I can come up with a patch for planned release 0.13 if the Trac Committee of Esthetics accepts my proposal.
Attachments (1)
Change History (18)
comment:1 by , 13 years ago
follow-up: 3 comment:2 by , 13 years ago
I would prefer a personal option to instantly present the whole page wide or narrow. A very good example is demonstrated by http://code.optaros.com/trac/oforge/; click the button at top-right to instantly change the width.
follow-up: 4 comment:3 by , 13 years ago
Replying to mrelbe:
(OForge) click the button at top-right to instantly change the width.
Never noticed that button, but it's very cool! Let's steal that.
comment:4 by , 13 years ago
Replying to cboos:
Never noticed that button, but it's very cool! Let's steal that.
The idea of making this a user preference has never occurred to me, even though it fixes the problem Remy is talking about.
I'm submitting a draft of what I had in mind (i.e., line-limiting of p
s, ul
s and ol
s, approx. 110 cpl), albeit with a user preference to control this (turned off by default). I still think that tables, code fragments and large images should not be limited in width, and limiting all these is what the Optaros narrow style does.
Is the preference enough? What do you think? Is it indeed useful to be able to switch width limiting on any page? any wiki page? If it is, where should I place the button?
I'd like to get your feedback.
by , 13 years ago
Attachment: | t10626-r1.diff added |
---|
Patch against trunk implementing line length limiting on wiki pages, with a user preference
comment:5 by , 13 years ago
Keywords: | patch review added |
---|
comment:7 by , 12 years ago
Definite +1 from me on the paragraph line limit. Partly related to my #10739 sidebar line of thought, where I happened to discuss this very thing without knowing about this ticket.
comment:8 by , 12 years ago
Cc: | added |
---|
comment:10 by , 12 years ago
Any feedback on the patch? If the entire idea has been thrown away by the Trac team as being inappropriate, I suggest to close the ticket altogether, not to leave it linger.
If, on the other hand, something can be done to fix the problems with the idea/implementation/patch, I'll be happy to do it.
comment:11 by , 12 years ago
I have a feeling it has gotten a bit lost in the shuffle but it did have plenty of positive feedback. Definitely no reason to close it just yet.
follow-up: 13 comment:12 by , 12 years ago
Milestone: | next-stable-1.0.x → next-dev-1.1.x |
---|
It's no longer appropriate for 1.0-stable, but I'd like to pursue Mikael's suggestion to do it the OptaroForge's way.
follow-up: 14 comment:13 by , 12 years ago
It's a pity that no one of the core contributors ever actually argued against my rationale of limiting the line length of paragraphs, as opposed to the width of the entire page (aka OptaroForge's way). If my suggestion was flawed in some way, I didn't have a chance to learn what the flaw was.
The only argument against the fixed line length was that it's hard to customize, while the browser window size is easy to adjust. I thought the user preference could solve this; moreover, on OptaroForge, there's no way (I know of) to customize the 'fixed' width.
I think it's possible to introduce an additional setting, allowing the user to adjust the 'fixed' line length. It's quite clumsy though.
Also, if the instantaneous nature of the OptaroForge's switch is what's needed, I guess this can be done in this more accessible way, not as a user preference.
Anyway, the decision to accept or reject a submission remains yours to make. However, I'd like to get a clearer understanding of what was actually decided.
comment:14 by , 12 years ago
Replying to Oleg Frantsuzov <franoleg@…>:
It's a pity that no one of the core contributors ever actually argued against my rationale of limiting the line length of paragraphs, as opposed to the width of the entire page (aka OptaroForge's way). If my suggestion was flawed in some way, I didn't have a chance to learn what the flaw was.
Nothing "flawed" per se, I just don't like it much:
- you have a limit on some elements, not on others (e.g. tables)
- it doesn't look well on wide pages anyway ("align left")
- it's done differently than on the ticket page
- it's just for the wiki, not for anything else (roadmap, milestone, etc.)
comment:15 by , 10 years ago
Milestone: | next-dev-1.1.x → next-major-releases |
---|
Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.
comment:16 by , 7 years ago
Milestone: | next-major-releases |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
The wiki now has a narrow/wide expander. I suspect that is as far as we'll go with this.
comment:17 by , 4 years ago
I like this for exactly all the reasons the developer dislikes it.
Is there some way I can get this patch for my own wiki - or can it be made into a plugin?
I have the feeling that this is a case where it won't be possible to please everyone anyway. I also use two large screens, and my browser windows are never maximized. And if I really want to have a full-width table from time to time, it's just one click away. Whereas if the text width is limited, but the limit doesn't suit me, I have no simple way to extend it, and have to go and customize the CSS.
So that's a -1 from me. I'm not on the committee, though.