Closed Bug 91468 Opened 24 years ago Closed 23 years ago

table inheriting text-indent and justify is broken

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 130116
Milestone:
mozilla1.1alpha

People

(Reporter: ezh, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: css1, testcase)

Attachments

(5 files)

Testcase which is a validated HTML 4.01 Transitional!
2.59 KB, text/html
Details
Simplified testcase. Should a <p> tag influence a table?
2.47 KB, text/html
Details
Demonstrates the problem in standards (noquirks) mode
2.52 KB, text/html
Details
valid version of testcase showing tables bug
3.70 KB, text/html
Details
test derived from attachment #4
554 bytes, text/html
Details
1. Load the URL 2. Scroll down to the first table. It is totally misdrawn. If needed I can attach a screenshot.
I'm not sure whether this is a CSS problem (we have styles + table here). The funny thing that the <p> above the table is the trigger for this problem. Does that ring a bell?
Whiteboard: CSS problem?
Keywords: testcase
I'm not sure anymore that this is a valid bug We have: <Style type="text/css"> <!-- P {text-indent: 3em; text-align: justify;} --> </Style> and the table is just below a (unclosed) <p> tag. Should the tag influence the table or does a <table> close a paragraph by definition? The http://validator.w3.org service claims a table kills a paragraph (I tried to insert </p> after the nested table. The validator claims that <p> <table> </table> is equal to <p> </p> <table> </table> while Mozilla think it is <p> <table> </table> </p> If validator is right (and it should be), this means we have a bug. The problem here is treating a table as a part of an open paragraph.
Summary: Table is broken → Table is broken (Mozilla includes tables in open <p> paragraphs)
Whiteboard: CSS problem?
Keywords: correctness
OK. The HTML 4.01 specifcation says "The P element represents a paragraph. It cannot contain block-level elements (including P itself)". Houston, we have a problem.
Summary: Table is broken (Mozilla includes tables in open <p> paragraphs) → Table is broken (Mozilla contains tables in open <p> paragraphs)
OS: Windows 98 → All
Hardware: PC → All
We probably need to behave this way in quirks mode (but maybe not). However, we should fix this in strict mode (i.e., in a quirks/strict switch within the nav dtd). Is there another bug on this?
Assignee: karnaze → harishd
Component: Layout → Parser
QA Contact: petersen → bsharma
David: I think you are wrong about the transitional mode. The w3.org validator in 4.01 Transitional mode treats the following <p> <table> </table> </p> as wrong, saying 'Error: end tag for element "P" which is not open; try removing the end tag or check for improper nesting of elements'. And my testcase is validated 4.01 Transitional (it does not have the </p> tag). It means Mozilla is wrong in both strict and transitional mode.
I'm well aware that it isn't correct HTML. However, at least a few web pages depend on it. If enough do, then we need to support it in quirks mode. It has nothing to do with DTDs (which we don't support).
Blocks: html4.01
This is totally a tables/layout issue not parser. Giving bug to karnaze.
Assignee: harishd → karnaze
No, it's a parser issue.
Assignee: karnaze → harishd
Er, well, there's both. Maybe we should split this bug?
David: If you're talking about P containing TABLE then it's so for backwards compatibility.
Refer to bug 43678.
Yes, but we shouldn't be doing it in strict mode.
I understand that...but the above page has nothing to do with strict mode. The problem is confined to the quirks mode and I think the layout/tables should deal with it.
We need a new bug, on the parser, to handle this case in strict mode.
<sarcastic_tone> If we break HTML specifcation for "backward compatibility", what about the <blink> tag? </sarcastic_tone> Seriously, I still do not see a reason not to use proper HTML here. The *correct* HTML of the bug' URL (andtestcases) is broken by Mozilla being not compliant to the standard. Do we prefer to break correct or uncorrect HTML?
Opened up a new bug ( bug 91927 ) on myself to handle this case in strict mode.
So, what exactly is the nature of the remaining bug against quirks mode here?
The logical outcome should be markng it as INVALID or WONTFIX because it seems there is nothing left to do here after spinning of bug 91927. However, I prefer not do that myself as I still do not see the logic behind supporting broken HTML. Please, do not mark it FIXED as nothing has been fixed here.
Well, I will add that Netscape 4.77 shows the bug's URL and the first testcase right (the second testcase has a clipping problem that has nothing to do with this bug). So where is the compatibility problem? Marking 4xp.
Keywords: 4xp
> I still do not see the logic behind supporting broken HTML. Mozilla is a standards compliant browser..and it's trying its best. However, since the older browsers were lenient with html markup a lot of quirkyness got introduced in the past few years. In order to support the existing quirky pages mozilla had to bend some rules ( thus not breaking most of the web ). Therefore, for backwards compatibilty mozilla is forced to do some ugly stuff. As for this bug...I think it should belong to the layout team. Handing over to karnaze...again.
Keywords: 4xp
OK, after that split, this bug should go to tables. I didn't get a chance to reduce the testcase further.
Assignee: harishd → karnaze
Component: Parser → HTMLTables
QA Contact: bsharma → amar
Summary: Table is broken (Mozilla contains tables in open <p> paragraphs) → table inheriting text-indent and justify is broken
Keywords: css1
Layout issue looks a bit like bug 90297. (text-indent messing up table layout).
Is this related to bug 56253 (inheritance of text-indent)?
No. Bug 56253 is about failure to cut off inheritance into anonymous content we generate that happens to respond to CSS properties.
In the 5th attachment, the blocks cannot live with the max element sizes they report. Reassigning to attinasi. Tbl 02A1D08C r=0 a=8940,UC c=0,0 cnt=0 Tbl 02A1D268 r=0 a=8940,UC c=UC,UC cnt=1 RowG 02A1D444 r=0 a=UC,UC c=UC,UC cnt=2 Row 02A1D5FC r=0 a=UC,UC c=UC,UC cnt=3 Cell 02A1D7FC r=0 a=UC,UC c=UC,UC cnt=4 Block 02A1D858 r=0 a=UC,UC c=UC,UC cnt=5 Block 02A1D858 d=2430,285 me=1710 Cell 02A1D7FC d=2490,345 me=1770 Cell 02A1DB20 r=0 a=UC,UC c=UC,UC cnt=6 Block 02A1DB7C r=0 a=UC,UC c=UC,UC cnt=7 Block 02A1DB7C d=1740,345 me=1020 Cell 02A1DB20 d=1800,405 me=1080 Cell 02A1DE8C r=0 a=UC,UC c=UC,UC cnt=8 Block 02A1DF68 r=0 a=UC,UC c=UC,UC cnt=9 Block 02A1DF68 d=2685,345 me=1965 Cell 02A1DE8C d=2745,405 me=2025 Cell 02A1E094 r=0 a=UC,UC c=UC,UC cnt=10 Block 02A1E0F0 r=0 a=UC,UC c=UC,UC cnt=11 Block 02A1E0F0 d=2685,345 me=1965 Cell 02A1E094 d=2745,405 me=2025 Row 02A1D5FC d=UC,405 RowG 02A1D444 d=UC,405 Initialized min=7080 des=8940 pref=9960 Balanced min=7080 des=8940 pref=9960 cols=2235 1545 2490 2490 RowG 02A1D444 r=2 a=8910,UC c=8910,UC cnt=12 Row 02A1D5FC r=2 a=8910,UC c=8910,UC cnt=13 Cell 02A1D7FC r=2 a=2235,UC c=2175,UC cnt=14 Block 02A1D858 r=2 a=2175,UC c=2175,UC cnt=15 Block 02A1D858 d=2430,285 Cell 02A1D7FC d=2490,345 Cell 02A1DB20 r=2 a=1545,UC c=1485,UC cnt=16 Block 02A1DB7C r=2 a=1485,UC c=1485,UC cnt=17 Block 02A1DB7C d=1740,345 Cell 02A1DB20 d=1800,405 Cell 02A1DE8C r=2 a=2490,UC c=2430,UC cnt=18 Block 02A1DF68 r=2 a=2430,UC c=2430,UC cnt=19 Block 02A1DF68 d=2685,345 Cell 02A1DE8C d=2745,405 Cell 02A1E094 r=2 a=2490,UC c=2430,UC cnt=20 Block 02A1E0F0 r=2 a=2430,UC c=2430,UC cnt=21 Block 02A1E0F0 d=2685,345 Cell 02A1E094 d=2745,405 Row 02A1D5FC d=8910,405 RowG 02A1D444 d=8910,405 Tbl 02A1D268 d=8940,495 Tbl 02A1D08C d=8940,495
Assignee: karnaze → attinasi
Target Milestone: --- → mozilla1.1
Blocks: 140682
The max-element-size problem was fixed on bug 130116. There's still the problem that table shouldn't be inheriting from p.
David: That issue is covered by bug 91927. Perhaps this bug should be resolved now?
ok, then *** This bug has been marked as a duplicate of 130116 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: