Edgewall Software
Modify

Opened 12 years ago

Closed 7 years ago

Last modified 4 years ago

#10626 closed enhancement (wontfix)

Limit the line length in paragraph text on the wiki pages

Reported by: Oleg Frantsuzov <franoleg@…> 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 pres 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)

t10626-r1.diff (3.3 KB ) - added by Oleg Frantsuzov <franoleg@…> 12 years ago.
Patch against trunk implementing line length limiting on wiki pages, with a user preference

Download all attachments as: .zip

Change History (18)

comment:1 by Remy Blank, 12 years ago

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.

comment:2 by Mikael Relbe, 12 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.

in reply to:  2 ; comment:3 by Christian Boos, 12 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.

in reply to:  3 comment:4 by Oleg Frantsuzov <franoleg@…>, 12 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 ps, uls and ols, 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 Oleg Frantsuzov <franoleg@…>, 12 years ago

Attachment: t10626-r1.diff added

Patch against trunk implementing line length limiting on wiki pages, with a user preference

comment:5 by Oleg Frantsuzov <franoleg@…>, 12 years ago

Keywords: patch review added

comment:6 by Christian Boos, 12 years ago

Milestone: next-stable-1.0.x

I'll give the patch a try.

comment:7 by lkraav <leho@…>, 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 lkraav <leho@…>, 12 years ago

Cc: leho@… added

comment:9 by olre, 12 years ago

+1! Great fix.

comment:10 by Oleg Frantsuzov <franoleg@…>, 11 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 lkraav <leho@…>, 11 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.

comment:12 by Christian Boos, 11 years ago

Milestone: next-stable-1.0.xnext-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.

in reply to:  12 ; comment:13 by Oleg Frantsuzov <franoleg@…>, 11 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.

in reply to:  13 comment:14 by Christian Boos, 11 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 Ryan J Ollos, 9 years ago

Milestone: next-dev-1.1.xnext-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 Ryan J Ollos, 7 years ago

Milestone: next-major-releases
Resolution: wontfix
Status: newclosed

The wiki now has a narrow/wide expander. I suspect that is as far as we'll go with this.

comment:17 by anonymous, 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?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.