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

Status: VERIFIED DUPLICATE of bug 24186

(Core :: Layout, defect, P3)

Description

[Eugene Savitsky]

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.

Comment 1

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

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
using?

Comment 2

[Eugene Savitsky]

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

www.delfi.ee

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

On the right column font is too incorrect.

So on www.ixbt.ru

Checked with 15.12.99 M12 build

Comment 3

[Jerry Baker]

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 4

[Jerry Baker]

Attachment: Mozilla renders small fonts very badly

Comment 5

[Jerry Baker]

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:

<p>
<font color="#989CFF" face="Verdana, Arial, Helvetica, sans-serif" size="1">
<a name="geometry_fundamentals"></a>
<b>Geometry Fundamentals</b></font></p>
<blockquote>
  <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>
  </font>
 </p>
</blockquote>

Comment 6

[Jerry Baker]

Adding myself to the CC: list.

Comment 7

[Eli Goldberg]

Reassigning all of leger's unscreened Browser-General bugs to [e-mail]
for pre-screening and triage.

Comment 8

[Phil "clef" Sweeney]

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.

Comment 9

[Phil "clef" Sweeney]

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.

Comment 10

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

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 11

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

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

[Jerry Baker]

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.

Comment 13

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

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

[Jerry Baker]

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.

Comment 15

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

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.

Comment 16

[Phil "clef" Sweeney]

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.

Comment 17

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

It can't be interpreted in more than one way (at least, the example given
above).  I was thinking of something else.

Comment 18

[Jerry Baker]

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.

Comment 19

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

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.

Comment 20

[Phil "clef" Sweeney]

Perhaps this discussion could move onto a newsgroup where others could
participate and offer their views? (this bug is getting rather long :)

Comment 21

[Jerry Baker]

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

Comment 22

[Hixie (not reading bugmail)]

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
solution/owner.

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

[Hixie (not reading bugmail)]

BTW, the font problem mentioned earlier on this bug is actually a font-weight
problem and is a dup of bug 972.

Comment 24

[Phil "clef" Sweeney]

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

[Erik van der Poel]

Which platform?

Comment 26

[Phil "clef" Sweeney]

Sorry.. win32 (win2k)

Comment 27

[Erik van der Poel]

When you say the font is "too big", do you mean relative to Nav4? Or just too
big in your opinion?

Comment 28

[Phil "clef" Sweeney]

Relative to Nav4 .. it looked almost exactly the same except for the font size 
differencees.

Comment 29

[Erik van der Poel]

That may be related to another change I made to WinMoz:

  http://bugzilla.mozilla.org/show_bug.cgi?id=24005

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
behavior.

Comment 30

[buster]

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?

Comment 31

[ekrock's old account (dead)]

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

Comment 32

[Hixie (not reading bugmail)]

Correctamundo.

Comment 33

[Jerry Baker]

Mass removing self from CC list.

Comment 34

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.