interpretation of 'width' for tables with border-collapse:separate

VERIFIED DUPLICATE of bug 61125

Status

()

defect
P3
normal
VERIFIED DUPLICATE of bug 61125
20 years ago
16 years ago

People

(Reporter: unapersson, Assigned: karnaze)

Tracking

({css2, testcase})

Trunk
mozilla1.0
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl])

Attachments

(2 attachments, 2 obsolete attachments)

If a table with its width set to 100% is given a margin through a stylesheet
then the margin is ignored. Shouldn't the 100% for the table represent all the
remaining space after the margin has been applied?
Status: NEW → ASSIGNED
Summary: clash between table width 100% and stylesheet margin → clash between table width 100% and stylesheet margin
David, in general do you know if the percentage width for a table is based on
the width of the containing block including the table's margin or not. The
attachment is a little special because the containing block is the body. And as
usual for compatibility, the width of the table is the border edge rather than
the content edge.
According to CSS, the width property defines the content width, and percentages
are in terms of body.  This means anything with 'width: 100%' and nonzero
padding, margin, or border is wider than its parent.  With normal blocks (rather
than tables) this can be overcome using 'width: auto' instead of 'width: 100%'.
It seems that it's a deficiency of the current CSS table model that this can't
be done with tables.  Perhaps whatever the proposed CSS3 property is that takes
values 'content-box' and 'border-box' could overcome this... if it has a value
'margin-box'.

I have no idea what the behavior of existing browsers is, though, which is
probably what you were asking.
So, I think what you are saying is that the submitter's request to have the
table fit in the viewport (I think that is what he/she desired) is contrary to
the spec, due to the presence of a 50px margin (not to mention the 1px border).

Unfortunately, there is no such thing as margin-edge (I'm not sure what the
terminology is either, but there is content-edge, padding-edge and border-edge).
In Nav 4.x and IE5, table width implies border-edge rather than content-edge.
That's what I'm saying.  But I didn't check myself whether table width implies
margin-edge or border-edge when interacting with CSS.  Have you checked its
interaction with CSS?
I think the CSS 2 spec only speaks of width in terms of content width, so a
strict interpretation of it would imply that CSS table width is content width.
However, this brings up an interesting question - should the html width <table
width=100%> be border-edge and the CSS width <table style="width:100%"> be
content-edge.
Perhaps, for the separated borders model, although the spec might actually say
something different.  I'd have to check.  (The collapsing borders model defines
the width as to the middle of the table border, I believe.  I think there's
already a bug on that...)
Summary: clash between table width 100% and stylesheet margin → {css2} clash between table width 100% and stylesheet margin
Whiteboard: Potential candidate for NavQuirks?
The related bug for the collapsing borders table model is bug 3000.

In the separated borders table model, the 'width' property sets the inner
border edge of the table. In the collapsing border model, the 'width' sets the
distance between the middle of the left table border and the middle of the
right table border.

You can see diagrams of the meaning of 'width' on tables at:
   http://www.w3.org/TR/REC-CSS2/tables.html#img-tbl-width (collapsing)
   http://www.w3.org/TR/REC-CSS2/tables.html#img-tbl-spacing (separated)

There is a test case for this at:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/tablewidth2.html

David has posted a proposal to www-style related to the content-edge property
in this particular scenario:
   http://lists.w3.org/Archives/Public/www-style/1999Oct/0083.html

Currently we are using the border edge. This is wrong per CSS2.

This may be a candidate for NavQuirks behaviour, depending on how legacy
browsers behave.
The issue of this bug is the treatment of table width percentage with stylesheet
margins. The other issue is the treatment of table width percentage as related
to the 'width' definition using the border-collapse: separate value. Should a
separate bug be filed for that? or is it the same bug? I have attached a file
demonstrating the 'border' problem.
Target Milestone: M14
Summary: {css2} clash between table width 100% and stylesheet margin → {css2} interpretation of 'width' for tables with border-collapse:separate
chrisd: actually, the percentage value is interpreted correctly (w.r.t. parent's
containing block), it is just that the wrong width is set. See above. Fixing
summary to be clearer.
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Target Milestone: M14 → M16
Summary: {css2} interpretation of 'width' for tables with border-collapse:separate → interpretation of 'width' for tables with border-collapse:separate
Moving to M17.
Target Milestone: M16 → M17

*** This bug has been marked as a duplicate of 41262 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
I should have made a dependency instead of a dup. 
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → ASSIGNED
Depends on: 41262
Keywords: testcase
I suggest dup with 61125 - the original reasoning is the same, as David Baron's 
first comment demonstrates.
Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.
Target Milestone: M17 → ---
Moving to m1.0
Target Milestone: --- → mozilla1.0
QA Contact: chrisd → amar
QA contact update
Whiteboard: Potential candidate for NavQuirks? → [awd:tbl] Potential candidate for NavQuirks?
sorry ... my attachment doesn't belong here, it's supposed for bug #9191 

*** This bug has been marked as a duplicate of 61125 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago18 years ago
Resolution: --- → DUPLICATE
Whiteboard: [awd:tbl] Potential candidate for NavQuirks? → [awd:tbl]
Posted file reduced testcase attached (obsolete) —
The width of all the cells should be consistant but they are not. Its more
visible in the second last cell(FRI).
Comment on attachment 64040 [details]
reduced testcase attached

This looks like it was attached to the wrong bug.
Attachment #64040 - Attachment is obsolete: true
please ignore my previous comments.. Wrong bug.
 The given testcase is rendered correctly on build ID : 2002011503
Marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.