Closed Bug 172213 Opened 18 years ago Closed 16 years ago

Problems with TABLE border=x rules=none


(Core :: Layout: Tables, defect, P3)






(Reporter: bugzilla, Unassigned)



(Keywords: testcase)


(2 files)

When rules="none" is specified, then NO RULES should appear between cells of the
- regardless of the border attribute (present or not; with an integer value or not)
- regardless of an border-collapse css declaration

Reproducible: always. XP Pro SP1 and using 2002100208.

The problem arises from litteraly understanding an "implies" as a "should" or as
a "must".

HTML 4.01 section 11.3.1 Borders and rules

"The value 'border' in the start tag of the TABLE element should be interpreted
as the value of the frame attribute. It implies rules='all' and some default
(non-zero) value for the border attribute."

But rules="none" should override this. 
"The RULES attribute defines which rules to draw between cells: If RULES is
absent then assume: 'none' if BORDER is absent or BORDER=0 otherwise 'all'."

But nowhere the HTML 4.01 spec suggests or says that if the table attribute
border="x" is declared, then it should override rules="none" and display table

Complete self-explanatory test case coming.
The first 3 tables in the test case render table rules despite the inclusion of
the table attribute rules="none" in the code. There should be no rules between
cells in the first 3 tables.
The 4th (and last) table in the test case is rendered accordingly.
Confirming; over to a more reasonable component....
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
Ever confirmed: true
OS: Windows XP → All
QA Contact: petersen → amar
Hardware: PC → All
Priority: -- → P3
Target Milestone: --- → Future
This bug is something strange. I move first table to last position and produce
a completely different result -- rules="none" apply correctly?
O'k. I see first part of trouble:

1431       if (NS_STYLE_BORDER_SEPARATE == tableStyle->mBorderCollapse) {
1432         // Set the cell's border from the table in the separate border
model. If there is a border
1433         // on the table, then the mapping to rules=all will take care of
borders in the collapsing model.
1434         nsHTMLValue value;
1435         aAttributes->GetAttribute(nsHTMLAtoms::border, value);
1436         if (((value.GetUnit() == eHTMLUnit_Pixel) &&
1437              (value.GetPixelValue() > 0)) ||
1438             (value.GetUnit() == eHTMLUnit_Empty)) {
1439           if (aData->mMarginData->mBorderWidth->mLeft.GetUnit() ==
1440             aData->mMarginData->mBorderWidth->mLeft.SetFloatValue(1.0f,

So this if have no check to rule="none", and even rule="none" it paint border.
I confirm (XP Pro SP1, build 2003012008) the strange behavior you see. I noticed
a similar behavior when doing the initial testcase. This behavior seems to be
related to the way Mozilla handles, parses the border-collapse property.

You are right! The chunk of code you listed suggests that Mozilla will paint
borders around cells even if rules="none" is declared. 

FWIW, the html.css file gives:

table {
  display: table;
  border-spacing: 2px; 
  border-collapse: separate;

table[rules] {
  border-collapse: collapse;

The default behavior of the rules attribute is rules="all" as long as the border
attribute is declared and implies a positive value:
"(...) If RULES is absent then assume: 'none' if BORDER is absent or BORDER=0
otherwise 'all'."
Depends on: 155507
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
Flags: blocking-aviary1.1?
Depends on: 299723
The fix/patch in attachment 188342 [details] [diff] [review] from bug 299723 has fixed this bug. Both
testcases from attachment 101453 [details] and attachment 112626 [details] render expected results
with Deer Park alpha 2 rv: 1.8b3 build 20050708 under XP Pro SP2.

Resolving as FIXED

Thank you Boris :)
Closed: 16 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.1?
You need to log in before you can comment on or make changes to this bug.