Closed Bug 25707 Opened 25 years ago Closed 24 years ago

Conflict between text-indent in percent and margin-left in percent in table

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dylang, Assigned: roc)

References

(
URL
)

Details

(Keywords: css1, helpwanted, testcase)

Attachments

(10 files)

testcase: conflict between text-indent and margin inside table
200 bytes, text/plain
Details
re-applied testcase with correct MIME
200 bytes, text/html
Details
Simpler testcase
1.45 KB, text/html
Details
Even simpler test case!
153 bytes, text/html
Details
The REAL testcase
162 bytes, text/html
Details
Example of the enormous difficulty of choosing correct desired width
418 bytes, text/html
Details
margin-left and text-indent in 600 pixel table
576 bytes, text/html
Details
Patch to nsBlockReflowContext::DoReflowBlock, nsBlockReflowContext::PlaceBlock
5.22 KB, patch
Details | Diff | Splinter Review
Screenshot of working table at www.thock.com/Dylan
19.33 KB, image/png
Details
V2 of patch to fix maxElementSize of elements with percentage margins and percentage-width content
5.55 KB, patch
Details | Diff | Splinter Review 
It looks like the CSS1 parser has caused major problems.  The entire client area 
seems to be filled with random bits of text and graphics.  It could be an array 
that wasn't properly terminated, or just a general memory leak or pointer 
confusion, but the entire window slowly randomises itself :-)
changed component to Style System.  Dylan, what build are you using?
Component: Browser-General → Style System
Whiteboard: [MAKINGTEST] ericmao@stanford.edu
Summary: CSS1 parser engine problems. → Conflict between text-indent and margin inside table.
Whiteboard: [MAKINGTEST] ericmao@stanford.edu → [TESTCASE] ericmao@stanford.edu
This is using Mozilla M13.
Under Windows, I get massive corruption of the browser window (<a 
href="http://www.thock.com/Dylan/M13_tasties.jpg">screenshot</a>).
Under Linux (2.2.15pre4/October Gnome/IceWM v1.0.1/XF86_SVGA 3.3.5), I get a 
bunch of text that does not wrap propely (long horizontal scrollbar).  This is 
using a prebuilt binary with fullcircle talkback.

M13 on Linux and Windows both misrender <a 
href="http://www.thock.com/3ilinux/">http://www.thock.com/3ilinux/</a> the same, 
though :-)
Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed 
thru.
Assignee: nobody → leger
Reassign to component owner.
Assignee: leger → pierre
Keywords: testcase
QA Contact: nobody → chrisd
I'm not seeing the major corruption, however the right-margins are clearly wrong 
as the text goes on and on toward the right without wrapping, as Dylan 
mentioned.

I'll take this one and investigate further.
Assignee: pierre → attinasi
Status: NEW → ASSIGNED
Target Milestone: M16
This looks like a table layout problem. When both margin-left and text-indent 
are specified in percentages the table is way to wide. If either one is 
specified in em or px units, then it is fine. 

Assigning to karnaze since the style looks correct.
Assignee: attinasi → karnaze
Severity: major → normal
Status: ASSIGNED → NEW
Component: Style System → Layout
Summary: Conflict between text-indent and margin inside table. → Conflict between text-indent in percent and margin-left in percent in table
Status: NEW → ASSIGNED
Buster, it looks like the cell's block is returning a very large desired and max 
element size upon an unconstrained reflow.
Assignee: karnaze → buster
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M16 → M18
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19
This bug has been marked "future" because we have determined that it is not 
critical for netscape6.0. 
If you feel this is an error, or if it blocks your work in some way -- please 
attach your concern to the bug for reconsideration.
Target Milestone: M19 → Future
Cool screenshot.

Do I understand it correctly, that we won't be CSS1-compliant with this bug?
Keywords: helpwanted
This bug means that valid HTML 4.0 and CSS1 will not work. There is no way that 
Netscape/Mozilla can go gold without *full* CSS1 HTML 4.0 compliance IMHO. It's 
the only way to stand out.
Full HTML4/CSS1 compliance can't mean "100% bug free". If it does, no-one will
ever ship a fully copmliant browser.
Right, but that is no reason to avoid fixing bugs either. There is a long time 
before the final release. Bugs that break compliance should be ahead of 
everything else except crashers.
I agree, if it breaks compliance then it should be fixed. Before Netscape 
PR3 - thats not exactly tomorrow.
Buster, thanks for considering this bug.  Jan, you seem to be the correct QA 
this bug needs to be fixed.  Buster, I'm sorry about your workload, could you 
possibly give a hint about how someone would fix this?  Milestone reset by /.

Justification for loss of future: /., css1
relnote2: if we don't fully support css we need to say so.
nsbeta3: css1
Severity: normal → major
Keywords: css1, nsbeta3, relnote2
OS: Windows 98 → All
QA Contact: chrisd → janc
Hardware: PC → All
Whiteboard: [TESTCASE] ericmao@stanford.edu
Target Milestone: Future → ---
First observation: incremental reflow of "text-indent: n%" is broken. It's easy 
to fix. I have filed bug 45631 with a patch.
Depends on: 45631
Sorry, ignore those testcases. I'm confused.
Some of my comments below may be wrong if you're flying without the 
incremental-text-indent patch. Table layout depends on incremental reflow; 
there's no point in attacking this bug until incremental reflow of text-indent 
is fixed.

If you open attachment 11475 [details] in Viewer, you will see that the layout is wrong. 
The table is unnecessarily wide. In fact, the table will always be as wide as 
the window. In fact, the table edge should be to the right of the text, i.e. the 
table should be sized so that the text should occupy 60% of the width and the 
identation the other 40%.

Note that NS 4.x bungles the layout in a different way: the indent is set to 40% 
of the window width, and then the table is laid out around that.

Currently what happens in Gecko is that the line is initially reflowed with 
unconstrained width. We calculate the text-indent as 40% of some very large 
number, which results in another very large number :-). Then we set the desired 
size to that plus the width of the text. The desired size is never updated 
again... The table sets its size, then the cell is reflowed to fit (which 
updates the text-indent amount, but does not change the desired size).

(I'm pretty sure that the insanity that results in combination with "margin" is 
a consequence of the unreasonable desired cell width. Even if it isn't, we 
should get text-indent in tables working before we tackle the real bug.)

The problem here is simply that reflowing with unconstrained width does not tell 
us the desired width of the block. I tried detecting the special case of taking 
the text-indent percentage of NS_UNCONSTRAINEDSIZE and returning 0 for the 
indent, but of course that just gives you a different wrong estimate of the 
desired width (although one that's a lot more reasonable).

Similar (although less spectacular) problems happen if you put a replaced-inline  
element into the cell, styled with a percentage width.

The solution is not going to be easy, but this should work: while reflowing a 
block with unconstrained width, accumulate in the block's reflow state an 
"additional percentage width required" factor. Things whose width is a 
percentage of the unconstrained-width-block are assigned zero width but add 
their percentages into the accumulator. Then we can calculate the desired width 
of the unconstrained-width-block by solving the equation
desired_width = measured_contents_width + desired_width*accumulated_percentages

Heh heh heh.
Oh dear. More bad news about "text-indent" is that it is one of the few 
inheritable percentage styles, and we need to inherit the computed value instead 
of the percentage. Currently we inherit the percentage. This breaks in 
situations like this:

<div style="text-indent: 10%; width: 100px;"><p>hellohello</p></div>

The indent should be 10% of the width of the DIV's containing block, but Gecko 
is making it 10px (10% of the width of the DIV) regardless of the width of the 
DIV's containing block.

Making that work right is also going to make fixing this bug harder.
I was overly optimistic last night. The previous example shows just how 
difficult it is to choose the desired cell width. At large widths, the table 
fits in two lines. At smaller widths (~250px), it wraps to three lines. At yet 
smaller widths (~180px), it fits in two lines again! And if you keep making it 
smaller, it goes back to three lines.

So, the question is, how should this table be laid out if the table width is 
unconstrained? Ideally I think we should choose the smallest width that 
minimizes the height, but that means we need to globally optimize a function 
with multiple local minima. That's fundamentally hard.

As a possible first step, when taking the precentage of an NS_UNCONSTRAINEDSIZE, 
always return some fixed very large value (independent of the %) so that if we 
add a lot of them up, we won't overflow, but we will always get a very large 
width. Then when we compute the desired size of a table cell, we can detect 
over-wide cells and invoke a more complex "desired size search" subroutine. This 
way we avoid penalizing the common case.

The big question is, exactly what should this subroutine do? We can try 
reflowing the cell into different widths and see how it fits, but how can we 
detect that it's fitting well?

A stopgap measure would be to force the table width to the width of its 
container if we see a strangely-wide child.
As an authoring practice, using percentage widths inside table cells whose width 
is otherwise unconstrained is probably unwise. Those measurements depend on the 
width of the cell, but the width of the cell depends on those measurements. No 
wonder no browsers get it right.
Follow the logic here.  Nested tables should inherit their sizes fairly easily. 
 The outer table has its percentage size translated into a hard pixel value.  
Then the next inner table has its size based on its percentage of the outer one. 
 And so on.  You could evaluate this recusesively.

Once you have a size for a table, it's simply a matter of dividing the space 
among the cells.  Then once you have a cell size and position within the table, 
you put the content into it.  This is where indentation and margins come in, and 
are relative to the size of the cell.

That's my reasoning behind it, but then I've never tried to program a layout 
engine (or browser for that matter) before :)
That's great if the page author specified the table width. That already works 
fine in Mozilla. The problem is when the table width is not specified at all so 
the browser has to find a good width.
This bug has to do with a conflict between margin-left and text indent when in 
percentages within tables. Even when the width of the table is set, I don't 
think it works properly in Mozilla. Otherwise, this bug would be marked FIXED 
and you guys would be using a different bug # for the problem with 
unconstrained tables.

If there is a width:X% specified for a table, then it should be easy for it to 
get the amounts for margin-left:X% and text-indent:X% from the table's width, 
which is gotten from the page's width. If it isn't specified, maybe anything 
that is specified in percentages within these kinds of tables should be 
ignored. I don't think anybody would have something against doing this if the 
W3C forgot to mention that specifying things in percentages within tables that 
don't have specified widths or heights might not work correctly.
Maybe I'm just dense, but eventually Mozilla has to layout a table that has no 
specified width right? Why not use that size to determine the %'s?
"Otherwise, this bug would be marked FIXED and you guys would be using a 
different bug # for the problem with unconstrained tables."

So is there a bug open for unconstrained tables, or are unconstrained tables 
symptoms of the indent/margin percentage conflict?
The deal with margins is this: the text indent is set to a bogusly large value, 
as I explained earlier. Therefore the P element's contents are bogusly wide. The 
P element is "shrink wrapping" its contents here, so its margins are calculated 
so that the left margin will be 1% of the final P width, i.e. the left margin is 
set to bogusly wide too. The sting is that when we look to see what the minimum 
cell width should be (the "maxElementSize"), we scan the contained P element to 
see what its "maxElementSize" is; we find that it's the width of the string plus 
the margins on the element! So we incorrectly decide that the element needs to 
be incredibly wide.

I think this means we should change nsBlockReflowContext::PlaceBlock so that it 
recomputes the margin values based on the maxElementSize (i.e. the minimum width 
required for the block) instead of the actual width.
There are a number of different bugs falling over each other here:
1) percentage text-indent doesn't inherit in the right way (bug 45631)
2) percentage text-indent doesn't incrementally reflow correctly (bug 45631)
3) table cells containing percentage text-indent and percentage width 
inline-replaced elements don't size correctly
4) the minimum width of shrink-wrapped blocks with percentage margins isn't set 
correctly

Bugs 2), 3) and 4) are all affecting this bug report. Bug 4) is probably causing 
the worst of the trouble. Thanks for pointing that out.

Bugs 1) and 2) really need to be solved together; they're tricky, but solvable. 
Bug 3) is a nightmare and probably deserves its own Bugzilla bug. Bug 4) is 
definitely solvable and should probably stay here.
Bradley: the problem is that you can't just use the table width to compute the 
margin and text-indents, for two reasons. First, if the minimum width of the 
columns is wider than the specified table size, Mozilla will make the table 
wider to fit. I don't know if that's a good decision, but it seems to have been 
done deliberately. Also, if there's more than one column you have to figure out 
how to distribute the space and that's not easy.

Jerry: Apart from the margin bug, the problem is all about how to choose the 
table width. If that's done correctly, everything else should work. But it seems 
terribly difficult to do "correctly", if indeed there is any correct way to do 
it.
The patch fixes the margin issues. The tables in this bug's testcases and on 
other sites seem to work OK. text-indent in tables still doesn't really work, 
but at least things don't get out of control.
I have another idea for getting a reasonable desired size for table cells 
containing percentage-width elements.

First, set things up so that when we reflow a table cell with unconstrained 
width to find its desired width, we can specify as a parameter the actual 
(very large) width that percentage-width children will base themselves on (the 
"putative width"). Right now they (or at least some of them) take a percentage 
of the value of NS_UNCONSTRAINEDWIDTH, which is just dumb.

Now, it seems to me that the desired width of a table cell in terms of this 
putative width should be a linear function, i.e. the desired width will normally 
consist of some fixed width "x" plus some fraction "f" of the putative width. I 
have a hard time thinking of content which could violate this rule (assuming the 
putative width is very large).

If so, then we can do the following: first reflow the cell with unconstrained 
width and a very large putative width W. If the resulting desired width D is 
not unreasonably large, then we're done. Otherwise reflow the cell again with 
unconstrained width and putative width W/2, obtaining desired width E. Then, by 
the assumption,
D = x + fW and E = x + fW/2
Solving the equations, we get
f = 2(D - E)/W and x = 2E - D
We'd check 0 < f < 1 and 0 < x and bail out (or do something else special) if 
not. Otherwise we can go ahead and compute the true desired width "T" by solving 
the equation
T = x + fT
i.e. set T = x/(1 - f)

Should be fast, robust and give good results.
Keywords: patch
I'll start looking at this.
What do you plan to look at?

My patch fixes the issues with percentage margins in the presence of 
percentage-width content making the minimum cell width unreasonably large. That 
patch should be enough to consider this bug "fixed".

The desired cell size calculation is still broken in the presence of 
percentage-width content, but it turns out that all the ideas I posted here are 
flawed and will give bad results. I have other ideas but they're complex and 
slow and the problem is so hard, it's really not worth fixing.
So has your patch been committed? Should we open another bug to work on desired
cell size
computation?

I'm just looking for other things to work on in Mozilla, and I was pointed to
this bug.

Should we add "Fix in hand" to the status whiteboard?

The patch hasn't been committed. I'm actually going to submit a new patch, which 
is slightly lower risk. If you can try it out, verify that it fixes the bug and 
doesn't cause any new problems, and report so here, that would be very helpful. 
Then I can seek review and approval and check it in myself.

Filing a new bug about choosing correct desired cell widths in the presence of 
percentage-width content would be a fine thing to do, but please don't burn time 
on it. I don't think anyone really cares about it.
If anyone files that cell-width bug, please CC me on it. Thanks.

I think that patch is checkin-worthy. However, let's wait until nsbeta2 has 
branched before we seek approval. This is minor stuff.

I'm stealing the bug from buster. I hope he doesn't mind :-).
Assignee: buster → roc+moz
Status: ASSIGNED → NEW
OK, can I have review and module owner/mozilla.org approval please? It's time to 
get this in. The patch is
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11896
Status: NEW → ASSIGNED
a=waterson
Do we still need r=? Marc, assuming this falls into your module, could you
review the patch please? Thanks...
Keywords: review
It would be better if Chris W. could review this, he is much more familiar with 
this are than I am. Chris, can you review the patch 
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11896)?
r=waterson, too!

roc, can you add an appropriate regression test to 
mozilla/layout/html/tests/table/bugs, too?
Fix and testcase checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I have double checked several times with recent builds and, to my great joy, 
this indeed works fine (and fixes problems with rendering other things I was 
doing with CSS and HTML).  I'm glad that something originally marked as "future" 
was just a simple patch away from proper HTML/CSS conformance :)
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: