Last modified: 2012-06-22 02:46:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 414 - <pre> should have scroll bars in Firefox
<pre> should have scroll bars in Firefox
Status: RESOLVED DUPLICATE of bug 260
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Low enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: css
  Show dependency treegraph
Reported: 2004-09-07 11:03 UTC by Aaron Peterson
Modified: 2012-06-22 02:46 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

pre_play (104.71 KB, image/png)
2004-09-13 14:59 UTC, Aaron Peterson
rendering2 (104.78 KB, image/png)
2004-09-13 14:59 UTC, Aaron Peterson
pre_play3 (108.30 KB, image/png)
2004-09-13 15:00 UTC, Aaron Peterson
screen dump (183.36 KB, image/jpeg)
2005-11-14 12:51 UTC, lɛʁi לערי ריינהארט

Description Aaron Peterson 2004-09-07 11:03:14 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: 
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: 
and in this page where it was causing problems
Comment 1 Gabriel Wicke 2004-09-07 11:05:45 UTC
Which problems are there with the current solution?
Comment 2 Aaron Peterson 2004-09-07 12:40:46 UTC
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... 
Comment 3 Brion Vibber 2004-09-07 19:01:37 UTC

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.
Comment 4 Gabriel Wicke 2004-09-07 19:14:46 UTC

*** This bug has been marked as a duplicate of 260 ***
Comment 5 Aaron Peterson 2004-09-07 23:28:42 UTC
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. 
Comment 6 Aaron Peterson 2004-09-08 12:30:20 UTC
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 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. 
Comment 7 Gabriel Wicke 2004-09-08 12:42:53 UTC
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.
Comment 8 Aaron Peterson 2004-09-08 22:35:26 UTC
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. 
Comment 9 Gabriel Wicke 2004-09-09 11:28:47 UTC
<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.
Comment 10 Aaron Peterson 2004-09-13 05:35:30 UTC

><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 
Comment 11 Brion Vibber 2004-09-13 06:44:52 UTC
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 

I really don't see the issue here.
Comment 12 Aaron Peterson 2004-09-13 14:52:55 UTC
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...  
Comment 13 Aaron Peterson 2004-09-13 14:59:01 UTC
Created attachment 36 [details]

here are some screen shots demonstrating the problems
Comment 14 Aaron Peterson 2004-09-13 14:59:59 UTC
Created attachment 37 [details]
Comment 15 Aaron Peterson 2004-09-13 15:00:48 UTC
Created attachment 38 [details]
Comment 16 Omegatron 2004-09-19 15:17:33 UTC
(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.
Comment 17 Omegatron 2005-01-21 05:56:34 UTC
(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:
Comment 18 Chris McKenna 2005-03-02 00:16:41 UTC
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.
   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.

   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

   apparently not rendered as a pre-formated section. <xmp> and </xmp> tags

Comment 20 lɛʁi לערי ריינהארט 2005-11-14 12:51:46 UTC
Created attachment 1064 [details]
screen dump


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
bug 3928: Textbox and <pre> renders text broken

The screendump is from the URL
or in "abreviated" form

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]]
Comment 21 Brion Vibber 2008-12-30 18:21:01 UTC
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 :

<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;

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.
Comment 22 Steve Buzonas 2009-07-23 19:44:45 UTC
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.
Comment 23 Happy-melon 2009-07-24 14:46:20 UTC
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.
Comment 24 Alexandre Emsenhuber [IAlex] 2010-04-05 17:38:45 UTC
*** Bug 22060 has been marked as a duplicate of this bug. ***
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-04-07 17:30:52 UTC
Bug 22060 comment 5 says that pre { overflow: auto } would cause problems in IE7 and 8.  I haven't looked into it.
Comment 26 Thana 2010-04-12 00:07:49 UTC
Wrapping might be a better approach than scroll-bars:

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.
Comment 27 Krinkle 2011-12-30 18:45:21 UTC
Is this still the case as of Vector and MediaWiki 1.18 ?
Comment 28 Andre Klapper 2012-06-01 17:06:14 UTC
Aaron: Is this still the case as of Vector and MediaWiki 1.19?
Comment 29 Krinkle 2012-06-22 02:46:43 UTC
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 ***

Note You need to log in before you can comment on or make changes to this bug.