Last modified: 2012-06-22 02:46:43 UTC
I think this is a pretty common problem for people. I spent the better part of the day looking for solutions for this problem, and.. even though the "width" attribute of <pre> is depreciated, there exists no other workable solution other than word-wrap:normal; --- but that only works on internet explorer... And... It is over-rideable, a person can specify the width if they have something, that say, uses 132 columns or what not. This just nukes the common case of people posting too long of lines in <pre> tags... and still allows for overrides when intended. I am looking for: width="80"; to be added to the stylesheet defaults for pre... it can be over ridden by those who know what they are doing, but it will keep problems from happening, say as in this example page: http://meta.wikimedia.org/wiki/User:AaronPeterson/pre_play and in this page where it was causing problems http://meta.wikimedia.org/wiki/Apache_config
Which problems are there with the current solution?
ah, well, lots of instances of <pre> formatted text were origionally viewed in an editor with wrapping... and since there is no wrapping in a <pre> tag without width, there are many instances where the <pre> formatted areas go under, and are hidden by, say sidebars, or other navigation / project content. Most preformatted text came from 80 column windows, or 60 or 40, or similar, 80 is the behavior that keeps the windows looking the same as they were origionally presented, and is wide enough to accomidate most cases... yet narrower than the current implementation... It is also really easy to implement, and over ride.. .. must sleep...
http://www.w3.org/TR/html4/struct/text.html#h-9.3.4 width = number [CN] Deprecated. This attribute provides a hint to visual user agents about the desired width of the formatted block. The user agent can use this information to select an appropriate font size or to indent the content appropriately. The desired width is expressed in number of characters. This attribute is not widely supported currently.
*** This bug has been marked as a duplicate of 260 ***
well, word-wrap:normal is what I was looking for, and it is not widely supported either... but a combination of word:wrap:normal and width="80" would cause these things to not be unbounded in most browsers. However, it is a bit more of a pain to deal with two style sheets.. So, there is a possibility of creating a class called, "unbounded" or something like that.. where class="unbounded" would make "word-wrap:none; width="normal"" or something similar. This isn't a duplicate of 260 because I just tagged my request on the end of 260 and there was no mention of it when it was closed. **** non-default compromise ***** The other thing is, maybe there could be a "bounded" class, that is not on by default, that would make it easier for people to get this desired effect, future proofing it when there is an alternative to the depreciated width attribute... so all that needs changing is the stylesheet.
Ok, I changed the summary, unbounded (with word-wrap:none , width="" ) (or whatever works) (this is default, but it shouldn't be, but people can choose this if they really want it to be unbounded forever) and narrow, and then people can specify the widths manually if needed for anything else... Narrow would provide a narrow enough margin for sidebars to work appropriately. and should be set at 60 (I think...) it makes it work in 800x600 ... or changing the default to 80 would be enough.
You can change the styles for yourself in your user stylesheet, but a default fixed-width pre area (or textarea for that matter) isn't going to happen. It would break accessibility on small devices, doesn't adjust to big screens/very high resolutions etc, makes horizontal scrolling more or less impossible if the pre area is both long and wide. If the pre width is too big, just add a line break. To identify things like this, page preview is generally encouraged, not just for pre areas.
The point IS to fix the display for small screens. that's why word-wrap:normal is requested... It is currently making horizontal scrolling on even large screens... Lots of configuration files requre, or have long lines, that normally get displayed on a word-wraped terminal or in a word-wraped text editor... There are normally ways to break long lines with funkey escaping of newlines or similar things like that, but, those are difficult to create, and are very awkward for code examples. <br />\s are not acceptable in a <pre> section, and newlines have meaning in the <pre> </pre> area, so they cannot be added with a whim. This problem has croped up in [[m:help:Apache config]] and a few other help files, where i am trying to install a sidebar. However, the sidebar covers text in the <pre> area, and I'd much rather not manually input style info, that WILL break small screens, wheras a stylesheet implementation WOULD NOT break the small screen display. So, I have a large display! and <PRE> breaks even my large display rendering! This stylesheet implementation, or inclusion of a class, so that sidebars are possible, allows me not to break the small screen, and allows for easy modification in the future. Wheter or not this is implemented in my user stylesheet is irrelevant. I have a huge monitor, and I am not making these pages for myself.
<tt> might me more like what you're looking for- pre areas are meant not to wrap, tt's have a fixed-width font, but wrapping.
><tt> might me more like what you're looking for- pre areas are meant not to wrap, tt's have a fixed-width font, but wrapping. tt doesn't work. it requires <br />'s to be injected into the code, loosing a major point of the pre formatted text stuff.. <pre> shouldn't mean "hide under other elements", and <pre> shouldn't mean "go on forever, past the boundaries of the page / small screen" <pre> should mean pre formatted text... or preserve formatting of the text.. I don't know which, but the point remains, that your envioned use of the <pre> tags is still possible, and this would break hardly anything, and it would fix a whole lot. If it's supposed to preserver the formatting of the text, then 80 column default would be prudent, as that is the most common way it is displayed. The problem is that these <pre> area's respect nothing, and don't even do their job. The text probably wasn't origionally displayed on an infinitely wide monitor. Therefore, the super duper wide nature of the <pre> areas is attrotious.... They arbitrarily decide that the text wasn't word wrapped when it was displayed origionally... and most text is word wrapped. This of course would be turn offable via style sheet usage.. but
Preformatted text has as many columns as you put in it. If you want it small, wrap the lines. Otherwise, if it's too big you get scroll bars. That's how it works. I really don't see the issue here.
hurm.. This is part of the reason why I wanted to just post this suggestion to a wiki page and keep developing it, I don't want to stick this under your nose so often! Mozilla Firefox doesn't have scroll bars for the <pre> tags... if you can enable scroll bars on <pre> tags in mozilla with the stylesheet, that would work as well. I'm changing the bug title again, and reopening.. please don't be offended.. I'm still gaining a bigger picture, and.. I really don't want to waste your valuable time...
Created attachment 36 [details] pre_play here are some screen shots demonstrating the problems
Created attachment 37 [details] rendering2
Created attachment 38 [details] pre_play3
(In reply to comment #12) > Mozilla Firefox doesn't have scroll bars for the <pre> tags... if you can enable scroll bars on > <pre> tags in mozilla with the stylesheet, that would work as well. ? Firefox supports scroll bars for pre text, as mentioned in bug 260. I thought internet explorer was the problem. I added pre { overflow: auto; } to my user stylesheet and it works delightfully in Firefox, automatically putting a horizontal scrollbar for pre sections when they overflow the screen, and not putting one when they don't. I suggested adding this to the site css but then it was pointed out that it doesn't work in IE.
(In reply to comment #8) > The point IS to fix the display for small screens. I concur. the overflow:auto setting creates a scrollbar for each pre area independently, so formatting is preserved, but it doesn't break the whole page and make the entire page need scrollbars. this setting is not implemented by IE yet, but it could be added with no harm to IE, and there are workarounds for IE (supposedly), though I think they depend on fixed character widths. I guess I never linked to this: http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css#pre_autoflow
Many <pre> elements cause my window to horizontally scroll when viewed in Mozilla Firefox 1.0 on windows or linux with a 1024x768 screen (I'm told this is the most common resolution). This also happens with the comment boxes on this bugzilla site. On the pre_play page linked in the description, the following occurs: pre style="white-space: normal; fills full width between right edge of sidebar and right edge of screen. pre respects linebreaks only, the page scrolls horizontally. pre width="100%" pre section is 100% of the width of the screen. Horizontal scrolling by the width of the sidebar is required. pre width="40" pre section is 40% the width of the screen. no horizontal scrolling required. code fits to screen width, no scrolling necessary. no border and the line after two linebreaks is not included. code width="50%" no obvious difference to 'code' pre width="100em" same as 'pre' pre style="word-wrap:normal; same as 'pre' pre style="word-wrap:normal !important;" same as 'pre' div style="word-wrap:normal !important; same as 'pre' div and style same as 'pre style="white-space: normal;' but with proportional font tt wrapping the div with the style same as 'pre style="white-space: normal;' but with proportional font tt inside of styled div same as 'pre style="white-space: normal;' but with proportional font after 2 line breaks xmp apparently not rendered as a pre-formated section. <xmp> and </xmp> tags visible. Chris
(In reply to comment #17) I guess I > never linked to this: > > http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css#pre_autoflow Updated link: http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css/archive1#pre_autoflow
Created attachment 1064 [details] screen dump Hallo! I do not know how this relates to bug 3820: for RTL wiki's add an additional vertical scrollbar for the pages main (sub-)frame / area and bug 3928: Textbox and <pre> renders text broken The screendump is from the URL http://ur.wikipedia.org/w/index.php?title=%D8%AD%D8%AF%DB%8C%D9%B9&oldid=7552 or in "abreviated" form http://ur.wikipedia.org/w/index.php?oldid=7552 As you can see the troble with the overlapping areas is because of the different ways how the *text area* is fixed inside the browsers window and of the way the scroll bars "work": a)in Mozilla Firefox the LEFT side of the main text area is fixed to the LEFT side of the browsers window b) in Internet Explorer the RIGHT side of the main text area is fixed to the MIDDLE of the browsers window If these comment does not fit here and it would be necessary to open another bug please do so. best regards reinhardt [[user:gangleri]]
Going back to the original issue... :) One difficulty with forcing line wrapping in the display when dealing with code or configuration examples is that frequently line breaks are semantically important. Take this example from http://www.mediawiki.org/wiki/Manual:Short_URL#Setup_steps : <source lang="php"> $wgScriptPath = '/w'; # Path to the actual files. This should already be there $wgArticlePath = '/wiki/$1'; # Virtual path. This directory MUST be different from the one used in $wgScriptPath $wgUsePathInfo = true; </source> A wrap to 80 columns would display as: $wgScriptPath = '/w'; # Path to the actual files. This should already be there $wgArticlePath = '/wiki/$1'; # Virtual path. This directory MUST be different from the one used in $wgScriptPath $wgUsePathInfo = true; which, if typed as it looks into an Apache config file would result in a big fat syntax error. (Cut-and-paste will *hopefully* preserve the original, but it may not be obvious to a reader who isn't cut-n-pasting in all cases.) Automatic soft wrapping also produces horribly ugly results for heavily indented code. Manual wrapping for comments and long lines can provide output which is both more attractive *and* works if copied as it looks; indentation, line continuations ("\" at end of line in many syntaxes), proper formatting of comments, etc all have to be done with knowledge of the syntax if they're to be done. So I do tend to recommend that <pre> or <source> sections be written targeting a relatively modest screen width.
In my experience I have seen this occur more often when users who are unfamiliar with html or wiki markup add spaces in front of a line to get a darker box behind their text. My proposed fix would be to remove the automatic generation of pre tags and perhaps add some other formatting option instead. This would prevent forced formatting constraints on a tag that defines text as already formatted. Most scenarios I have seen break the display are because of adding text that is not already formatted to a tag that is supposed to preform as if it has already been formatted.
So it seems that the only viable way to "fix" this bug would be to add pre { overflow: auto; } To common stylesheets, or at least to monobook/main.css. Do we want to do that? Everything else is, at this stage, a red herring.
*** Bug 22060 has been marked as a duplicate of this bug. ***
Bug 22060 comment 5 says that pre { overflow: auto } would cause problems in IE7 and 8. I haven't looked into it.
Wrapping might be a better approach than scroll-bars: From https://bugs.launchpad.net/mailman/+bug/266467 pre { white-space: pre-wrap; /* css-3 */ white-space: -moz-pre-wrap; /* Mozilla, since 1999 */ white-space: -pre-wrap; /* Opera 4-6 */ white-space: -o-pre-wrap; /* Opera 7 */ word-wrap: break-word; /* Internet Explorer 5.5+ */ _white-space: pre; /* IE only hack to re-specify in addition to word-wrap */ } Granted I don't have IE or Opera handy to test the lower properties.
Is this still the case as of Vector and MediaWiki 1.18 ?
Aaron: Is this still the case as of Vector and MediaWiki 1.19?
This is still an issue in Vector and 1.19+. Marking as dupe of bug 260, however. *** This bug has been marked as a duplicate of bug 260 ***
