Last Comment Bug 22274 - [INLINE] Too much space (for descenders) under image (<img>) elements, e.g. in table cells
: [INLINE] Too much space (for descenders) under image (<img>) elements, e.g. i...
Status: VERIFIED INVALID
: testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal with 8 votes (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
: Chris Petersen
Mentors:
http://devedge.netscape.com/viewsourc...
: 18941 19956 20575 40355 44978 46299 46970 47165 48520 51518 59227 63715 64487 65365 65514 67311 68562 69083 70151 71913 74708 75529 77692 78000 80360 80474 80590 82600 83955 86935 87800 89012 89307 89384 89482 89857 90798 95603 96183 96297 96424 97801 97804 98628 101708 103108 103109 105617 105652 106252 107563 107774 107942 108444 110058 111452 111643 113048 114159 116668 119189 119339 122620 123856 123979 124811 125901 126219 126519 126579 126848 127023 129948 130056 130669 131200 131591 132520 132706 132728 133198 135096 139409 139966 141506 141604 142037 142600 143652 144199 146273 147906 151823 153953 154316 156244 161112 165428 168943 171676 172864 173661 174741 175880 177687 186321 189163 193299 194379 196765 200847 203437 203815 205416 213431 216185 216446 219742 230102 231653 237644 240617 244494 251330 253271 258198 261316 264136 265666 271884 273030 273811 276739 279082 281191 301373 301919 302228 314090 320745 330405 337194 361988 405116 407549 414377 561624 723661 985616 (view as bug list)
Depends on:
Blocks: 168782
  Show dependency treegraph
 
Reported: 1999-12-21 08:57 PST by Mike Palczewski
Modified: 2016-02-23 23:48 PST (History)
143 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (520 bytes, text/html)
1999-12-21 11:05 PST, Mats Palmgren (vacation)
no flags Details
frame dumps with and without strict DocType statement (2.22 KB, text/plain)
2000-06-05 17:09 PDT, buster
no flags Details
Testcase (941 bytes, text/html)
2001-03-02 19:15 PST, Brian 'netdragon' Bober
no flags Details
Testcase without the display: block (923 bytes, text/html)
2001-03-02 19:16 PST, Brian 'netdragon' Bober
no flags Details
Just my example of the "bug." (2.27 KB, text/html)
2002-07-15 17:47 PDT, Travis Bell
no flags Details
Drop down list items use much more length then allotted for drop down list (143.12 KB, text/html)
2004-01-21 07:58 PST, Joe Mooney
no flags Details

Description Mike Palczewski 1999-12-21 08:57:32 PST
I'm using mozilla 1999-12-20-08-M13 for linux.
There seems to be some space between table elements on this site.  The page
renders without those spaces in netscape 4.7.
Comment 1 Mats Palmgren (vacation) 1999-12-21 11:05:59 PST
Created attachment 3692 [details]
Testcase
Comment 2 Mats Palmgren (vacation) 1999-12-21 11:12:59 PST
Removing the DOCTYPE (strict dtd) makes the testcase look OK.
Also tested with IE5 on NT, which renders the page/testcase fine.
Comment 3 troy 1999-12-22 14:05:59 PST
Block/line layout issue
Comment 4 buster 1999-12-27 22:11:59 PST
the line height is different based on whether the strict doctype is present or
not.  Seems like a fairly minor block reflow issue.  Set to M15.
Comment 5 ekrock's old account (dead) 2000-01-21 13:50:50 PST
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Comment 6 buster 2000-03-03 16:07:39 PST
mine! mine mine mine!  all mine!  whoo-hoo!
Comment 7 Asa Dotzler [:asa] 2000-03-29 07:21:56 PST
*** Bug 33702 has been marked as a duplicate of this bug. ***
Comment 8 rickg 2000-04-07 16:39:05 PDT
moving all buster m15 bugs to m16.
Comment 9 buster 2000-04-17 08:45:10 PDT
Won't make beta2 if it stays on my list.  Moving to M18.
Comment 10 buster 2000-06-01 14:20:46 PDT
redistributing bugs across future milestones, sorry for the spam
Comment 11 buster 2000-06-05 17:08:52 PDT
tables are not involved.  changing summary.  about to attach partial frame dumps 
illustrating the problem
Comment 12 buster 2000-06-05 17:09:27 PDT
Created attachment 9665 [details]
frame dumps with and without strict DocType statement
Comment 13 buster 2000-06-13 09:40:45 PDT
I'm 90% sure this is a dup of 19956
Comment 14 buster 2000-06-13 09:44:35 PDT
this also looks like a line height issue in standard mode only.  Assigning to 
David (along with probably dup 19956)
Comment 15 buster 2000-06-13 09:54:19 PDT
*** Bug 18941 has been marked as a duplicate of this bug. ***
Comment 16 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-06-13 10:07:04 PDT
*** Bug 19956 has been marked as a duplicate of this bug. ***
Comment 17 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-06-13 10:09:23 PDT
This is correct according to (our interpretation of) the CSS2 inline box model.
 (The "interpretation" is that CSS2 10.8.1 says that 'line-height' on a block
specifies the minimum height of all of that block's line boxes.  It doesn't say
*how* it sets this minimum.  If it's just a direct setting of a minimum, it
leads to really strange things, like the problem described here happening for
small images but not for large ones.  If it sets the minimum by creating an
anonymous inline with the font/line-height of the block, things make much more
sense (this is our interpretation).)
Comment 18 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-06-14 21:23:37 PDT
Marking INVALID based on previous comments.  (I sometimes have some reservations 
about a strict implementation of the CSS inline box model.  I think the model is 
very good, but might not mesh that well with today's web.  However, since our 
implementation is (arguably) correct right now, I'd want a more compelling 
reason to consider changing it.  Also, it's only used in strict mode, so 
today's web shouldn't be much of an issue -- tables for layout aren't 
good use of semantic markup.)

(Note that this is very clear according to the CSS spec if there is an inline 
element containing the image.  The somewhat unclear case is if the image is 
directly in the block/table cell.  That inconsistency is one of the things I 
don't like about the alternate interpretation of CSS.)
Comment 19 Hixie (not reading bugmail) 2000-06-15 03:44:23 PDT
By "alternate interpretation" I assume you mean "not our interpretation", right?

Checked testcase, VERIFIED that it is INVALID per our interpretation of the 
specification, which is explained in detail here:
   http://www.fas.harvard.edu/~dbaron/css/2000/01/dibm
Comment 20 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-07-09 21:16:03 PDT
*** Bug 40355 has been marked as a duplicate of this bug. ***
Comment 21 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-07-10 10:28:52 PDT
*** Bug 44978 has been marked as a duplicate of this bug. ***
Comment 22 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-07-24 15:14:33 PDT
*** Bug 46299 has been marked as a duplicate of this bug. ***
Comment 23 Bart Szyszka 2000-07-24 16:06:07 PDT
So what's the result of this bug? Specifically stating line-height for IMGs and 
the cells they're inside doesn't always seem to fix this, at least not the 
problem described in Bug ID 46299. What's worse is that adding a lot of stuff 
having to do with line-height can completely mess up a site in Netscape4.
Comment 24 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-07-24 16:15:44 PDT
try:

img { display: block; }

to fix the problem you described.
Comment 25 R.K.Aa. 2000-08-10 20:16:42 PDT
*** Bug 48520 has been marked as a duplicate of this bug. ***
Comment 26 Masatoshi Kimura [:emk] 2000-08-23 10:35:28 PDT
*** Bug 46970 has been marked as a duplicate of this bug. ***
Comment 27 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-09-06 09:12:35 PDT
*** Bug 51518 has been marked as a duplicate of this bug. ***
Comment 28 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-12-25 17:24:40 PST
*** Bug 63715 has been marked as a duplicate of this bug. ***
Comment 29 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-01-13 17:28:49 PST
*** Bug 64487 has been marked as a duplicate of this bug. ***
Comment 30 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-01-13 18:59:04 PST
*** Bug 65365 has been marked as a duplicate of this bug. ***
Comment 31 Boris Zbarsky [:bz] 2001-01-15 10:46:20 PST
*** Bug 65514 has been marked as a duplicate of this bug. ***
Comment 32 Boris Zbarsky [:bz] 2001-02-01 11:22:34 PST
*** Bug 67311 has been marked as a duplicate of this bug. ***
Comment 33 Andreas M. "Clarence" Schneider 2001-02-12 10:43:43 PST
*** Bug 68562 has been marked as a duplicate of this bug. ***
Comment 34 Boris Zbarsky [:bz] 2001-02-16 11:22:49 PST
*** Bug 69083 has been marked as a duplicate of this bug. ***
Comment 35 Mats Palmgren (vacation) 2001-02-24 12:57:54 PST
*** Bug 70079 has been marked as a duplicate of this bug. ***
Comment 36 R.K.Aa. 2001-02-24 13:51:21 PST
Opera 5.0b6 does not have this bug.
MSIE5.5 does not have this bug.
Adding mostfreq keyword. (16 dups and counting)
Comment 37 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-02-24 19:51:37 PST
That doesn't make it a bug.  The CSS2 inline box model really only makes sense
this way.  The problem is that people are trying to use inline images as blocks,
which they're not, unless you make them blocks.

It can be worked around by:
 * triggering compatibility mode
 * using 'display: block' on the images (works in many situations, but not all,
and logically preferred)
 * using 'vertical-align: bottom' on the images
Comment 38 Boris Zbarsky [:bz] 2001-02-26 07:10:41 PST
*** Bug 70151 has been marked as a duplicate of this bug. ***
Comment 39 Brian 'netdragon' Bober 2001-03-02 19:15:38 PST
Created attachment 26678 [details]
Testcase
Comment 40 Brian 'netdragon' Bober 2001-03-02 19:16:57 PST
Created attachment 26679 [details]
Testcase without the display: block
Comment 41 Brian 'netdragon' Bober 2001-03-02 20:16:14 PST
DBaron: I am not entirely sure you're explanation is clear. I hate to ask this, 
but can please give a more detailed explanation of why this bug is marked 
invalid? Also, can you give a short definition of all the css lexicon you use 
(and a link to its location in the spec down to the #.#.#) so that nothing 
sounds ambigious? Please base your explanation off the CSS spec and not the 
interpretation you made. If you had to make any assumptions, then please state 
what the assumptions are.

For example, "If it sets the minimum by creating an
anonymous inline with the font/line-height of the block, things make much more
sense (this is our interpretation)"  

<P>Some <EM>emphasized</em> text</P> - It seems from the spec that anonymous 
inline boxes are created for the "Some" and "text" and not emphasized. If <img> 
is an inline box (what kind of inline box is it btw?) then it can't also be 
made an anonymous inline.

Comment 42 Hixie (not reading bugmail) 2001-03-13 18:11:47 PST
NeTDeMoN: Think of it this way:

   <p><img></p>

...and:

   <p> <img> </p>

...should render the same, right? If you agree, then please show the part of
the spec that indicates that we are incorrect in our rendering. If you don't
agree, then please show the part of the spec that explains why they should be
renderered differently.
Comment 43 Boris Zbarsky [:bz] 2001-03-14 05:36:38 PST
*** Bug 71913 has been marked as a duplicate of this bug. ***
Comment 44 Boris Zbarsky [:bz] 2001-03-15 16:04:36 PST
*** Bug 59227 has been marked as a duplicate of this bug. ***
Comment 45 Hixie (not reading bugmail) 2001-03-25 17:22:41 PST
*** Bug 47165 has been marked as a duplicate of this bug. ***
Comment 46 Boris Zbarsky [:bz] 2001-04-04 15:22:51 PDT
*** Bug 74708 has been marked as a duplicate of this bug. ***
Comment 47 Boris Zbarsky [:bz] 2001-04-11 10:26:57 PDT
*** Bug 75529 has been marked as a duplicate of this bug. ***
Comment 48 Martin Horwath 2001-04-27 00:50:02 PDT
*** Bug 77692 has been marked as a duplicate of this bug. ***
Comment 49 Andreas M. "Clarence" Schneider 2001-04-28 08:44:38 PDT
*** Bug 78000 has been marked as a duplicate of this bug. ***
Comment 50 Andreas M. "Clarence" Schneider 2001-05-11 15:06:37 PDT
*** Bug 80360 has been marked as a duplicate of this bug. ***
Comment 51 Andreas M. "Clarence" Schneider 2001-05-12 13:01:40 PDT
*** Bug 80474 has been marked as a duplicate of this bug. ***
Comment 52 Andreas M. "Clarence" Schneider 2001-05-13 12:35:43 PDT
*** Bug 80590 has been marked as a duplicate of this bug. ***
Comment 53 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-05-14 09:34:08 PDT
In bug 78208, it was questioned whether we should have this behavior in
standard mode or whether we should use a different line box model (such
as the one we use in quirks mode).  I'd like to address that point in a
little more detail.

First, why do we have quirks mode?  We have quirks mode so that existing
pages lay out correctly and we don't break the web.  But why not have
*only* quirks mode?  One might say, because we want to conform to
standards.  But that's not an answer.  Why do we want to conform to
standards (or W3C recommendations, or whatever) rather than standardize
on legacy behavior?  I argue that it's because the standards (at least
the ones relevant to this bug) are designed to create a better web --
one that's more accessible and easier for page authors to maintain.
(Accessible to what?  To users with disabilities, users with outdated
equipment, and to quasi-intelligent programs such as advanced search
robots -- in other words, to anything other than a person with good
vision behind a 800x600+ color monitor and a 28.8Kbps+ Internet
connection.)

In particular, one of the things CSS2 allows is replacing
tables-as-layout with semantic markup with separate style sheets that
describe the layout.  Tables-as-layout is the old way -- it's bad for
accessibility and hard for web authors to write.  CSS2 layout (floats,
positioning, and perhaps table display types for people who are stuck in
the patterns of layout that were adapted to HTML tables) is the new way.
(I admit that the one type of page design that's possible with
tables-as-layout -- the one that's most prominent on the web today -- is
one of the more difficult types of layout to achieve with CSS2.  But the
reason it's prominent on the web is that it is possible with tables, not
that it's good design.)

The new line-height rules make lots of sense in the new world -- a world
where styles are specified on the elements to which they apply.  They
only cause strange problems in the old world -- where it is common to
specify the font for a block-level element on an inline-level element
inside that block or to create a page out of a huge image chopped up
into pieces and stuck in a table so that parts of the image can be
links.  The workarounds are not the real solution -- they're just a way
of being able to continue the bad web page authoring habits in the new
world.  The real solution is to scrap tables-as-layout and start using
CSS2 for layout.

As I started to say above, the point of standards mode is to allow
people to move into this new world without being hampered by all the
strange bugs that hold the old world together.  This is needed to allow
the web to move forward into this new world.  If we change the
standards-mode line box model to something that makes it easier to write
old-style web pages and harder to write new-style web pages, we'll slow
down that movement rather than speed it up.

Good leadership sometimes requires making decisions that are good in the
long term but make things harder in the short term.  The W3C is trying
to provide that king of leadership, but someone in the browser business
needs to do that as well.  Microsoft is not, I think, inclined to do so.
So if we do not lead, the web will not move forward.
Comment 54 Aaron Kaluszka 2001-05-14 12:30:21 PDT
I am not seeing just _what_ part of the new standards breaks the old way. I
only see that the way in which Moz handles them causes the oddities. Why does
<font size="3"> and <font size="5"> look fine under the new rendering, but <font
size="1"> does not? The line-height is too high. I have a feeling that the
same is causing the spacing under <img>s. I still do not see the need for this
extra spacing. The absence of it would seem to conform to the new standards
_and_ the old style. I do not see why a change in display type would change the
resulting layout in some of these cases, or why it should even be necessary. I
guess the root question is: where is the extra space coming from and why is it
there? What specific part of the standards says we should have this space?
Comment 55 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-05-14 12:39:53 PDT
The reason for the extra spacing is that the line-height of a
block-level element establishes a minimum height for all the lines that
it contains (by creating an anonymous inline box around all its
children).  This is needed to ensure even spacing of lines, for example,
when a paragraph contains some smaller text in the middle or when a
paragraph contains a line containing only an inline image.  Changing the
display type makes the block the image itself rather than an anonymous
block constructed around the image that contains a line containing the
image.

See http://www.people.fas.harvard.edu/~dbaron/css/2000/01/dibm for
further explanation.
Comment 56 Aaron Kaluszka 2001-05-14 13:28:49 PDT
Yes, but why can't the anonymous box have a default height of something smaller 
than the amount that is currently used (ie, get rid of the space).  Again, why 
are normal sized elements (text) handled seemingly properly, but small elements 
have spacing issues?  Why does the anonymous block have extra space?  Is there 
any way to set a default anonymous block space to 0?  It seems like the current 
handling harms more than it helps.  The reason is logical, but I believe the 
implementation is questionable.  It should act the same no matter what size 
font or images are used.
Comment 57 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-05-14 13:42:09 PDT
> Yes, but why can't the anonymous box have a default height of something
> smaller than the amount that is currently used (ie, get rid of the
> space).

That would mess up situations like those that I mentioned in my previous
comment.

> Again, why are normal sized elements (text) handled seemingly properly,
> but small elements have spacing issues?

The "small elements" have a font-size smaller than the font-size of the
block that contains them.  If the display concept you want to specify is
that of a block having smaller font size, then specify that, rather than
specifying the font size on an inline inside the block.

> Why does the anonymous block have extra space?

All the content of a non-replaced block-level element must fit in lines.
See http://www.people.fas.harvard.edu/~dbaron/css/2000/01/dibm for a
description (with clarifications) of the CSS2 inline box model.

> Is there any way to set a default anonymous block space to 0?

What's the "default anonymous block space"?  Did you read
http://www.people.fas.harvard.edu/~dbaron/css/2000/01/dibm ?  It
describes no such concept, nor does the CSS2 spec.

> It seems like the current handling harms more than it helps.

See my comment dated 09:34 today.

> It should act the same no matter what size font or images are used.

This statement makes me think you don't understand the issue here.  The
size of the anonymous inline depends on the 'font-size' and
'line-height' of the block level element.
Comment 58 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-05-14 13:51:44 PDT
Instead of "This statement makes me think you don't understand the issue
here," I should have said that it doesn't make sense for me to answer
questions that I've already answered in
http://www.people.fas.harvard.edu/~dbaron/css/2000/01/dibm .  If you read
that and still have questions then I'd be happy to answer those, but the
issues here are very complicated and it really does take that long a
document to explain the whole thing.  I get annoyed (perhaps too easily)
having to explain it over and over again.
Comment 59 Aaron Kaluszka 2001-05-14 14:11:05 PDT
Right.  I did read it, and perhaps I missed what I am about to ask, so forgive 
me if that is true.  I should have clarified what I meant by the 'default 
anonymous block space.'  Say I have a document with nothing but a <font 
size="n">some text</font> inside the <body></body>, where n is a number.  If n 
is >=3, the text displays the same in standard and quirks.  However, if n <3, 
we see the variance in renderings: the line-height still acts as if n=3.  So, 
when I said default, I meant, what is causing all elements to have a default 
line-height equivalent to <font size="3"> and is there any way around it other 
than defining line-height on all affected blocks?  That is what I am perceiving 
as the problem; is an all-encompassing default line-height of 12pt the standard 
model?
Comment 60 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-05-14 14:18:35 PDT
>when I said default, I meant, what is causing all elements to have a default 
>line-height equivalent to <font size="3"> and is there any way around it other 
>than defining line-height on all affected blocks?  That is what I am perceiving 
>as the problem; is an all-encompassing default line-height of 12pt the standard 
>model?

BODY is a block-level element while FONT is an inline level element. 
Inline-level elements are always within lines of block-level elements.
The 'line-height' on a block-level element establishes a minimum height
for all of the lines in that box by establishing an anonymous inline
box that surrounds all of the contents of the block.  If you want to
make the entire contents of BODY have a smaller font size, then you
should specify that BODY has a smaller font size rather than putting
that information on an inline element surrounding all of BODY's
contents.  The "all-encompassing default line-height" you speak of is
just the line-height established by the 'line-height' (which often
depends on 'font-size') of the BODY element.  The solution is not to
specify 'line-height' on the BODY element, but to specify 'font-size'
on the BODY element rather than on a FONT element, which will thus
affect the computed 'line-height' of the BODY element.
Comment 61 Hixie (not reading bugmail) 2001-05-15 18:44:36 PDT
Incidentally, given that you have to go to some lengths to validly use <font>
while triggering Strict mode, it shouldn't be a big deal. Strict mode is mainly
designed to work when you have HTML4 Strict or XHTML1 Strict documents (i.e.,
no <font> elements, align="" attributes, and <table>s only used for showing 
tabular data and not for layout). In those scenarios, it is easier to set the
font-size on the block element (<body>, <p>) than to set it on inline elements
(as it is with <font>).
Comment 62 Aaron Kaluszka 2001-05-22 16:33:54 PDT
*** Bug 47165 has been marked as a duplicate of this bug. ***
Comment 63 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2001-05-24 15:44:05 PDT
*** Bug 82600 has been marked as a duplicate of this bug. ***
Comment 64 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2001-05-24 16:00:33 PDT
> The reason for the extra spacing is that the line-height of a
> block-level element establishes a minimum height for all the lines that
> it contains (by creating an anonymous inline box around all its
> children). This is needed to ensure even spacing of lines, for example,
> when a paragraph contains some smaller text in the middle or when a
> paragraph contains a line containing only an inline image.

That still doesn't explain why the CSS WG could not make a special case of
replaced inline element (possibly wrapped in a non-replaced inline element)
inside a table cell with no non-whitespace in the same cell.

(Yes, the point about layout tables being bad explains that, but I think making
the standard work better with real world is better than encouraging people to
stick with the quirks mode and *all* of its quirks.)
Comment 65 Hixie (not reading bugmail) 2001-05-24 19:52:08 PDT
That's not the only quirk.

Would you also like the CSS specification to state that the last line of a 
list-item block that is the last child of a block containing only list-item
blocks should have a line-height that is, at a minimum, the line-height of
the parent list-item block?

Because that is something else that tag soup renderers do which old markup
relies on.

My point is that we have a quirks mode for a reason. If people want to write 
pages that are backwards compatible and use bad techniques such as putting
replaced elements alone in table cells with no intervening whitespace and 
expecting the minimum line height rule to be ignored, then they should not be 
using a DOCTYPE, and should be triggering quirks mode. It is not a reason for 
the specs to become bogged down with backwards-compatible quirk rules that have
bad side effects such as two images in adjacent cells not lining up just 
because one cell happens to also have text in it.
Comment 66 Boris Zbarsky [:bz] 2001-06-04 06:23:16 PDT
*** Bug 83955 has been marked as a duplicate of this bug. ***
Comment 67 Boris Zbarsky [:bz] 2001-06-20 16:30:15 PDT
*** Bug 86935 has been marked as a duplicate of this bug. ***
Comment 68 Aaron Kaluszka 2001-06-26 07:41:23 PDT
*** Bug 87800 has been marked as a duplicate of this bug. ***
Comment 69 AriB 2001-06-26 12:56:00 PDT
I don't understand why this bug isn't being fixed. There are so many dupes for
this. People will dump mozilla for IE because it 'works' on those sites and I'm
afraid mozilla will be like amaya-just a proof of concept of W3C standards that
nobody uses
Comment 70 Boris Zbarsky [:bz] 2001-07-03 09:58:24 PDT
*** Bug 89012 has been marked as a duplicate of this bug. ***
Comment 71 Edy Incoletti 2001-07-04 02:16:17 PDT
The majority of people who creates pages for the web uses programs such as
Dreamweaver or FrontPage. These programs use an "old" style to create pages.

If someone create a page with this programs and try that page with IE all works
fine, but with Mozilla there are some problems.

"Whe must correct this" say is manager. The solution is simple: put a line with
the right DOCTYPE in front of file.
"Oh, yes, with IE it's allright, and we have correct the bug in Mozilla, but now
all the images in our pages are breaked!!!"
"So this is a bug in Mozilla. It doesn't matter, if Mozilla doesn't works nobody
will use it!! Search the compatibility only for IE"

I'm sorry for my english, but I think this is a good method to determine if an
interpretation must or not considered a bug. In my mind Mozilla must become THE
standard for the web browsing and not an "Educational project for young
developers"...
Comment 72 Aaron Kaluszka 2001-07-05 07:41:13 PDT
*** Bug 89384 has been marked as a duplicate of this bug. ***
Comment 73 Aaron Kaluszka 2001-07-05 10:10:31 PDT
I think we're either going to have to reconsider some things decided about this
bug or reopen all the DUPs under Evangelism.  (Personally, I'd rather see the
former).
Comment 74 Aaron Kaluszka 2001-07-05 10:37:16 PDT
Quoting bug 19956

------- Start Comments From David Baron 2000-06-13 10:02 -------
This is correct according to (our interpretation of) the CSS2 inline box model.
 (The "interpretation" is that CSS2 10.8.1 says that 'line-height' on a block
specifies the minimum height of all of that block's line boxes.  It doesn't say
*how* it sets this minimum.  If it's just a direct setting of a minimum, it
leads to really strange things, like the problem described here happening for
small images but not for large ones.  If it sets the minimum by creating an
anonymous inline with the font/line-height of the block, things make much more
sense (this is our interpretation).)
------- End Comments From David Baron 2000-06-13 10:02 -------

Summary
We are getting our line-height from the <body> by default which is using the
font size.  Now, the default font size has always been 12pt.  This creates the
'descenders' on any images shorter than the height of 12pt because the anonymous
box is created per 'interpretation'.

Proposal
We remove this problem by interpreting the default line-height to be zero unless
a line-height/font-size is _explicitly_ set.  This would remove most of the
visible difference between standards and quirks and wouldn't necessarily violate
CSS2 standards since we're working off of interpretation.  The anonymous box
would still live.

Another thing
There still seems to be a pixel added to the bottom of graphics.  Currently, I
can't get rid of the 'descenders' completely on graphics unless I set the
font-size to 1px (for 1px tall images) AND vertical-align to top.. unfortunately
doing so breaks the page under IE and Opera.  There seems to be something
strange with the default vertical-align.  If this is not clear I will come up
with an example page.

If people WANT to keep things 'broken' solely because they consider it bad form
to use tables as layout.. this is ridiculous and will eventually hurt Mozilla
acceptance (per Edy's comments).
Comment 75 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-07-05 11:06:32 PDT
>We are getting our line-height from the <body> by default which is using the
>font size.  Now, the default font size has always been 12pt.  This creates the
>'descenders' on any images shorter than the height of 12pt because the
>anonymous box is created per 'interpretation'.

Since the images are by default baseline-aligned, even larger images will have
space for the descent of the font. (Mozilla's default font size is 16px, not
12pt.  Points are meaningless for screen media.)

>We remove this problem by interpreting the default line-height to be zero
>unless a line-height/font-size is _explicitly_ set.  This would remove most of
>the visible difference between standards and quirks and wouldn't necessarily
>violate CSS2 standards since we're working off of interpretation.  The
>anonymous box would still live.

I will not under any circumstances consider a solution that depends on how a CSS
property was set.  That completely misses the point of CSS.  It's also very
difficult to implement in our implementation since we have a good implementation
of CSS.

>There still seems to be a pixel added to the bottom of graphics.  Currently, I
>can't get rid of the 'descenders' completely on graphics unless I set the
>font-size to 1px (for 1px tall images) AND vertical-align to top.. >unfortunately
>doing so breaks the page under IE and Opera.  There seems to be something
>strange with the default vertical-align.  If this is not clear I will come up
>with an example page.

Why don't you just trigger quirks mode?  Tables-as-layout is not the future of
web authoring.

>If people WANT to keep things 'broken' solely because they consider it bad form
>to use tables as layout.. this is ridiculous and will eventually hurt Mozilla
>acceptance (per Edy's comments).

I see no evidence that it has hurt Mozilla's acceptance and I doubt it ever will.
Comment 76 Aaron Kaluszka 2001-07-05 15:44:31 PDT
I'll reply to David's comments later, but I wanted to bring this issue up:
Ian Hixie said,
"Strict mode is mainly designed to work when you have HTML4 Strict or XHTML1 
Strict documents"
That's fine.. I'm assuming Strict mode means Standards mode...
But based on that statement, why are we applying it to HTML4/XHTML1 
_Transitional_?
I thought that W3C came up with the Transitional namespace as a way for authors 
to add new attributes/methods but keep the old style of web design.  Strict was 
for strict conformance to become ready for recommendations such as XHTML1.1
So I ask again, should we even be applying Standards "Strict" mode to 
Transitional documents?  It seems to me we're breaking the intent of the 
Transitional namespace.
Comment 77 Boris Zbarsky [:bz] 2001-07-05 15:46:23 PDT
*** Bug 89482 has been marked as a duplicate of this bug. ***
Comment 78 Hixie (not reading bugmail) 2001-07-11 16:43:23 PDT
We don't trigger standard mode for HTML 4 Transitional.
We trigger standard mode for all XHTML content on the explicit request of the
HTML working group.
Comment 79 Jason Fleshman 2001-07-13 12:55:06 PDT
Sorry to spam half the known universe, but I need to correct a mistake that Ian
made: This applies to HTML 4.01 Transitional as well.  I know this from personal
experience dealing with trying to make technically valid pages that display
properly in Moz.  Now I know the purpose of this bug isn't to argue whether
Transitional should use quirks or standards mode (I think there's a bug for that
somewhere), I just felt that needed to be pointed out. 
Comment 80 Andreas M. "Clarence" Schneider 2001-07-14 23:06:27 PDT
*** Bug 89307 has been marked as a duplicate of this bug. ***
Comment 81 Hixie (not reading bugmail) 2001-07-21 10:21:35 PDT
I didn't say "4.01 Transitional" I said "4 Transitional". My statement stands.
(Yes, for 4.01 Transitional we use standard mode, because there was demand for
a way of using transitional mode with standard rendering, and at the time it
was felt that 4.01 was in rare enough use for it to be a safe compromise.)
Comment 82 Scott James Remnant 2001-08-05 06:06:56 PDT
Doing the "display: block" trick on images layed out in a table *severely*
screws up the layout of that site in Netscape 4.7.  This means that Mozilla
pages will not be backwards compatible!
Comment 83 Jason Fleshman 2001-08-05 07:27:42 PDT
[QA ignore this post]
To solve this problem, you can use a trick I read about in the O'Reilly CSS
book.  Make a separate style sheet with things that only work right in Explorer
and Mozilla (like display: block in your case).  Then reference the sheet after
your other style sheet(s) by using this syntax:

<style type="text/css"><!--
@import url(moz_and_ie.css);
--></style>
Since N4 doesn't recognize the @import rule, it will ignore anything you put in
moz_and_ie.css.  (FYI, you can also do the spacing around paragraphs like this
by putting N4's broken way in the main sheet and the correct way in the non-N4
sheet.  Just make sure it comes after the main sheet so the rules get
overwritten properly.
Comment 84 Stephen D Cope 2001-08-05 13:18:42 PDT
Using 'display: block' is a bit of a messy kludge, as it really messes up the way ANY browser handles images. It aligns them to the left and does other things.

My preferred method is:

  Quoting 'David Baron' on 2001-02-24 19:51:
  It can be worked around by ... using 'vertical-align: bottom' on the images

You can also change the vertical-align of the block surrounding the image.

(BTW, Hi Scott.)
Comment 85 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-08-06 06:10:12 PDT
But the fact remains that 'display: block' is really what you mean (when you 
only have one image per cell) and the 'vertical-align' trick is a hack that 
won't even work when the images have a height smaller than the 'line-height'.
Comment 86 Stephen D Cope 2001-08-06 14:06:45 PDT
David Baron:
  won't even work when the images have a height smaller
  than the 'line-height'.

That is correct. However, once images are less than the line-height, the reason for their existance must be questioned.

1 - Are they being used to make the page look a particular way? Probably (how many spacer.gif and 1x1.gif can you fit on one page?). In that case they should be using the 'border' property. Or perhaps they could investigate 'width' and stop fluffing around with HTML hacks which can be solved in CSS.

2 - At that size and image would be difficult to view, which would pose an accessibility problem.

While having tiny images may be legal HTML, it is bad practice. Both because of impairing accessibility (how many designers omit the ALT tag for their many 1x1.gifs?) and mingling design with content.
Comment 87 Aaron Kaluszka 2001-08-10 13:19:12 PDT
*** Bug 89857 has been marked as a duplicate of this bug. ***
Comment 88 Niels Aufbau 2001-08-13 11:32:58 PDT
For the sake of completeness: <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=95049">bug 95049</a> (hovering
over images at webelements.com draws purple bars under the images) is also a
duplicate of this bug.  It's been moved to evangelism instead of being marked as
a duplicate.
Comment 89 Mats Palmgren (vacation) 2001-08-21 16:57:18 PDT
*** Bug 96183 has been marked as a duplicate of this bug. ***
Comment 90 Randell Jesup [:jesup] 2001-08-22 08:06:37 PDT
*** Bug 96424 has been marked as a duplicate of this bug. ***
Comment 91 Andreas M. "Clarence" Schneider 2001-08-24 12:39:21 PDT
*** Bug 95603 has been marked as a duplicate of this bug. ***
Comment 92 Gervase Markham [:gerv] 2001-08-25 09:22:52 PDT
Resummarising to make it more clear what this is on duplicates.cgi. If I've
resummarised incorrectly, please correct my correction :-)

Gerv
Comment 93 Andreas M. "Clarence" Schneider 2001-08-31 10:42:32 PDT
*** Bug 97801 has been marked as a duplicate of this bug. ***
Comment 94 Andreas M. "Clarence" Schneider 2001-08-31 11:04:08 PDT
*** Bug 97804 has been marked as a duplicate of this bug. ***
Comment 95 Brian Haskin (Janzert) 2001-09-16 11:15:50 PDT
*** Bug 90798 has been marked as a duplicate of this bug. ***
Comment 96 Bernd 2001-09-20 12:11:07 PDT
*** Bug 98628 has been marked as a duplicate of this bug. ***
Comment 97 Tuukka Tolvanen (sp3000) 2001-09-26 06:07:21 PDT
*** Bug 101708 has been marked as a duplicate of this bug. ***
Comment 98 Matthijs Sypkens Smit 2001-10-03 05:12:36 PDT
Mozilla's behaviour being discussed under this 'bug' seems to change when I hit
reload. See http://www.sv-irene.nl/mozilla/. When the page first loads there's
spacing between the images on the left. If I hit reload (no shift) then the
spacing between the images is reduced. When I then choose one of the links or
hit shift-reload the spacing changes back again.

Comment 99 Jason Fleshman 2001-10-03 06:13:10 PDT
Don't see this with a Win98 build from two days ago (2001100103).
Comment 100 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2001-10-04 06:14:06 PDT
*** Bug 103109 has been marked as a duplicate of this bug. ***
Comment 101 Jason Johnston 2001-10-04 08:13:34 PDT
*** Bug 103108 has been marked as a duplicate of this bug. ***
Comment 102 Gael Le Mignot 2001-10-12 04:26:42 PDT
Isn't this the same bug than 81698?
Comment 103 Boris Zbarsky [:bz] 2001-10-19 13:29:13 PDT
*** Bug 105617 has been marked as a duplicate of this bug. ***
Comment 104 Boris Zbarsky [:bz] 2001-10-21 10:09:51 PDT
*** Bug 105617 has been marked as a duplicate of this bug. ***
Comment 105 Boris Zbarsky [:bz] 2001-10-23 10:57:31 PDT
*** Bug 106252 has been marked as a duplicate of this bug. ***
Comment 106 Marc Boullet 2001-10-24 04:30:22 PDT
*** Bug 105652 has been marked as a duplicate of this bug. ***
Comment 107 Marc Boullet 2001-10-24 06:27:35 PDT
I'm the reporter of bug 105652 which I duped to this one.

Though I can understand (hardly) the arguments for the strict mode,
I'm still looking for a solution in quirks mode that works for Moz,
NS 4.7 and IE (see my testcase1.htm in bug 105652).
Since style="display: block;" satellites NS 4.7, I suggest that Mozilla
quirks mode behaves exactly the same as strict mode (at least for small
images). The purpose of quirks mode is to make Mozilla renders like older
browsers when strict mode is not specified, right?

As a developer, I'd like to avoid special casing in JS as far as I can.
Comment 108 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-10-24 14:09:07 PDT
Anything that happens in quirks mode is not this bug.

FWIW, I'm thinking of finding a fix for table cells only that we'd use in strict
mode too that acts something like the 'line-box-policy' property proposed for CSS3.
Comment 109 Boris Zbarsky [:bz] 2001-10-30 10:44:08 PST
*** Bug 107563 has been marked as a duplicate of this bug. ***
Comment 110 Boris Zbarsky [:bz] 2001-10-31 11:11:27 PST
*** Bug 107774 has been marked as a duplicate of this bug. ***
Comment 111 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2001-11-01 03:39:22 PST
*** Bug 107942 has been marked as a duplicate of this bug. ***
Comment 112 Boris Zbarsky [:bz] 2001-11-04 11:37:23 PST
*** Bug 108444 has been marked as a duplicate of this bug. ***
Comment 113 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2001-11-10 14:48:11 PST
*** Bug 109547 has been marked as a duplicate of this bug. ***
Comment 114 Boris Zbarsky [:bz] 2001-11-14 12:24:04 PST
*** Bug 110058 has been marked as a duplicate of this bug. ***
Comment 115 eberry 2001-11-16 00:28:12 PST
*** Bug 110408 has been marked as a duplicate of this bug. ***
Comment 116 R.K.Aa. 2001-11-22 09:48:18 PST
*** Bug 111452 has been marked as a duplicate of this bug. ***
Comment 117 Boris Zbarsky [:bz] 2001-12-01 11:42:42 PST
*** Bug 113048 has been marked as a duplicate of this bug. ***
Comment 118 Boris Zbarsky [:bz] 2001-12-11 13:49:32 PST
*** Bug 114159 has been marked as a duplicate of this bug. ***
Comment 119 Maurício Collares Neto [:mauricioc] 2001-12-28 13:08:43 PST
*** Bug 116668 has been marked as a duplicate of this bug. ***
Comment 120 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-01-02 08:02:55 PST
*** Bug 20575 has been marked as a duplicate of this bug. ***
Comment 121 Olav Vitters 2002-01-10 06:57:14 PST
*** Bug 119189 has been marked as a duplicate of this bug. ***
Comment 122 Olav Vitters 2002-01-10 15:15:56 PST
*** Bug 119339 has been marked as a duplicate of this bug. ***
Comment 123 Boris Zbarsky [:bz] 2002-01-31 00:28:57 PST
*** Bug 122620 has been marked as a duplicate of this bug. ***
Comment 124 miki 2002-01-31 01:25:18 PST
This is impossible :(
Konquere show web without this error
IE X.X show it correctly.

Mozilla shot its own leg by not fixing this major bug even if it slightly defer 
from XHTML but then why do we have transitional.
Comment 125 Christopher Aillon (sabbatical, not receiving bugmail) 2002-02-06 14:50:17 PST
*** Bug 123856 has been marked as a duplicate of this bug. ***
Comment 126 Boris Zbarsky [:bz] 2002-02-07 20:27:47 PST
*** Bug 123979 has been marked as a duplicate of this bug. ***
Comment 127 Christopher Aillon (sabbatical, not receiving bugmail) 2002-02-11 01:33:41 PST
*** Bug 124811 has been marked as a duplicate of this bug. ***
Comment 128 John Flynn 2002-02-11 07:23:29 PST
I've been following this "bug" for some time now, and just wanted to add my
opinion on it. Not that I feel anything will be done, but I must state my position.

This "bug" is hurting Mozilla. There are thousands of web sites out there that
render incorrectly because of this "bug" and there will be hundreds more. It is
a mission of colossal magnitude to attempt to evangelize current and future
webmasters about this "bug". There will always be web pages that render
incorrectly because of this.

Now, let's look at this from another angle. If we modify Mozilla so that those
pages render "correctly", even if we bend W3C standards slightly, how many pages
that previously rendered properly will now break? I'm almost certain that this
number will be much lower than the number of pages broken now, because those
broken pages would likely break in MSIE and Netscape as well.

Mozilla is currently the only browser I'm aware of that has this problem. MSIE,
Netscape, even Opera render the pages properly. I personally feel that this
"bug" is a major stumbling block for Mozilla and should be "fixed".
Comment 129 Stephen D Cope 2002-02-11 17:15:31 PST
> Mozilla is currently the only browser I'm aware of that has this problem.

It's not a problem.

> MSIE, Netscape, even Opera render the pages properly.

No they don't.

I can't spel properly. Call Oxford and tell them to fix their dictionary.
Comment 130 Frédéric De Vries 2002-02-12 03:19:43 PST
I fully agree with the previous message about this being a bug that is 
defeinitely a blocker -- though I don't see why mozilla should bend the
standards in order to fix the bug (?) -- and intend to point that out to the
Mozilla developers who will attend Fosdem in Brussels.

If Mozilla still doesn't resolve this bug in 1.0, I can't see how I could
even try to impose the browser as a standard for the corporate
intra/extranets at our clients, since the majority of those sites will
suffer a broken layout.

Furthermore, I don't see why that hostile reaction to the mail was necessary, 
let alone usefull.

kind regards,
Frédéric De Vries
Comment 131 miki 2002-02-12 04:10:59 PST
I fully agree with comment 130.

This is the biggest block of mozilla.

Small sugestions
To sustain the hard rules the developer can add a Question while installation:
Do you want to install aditional module to fix RFC layout problems ?
Comment 132 Jason Fleshman 2002-02-12 06:21:23 PST
<QA Ignore>
Sorry, but comment 128 and comment 130 are ignoring some of the facts
(understandable -- this is a very long bug now).  When the Moz team was figuring
out what to do with Standards vs. Quirks mode they took input from Web
developers who wanted to make a Transitional doctype without having to code
around N4's misbehaviors.  Here's what they came up with:

Missing doctype - Quirks mode
HTML 2.x, 3.x - Quirks mode
HTML 4.0 Transitional - Quirks mode
HTML 4.01 Transitional - Standards mode
HTML 4.x Strict - Standards mode
Any unknown doctype - Standards mode (for forwards-compatibility)
Any XHTML doctype - Standards mode

If I understand correctly, IE6 uses a similar algorithm for the same reasons. 
If your layout is breaking due to this "bug" then switch your doctype to 4.0
from 4.01.

Feel free to disagree, but this is the compromise that's been worked out since
this was filed two and a half years ago.  And the "hostile" reaction (I'm
assuming you mean comment 129) was blunt and illustrated the point perfectly --
the page wasn't written to the specification, because the spec says that images
are inline elements, and inline elements have a line-height associated with
them.  This situation is akin to telling Websters "your dictionary is wrong; I
spell this word this way."  The Websters people, I'm sure, would reply by
telling you to learn how to spell.  If your layout depends on broken browsers,
use an older doctype.  Don't punish those of us who are taking the time to write
pages properly.
Comment 133 Frédéric De Vries 2002-02-12 09:08:54 PST
2 points:
1. About the 'standards' approach:
True, the algorithm is intelligent. I too am an evangelist of web standards and 
browsers complying with them. But I don't see why this is not a bug. Also true: 
one should specify line-height along with the container of the images when 
declaring an XHTML doctype or a 4.X strict one. False to my belief: Mozilla 
behaves correctly. Let me explain: default line-height of any given element is 
to my knowledge 12 or 14 pixels (give or take one). If I use images that are 30 
pixels high, there is no reason why the browser should add whitespace to it. 
However, that's what Mozilla does. If I specify a line-height of 100% (default 
being 120%, again: to my knowledge), Mozilla must not add whitespace, because 
the line-height should be identical to the height of the elements, wether those 
are text cahracters or an image. In the example of images with a height of 30 
pixels, I get rid of the whitespace if I put my lineheight exactly to 10 
pixels. Now you pllease explain to me why this is not a bug...
As you point out yourself: MSIE6 uses a similar standards vs quirk mode 
algorithm and still he renders the pages as intended.

2. About the 'blunt' reaction
I've never been a fan of MS. Still, when a bèta user comes up with a comment -- 
*right or wrong* -- I don't believe that they 'd send him off with a reply that 
comes down to: learn how to read, study the specs. Where do you buy your stuff: 
in the shop where a kind salesman answers your questions with patience or the 
one where they call you an idiot? You may have the best product, but the VHS 
victory in the videomarket may teach you that that is *not* enough.
Comment 134 Arthur 2002-02-12 10:11:51 PST
Frédéric, if you don't add whitespache to an element (i.e. text, formulas,
images) in an inline box, you end up with for example the lower part of a 'p'
touching the upper part of a 'l' a line below. You don't want that and I'm sure
you agree here. Let's assume you have a formula below the p, you don't want to
touch them either, same for an image below or above text. If you define
something as an inline element, it's *in* the line no matter how large it is and
there's space between lines, that's why it is called a line. It would be very
strange to handle inline images differently. Simply don't make them inline
elements if you don't want them to behave like inline elements. I've posted a
duplicate to this bug myself and as a result, I took the time to dig a little
deeper into css. It was sure worth the time.
Comment 135 Stephen D Cope 2002-02-12 23:01:49 PST
Maybe I can be a bit unblunt this time around, but when someone wanders in and
makes a comment that has been attached to this bug almost as many times as it
has been duped ...

Frankly, if your page triggers Standards mode you should be smart enough to know
about leaving room for descenders.

If you haven't a clue about needing to leave space for the tail on the "y", then
you probably don't know how to add a DTD to your document that triggers
Standards mode.

If you do have the DTD, but your page doesn't live up to it because of your
oversight - and yes, this is a fairly obscure feature/quirk - then YOUR
ignorance is YOUR FAULT and YOU need it fix YOUR page. If you don't want to fix
it or you don't know how to fix it (although several fixes are listed if you
*read* the comments) then take your DTD out of your document or go back to a
cushier DTD. You're not worthy of HTML 4.01 or XHTML. (Thank you jfleshman for
the list.)

Take for example this page that displays how to spell "yoyo". The second letter
has been replaced by an image. (See the dictionary.com pronunciation keys to
understand this why someone would mingle text and images.)

http://bla.crysm.net/mozilla/descender/

There are two pages here. Lets look at how it SHOULD look. This is in Standard
rendering mode. I've said the page is XHTML 1.1 (Strict):

http://bla.crysm.net/mozilla/descender/strict.html

Everything lines up nicely. The two "o"s are on the correct level. Have a look
at "strict-zoom.png" which I've added a red line to mark out the metrics.

Now, here is a second page. This is how the page appears in quirks mode. If the
browser was forced to always display in "broken" mode. Lets see ...

http://bla.crysm.net/mozilla/descender/quirks.html

Have a look at "quirks-zoom.png" for more detail.

Is any further commentary needed?

Go fix your pages already. I fixed mine.
Comment 136 Jason Johnston 2002-02-16 16:27:33 PST
*** Bug 125901 has been marked as a duplicate of this bug. ***
Comment 137 Jesse Ruderman 2002-02-17 01:07:34 PST
http://developer.netscape.com/evangelism/docs/articles/img-table/ explains where
this problem comes from and describes several solutions.
Comment 138 Boris Zbarsky [:bz] 2002-02-19 21:21:19 PST
*** Bug 126519 has been marked as a duplicate of this bug. ***
Comment 139 Frédéric De Vries 2002-02-20 00:55:42 PST
Apologies are in order... I've carefully read the Devedge article 
(http://developer.netscape.com/evangelism/docs/articles/img-table/) and looked 
it up in the W3C specs. I must come to the conclusion that Mozilla is right in 
rendering the whitespace below the image. So you guys are right: this is not a 
bug. Nevertheless, I do agree with the conclusion of the article that this is 
sth that ought to be looked into for the CSS 3 specs.
Furthermore, I still wonder about the line-height handling (see post #132) with 
images though, but I guess this is not the place to discuss that.
Thanks and apologies to Stephen C and Arthur for their patience.
Frédéric.
Comment 140 Amarendra Hanumanula 2002-02-20 18:21:52 PST
*** Bug 126579 has been marked as a duplicate of this bug. ***
Comment 141 Christopher Aillon (sabbatical, not receiving bugmail) 2002-02-21 09:04:56 PST
*** Bug 127023 has been marked as a duplicate of this bug. ***
Comment 142 R.K.Aa. 2002-03-10 10:41:26 PST
*** Bug 129948 has been marked as a duplicate of this bug. ***
Comment 143 Christopher Aillon (sabbatical, not receiving bugmail) 2002-03-11 07:35:59 PST
*** Bug 130056 has been marked as a duplicate of this bug. ***
Comment 144 Boris Zbarsky [:bz] 2002-03-13 21:37:57 PST
*** Bug 130669 has been marked as a duplicate of this bug. ***
Comment 145 Christopher Aillon (sabbatical, not receiving bugmail) 2002-03-15 10:35:19 PST
*** Bug 131200 has been marked as a duplicate of this bug. ***
Comment 146 Bernd 2002-03-17 11:50:16 PST
*** Bug 131591 has been marked as a duplicate of this bug. ***
Comment 147 Sebastian Biallas 2002-03-21 02:23:42 PST
*** Bug 132520 has been marked as a duplicate of this bug. ***
Comment 148 Boris Zbarsky [:bz] 2002-03-21 19:04:47 PST
*** Bug 132706 has been marked as a duplicate of this bug. ***
Comment 149 Michael A. Peters 2002-03-26 12:32:39 PST
How is this not a bug if removing the DOCTYPE definition fixes it?

I'm not talking a 4.01 strict doctype, a 4.01 transitional.

height, spacing, padding are all legal in transitional.
When used in a page that declares itself transitional, mozilla says to hell with
them, to hell with people who code for Netscape 4 compatability, I'm going to
take the strict doctype even though the guy specified 4.01 transitional in his
doctype.

That is a bug.
Comment 150 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-03-26 13:00:54 PST
The names of the Transitional versus "Strict" doctypes have nothing to do with
how HTML markup should be treated -- the "Strict" (I put it in quotes because
it's never called strict -- only the filename is strict.dtd) is simply the
DOCTYPE that represents strict compliance with all of the requirements of HTML
4.0 that can be expressed in a DTD, while the Transitional DTD is one that
relaxes some of those requirements for transitional purposes.

We use those DTDs to trigger two different mode not because they actually mean
anything but because they're an indicator of how "new" the page is and whether
the page author was aware of browsers that support web standards, such as
MacIE5, Opera, and Mozilla, when writing the page.  See
http://mozilla.org/docs/web-developer/quirks/ .
Comment 151 Mats Palmgren (vacation) 2002-03-31 14:40:51 PST
*** Bug 133198 has been marked as a duplicate of this bug. ***
Comment 152 Michael A. Peters 2002-04-01 02:28:38 PST
I think that is an invalid use of the doctype.It was stated with a rather tripe closing comment in bug 133198 that Mozilla was handling the rendering properly to CSS2 definitions.But I didn't say that I wanted CSS2 definitions.I said I wanted 4.01 transitional, for which the layout tags I used were proper.I did not use any CSS2 for layout of the table because there are browsers that wouldn't know what to do with them.And that is, if I'm not mistaken, why transitional DTD's exist-So that I can declare a transitional dtd, and allow _commonly used browsers_ some time to catch up with current technology.Otherwise, I would use strict :)Should I break compatability with other browsers for the sake of looking good in Mozilla?Should I just not declare the DTD?W3C says to declare it.If I declare it 3.2 I get errors.If I declare it 4.x strict same.The page meets W3C's requirements using tags that are valid to use and Mozilla doesn't handle it right because of a "holier than thou" attitude regarding CSS2 when you are the only browser I have seen that properly handles CSS2.HTML 4.01 Transitional != CSS2But oh well.
Comment 153 Olav Vitters 2002-04-01 03:20:18 PST
*** Bug 126848 has been marked as a duplicate of this bug. ***
Comment 154 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-04-01 06:05:11 PST
See http://mozilla.org/docs/web-developer/quirks/ for what we are doing and why.
Comment 155 Boris Zbarsky [:bz] 2002-04-03 10:50:14 PST
*** Bug 135096 has been marked as a duplicate of this bug. ***
Comment 156 Sitsofe Wheeler 2002-04-10 15:03:46 PDT
*** Bug 96297 has been marked as a duplicate of this bug. ***
Comment 157 David A. Pérez 2002-04-15 08:44:46 PDT
*** Bug 111643 has been marked as a duplicate of this bug. ***
Comment 158 Sebastian Biallas 2002-04-23 01:52:46 PDT
*** Bug 139409 has been marked as a duplicate of this bug. ***
Comment 159 Sebastian Biallas 2002-04-23 08:53:29 PDT
*** Bug 139409 has been marked as a duplicate of this bug. ***
Comment 160 R.K.Aa. 2002-04-25 01:47:10 PDT
*** Bug 139966 has been marked as a duplicate of this bug. ***
Comment 161 Karsten Schramm 2002-04-25 03:48:58 PDT
ok, i see, Mozilla won't repair this Non-Bug.

My Page is 4.01 Transitional an validated by W3C-Validator.

IE 5-6, Opera shows the same page, Mozilla and NS 6.x doesn't.

Now I have 2 Options:

somebody tells me, how to build my site, so that looks in all browsers correct 
(but: primary is IE, he is the master-Browser in WWW, and far far behind is 
Mozilla)

or I ignore Mozilla and have to write a "best viewed with", what I not really 
want.

My Bug report was http://bugzilla.mozilla.org/show_bug.cgi?id=139966


I build my Site not for the W3C or some standards, I build my Site for my 
Users, and they must see the site correct. _Nobody_ of my users is interested 
in a standard-conform-site, only in a well formed site.
Comment 162 Dwight Brown 2002-04-25 08:27:33 PDT
Your bug report was filed as a duplicate, if you would read all the replies to 
that report you would learn of methods to fix this problem.

The problem is with your html, what you should do is add a css "display: 
block;" to the images that have extra space under them.

Like this:

<img src="path_to_image/image.gif" style="display: block;">

And as a side note, you SHOULD build your site on W3C standards. It is 
perfectly easy to write a "WELL FORMED" web site using STANDARDS.

The standards almost never limit what you can do, it just applies rules on how 
you go about doing that. With some more study, testing, and experience you 
should have no problem writing websites that look identical in IE and Mozilla.

I once submitted a dupe of this bug, but thanks to the helpful replies learned 
what I need to do to fix *my* bug.
Comment 163 Hixie (not reading bugmail) 2002-04-25 13:58:59 PDT
If you don't want to fix your site, just remove the <!DOCTYPE> line. If you
leave the DOCTYPE line you are saying that you want to follow standards. If you
remove the DOCTYPE line then we will do what you think is "the right thing".
Comment 164 R.K.Aa. 2002-05-01 10:24:08 PDT
*** Bug 141506 has been marked as a duplicate of this bug. ***
Comment 165 Boris Zbarsky [:bz] 2002-05-01 19:29:26 PDT
*** Bug 141604 has been marked as a duplicate of this bug. ***
Comment 166 Boris Zbarsky [:bz] 2002-05-03 10:43:49 PDT
*** Bug 142037 has been marked as a duplicate of this bug. ***
Comment 167 Boris Zbarsky [:bz] 2002-05-06 23:42:50 PDT
*** Bug 142600 has been marked as a duplicate of this bug. ***
Comment 168 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2002-05-11 16:11:11 PDT
*** Bug 143652 has been marked as a duplicate of this bug. ***
Comment 169 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2002-05-13 02:11:28 PDT
*** Bug 126219 has been marked as a duplicate of this bug. ***
Comment 170 Michael A. Peters 2002-05-13 03:48:22 PDT
In reply to comment 162

You can create a W3C 4.0 transitional compliant page that has this problem.
In such a page html 4.0 depricated but still legal tags are not respected by
Mozilla.

Therefore, I consider it a bug even though Mozilla people do not.

If they want to parse a page that defines itself as transitional as a STRICT
page then it is a bug.

Transitional says I can use those tags and the html renderer should still
respect them, because they are legal.

Mozilla does not respect them.
Comment 171 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2002-05-15 11:49:06 PDT
*** Bug 144199 has been marked as a duplicate of this bug. ***
Comment 172 Gunnar Wagenknecht 2002-05-17 03:33:23 PDT
Regarding comment 170: When will this bug be fixed? It's opened since 1999 and 
it's going to be awkward for Mozilla now. Every browser supports it also W3C 
allows it.
Comment 173 Boris Zbarsky [:bz] 2002-05-17 08:06:22 PDT
Gunnar, this is marked "VERIFIED INVALID".  That means "This is not a bug, but
correct behavior."
Comment 174 Bernd 2002-05-22 21:54:51 PDT
*** Bug 146273 has been marked as a duplicate of this bug. ***
Comment 175 Boris Zbarsky [:bz] 2002-05-29 12:24:04 PDT
*** Bug 147906 has been marked as a duplicate of this bug. ***
Comment 176 Bernd 2002-06-14 12:38:57 PDT
*** Bug 151823 has been marked as a duplicate of this bug. ***
Comment 177 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-19 10:52:54 PDT
See bug 151620, where this behavior is being reconsidered (perhaps only partly).
Comment 178 Elizabeth Lemke 2002-06-19 17:51:00 PDT
Okay, as a web designer this thing is driving me nuts.  Quirks mode *should* be invoked for transitional 4.01 (look up the definition of the word transitional).

And no I won't change the page as this is valid HTML 4.01 Transitional and it is Moz's behavior that is the issue not the code (after all 4.0 Transional is in quirks mode).

Until more browsers support strict, transitional is a way of life whether you guys like it or not.

-Beth

(Who files a bug on this that turned out to be a duplicate of this bug)
Comment 179 Boris Zbarsky [:bz] 2002-06-19 18:01:06 PDT
You can have a transitional DTD _and_ quirks mode.  You can also have a
transitional DTD and _standards_ mode ('strict' is a misnomer in that there are
things that are not done 'strictly' in this mode as much as 'correctly' and in
many cases these things are desirable).

This allows content authors to create pages that use the transitional DTD so
they can include markup for the sake of legacy browsers (eg NS4 and
IE5.0/Windows) while at the same time not having to deal with the nastiness that
is quirks mode (there are all sorts of weird things that happen to layout in
quirks mode).  This also allows content authors who want quirks mode to have a
transitional doctype and get quirks mode while having a page that properly
validates as HTML4.01/Transitional.

See http://www.mozilla.org/docs/web-developer/quirks/doctypes.html, in
particular the part that says:

  The following trigger quirks mode (this list must be comprehensive):
    *  The public identifier "-//W3C//DTD HTML 4.01 Transitional//EN", without a
       system identifier.

In other words, just leaving out the DTD uri from the doctype will get you the
quirks mode you want with the transitional doctype you want while allowing
others to simultaneously design for standards-compliant browsers and legacy
browsers.
Comment 180 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-19 18:03:30 PDT
No, quirks mode should only be invoked on pages that were written before Mozilla
was a known user-agent (i.e., sometime in 2000).  Our current algorithm for mode
determination is the best approximation we have for that.
Comment 181 Elizabeth Lemke 2002-06-19 18:20:25 PDT
Your wrote:


------- Additional Comment #180 From David Baron 2002-06-19 18:03 ------- 

No, quirks mode should only be invoked on pages that were written before Mozilla
was a known user-agent (i.e., sometime in 2000).  Our current algorithm for mode
determination is the best approximation we have for that.


That is just an opinion.  I read this whole bug thread thing and it just says that you use standards mode with 4.01 Transitional because not many web developers were using it.  Now you are arguing that this is fine becuase Moz is a known user agent now?

BS.

All you are really saying is that you don't want to fix it (in fancy language but, that is it)

All I'm going to say is that if you want to keep along this path then you are shooting yourself in the foot,

Note: I've noticed you also blocked this now from being reopened.
Comment 182 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-19 20:18:08 PDT
I'm saying that that was the rationale for the design of quirks and standard mode.
Comment 183 Hixie (not reading bugmail) 2002-06-20 03:16:37 PDT
VERIFIED INVALID -- we are considering a "semi-quirky" transitional mode to
cater for this issue. See bug 153032.
Comment 184 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-24 11:47:58 PDT
*** Bug 153953 has been marked as a duplicate of this bug. ***
Comment 185 Boris Zbarsky [:bz] 2002-06-25 23:22:27 PDT
*** Bug 154316 has been marked as a duplicate of this bug. ***
Comment 186 Jacob Rose 2002-07-04 12:27:54 PDT
My problem with this behavior is that it breaks lots of old pages coded for
Netscape 3.0 and up. For instance, a page I put together when my sister was
hiking the Appalachian Trail: http://whiteshell.com/at/. Today, I would not code
that page the way I did then, but Mozilla shouldn't *change* the way it's
displayed by adding more space where it's not asked for. This essentially
requires everyone who's ever built a web site to go back and re-code it for CSS
- even sites that were built *before* CSS. To me, this makes it a genuine bug
and not simply an academic discussion of CSS standards.
Comment 187 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-07-04 13:02:43 PDT
Marking invalid again.  We're only triggering this behavior on pages that
trigger our full standards mode (see bug 153032 and
http://mozilla.org/docs/web-developer/quirks/ ), so backwards compatibility
isn't really an issue since any pages that trigger that mode should have been
written since Mozilla was a known UA on the web.  (That's the basic idea behind
the DOCTYPE sniffing heuristics.)
Comment 188 Boris Zbarsky [:bz] 2002-07-04 19:15:26 PDT
Jacob, since that page has an XTHML 1.0 Basic doctype, it looks like you've
already done the "go back and re-code it" part... and just did it wrong.

It's not clear why you added that doctype, since that page comes nowhere close
to being anything resembling valid XHTML 1.0 Transitional, much less any other
XHTML doctype...
Comment 189 Hixie (not reading bugmail) 2002-07-05 05:05:07 PDT
reverified for the gazillionth time...
Comment 190 Marc Boullet 2002-07-08 07:46:10 PDT
*** Bug 156244 has been marked as a duplicate of this bug. ***
Comment 191 Kai Lahmann (is there, where MNG is) 2002-07-15 17:03:50 PDT
*** Bug 111643 has been marked as a duplicate of this bug. ***
Comment 192 Travis Bell 2002-07-15 17:47:37 PDT
Created attachment 91429 [details]
Just my example of the "bug."

This is just an exmaple of perfectly legit code, and yet the space that is
created nuder the images. Seems to be a bug to me.
Comment 193 Aaron Kaluszka 2002-07-15 17:56:31 PDT
Travis: that page works fine if you get a newer build.  See bug 153032.
Comment 194 Travis Bell 2002-07-15 19:50:02 PDT
Well call me stupid! :)

I am downloading 1.0 as we speak!

Comment 195 Aaron Kaluszka 2002-07-15 20:10:15 PDT
You'll need something newer than 1.0.  The patch went in after 1.0 was released.
Comment 196 Travis Bell 2002-07-15 21:53:12 PDT
I just downloaded 1.1a, and the descender is still a problem. I thought you had
said it was fixed...?
Comment 197 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-07-15 21:57:03 PDT
You need something newer that 1.1alpha, and newer than 1.0.  (Meaning you'll
need 1.0.1 or 1.1beta, but neither of those have come out yet, so you could
check the nightly builds.)

However, saying it's "fixed" is an exaggeration -- it's just that the quirks
modes have been adjusted so that we have the quirk for bug 5821 on more pages.
Comment 198 Mats Palmgren (vacation) 2002-08-05 08:02:08 PDT
*** Bug 161112 has been marked as a duplicate of this bug. ***
Comment 199 Sébastien Delahaye 2002-08-29 05:59:03 PDT
Could someone change the URL to
http://devedge.netscape.com/viewsource/2002/img-table/ , since the current one
is obsolte?
Comment 200 Boris Zbarsky [:bz] 2002-08-29 19:13:41 PDT
*** Bug 165428 has been marked as a duplicate of this bug. ***
Comment 201 David A. Pérez 2002-09-02 09:13:10 PDT
Hi

I know I'm bad coding XHTML but I cannot be that bad!

The solution for this "bug" in Mozilla 1.0 it's not working all the way, at 
least for me.

Check out http://kamborio.com/

There use to be 3 horizontal lines on the left. The patch has sorted out just 
two of them.

But it is worst, with a window smaller of 700px in width the top of the page 
gets mixed up.

As far as I remember these thing didn't happen with Mozilla 1.0

David A. Pérez
Comment 202 Greg K. 2002-09-16 10:15:18 PDT
*** Bug 168925 has been marked as a duplicate of this bug. ***
Comment 203 Daniel Wang 2002-09-29 20:58:48 PDT
*** Bug 132728 has been marked as a duplicate of this bug. ***
Comment 204 Boris Zbarsky [:bz] 2002-09-30 18:13:44 PDT
*** Bug 171676 has been marked as a duplicate of this bug. ***
Comment 205 Boris Zbarsky [:bz] 2002-10-06 11:49:18 PDT
*** Bug 172864 has been marked as a duplicate of this bug. ***
Comment 206 Boris Zbarsky [:bz] 2002-10-09 23:05:04 PDT
*** Bug 173661 has been marked as a duplicate of this bug. ***
Comment 207 Boris Zbarsky [:bz] 2002-10-10 12:39:28 PDT
*** Bug 168943 has been marked as a duplicate of this bug. ***
Comment 208 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2002-10-16 05:29:07 PDT
*** Bug 174741 has been marked as a duplicate of this bug. ***
Comment 209 Boris Zbarsky [:bz] 2002-10-21 22:35:36 PDT
*** Bug 175880 has been marked as a duplicate of this bug. ***
Comment 210 Boris Zbarsky [:bz] 2002-10-31 09:32:22 PST
*** Bug 177687 has been marked as a duplicate of this bug. ***
Comment 211 Eric A. Meyer (dead account) 2002-12-20 13:11:22 PST
*** Bug 186321 has been marked as a duplicate of this bug. ***
Comment 212 Boris Zbarsky [:bz] 2003-01-15 01:13:22 PST
*** Bug 189163 has been marked as a duplicate of this bug. ***
Comment 213 Eric A. Meyer (dead account) 2003-02-14 08:01:59 PST
*** Bug 193299 has been marked as a duplicate of this bug. ***
Comment 214 Eric A. Meyer (dead account) 2003-02-21 08:04:58 PST
*** Bug 194379 has been marked as a duplicate of this bug. ***
Comment 215 Boris Zbarsky [:bz] 2003-03-10 18:07:30 PST
*** Bug 196765 has been marked as a duplicate of this bug. ***
Comment 216 Boris Zbarsky [:bz] 2003-04-05 15:31:13 PST
*** Bug 200847 has been marked as a duplicate of this bug. ***
Comment 217 Boris Zbarsky [:bz] 2003-04-26 08:45:37 PDT
*** Bug 203437 has been marked as a duplicate of this bug. ***
Comment 218 Boris Zbarsky [:bz] 2003-04-29 11:51:56 PDT
*** Bug 203815 has been marked as a duplicate of this bug. ***
Comment 219 Jo Hermans 2003-05-12 16:05:21 PDT
*** Bug 205416 has been marked as a duplicate of this bug. ***
Comment 220 Madhur Bhatia 2003-05-16 13:41:37 PDT
my ! oh my !
This bug has over 130 bugs duplicated against it. What a number !! 
Comment 221 Jonadab the Unsightly One (Nathan Eady) 2003-05-17 12:11:51 PDT
<qaignore>
> This bug has over 130 bugs duplicated against it.

Yes, that's because (due to the nature of it) it's almost impossible for
people who encounter this issue to figure out what words to use to search
for it in Bugzilla.  DOM Inspector shows the extra whitespace as belonging
to the child element, but it is the line-height of the parent element that
has to be set to 0 to get the behavior most of the people filing dupes are
looking for.  This makes it hard for people to find the bug in a query, so
they file dupes.  Additionally, the inline box model is very poorly 
understood in general by most folks, because AFAIK none of the major HTML
tutorials (not even the good ones, like at w3schools) cover it.  And the
official spec scares people, so they don't read it.  (I didn't...)

I wouldn't worry about it.  130 dupes is a lot, yes, but very few issues
are so hard to summarise as this one, and that's why.
</qaignore>
Comment 222 Boris Zbarsky [:bz] 2003-07-22 10:55:37 PDT
*** Bug 213431 has been marked as a duplicate of this bug. ***
Comment 223 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-08-14 11:31:02 PDT
*** Bug 216185 has been marked as a duplicate of this bug. ***
Comment 224 Bernd 2003-08-17 06:08:54 PDT
*** Bug 216446 has been marked as a duplicate of this bug. ***
Comment 225 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-09-19 16:55:40 PDT
*** Bug 219742 has been marked as a duplicate of this bug. ***
Comment 226 Hixie (not reading bugmail) 2004-01-05 07:26:18 PST
*** Bug 230102 has been marked as a duplicate of this bug. ***
Comment 227 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2004-01-20 14:25:43 PST
*** Bug 231653 has been marked as a duplicate of this bug. ***
Comment 228 Joe Mooney 2004-01-21 07:58:27 PST
Created attachment 139575 [details]
Drop down list items use much more length then allotted for drop down list

This bug description seems to match what I am seeing.  Here is an example
website
http://www.plantronics.com.  Click on a drop down menu and the list items are
completely off the alloted drop down list space.

Only Mozilla browser seems to have this problem (under both Windows and Linux).
 Tried using Konquerer (which uses Gecko engine?) and it works fine.  Also
works fine with Internet Explorer.
Comment 229 Hixie (not reading bugmail) 2004-01-21 13:17:23 PST
The last attachment appears to be an executable.

Note that both Safari and the next version of Opera do this just like Mozilla.
Comment 230 Boris Zbarsky [:bz] 2004-03-16 09:03:57 PST
*** Bug 237644 has been marked as a duplicate of this bug. ***
Comment 231 Boris Zbarsky [:bz] 2004-04-15 15:39:38 PDT
*** Bug 240617 has been marked as a duplicate of this bug. ***
Comment 232 tom.williams 2004-04-19 15:46:11 PDT
(In reply to comment #228)
> Created an attachment (id=139575)
> Drop down list items use much more length then allotted for drop down list
> 
> This bug description seems to match what I am seeing.  Here is an example
> website
> http://www.plantronics.com.  Click on a drop down menu and the list items are
> completely off the alloted drop down list space.
> 
> Only Mozilla browser seems to have this problem (under both Windows and Linux).
>  Tried using Konquerer (which uses Gecko engine?) and it works fine.  Also
> works fine with Internet Explorer.

I just tried this site in Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.8a) Gecko/20040416 Firefox/0.8.0+) and it rendered and behaved just
like IE 6 on Windows.  Did the site change or did Mozilla change?

Peace...
Comment 233 Peter Grabner 2004-04-19 16:52:58 PDT
because strict standard mode handles the img
(when display:inline (default on img)) like font

..depending on font-size and line-heigth it produces
the additional space before and after the image
- the container (div) gets the heigth of a "font-line"

the image starts (by default) at the baseline of the font
- you can set vertical-align:top; on the img
.. and the img starts at the top

-> in that case the added space is NOW left UNDER the image

you have to do something more because
of the heigth of the container (div)

it could affect problems with some javascript-code
due to that extended heigth there can be a problem with a link on that
("link-sensitive-area" can get larger than the image itself)

****
i found out two solutions (i for myself generate easy with php):

1. solution (as inline) accepts the code before "text-align:center;" etc.:

<div style="line-heigth:0;">
<img style="vertical-align:top;" .....
</div>

2. solution is to make the image a block;

<div style="">
(to style you can set width (width:100%;) for additional "centering" etc.
because block works not with text-align)

<img style="display:block;" ..... 
(style can be added with: margin: auto auto; for "centering" etc.

</div>

DID NOT WATCH YOUR SITE..
.. with <li> elements at least the leading additional space works the same, thoght.

.. as i "learned" that all is not a bug
its a standard-definition and wanted for some reasons
(for myself i think its hard - and i had tried to go another way with standard -
at least a disable-property for a softer web-code change, - and less need to
discussions)

peace too
peter grabner
Comment 234 Peter Grabner 2004-04-19 17:17:49 PDT
dont missunderstand me..

i know MOZILLA IS THE BEST BROWSER, and i know i have "nerved" some people as i
have followed that problem..

..but beside all that css definitions and c++ gurus there are a lot of that
"chaotic creatives" "web-coder" like me.

..think that microsoft laughs about, when out there people tell,
with ie it where much easier and opera.

if so much people work on that "bug" that isnt one,
..here and out there
there is need for easy help or information.

if BUGZILLA.MOZILLA is not the place for that, as i learned,
.. its the web, it could link to information,
to solve (or disable-property).
Comment 235 Christian :Biesinger (don't email me, ping me on IRC) 2004-05-24 04:28:07 PDT
*** Bug 244494 has been marked as a duplicate of this bug. ***
Comment 236 Boris Zbarsky [:bz] 2004-07-14 03:57:09 PDT
*** Bug 251330 has been marked as a duplicate of this bug. ***
Comment 237 Bill Mason 2004-07-27 08:52:08 PDT
*** Bug 253271 has been marked as a duplicate of this bug. ***
Comment 238 Florian Idelberger 2004-08-21 16:46:37 PDT
It also happens if you do a newline after an image on the same level, like you
can see here www.evergreenbusiness.de/dgc/index-bug.xhtml
otherwise, the given page is strictly xhtml 1.0 compliant.
Comment 239 Anne (:annevk) 2004-09-06 11:45:33 PDT
*** Bug 258198 has been marked as a duplicate of this bug. ***
Comment 240 Bill Mason 2004-09-23 19:17:21 PDT
*** Bug 261316 has been marked as a duplicate of this bug. ***
Comment 241 Bill Mason 2004-09-25 21:31:30 PDT
*** Bug 261609 has been marked as a duplicate of this bug. ***
Comment 242 Andrew Schultz 2004-10-12 22:37:25 PDT
*** Bug 264136 has been marked as a duplicate of this bug. ***
Comment 243 Boris Zbarsky [:bz] 2004-10-25 21:57:53 PDT
*** Bug 265666 has been marked as a duplicate of this bug. ***
Comment 244 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-03 13:43:29 PST
*** Bug 273030 has been marked as a duplicate of this bug. ***
Comment 245 Boris Zbarsky [:bz] 2004-12-07 16:03:54 PST
*** Bug 271884 has been marked as a duplicate of this bug. ***
Comment 246 Bernd 2004-12-08 22:08:04 PST
*** Bug 273811 has been marked as a duplicate of this bug. ***
Comment 247 Mats Palmgren (vacation) 2005-01-02 02:32:04 PST
*** Bug 276739 has been marked as a duplicate of this bug. ***
Comment 248 José Jeria 2005-01-20 04:32:18 PST
*** Bug 279082 has been marked as a duplicate of this bug. ***
Comment 249 Peter Friis Jensen 2005-01-21 21:43:14 PST
(In reply to comment #162)
I have not been able to find a workaround for my site
http://xfriis.dk/maxfriis/bg/opening.html via this discusion.

<div style="line-heigth:0;">
<img style="vertical-align:top;" .....
</div>

still leaves some spaces and

display:block; puts everything on top of each other like
http://xfriis.dk/maxfriis/bg/openingdb.html (will be deleted in one month sorry)

The only solution I know is still to work on the code substituting <td> <img
.../> </td> with <td><img .../></td> messing up my code readability.

You can say that what I'm doing on my site is not the right method using all
thouse small images to generate a larger image, but I think that should be no
problem.
Comment 250 Brian 'netdragon' Bober 2005-02-01 10:27:36 PST
Peter: Have you tried display: table-cell or float:left and then eventually
clear:both?
Comment 251 José Jeria 2005-02-05 11:43:00 PST
*** Bug 281191 has been marked as a duplicate of this bug. ***
Comment 252 Mats Palmgren (vacation) 2005-07-19 16:25:58 PDT
*** Bug 301373 has been marked as a duplicate of this bug. ***
Comment 253 Timwi 2005-07-21 09:05:38 PDT
(In reply to comment #249)
> 
> <div style="line-heigth:0;">
> <img style="vertical-align:top;" .....
> </div>
> 
> still leaves some spaces

That's because you have misspelt "line-height".
Comment 254 Peter Grabner 2005-07-21 10:59:52 PDT
Thanks TIMWI ! that was old stuff.

- BUT EVEN with the right spelling it was the same.
ANYWAY that all the "extra-space" was really NO BUG.
like me - lots of people have missunderstood the css-definition.
(lots of long discussions and bug-duplicates)

see also - that - #17 - that all is no bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=240886

to go with the definition - and remove "the extra space":

1. solution - elm inline
<div style="line-height:0;">
<img style="vertical-align:top;" .....
</div>

2. solution is to make the image a block;
<div style="">
<img style="display:block;" ..... 
</div>
Comment 255 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-07-24 19:49:39 PDT
*** Bug 301919 has been marked as a duplicate of this bug. ***
Comment 256 Erik Fabert 2005-07-26 12:26:03 PDT
*** Bug 302228 has been marked as a duplicate of this bug. ***
Comment 257 Mats Palmgren (vacation) 2005-07-31 08:27:09 PDT
*** Bug 301373 has been marked as a duplicate of this bug. ***
Comment 258 Ed DeFinis 2005-07-31 10:01:48 PDT
My test results indicated that the problem is related to DOCTYPE XHTML 1.x
The spacing worked fine with DOCTYPE HTML 4.01 or with no DOCTYPE at all.
See for yourself; visit
http://www.hinkleyauto.com/pdfs/pdf_slices.html (using no Doctype)
http://www.hinkleyauto.com/pdfs/pdf_slices_HTML_41.html (using DOCTYPE HTML 4.01)
http://www.hinkleyauto.com/pdfs/pdf_slices_XHTML_11.html (using DOCTYPE XHTML 1.1)





















Comment 259 bjoern.winkler 2005-10-28 05:21:12 PDT
*** Bug 314090 has been marked as a duplicate of this bug. ***
Comment 260 Phil Ringnalda (:philor, back in August) 2005-12-25 22:36:17 PST
*** Bug 320745 has been marked as a duplicate of this bug. ***
Comment 261 Andrew Schultz 2006-03-13 22:32:21 PST
*** Bug 330405 has been marked as a duplicate of this bug. ***
Comment 262 Phil Ringnalda (:philor, back in August) 2006-05-08 17:49:59 PDT
*** Bug 337194 has been marked as a duplicate of this bug. ***
Comment 263 Jesse Ruderman 2006-11-27 11:47:51 PST
*** Bug 361988 has been marked as a duplicate of this bug. ***
Comment 264 Jonathan Watt [:jwatt] (catching up after vacation) 2007-11-23 10:57:27 PST
*** Bug 405116 has been marked as a duplicate of this bug. ***
Comment 265 Robert Longson 2007-12-09 01:04:26 PST
*** Bug 407549 has been marked as a duplicate of this bug. ***
Comment 266 Jesse Ruderman 2008-01-28 08:51:37 PST
*** Bug 414377 has been marked as a duplicate of this bug. ***
Comment 267 Daniel.S 2008-03-23 15:00:59 PDT
*** Bug 240617 has been marked as a duplicate of this bug. ***
Comment 268 Robert Longson 2010-04-22 09:41:58 PDT
*** Bug 561114 has been marked as a duplicate of this bug. ***
Comment 269 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2010-05-02 15:52:02 PDT
*** Bug 561624 has been marked as a duplicate of this bug. ***
Comment 270 marco 2010-05-06 02:04:42 PDT
(In reply to comment #2)
> Removing the DOCTYPE (strict dtd) makes the testcase look OK.
> Also tested with IE5 on NT, which renders the page/testcase fine.

sfdf dfdsfsdfsdf
Comment 271 Alexander K 2010-05-14 07:22:35 PDT
Stop bothering developers with this minor problem, you are the only one, who has it.”.
Comment 272 lijianan 2010-05-15 23:59:26 PDT
今天2010 5 16 提交的日志
Comment 273 Jo Hermans 2010-05-21 14:41:05 PDT
excuses for comment 271, some is spamming various bugs, see bug 567347
Comment 274 neethu 2010-07-16 23:34:19 PDT
Test comment on 17/07/2010
Comment 275 neethu 2010-07-16 23:35:18 PDT
Please ignore previous comment
Comment 277 gurusathy 2010-07-29 02:07:43 PDT
has been marked as a duplicate of this bug
Comment 278 gurusathy 2010-07-29 02:11:16 PDT
has been marked as a duplicate of this bug
Comment 280 sandeep 2010-11-06 04:32:02 PDT
Executed TC 45 & was reproducible in IE 7 & Google chromo.
Comment 281 sandeep 2010-11-06 04:33:13 PDT
Since the Status of Defect is aleardy OPEN(means Devel team is already working on),made a note
Comment 283 marginleft 2011-03-16 08:09:30 PDT
oh.the bug is so long...it works for 10+ years
Comment 284 prince pal 2011-03-20 05:26:01 PDT
Comment on attachment 3692 [details]
Testcase

good
Comment 285 Boris Zbarsky [:bz] 2012-02-02 13:06:29 PST
*** Bug 723661 has been marked as a duplicate of this bug. ***
Comment 286 Boris Zbarsky [:bz] 2014-03-19 19:00:22 PDT
*** Bug 985616 has been marked as a duplicate of this bug. ***
Comment 287 Musab 2016-02-23 23:48:18 PST Comment hidden (spam)

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