300261 - [quirks] PRE element (border & background) should expand to fit contents

Status: NEW

(Core :: Layout: Block and Inline, defect)

Description

[wiktorw]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050522 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050522 Firefox/1.0.4

While browsing the on-line documentation generated by doxygen, I've noticed that
both Firefox 1.0.4 as well as Mozilla 1.7.8 don't display correctly margins for
<pre> box. If the window (or frame) is too small horizontally, the scroller do
appears, but the light-gray background for the code has the margin calculated
based on window's width, and not the actual view.
The problem is easily spotted on the page that demonstrates the problem, if the
browser's window is resized (shrunk) horizontally.

Reproducible: Always

Steps to Reproduce:
1. Open the above link.
2. Size window horizontally.

Actual Results:  
The horizontal scroller is resized correctly, while right margin of the
background box goes over the text.

Expected Results:  
The right margin of the background box should stay at the same place, and its
width should be calculated based on the view's width, and not the window's.

I really wanted to report this issue using standard "Report a broken website"
method, but I couldn't find any menu entries as described on the page
https://bugzilla.mozilla.org/page.cgi?id=broken-website.html

Comment 1

[wiktorw]

Attachment: about:buildconfig

Just in case, output of my firefox-1.0.4 build:config.

Comment 2

[wiktorw]

And here goes the URL that demonstrates the problem I reported
(it was eaten by bugzilla somehow :-/)

http://0pointer.de/lennart/projects/libdaemon/reference/html/testd_8c-example.html

Comment 3

[Frank Wein [:mcsmurf]]

Minimal testcase, anyone?

Comment 4

[Frank Wein [:mcsmurf]]

Dupe of Bug 248139 maybe?

Comment 5

[wiktorw]

Even if it is a kind of duplication of Bug 248139, it still looks silly.
I suppose I know the reluctance of Great Mozilla Developers (I'm a developer too)
to do any changes to the code working "correctly according to the specs".

But anyway, that's probably _not_ the expected behaviour from doxygen's developers
nor the rest of HTML users/writers. IMHO, margins should be nicely drawn around
the preformatted text, not cross over it.

My vote is to fix this issue. It may be as simple as changing just several lines
of code (oversimplifying: getWindowWidth() --> getViewportWidth()), but I'm not
too familiar with Gecko's internals to be sure.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There would be bigger problems if things worked the way you want (especially
with text that wraps, since it would wrap wider than the window width).

Comment 7

[wiktorw]

Yeah, and it's so hard to do, that even Internet Explorer displays it right.
It's a shame, dbaron, that you dismiss this problem so easily.

And the scroller is calculated CORRECTLY, so why cannot the margins around the
preformatted box be also calculated in a similar way?

For the end user it doesn't matter if it's really hard to do or standard
[in]compliant. As for today this type of rendering leaves the reader with the
feeling that something is broken. Really, compare the rendering for this page:

http://0pointer.de/lennart/projects/libdaemon/reference/html/testd_8c-example.html

in MSIE and Gecko-based browser. For just one time, I really like the IE's
behaviour better.

BTW. If you shut this bug down again, I will too. I know when to stop.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Maybe a reasonable solution here would be to have pre { min-width: intrinsic; }
in the UA stylesheet, except that min-width overrides width.  (We also don't
implement that value yet.)

At least giving the bug a summary remotely related to what it's requesting.

Comment 9

[Daniel.S]

(In reply to comment #8)
> Maybe a reasonable solution here would be to have pre { min-width: intrinsic; }
> in the UA stylesheet, except that min-width overrides width.  (We also don't
> implement that value yet.)

If we'll do that we should only do it for quirks mode. In strict mode, IE renders the situation according to the spec.