{compat} Spaces between lines bigger than legacy browsers'.




20 years ago
17 years ago


(Reporter: ezh, Assigned: ian)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



20 years ago
I think it is a same bug as at http://www.ixbt.ru/.

All is the same. Tables, css and double spaces between lines, bigger font.
Whiteboard: not enough information (1999-12-18)
Where in the page is the problem, and what do you see?  It looks OK to me.
Attaching a screenshot to this bug would be helpful.  Also, what build are you

Comment 2

20 years ago
Is it so hard to compare the page with NC or IE?


On the left column on top where is "sisukord". In Mozilla is not the correct

On the right column font is too incorrect.

So on www.ixbt.ru

Checked with 15.12.99 M12 build

Comment 3

20 years ago
Not sure if this is related, but when a font size that is smaller than the
default is specified, Mozilla still appears to space the lines as if it were
laying out for the default font size. In simpler terms, the vertical spacing
between lines of a paragraph where the font size is small is too great when
compared to NC 4.X or IE.

Comment 5

20 years ago
Note the extremely disproportionate way that Mozilla renders the same HTML when
compared to IE and NC 4.X. The specific HTML for that screen capture is:

<font color="#989CFF" face="Verdana, Arial, Helvetica, sans-serif" size="1">
<a name="geometry_fundamentals"></a>
<b>Geometry Fundamentals</b></font></p>
  <p><font face="Verdana, Arial, Helvetica, sans-serif" size="1">
  <a href="Fundamentals/LocationMenu/index.html">The Location Menu</a><br>
  <a href="Fundamentals/Selection/index.html">The Selection Menu</a><br>
  <a href="Menu/Edit/Edit-Trim/index.html">Trim, Extend and Break</a><br>
  <a href="Menu/Layers/LayerOverview.html">Layer Management</a><br>
  <a href="Menu/Transform/TransformOverview.html">Transforming Geometry</a><br>
  <a href="Fundamentals/cviews/cview1.html">Construction Views (cview)</a><br>
  <a href="Fundamentals/cviews/cview2.html">Creating Cviews</a><br>
  <a href="Fundamentals/Surfaces/Surfaces1.html">Surfacing Basics</a><br>
  <a href="Menu/Create/Points/index.html">Creating Multiple Points</a><br>
  <a href="Fundamentals/NormalorCview/index.html">'Normal'or 'Cview'</a>

Comment 6

20 years ago
Adding myself to the CC: list.

Comment 7

20 years ago
Reassigning all of leger's unscreened Browser-General bugs to nobody@mozilla.org
for pre-screening and triage.


20 years ago
Summary: Spaces between lines, font size not correct → [4.xP] Spaces between lines, font size not correct
I also see this problem on http://www.dvdfile.com/

(win98, build 2000/01/12)

The font spacing is quite different to that of nav/ie.


20 years ago
Whiteboard: not enough information (1999-12-18)
http://www.sofcom.com.au/ shows inherent problems with this incorrect rendering.
 Have a look at the blue titles where it shows the date, or 'today's weather',
or today's starsigns'.. and see how the text has large spaces above and below
that cause it not to line up with images that are beside it.
Large linespacing around a <font size=1> is arguably the correct behavior
according to the CSS inline box model (for somewhat complex reasons).  This is
being argued out on www-style lately.
Large linespacing around a <font size=1> is arguably the correct behavior
according to the CSS inline box model (for somewhat complex reasons).  This is
being argued out on www-style lately.

Comment 12

20 years ago
I don't think this is a good idea. This means that pages that are carefully laid
out will have to sniff for Mozilla and direct them to another page if they wish
to keep appearance consistent. I don't think that Mozilla wants to be in the
business of creating another disparity between browsers when it is not necessary
according to specs.

Additionally, the idea that smaller fonts should take up as much space as larger
fonts is as ridiculous as larger fonts taking up as much space as smaller ones.
By this same stream of thinking, +4 fonts should have the same line spacing as
default. This is no good obviously.
The reason for the "problem" is the font size on the P element.  If the font
size were made smaller on a block-level element, rather than an inline element,
the line boxes could shrink.

Actually, this isn't ambiguous at all in the spec.  Mozilla is currently
correct.  The ambiguous issue is something much more complicated.

Comment 14

20 years ago
I think you are thinking of style sheets. I am speaking of not using style
sheets. Is it legal to say <p font size="1">? I don't think it is. And we can't
have Mozilla ditching backwards compatibility.
Slight presentational differences aren't really that important.  If you can show
major examples of where they cause problems, then maybe someone will write yet
another compatibility hack, adding to the bloat of the software.

The web is not DTP.
The www.sofcom.com.au example shows a slight problem.

If it can be interpreted more than one way, which is the way that most interpret
it?  Seems not to be the current mozilla way.
It can't be interpreted in more than one way (at least, the example given
above).  I was thinking of something else.

Comment 18

20 years ago
To me, as a Web designer, it is a major problem when the vertical space taken up
by my pages is effectively doubled by one browser and no others. What is the
point of small fonts if they save no space - maybe small just for the sake of
being small?

BTW - Do you have a reference to the spec where it mentions that the vspace of
small fonts should be the same as large fonts.
http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height , in the
definition of how line-height effects block-level elements.  Note that I
strongly dislike the way this definition is worded (even after fixing the typo
that "inline box" should be "line box", but not its intent.
Perhaps this discussion could move onto a newsgroup where others could
participate and offer their views? (this bug is getting rather long :)

Comment 21

20 years ago
Please let's discuss this in n.p.m.layout. I started a thread there.


20 years ago
Assignee: nobody → py8ieh=bugzilla
Severity: normal → minor
Component: Browser-General → Layout
QA Contact: nobody
Summary: [4.xP] Spaces between lines, font size not correct → {compat} Spaces between lines bigger than legacy browsers'.

Comment 22

20 years ago
On Mon, 17 Jan 2000, in the newsgroups, Jerry Baker wrote:
> http://www.cnn.com/
> http://www.latimes.com/
> http://www.abcnews.com/
> http://www.nytimes.com/
> http://www.amd.com/
> http://www.oracle.com/
> http://www.zdnet.com/ (look at Community links toward bottom)
> http://www.wired.com/
> This should be enough for now. I will find more if this list is not
> enough.

Yup, that's enough. I'm assigning the bug to me until I find the proper

Removing [4.XP] marker since Mozilla is a CSS-based browser and we are correct
per CSS. Marking {compat} as this is required for compatability with legacy
browsers. Reducing severity to Minor as there are more serious problems around.
Moving to Layout component. Removing QA contact. Updating summary.

This will be a Quirks Mode fix.

Comment 23

20 years ago
BTW, the font problem mentioned earlier on this bug is actually a font-weight
problem and is a dup of bug 972.
In today's build (2000012208) slashdot looks correct, except that the font is 
slightly too big.  Or does it only look right BECAUSE the font is too big?

Comment 25

20 years ago
Which platform?
Sorry.. win32 (win2k)

Comment 27

20 years ago
When you say the font is "too big", do you mean relative to Nav4? Or just too
big in your opinion?
Relative to Nav4 .. it looked almost exactly the same except for the font size 

Comment 29

20 years ago
That may be related to another change I made to WinMoz:


I'll keep this in mind over the next few months. We haven't even shipped the
first beta yet, so there is still time to change back to the old rounding

Comment 30

20 years ago
the line height/spacing issues in compatibility mode are covered in bug 24186, 
which has a fix pending.  are there other problems described in this bug that 
should keep it open, or can we dup it to 24186?
Severity: minor → major
Marking DUP #24186. Don't see other independent issues here. If there are any, 
please open a separate bug to start a clean discussion. Good work on analysis 
and resolution folks!

*** This bug has been marked as a duplicate of 24186 ***
Closed: 20 years ago
Keywords: beta1
Resolution: --- → DUPLICATE
Target Milestone: M14

Comment 32

20 years ago

Comment 33

17 years ago
Mass removing self from CC list.

Comment 34

17 years ago
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.