37656 - moz handles <td><img><img></td> differently than ns4x/ie

Status: VERIFIED DUPLICATE of bug 32191

(Core :: Layout, defect, P2)

Description

[Andrew]

From Bugzilla Helper:
BuildID:    2000042809

Background images are rendered/tiled? incorrectly. Selecting areas
causes it to clear up a bit sometimes.


Reproducible: Always
Steps to Reproduce:
1. Goto www.lego.com

Comment 1

[Jesse Ruderman]

Confirming; will try to simplify.  May be bug 15943, but adding a doctype 
doesn't help.

Comment 2

[Jesse Ruderman]

Attachment: testcase (kept disparity between IE and moz, but not NS4x and moz)

Comment 3

[Jesse Ruderman]

Attachment: another test case. ns4x and ie agree this time.

Comment 4

[Jesse Ruderman]

(Based on some of my comments in the first testcase)

The question seems to be whether the two images with no whitespace between 
their tags are placed side-by-side or bottom-to-top inside a td.  IE and NS 
leave them side-by-side, but Moz splits them up (unless a <nobr> tag is 
added).  

The table and td elements don't all specify height/width, which is probably a 
major reason why the browsers disagree (I didn't test this aspect very 
rigorously).

Comment 5

[Jesse Ruderman]

I'm using windows and reporter used linux, so assuming all/all.  Updating 
summary and adding 4xp (netscape 4.x parity = mozilla and ns4.x don't agree) 
keyword.

I wasn't able to reproduce "Selecting areas causes it to clear up a bit 
sometimes."

Comment 6

[karnaze (gone)]

Buster, this is that nasty compatibility problem I mentioned before. IE achieves 
better compatibility than us in some cases because they treat adjacent images 
with no whitespace between them as a non separable unit.

I'll mark this M18 and you need to decide if this can ever be fixed. I can't see 
how tables can fix the compatibility problem.

Comment 7

[karnaze (gone)]

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

Comment 8

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 9

[buster]

definately not a table issue.  This is a nasty quirk.  basically, it means that 
consecutive images (really consecutive, no whitespace) need to be treated as a 
single inline object for purposes of formatting lines, but not for other things 
(like drawing borders.)

Comment 10

[karnaze (gone)]

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

Comment 11

[karnaze (gone)]

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

Comment 12

[karnaze (gone)]

Buster, please note that bug 14323 has a bunch of test cases and duplicates of 
its own and pre-dates this bug. I could have duped the other way around, but 
this bug report is a bit cleaner.

Comment 13

[karnaze (gone)]

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

Comment 14

[Peter "jag" Annema]

buster, I think this is a dupe of 32191 (or the other way around, leaving that 
up to you), which deals with the same thing, except instead of the second image 
it has "normal" text.

In general, an img is inline content, and in general, line-breaks for inline 
content only happen at whitespace (though it's really up to the User Agent).

|<img><img>|, |<img>text| and |<img><span>text</span>| should all be treated the 
same: no line-breaks.

Comment 15

[Christine Hoffman]

If this is not table specific, can the component be changed to 'HTML element'?

Comment 16

[Peter "jag" Annema]

Nope, not table specific, this is an inline content wrap issue.

Changing component.

Comment 17

[Christine Hoffman]

Changing QA contact to [e-mail] as this bug is not table specific; 
rather the problem is with images.

Comment 18

[buster]

It's really a core layout issue, changing component to "Layout"
Probably a dup of one I'm already looking at...

Comment 19

[buster]

I think this is a quirk that we should not try to emulate.
What we are dealing with here is an over-constrained situation.  The images are 
within a container (a table cell) that is not wide enough to hold both images.  
So, we naturally break the images into two different lines.
Nav 4 also breaks between images.  
IE 5 forces the images to stay together.  In other words, multiple images 
without spaces between the markup act as an indivisible unit.
IE's behavior can easily be mimiced by adding a <NOBR> tag around the images.  
Likewise, Nav's behavior could be mimiced by adding spaces between elements.

Worse yet, Nav treats consecutive images are a single unit for purposes of 
measuring table cells.  In our vocabulary, Nav pretends the max-element-size 
(the minimum possible width) of two consecutive images as the sum of the image 
widths.  However, in some situations Nav happily violates this constraint.  We 
have no easy way to mimic this behavior.
Since the two are different, and one is not better or more expressive than the 
other, I say we should stick with what we have.  We are more like Nav, but with 
the rationalization that we measure table cell widths based on the fact that 
images are allowed to break.

So, the real problem is the html source is not rational...table cell widths are 
over-constrained for the content within them.  This clearly isn't the author's 
intent.

ekrock, this will mean we need some evangelical love spread to the sites who 
rely on this quirk.

I am leaving this bug open for now.  Discussions should take place on the 
newsgroup.  I'll start the thread...

Comment 20

[buster]

Attachment: a much more detailed test case

Comment 21

[Peter "jag" Annema]

<nobr> is an invalid HTML tag. This doesn't sound like a good suggestion. Talk
about evangelizing :-) <span style="white-space:nowrap"> was suggested.

Comment 22

[Jesse Ruderman]

Is that written as <nobr><span style="white-space:nowrap"> or as <span 
style="white-space:nowrap"><nobr>?

Comment 23

[Peter "jag" Annema]

Actually, it should be used instead of, so <span style="white-space:nowrap">not
to be wrapped content</span>. Of course, this may not be backward compatible,
but in this specific case, i.e. adding it where it wasn't before, specifically
to make Mozilla happy, I don't think that's an issue. Of course, whether you use
invalid tags or not is completely up to you, but we shouldn't be recommending
it, was my point.

Comment 24

[Chris Waterson]

see also bug 32191.

Comment 25

[ekrock's old account (dead)]

Agree with Buster's analysis. This should be WONTFIX in terms of modifying 
Gecko. Reassigning to [e-mail] and Evangelism component for 
evangelism of lego.com.

Comment 26

[timeless]

Ok so how is he supposed to evangelize this one?
Assuming <nobr> is taboo and that our parser or some other validating parser 
will complain or shread the document.
Is the http server supposed to see <nobr> and serve <span 
style="white-space:nowrap"> instead and replace </nobr> w/ </span>
[But only for anal browsers like mozilla]

Actually, if all old browsers misbehave by assuming <nobr>arround images w/o 
spaces then all we need to do is recommend: <span 
style="white-space:nowrap"><img><img></span>.

Marking relnotertm, once we decide how we want people to handle our WONTFIX bug 
we need to explain it in the release notes.

Hixie: is there a W3 recommended way to be compatible?

Comment 27

[Hixie (not reading bugmail)]

timeless: sure, stick white-space:nowrap on the container, probably the cell.

However, the real W3 way is to not use tables and images for layout. So...

Comment 28

[buster]

Ian's got it right.  Marking WontFix

Comment 29

[Braden]

Reopening; changing component. This is not an evangelism issue. While it may be
arguable as to whether Gecko's current behavior conforms to HTML 4, it is quite
clear that *not* breaking "<img><img>" *is* conforming. So what's to evangelize?
Are we going to try to convince Web authors to adopt a Mozilla peculiarity
instead of an (already well-established) IE peculiarity? No, the Right Thing is
for Mozilla to follow the established standard conforming practice.

 * Since that is the mode of operation of the dominant browser, Gecko ought to
emulate it.

 * Allowing consecutive images with no visible space between them is possible
with a zero-width space, and how this should behave is unambiguous in the HTML4
spec.

Comment 30

[Braden]

This is pretty surely a duplicate of 32191 rather than a dependency.

*** This bug has been marked as a duplicate of 32191 ***

Comment 31

[ekrock's old account (dead)]

I need to clarify one point here just to make certain we're all on the same 
page--and I think we are. 

First of all, I'm taking no position on the question of what the HTML 4.0 spec 
says would be the right thing about this particular markup; on that I defer to 
others who have greater expertise. Second, as a mozilla community volunteer, 
Blake is of course free to decide on what issues he will/won't spend his time.

Here's the point I need to clarify: with regards to this comment: "the Right 
Thing is for Mozilla to follow the established standard conforming practice.
 * Since that is the mode of operation of the dominant browser, Gecko ought to
emulate it." 

Summarized, the argument there is that "the IE rendering control has the highest 
market share at the current time, therefore Gecko's goal should be to match its 
behavior."

As an FYI, that is not the philosophy guiding the design of the Gecko browser 
engine, the open source Mozilla browser, or branded Netscape 6. The goal of the 
project has been (1) to comply with the de jure web standard specifications as 
written, in response to requests for standards compliance from the web developer 
community, and (2) to the extent possible permitted by (1), provide backward 
compatibility with existing web content wherever possible. Where IE violates a 
standard, we're going to comply with the standard, not IE. 

Keep in mind that: (a) market share for browser engines has changed in the past 
and could change again going forward, (b) IE's behavior has changed in the past 
and could change again going forward, and (c) only written standards provide the 
stable foundation free of individual vendor interests that developers can rely 
upon.

We're of course not going to try to create gratuitous incompatibilities with 
IE. Also, if there's no standard for a given issue, and no previous de facto 
behavior standard established by previous browsers, I have no problem with 
matching IE's behavior and have advocated doing so on numerous issues like 
client sniffer strings and the like. But our goal is standards compliance first, 
backward compatibility with existing content wherever possible second--and we've 
put great effort into that via quirks mode and DOCTYPE sniffing.

Comment 32

[Braden]

"the IE rendering control has the highest market share at the current time,
therefore Gecko's goal should be to match its behavior."

That is not an accurate summary, though I can see how you might have drawn that
conclusion if you aren't familiar with my comments on this in the layout
newsgroup.

"the IE rendering control has the highest market share at the current time,
therefore a goal of Gecko should be to match its behavior *where it conforms to
the HTML 4 specification*."

That is an accurate summary.

I think the consensus is that the spec is slightly gray on exactly what should
happen here. But AFAIK, no one has posited that IE is not conforming here. Quite
the contrary, IE appears to have extrapolated the text flow rules described in
the spec to cover this case.

Comment 33

[Loco]

Verifying DUPLICATE.

Comment 34

[Jesse Ruderman]

> Summarized, the argument there is that "the IE rendering control has the
> highest market share at the current time, therefore Gecko's goal should be to 
> match its behavior."

Netscape 4.x has behavior similar to IE's in this case, so that isn't a perfect 
argument.

Whatever Mozilla decides what to do with the page, it should also warn the user 
that the page is ambiguous.

Comment 35

[Christian Mattar]

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