Closed Bug 22274 Opened 25 years ago Closed 23 years ago

[INLINE] Too much space (for descenders) under image (<img>) elements, e.g. in table cells

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: mpalczew, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(6 files)

Testcase
520 bytes, text/html
Details
frame dumps with and without strict DocType statement
2.22 KB, text/plain
Details
Testcase
941 bytes, text/html
Details
Testcase without the display: block
923 bytes, text/html
Details
Just my example of the "bug."
2.27 KB, text/html
Details
Drop down list items use much more length then allotted for drop down list
143.12 KB, text/html
Details 
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.
Attached file Testcase — 
Whiteboard: [TESTCASE]

    
    

    
  
Removing the DOCTYPE (strict dtd) makes the testcase look OK.
Also tested with IE5 on NT, which renders the page/testcase fine.

    
  
Assignee: troy → kipp

    
    

    
  
Block/line layout issue

    
  
Summary: there is a space between table elements → [BLOCK] there is a space between table elements
Target Milestone: M15

    
    

    
  
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.

    
    

    
  
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

    
    

    
  
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster

    
    

    
  
*** Bug 33702 has been marked as a duplicate of this bug. ***

    
    

    
  
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

    
    

    
  
Won't make beta2 if it stays on my list.  Moving to M18.
Status: NEW → ASSIGNED
Target Milestone: M16 → M18

    
    

    
  
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19

    
    

    
  
tables are not involved.  changing summary.  about to attach partial frame dumps 
illustrating the problem
Summary: [BLOCK] there is a space between table elements → [BLOCK] there is a space between image elements

    
    

    
  
I'm 90% sure this is a dup of 19956

    
  
Blocks: 19956

    
    

    
  
this also looks like a line height issue in standard mode only.  Assigning to 
David (along with probably dup 19956)
Assignee: buster → dbaron
Status: ASSIGNED → NEW

    
    

    
  
*** Bug 18941 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 19956 has been marked as a duplicate of this bug. ***

    
    

    
  
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).)
Summary: [BLOCK] there is a space between image elements → [INLINE] space for descenders under image elements

    
    

    
  
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.)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID

    
    

    
  
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

Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: PC → All
Whiteboard: [TESTCASE]

    
    

    
  
*** Bug 40355 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 44978 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 46299 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
try:

img { display: block; }

to fix the problem you described.

    
    

    
  
*** Bug 48520 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 46970 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 51518 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 63715 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 64487 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 65365 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 65514 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 67311 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 68562 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 69083 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 70079 has been marked as a duplicate of this bug. ***

    
    

    
  
Opera 5.0b6 does not have this bug.
MSIE5.5 does not have this bug.
Adding mostfreq keyword. (16 dups and counting)

Keywords: mostfreq

    
    

    
  
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

    
    

    
  
*** Bug 70151 has been marked as a duplicate of this bug. ***

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase
        — 
      

    


  

    
    

    
  
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.



    
    

    
  
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.

    
    

    
  
*** Bug 71913 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 59227 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 47165 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 74708 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 75529 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 77692 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 78000 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 80360 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 80474 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 80590 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  
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?

    
    

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

    
    

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

    
    

    
  
*** Bug 47165 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 82600 has been marked as a duplicate of this bug. ***

    
    

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


    
    

    
  
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.

    
    

    
  
*** Bug 83955 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 86935 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 87800 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
*** Bug 89012 has been marked as a duplicate of this bug. ***

    
    

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


    
    

    
  
*** Bug 89384 has been marked as a duplicate of this bug. ***

    
    

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

    
    

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

    
    

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


    
    

    
  
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.

    
    

    
  
*** Bug 89482 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
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. 

    
    

    
  
*** Bug 89307 has been marked as a duplicate of this bug. ***

    
    

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

    
    

    
  
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!

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
*** Bug 89857 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 96183 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 96424 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 95603 has been marked as a duplicate of this bug. ***

    
    

    
  
Resummarising to make it more clear what this is on duplicates.cgi. If I've
resummarised incorrectly, please correct my correction :-)

Gerv
Summary: [INLINE] space for descenders under image elements → [INLINE] Too much space (for descenders) under image elements

    
    

    
  
*** Bug 97801 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 97804 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 90798 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 98628 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 101708 has been marked as a duplicate of this bug. ***

    
    

    
  
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.



    
    

    
  
Don't see this with a Win98 build from two days ago (2001100103).

    
    

    
  
*** Bug 103109 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 103108 has been marked as a duplicate of this bug. ***

    
    

    
  
Isn't this the same bug than 81698?


    
    

    
  
*** Bug 105617 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 105617 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 106252 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 105652 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
*** Bug 107563 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 107774 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 107942 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 108444 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 109547 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 110058 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 110408 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 111452 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 113048 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 114159 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 116668 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 20575 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 119189 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 119339 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 122620 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 123856 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 123979 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 124811 has been marked as a duplicate of this bug. ***

    
    

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

    
    

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

    
    

    
  
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

    
    

    
  
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 ?

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
*** Bug 125901 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 126519 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 126579 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 127023 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 129948 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 130056 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 130669 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 131200 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 131591 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 132520 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 132706 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

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

    
    

    
  
*** Bug 133198 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 126848 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 135096 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 96297 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 111643 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 139409 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 139409 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 139966 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
*** Bug 141506 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 141604 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142037 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142600 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 143652 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 126219 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 144199 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
Gunnar, this is marked "VERIFIED INVALID".  That means "This is not a bug, but
correct behavior."

    
    

    
  
*** Bug 146273 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147906 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 151823 has been marked as a duplicate of this bug. ***

    
    

    
  
See bug 151620, where this behavior is being reconsidered (perhaps only partly).

    
    

    
  
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)
Status: VERIFIED → REOPENED
Resolution: INVALID → ---

    
    

    
  
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.

Status: REOPENED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → INVALID

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
I'm saying that that was the rationale for the design of quirks and standard mode.

    
    

    
  
VERIFIED INVALID -- we are considering a "semi-quirky" transitional mode to
cater for this issue. See bug 153032.
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 153953 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 154316 has been marked as a duplicate of this bug. ***

    
    

    
  
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.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---

    
    

    
  
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.)
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID

    
    

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

    
    

    
  
reverified for the gazillionth time...
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 156244 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 111643 has been marked as a duplicate of this 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.

    
    

    
  
Travis: that page works fine if you get a newer build.  See bug 153032.

    
    

    
  
Well call me stupid! :)

I am downloading 1.0 as we speak!



    
    

    
  
You'll need something newer than 1.0.  The patch went in after 1.0 was released.

    
    

    
  
I just downloaded 1.1a, and the descender is still a problem. I thought you had
said it was fixed...?

    
    

    
  
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.

    
    

    
  
*** Bug 161112 has been marked as a duplicate of this bug. ***

    
    

    
  
Could someone change the URL to
http://devedge.netscape.com/viewsource/2002/img-table/ , since the current one
is obsolte?

    
    

    
  
*** Bug 165428 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
*** Bug 168925 has been marked as a duplicate of this bug. ***

    
  
Blocks: majorbugs

    
  
No longer blocks: 19956

    
    

    
  
*** Bug 132728 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 171676 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 172864 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 173661 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 168943 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 174741 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 175880 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 177687 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 186321 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 189163 has been marked as a duplicate of this bug. ***

    
  
Blocks: 168782

    
    

    
  
*** Bug 193299 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 194379 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 196765 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 200847 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 203437 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 203815 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 205416 has been marked as a duplicate of this bug. ***

    
    

    
  
my ! oh my !
This bug has over 130 bugs duplicated against it. What a number !! 


    
    

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

    
    

    
  
*** Bug 213431 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 216185 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 216446 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 219742 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 230102 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 231653 has been marked as a duplicate of this bug. ***

    
    

    
  


  
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.

    
    

    
  
The last attachment appears to be an executable.

Note that both Safari and the next version of Opera do this just like Mozilla.

    
    

    
  
*** Bug 237644 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 240617 has been marked as a duplicate of this bug. ***

    
    

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

    
    

    
  
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

    
    

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

    
    

    
  
*** Bug 244494 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 251330 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 253271 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 258198 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 261316 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 261609 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 264136 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 265666 has been marked as a duplicate of this bug. ***
Summary: [INLINE] Too much space (for descenders) under image elements → [INLINE] Too much space (for descenders) under image (<img>) elements

    
    

    
  
*** Bug 273030 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 271884 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 273811 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 276739 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 279082 has been marked as a duplicate of this bug. ***

    
    

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

    
    

    
  
Peter: Have you tried display: table-cell or float:left and then eventually
clear:both?

    
    

    
  
*** Bug 281191 has been marked as a duplicate of this bug. ***

    
  
No longer blocks: majorbugs

    
    

    
  
*** Bug 301373 has been marked as a duplicate of this bug. ***

    
    

    
  
(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".

    
    

    
  
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>

    
    

    
  
*** Bug 301919 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 302228 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 301373 has been marked as a duplicate of this bug. ***

    
    

    
  
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)























    
    

    
  
*** Bug 314090 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 320745 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 330405 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 337194 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 361988 has been marked as a duplicate of this bug. ***

    
  
Summary: [INLINE] Too much space (for descenders) under image (<img>) elements → [INLINE] Too much space (for descenders) under image (<img>) elements, e.g. in table cells

    
    

    
  
(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

    
    

    
  
Stop bothering developers with this minor problem, you are the only one, who has it.”.

    
    

    
  
今天2010 5 16 提交的日志

    
    

    
  
excuses for comment 271, some is spamming various bugs, see bug 567347

    
    

    
  
Test comment on 17/07/2010

    
    

    
  
Please ignore previous comment

    
    

    
  
has been marked as a duplicate of this bug

    
    

    
  
has been marked as a duplicate of this bug

    
    

    
  
Executed TC 45 & was reproducible in IE 7 & Google chromo.

    
    

    
  
Since the Status of Defect is aleardy OPEN(means Devel team is already working on),made a note

    
    

    
  
oh.the bug is so long...it works for 10+ years

    
    

    
  
Comment on attachment 3692 [details]
Testcase

good

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: