130116 - text-indent should affect shrink wrapping

Status: RESOLVED FIXED

(Core :: Layout, defect, P4)

Description

[Eugene Savitsky]

<table border=1><tr><td> 
<p style="margin-left: 30px; text-indent: -10px;">Line1
<p style="margin-left: 10px; text-indent: 10px;">Line2
</td></tr></table>

Look at the attach. IE shows it different. Who's wrong?

moz 2002030703

Comment 1

[Eugene Savitsky]

Attachment: the test file

Comment 2

[Boris Zbarsky [:bzbarsky]]

Could you attach screenshots of what you see with IE and Mozilla?  I see what
looks like correct rendering in Mozilla here... (the two lines are exactly lined
up).

Comment 3

[Eugene Savitsky]

In IE the lines are aligned to the right of table, but in moz they are more
centered.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Ah, OK.  That would be because the text-indent does not, and should not, imo,
affect the sizing of the <p> it's applied to.

Ian, is that correct?

Comment 5

[Hixie (not reading bugmail)]

That depends on whether the P is being shrink wrapped or not.

I'd say this is valid -- in the following examples, the box is being
shrinkwrapped, like in the table case here. The notch in the bottom border, and
the dotted area, represent the margin (or padding) that the text (or box) has.


In the first case, no text-indent:
  +------------------------+
  |::::::::TEXTTEXTTEXTTEXT|
  +-------'----------------+

Next case, positive text-indent:
  +----------------------------+
  |::::::::    TEXTTEXTTEXTTEXT|
  +-------'--------------------+

Final case, negative text-indent:
  +--------------------+
  |::::TEXTTEXTTEXTTEXT|
  +-------'------------+

Seems to me like IE is doing the right thing, and we are not. No?

Comment 6

[DStile]

Reporter: is this still happening with Moz 1.0 RC1 or a Current Nightly Build?

As far as I can tell, IE6 and Moz 1.0RC1 handle this case in exactly the same
way now (attaching screenshots).  If that is indeed the case, I suggest that
someone who has the power to do so please change status to RESOLVED.

Part of the reason I was at first confused is that the FIRST LINE of BOTH
PARAGRAPHS should have the same TOTAL margin: 

PARAGRAPH 1, 30px(left-margin) -10px (indent) = 20 px
PARAGRAPH 2, 10px(left-margin) +10px (indent) = 20 px

However, if there were susequent lines of text in these paragraphs they would
have different margins, since every line after the first is not indented- but
like I said, there are no lines after the first- if there were, they would have
margins of 30 and 10px respectively.  Am attaching html file to show what
happens to subsequent lines of text...

Comment 7

[DStile]

Attachment: Screenshot of how Moz1.0RC1 handles page

Comment 8

[DStile]

Attachment: Screenshot of how IE6.0 handles page

Comment 9

[DStile]

Attachment: Multiple-line test file

Comment 10

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

The difference between the two screenshots is the position of the right edge of
the table.

Comment 11

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

Comment on attachment 83160 [details]
Multiple-line test file

This testcase is unrelated to the bug.

Comment 12

[DStile]

Ah, OK, I see what you mean now- if I make this other testcase (just pretend
that the other never existed, OK?), it shows how Moz is handling the
shrinkwrapping in the two cases differently:

Have put both paragraphs within their own tables to show the diffence- IE6
handles both lines the same- Moz adds extra space to Line1 but appears to handle
Line2 correctly...

Comment 13

[DStile]

Attachment: This shows each paragraph within it's own table

Comment 14

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

Attachment: proposed fix

This fixes the bug.  It should also fix bug 45694, although I haven't tested
that yet.  It's the least ugly solution I could think of at the moment
(although it's not really that bad).

Comment 15

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

Taking bug.

Comment 16

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

Attachment: slightly cleaner fix

Slightly cleaner fix.  I did check, and this does also fix bug 45694.

Comment 17

[Chris Waterson]

Comment on attachment 83168 [details] [diff] [review]
slightly cleaner fix

sr=waterson. very nice.

Comment 18

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

As waterson points out, bug 140682 and bug 91468 seem to be the same and/or very
similar.

Comment 19

[Marc Attinasi]

Comment on attachment 83168 [details] [diff] [review]
slightly cleaner fix

r=attinasi

Comment 20

[Bernd]

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

Comment 21

[Anatoly Kochergin]

Attachment: much better testcase from 97753

Comment 22

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

Fix checked in 2002-05-14 05:55 PDT.

Comment 23

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

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

Comment 24

[Anatoly Kochergin]

Does the fix checked in to m1.0RC3 too? Still see the problem in RC3.
Reopen?

Comment 25

[Boris Zbarsky [:bzbarsky]]

> Does the fix checked in to m1.0RC3 too? 

No (note the patch has no approval).  This is not going to be in 1.0.  It will 
be in 1.1.