Open
Bug 16909
Opened 25 years ago
Updated 8 years ago
Word-wrap text/plain content pref UI
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(Not tracked)
NEW
People
(Reporter: dmosedale, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(3 files, 2 obsolete files)
127 bytes,
text/plain
|
Details | |
3.87 KB,
patch
|
Details | Diff | Splinter Review | |
5.57 KB,
patch
|
Details | Diff | Splinter Review |
Text files with very long lines (like the chat log in the URL field of this bug) are extremely unpleasant to read with the browser. There needs to be a way to force documents like this to wrap instead of creating a way-too-wide scrollbar, as happens now.
There is. You can use the -moz-pre-wrap style Here's an example from the ua style sheet: pre[wrap] { white-space: -moz-pre-wrap; }
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Component: Layout → UE/UI
Reporter | ||
Comment 2•25 years ago
|
||
More specifically, there should be UI to allow the user to do this trivially. Probably a menu item and a preference. Resetting the component to UI/UE and reassigning.
Reporter | ||
Updated•25 years ago
|
Assignee: troy → shuang
Status: REOPENED → NEW
QA Contact: petersen → claudius
Reporter | ||
Updated•25 years ago
|
Resolution: INVALID → ---
Comment 3•25 years ago
|
||
In 4.x we had pref of wrap text under Mail prefs. To me, I think it will be lot easier to make this wrapping happen by default in Browser if possible. Would any type of user prefer to "not wrap" the text and rather scroll further to read it? I realy doubt. Thoughts?
Reporter | ||
Comment 4•25 years ago
|
||
I agree with shuang; this particular pref is really useful for all of the browser, not just for the special case of mail/news.
Updated•25 years ago
|
Assignee: shuang → troy
Comment 5•25 years ago
|
||
I think troy should have this bug...
It can't go back to me. We already have a layout pseudo style that gets you the behavior Mose wants. We just don't have a way in the UI to specify it. I'll give it to Gramps. He'll know what to do.
Updated•25 years ago
|
Assignee: don → mcafee
Summary: no way to word-wrap text/plain content → [FEATURE] need UI pref for word-wrap text/plain content
Target Milestone: M14
Severity: normal → enhancement
Summary: [FEATURE] need UI pref for word-wrap text/plain content → [RFE] Word-wrap text/plain content pref
Target Milestone: M14 → M15
Comment 8•25 years ago
|
||
spam: added self to cc list as this might affect my realm.
Updated•24 years ago
|
Target Milestone: M16 → Future
Updated•24 years ago
|
Summary: [RFE] Word-wrap text/plain content pref → [RFE] Word-wrap text/plain content pref UI
Updated•23 years ago
|
Keywords: helpwanted
Comment 12•23 years ago
|
||
I encounter this a lot when using view-source to read the raw html-code. Often, it's generated code and the entire html-code can be found on a single line. Or (as seen on many news-sites) part of the file is from a template (correctly wrapped), and part of is included from a database without any wrapping at all. Scrolling can be very annoying in this case.
Comment 13•23 years ago
|
||
I can make a UI for this if someone tells me how to actually enable the wrapping for a www page. Do I apply white-space: -moz-pre-wrap; to the container holding the text file?
Reporter | ||
Comment 14•23 years ago
|
||
Since vishy's no longer around, reassigning to Ben Goodger; he'll have some idea of who should really own it, if it's not him.
Assignee: vishy → ben
Comment 15•23 years ago
|
||
Comment 16•23 years ago
|
||
This patch works, but I have no idea if I've done it properly. I just hacked at navigator.js until the menu option worked the way I wanted it. The option is disabled until mozilla comes across a text/plain document. It also forgets the word wrap option between pages because I didn't make a pref. I figured it wasn't necessary.
Comment 17•23 years ago
|
||
We should really support this. I'm surprised this would work, since it seems to be looking for a pre tag and I wouldn't have thought that a plaintext document would have a pre tag (I would have expected us just to show it with pre style but not actually insert that tag into the tree). But it does indeed work. Adding Daniel (CSS guru) -- Daniel, is there a straightforward way that we could just add a wrap style to our style sheet, instead of adding a style tag on the first pre node? If so, would that be a better way of accomplishing this?
Comment 18•23 years ago
|
||
I went through the dom tree manually and I believe a plain text doc looks like this: <html><head></head><body><pre>text</pre></body></html> I looked to see if there was an id="" on the pre tag like View Source, but I couldn't find one.
Just for the record, WRAP is not an attribute of PRE, so we have to use CSS but we can't use the rule that Troy Chevalier gave above. Akkana: that depends if we want a pref or not, an automatic wrapping or not. 1) if we want all text documents to be rendered with wrapping, I suggest to add the following rule to our default stylesheet body > pre:first-child:last-child { white-space: -moz-pre-wrap; } it will also apply to HTML documents consisting of only a PRE but we're really in the same case than a text/plain doc, aren't we ? 2) if we want this feature to be user-selectable by a selectable menu item for instance, I would suggest a preference. The menu item is selectable only if the document is text/plain. If the pref changes to true, do the following : a) the menu item being selectable only for a text/plain document, insert in HEAD a LINK element to a resource stylesheet containing the rule above. P.ex: <link rel="stylesheet" type="text/css" href="resource:///res/pre-wrap.css"> b) make the parser automatically generate this LINK element into the HTML document containers for text/plain objects; this LINK will never be saved because the document is text/plain... If the pref changes to false, do the following : remove the LINK element from the HEAD of the current document (or perhaps documentS... You'll have to look at all rendered docs) A variant of (2) is the application/removal of a specific UA stylesheet containing the rule above. From my personal user's perspective, (1) is not desirable. I don't want the UA to decide for me if it does wrapping or not. That should be my choice and only my choice.
Updated•23 years ago
|
Comment 20•23 years ago
|
||
I've pretty much got a patch made which will insert the link tag into the document, I'm just wondering... is my call to updateWordWrap is in the correct place in the code?
Comment 21•23 years ago
|
||
This new version attaches a <link> tag at runtime. The rest of the patch is above my head and I need some help with it (This SHOULD be the easy stuff). 1) it needs to be applied as soon as a page of content-type: text/plain is loaded 2) the menu option needs to be grayed out when the document isn't wrappable. 3) I'm using patch maker so I couldn't attach the .css file in the patch. 4) Make a pref and have the checkmark reflect it and finally an optional 5) Make it work on html documents with <pre> tags. For some reason, it won't work if there are other objects in the <head> of the document, but I can't see what, in the code, is wrong.
Comment 22•23 years ago
|
||
Comment 23•23 years ago
|
||
Can someone obsolete Word wrap patch patch 11/02/01 15:16?
Attachment #56318 -
Attachment is obsolete: true
Comment 24•23 years ago
|
||
Just a few comments: 1) We likely want to be able to apply this to application/x-javascript, text/javascript, text/css, and the like, not just to text/plain. 2) When the user toggles wrap, I feel that documents in other windows should not be affected until the user loads a new document in those windows. This is similar to how toolbar visibility and the like works (and to how word wrap works in view-source) 3) There is really no reason to remove the link tag. Simply disabling the style sheet will do (so add the tag the first time, then just toggle whether the sheet is enabled). In fact, the simplest way to do the whole thing, in my view, is to have the parser generate an alternate stylesheet <link> with the above rule for non-html content. Then the user can use the normal alternate stylesheet selection menu to toggle whether the sheet is on or off. The only problem with this solution is that it's not persisted.... 4) + var header = plainTextDoc.getElementsByTagName('HEAD')[0] + if (header != null) { This will not work. For backwards compat, the DOM0 [] notation returns "undefined" instead of "null" if there is no such node, whereas item() returns "null" per DOM2. Just test for truth of |header|, which will cover both cases.
Comment 25•23 years ago
|
||
"2) When the user toggles wrap, I feel that documents in other windows should not be affected until the user loads a new document in those windows." Isn't this whats happening currently (Haven't looked at the code in a while)? If not, do you have any ideas on how to fix it? "3) There is really no reason to remove the link tag. Simply disabling the style sheet will do" How do you disable a stylesheet? Is the code in the use stylesheet section? "Just test for truth of |header|, which will cover both cases." Okay
Comment 26•23 years ago
|
||
I added a user pref, a semi-colon :) and it now takes into account the other content types. I changed patch so it now executes every time a web page is loaded. I hope this doesn't affect page load times much. There is one case where the checkmark on the menu option will be totally wrong, and the menu option is never greyed out because I can't figure out how to do it without a lot of javascript. I think I've done as much as I can to this patch. Someone with more knowledge will need to pick it up and finish it or they could always tell me how to finish it :)
Attachment #60365 -
Attachment is obsolete: true
Comment 27•23 years ago
|
||
> Isn't this whats happening currently It should be, reading the code. It wasn't clear that this was agreed on. :) > How do you disable a stylesheet? If "elt" is a Link element: elt.disabled = true; (or false to enable)
Comment 28•23 years ago
|
||
*** Bug 126115 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
Bug 114707 seems related (but it is for all kinds of files).
Comment 30•22 years ago
|
||
I would really like to see this in the trunk and have it work for text/html as well. So often web pages have annoying text wrapping issues, and to be able to force all the text of the page to fit in the window would be excellent. (For an example, see above bug 114707.)
Summary: [RFE] Word-wrap text/plain content pref UI → Word-wrap text/plain content pref UI
Comment 31•21 years ago
|
||
*** Bug 206969 has been marked as a duplicate of this bug. ***
Comment 32•21 years ago
|
||
Can some kind person please send a really simple person a really simple guide to doing this patch? I don't really understand what I need to do. All I want to do is set Mozilla up so .TXT files are displayed with long lines wrapped to the window width. That's all. Thanks in advance!
Comment 33•21 years ago
|
||
Mark, you can use Neil's existing patches in this bug as a guide....
Comment 34•21 years ago
|
||
*** Bug 229678 has been marked as a duplicate of this bug. ***
Comment 35•21 years ago
|
||
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Comment 36•20 years ago
|
||
This looks like low hanging fruit with a nice bang for the buck. I just checked, and the latest IE does not do this. This would be a really nice little thing to demo to someone. > Comment #1: You can use the -moz-pre-wrap style The functionality is basically done. > Comment #2: there should be UI to allow the user to do this trivially. > Comment #3: lot easier to make this wrapping happen by default ... Would any type of user prefer to "not wrap" the text and rather scroll further to read it? > bug 114707, Comment #2: toggle ... Apache logs without hte wrapping, one hit at a line and with the wrapping - all info on the screen without scrolling. Imo, you should make plain text wrap by default, with no UI in the standard product to do otherwise. Then someone can write an extension to support a no wrap stylesheet, or better yet, arbitrary user stylesheets with nowrap being an example supplied with the extension.
Flags: blocking1.8a?
Comment 37•20 years ago
|
||
> Imo, you should make plain text wrap by default
Sorry, but this would probably break a lot of things out there, especially since
IE doesn't do it.
Argue for things if you will, but have some perspective.
Comment 38•20 years ago
|
||
>> Imo, you should make plain text wrap by default > this would probably break a lot of things out there, especially since IE doesn't do it. Well yeah, I'm hoping it will indeed *break* lots of *long lines*. ;> What you say is correct. And it maybe that the change I suggest is a bad one. But the latter doesn't follow from the former; it doesn't necessarily follow from "this would probably break a lot of things out there" that one shouldn't make the change. It depends on what "break" means, what the benefits of the change are, and other factors. Imo, when one takes a quick look at the details, the change I suggest is a compelling one: 1. For each page that ends up "broken" as a result of a default plain text wrap, I would expect there to be rather more pages that users would say are rendered "fixed", or at least "better, on balance". Ime, I'd guess a couple orders of magnitude more. I think that's about right for the average web user too. 2. In all the "broken" cases I can think of, I would expect "broken" to mean a minor presentational problem. One of the more problematic cases would be technical content such as programming code or log data that contains long lines. But see point 4 below. Another might be artistic pages, where horizontal scrolling is intended: see point 5 below. I could just about conceive of a page where wrapping has a minor input or ui impact, but I don't think I've seen such a page. Again, see point 5 below. 3. In almost all "fixed" cases (which, as I said, are quantitively greater), the improvement is qualitatively greater than the degradation is for "broken" pages. Text is presented wrapped, which by definition of this point 3 is desirable. And the user doesn't have to scroll. 4. I believe it would be relatively trivial for users, especially technical ones, to override the default, reverting behavior to be no wrap. 5. I believe it would be relatively trivial for authors to override the default, reverting behavior to be no wrap.
Updated•20 years ago
|
Flags: blocking1.8a? → blocking1.8a-
<Neil> CTho: well, it looks as if what you need to do is to make the plain text sink add in the link element, and the stylesheet switcher will do the rest <CTho> is there no way from JS to check the content-type and then set the stylesheet? <Neil> CTho: far too hacky
Assignee: ben_seamonkey → cst
Keywords: helpwanted
Flags: blocking1.8a4?
Flags: blocking-aviary1.0PR?
This patch works as long as my computer is on to serve the css file. It's ugly and incomplete.
<bz> I think asking jst for review would be a good idea. And checking whether he prefers a separate plaintext DTD...
Status: NEW → ASSIGNED
Comment 42•20 years ago
|
||
too late for this in firefox PR. it needs to be baked on the trunk for a while if it is going to go on branches.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Comment 43•20 years ago
|
||
So I don't think the approach in this patch is how we would want to solve this. This code will inject a link tag into the token stream which means that now if this pref is set, every DOM tree will get this magic link tag from nowhere that scripts etc may not expect etc. Seems like this is a probem that should be solved in the presentation layer (i.e. layour/css code), not in the HTML parser.
Comment 44•20 years ago
|
||
Sorry, didn't realize this would happen only for text/plain documents, so injecting an element into the DOM isn't as bad. But I'm still of the oppinion that the more correct fix for this would be in layout/css code...
Assignee: cst → jag
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: bugzilla → pawyskoczka
Target Milestone: Future → ---
Updated•20 years ago
|
Flags: blocking1.8a4?
Flags: blocking1.8a4-
Flags: blocking1.8a1-
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-
Comment 45•20 years ago
|
||
*** Bug 248290 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 46•19 years ago
|
||
(In reply to comment #2) > More specifically, there should be UI to allow the user to do this trivially. > Probably a menu item and a preference. Resetting the component to UI/UE and > reassigning. This post is a "me too" reply and a bump. I'd like to see this feature (the option of wrapping long lines in plain text output), but the ticket appears to have been abandoned.
*** Bug 303717 has been marked as a duplicate of this bug. ***
Comment 48•18 years ago
|
||
*** Bug 362600 has been marked as a duplicate of this bug. ***
Comment 49•18 years ago
|
||
The implementation of this RFE was actively discussed until a little more than two years ago. Then nothing. Is this dead, or will it be implemented? Note: After reading the discussion, I believe -- 1. This should be an option to avoid breaking pages where tabular or artistic layout is important. The discussion seemed to conclude with this intent. 2. This should be limited to pages that have NO HTML markup. Content within <pre> </pre> obviously is intended to be displayed as written, even if that means annoying horizontal scrolling. Content not within <pre> </pre> already has its wrapping defined, either implicitly by default or as specified via explicit HTML and CSS.
Comment 50•17 years ago
|
||
Hi, I´m a newbie so sorry if I might post wrong! Could you integrate this Add-on (https://addons.mozilla.org/en-US/firefox/addon/2547) into the standard FF? This is standard of IE 7 so FF should be at the same level. ;-)
Comment 51•17 years ago
|
||
(In reply to comment #50) > Could you integrate this Add-on > (https://addons.mozilla.org/en-US/firefox/addon/2547) into the standard FF? Link Wrapper does not seem appropriate to this bug... Am I right that it does not wrap plain text files -- only long links?
Comment 52•17 years ago
|
||
There has been a lengthy, detailed discussion of line breaks at <news://news.mozilla.org:119/mozilla.dev.tech.layout> in the thread "Line Breaking". The main problem is that humans can judge when to break a line, but it's very difficult to create an algorithm that will always be correct. One example discussed is the breaking of a line at a /. While long URIs might be broken before /, the term "c/o" (for "care of") should not be broken. There was also some discussion whether long URIs should break just before or just after /. By the way, Micro$oft does not create standards. Thus, the fact that IE 7 does something may be a poor reason for Mozilla to also do it. Too often, the way IE 7 does something is just plain wrong.
Comment 53•17 years ago
|
||
That has nothing to do with this bug. This bug is about making text files with long lines wrap *at all*, not about exactly where they should wrap (which is a CSS issue) or what IE does (which, for this, is irrelevant).
Updated•16 years ago
|
QA Contact: pawyskoczka
Comment 54•15 years ago
|
||
Bug 253564 is shown as being blocked by this, but apart from that it isn't mentioned here. People may be interested in the workaround mentioned there (bug 253564, comment #1). In response to comment #52, I agree that there may be no perfect algorithm for line breaking, but Mozilla products already include attempts to come close - for example, the text box that I am typing into right now! To mitigate concerns though, I do agree it should be up to the user whether to 'wrap'. Perhaps a page-specific option in the View menu? This option could even be generalized beyond plain text pages. It could say "Attempt to fit page to available width" and do various additional things to try and get rid of the horizontal scroll bar, such as shrinking too-wide images and ignoring <pre> tags. (If so, it might then cover bug 114707.)
Updated•15 years ago
|
Assignee: jag → nobody
QA Contact: ui-design
Updated•11 years ago
|
Comment 55•11 years ago
|
||
When the patch in bug 253564 gets merged to mozilla-central, this bug can be fixed by setting the plain_text.wrap_long_lines pref to true in the Seamonkey default preferences.
Comment 56•11 years ago
|
||
I much prefer the ability to wrap only selected Web pages via the Toggle Word Wrap extension from <https://addons.mozilla.org/addon/toggle-word-wrap/>. This provides a Word Wrap item in the pull-down context menu when I right-click on a Web page, thus avoiding the need to repeatedly toggle a preference.
Comment 57•11 years ago
|
||
(In reply to David E. Ross from comment #56) > I much prefer the ability to wrap only selected Web pages via the Toggle > Word Wrap extension from > <https://addons.mozilla.org/addon/toggle-word-wrap/>. This provides a Word > Wrap item in the pull-down context menu when I right-click on a Web page, > thus avoiding the need to repeatedly toggle a preference. This bug is for Seamonkey. If you are looking for a context-menu toggle for Firefox, see bug 849373.
Comment 58•11 years ago
|
||
Re comment #57: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 SeaMonkey/2.16.1 I have NEVER been a Firefox user. I migrated from Netscape 4.x to the Mozilla Suite to SeaMonkey. You will note from the above UA string that I do not even advertise Firefox compatibility. The Toggle Word Wrap extension provides a capability that is easier to use than any preference. As I noted in comment #56, this is via an entry in the pull-down context menu of a page, which means I do not have to use about:config or navigate to [Edit > Preferences > ??] to toggle a preference. Why cannot the code in Toggle Word Wrap be implemented within SeaMonkey?
You need to log in
before you can comment on or make changes to this bug.
Description
•