158742 - [BC] border-collapse/CSS/XML/XHTML/XSLT problem

Status: RESOLVED FIXED

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

Description

[kelvSYC]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.21; Mac_PowerPC)
BuildID:    2002061014

Mozilla does not render borders (or any other border category properties, such as 
border-collapse or border-style) around <table> or <tr> tags styled through CSS, just <
th> and <td> tags.

An "ASCII picture" of a sample table and expected and actual results follow.

Sample Table Code Fragment
<table>
 <tr>
  <td>1</td>
  <td>2</td>
 </tr><tr>
  <td>3</td>
  <td>4</td>
 </tr>
</table>

Sample CSS Code
table tr {
 border-top-width: 1px;
 border-top-style: solid;
}
table {
 border-left-width: 1px;
 border-left-style: solid
}

Reproducible: Always
Steps to Reproduce:
1. Create a table in an HTML document
2. Style the table with a border through CSS
3. Render using Mozilla

Actual Results:  Using the sample code above, Mozilla renders it similar to the following:


 1 2
 
 3 4

Expected Results:  Using the sample code above, Mozilla should have rendered it like 
so:

|---
|1 2
|---
|3 4

I'm only sure that borders are rendered around <td> and <th> elements.  

When trying with non-border elements, such as this:

h1 {
 border-width: 1px;
}

The borders do not render.

Comment 1

[Eli Friedman]

attach a testcase

Comment 2

[Greg K.]

Adding qawanted for testcase generation (and possible duplication?).

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase

Works just fine with 2002-07-18-08 (trunk) on Linux.

Comment 4

[Mats Palmgren (inactive)]

The reason for:
h1 {
 border-width: 1px;
}

not showing the border is that the border style is by default 'none'.

See http://www.w3.org/TR/REC-CSS2/box.html#propdef-border-style:
" Since the initial value of the border styles is 'none', no borders will be
visible unless the border style is set. "

Comment 5

[Mats Palmgren (inactive)]

For the separated border issue:
http://www.w3.org/TR/REC-CSS2/tables.html#separated-borders
" In this model, each cell has an individual border. ...  Rows, columns, row
groups, and column groups cannot have borders (i.e., user agents must ignore the
border properties for those elements). "

Comment 6

[Mats Palmgren (inactive)]

Your build is a bit old - please try a newer one from here:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/

Report back if you still see a problem with a newer build.

Comment 7

[kelvSYC]

Using the Mac OS X build 2002072303, the problem still persists.

Upon closer inspection, it seems that:

- Mozilla ignores "border-collapse: collapse;" and renders everything under the 
separated borders model (even though the default should be collapse).  This is why 
border style rules for anything other than individual cells or the table as a whole fail to 
show up, as under the separated borders model they are ignored.

Sample code that will confirm this:

<table>
 <tr>
  <td>1</td>
  <td>2</td>
 </tr>
</table>

table { border-collapse: collapse; border: 1px solid black;}
table tr td:first-child { border: 3px solid black; }

You will see that, when rendered wiht Mozilla, the border between the two cells does not 
reach the border of the table, which should not happen under the collapsing border 
model.

Comment 8

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

Please attach a complete testcase rather than pasting snippets of HTML and CSS
into the bug.  The problem is probably something that you don't think is
relevant and that you're not telling us.

Comment 9

[Greg K.]

David, did you have a look at the testcase Mats attached? (I haven't looked at
it yet.)

Comment 10

[Mats Palmgren (inactive)]

The default value is 'separate' in Mozilla (and in every other browser I know).

The CSS2 errata says:
http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata#s-17-6
"Several popular browsers assume an initial value for 'border-collapse' of
'separate' rather than 'collapse' or exhibit behavior that is close to that
value, even if they do not actually implement the CSS table model. Therefore the
CSS WG proposes to change the initial value to 'separate', in the expectation
that it better matches what users expect it to be."

So if you want 'collapse' - please specify it explicitly.

Comment 11

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

Our layout and rendering of the testcase Mats attached seemed correct to me.

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase #2

A testcase for the second code snippet from Reporter.
I exaggerated the border for the 1st cell even more, now it's 10px.

Comment 13

[Mats Palmgren (inactive)]

Attachment: Snapshot of Testcase #2 (Linux)

Comment 14

[Mats Palmgren (inactive)]

AFAICT this is exactly how it should render. See
http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#collapsing-borders

[e-mail] is this what you see also?

Comment 15

[kelvSYC]

Attachment: Test XML document

This is the XML document that is causing me problems.

Comment 16

[kelvSYC]

Attachment: This is the Sample XSL Stylesheet

This is the XSL Stylesheet that processes the XML document.  Please adjust the
filepaths found inside accordingly.

Comment 17

[kelvSYC]

Attachment: Dependent XML document #1

This is one of the dependent XML documents.

Comment 18

[kelvSYC]

Attachment: Dependent XML document #2

Comment 19

[kelvSYC]

Attachment: Dependent XML document #3

Comment 20

[kelvSYC]

Attachment: Dependent XML document #4

Comment 21

[kelvSYC]

Attachment: Dependent XML document #5

Comment 22

[kelvSYC]

Attachment: Dependent XML document #6

Comment 23

[kelvSYC]

I have added a sample XML document (ryu.xml) and an XSLT stylesheet (although the 
filepaths are wrong, they are ripped from my site), and all dependent files.

After processing the XML with the XSLT, you will see that the borders do not collapse as 
it should in theory.  In fact, if you had processed it, saved the file as XHTML, and then 
viewed it using Mozilla, the borders are correct.

Here's a sample stylesheet to go with the document(s) to show what I mean.

table {
	border-collapse: collapse;
	border: 1px solid #000;
}
table td,table th {
	border:1px solid #F00;
}
body {
	background-color: #FFF;
	color: #000;
	font-family: Verdana,proportional;
	font-size: 9px
}

Comment 24

[Boris Zbarsky [:bzbarsky]]

Please attach files in order from bottom up (so attach the linked-to stuff, change
the links in the other files to point to the attachment, then attach those,
etc; the top-level XML file to be loaded should be attached _last_).

Alternately, provide a mapping from filenames being linked to to the attachments
you posted and someone will have to go through and reattach things properly....

Comment 25

[kelvSYC]

Attachment: Screenshot output

If you were unable to render using Mozilla (through tweaking the dependent
filepaths in the files as necessary), here's a picture of the output.

The same CSS stylesheet, provided below, has been applied to these two screens.
 The window at the top is when the XML is loaded directly, and transformed
using Mozilla's XSLT processor, then a CSS stylesheet is applied to the output
of the XSLT processor.	The window at the bottom is when the XML runs through
another XSLT processor, saved as XHTML, and viewed in Mozilla.

The CSS in question:

tr {
	border-top: 1px solid #000;
}
table {
	border-collapse: collapse;
	border: 1px solid #000;
}
table td,table th {
	border-right:1px solid #F00;
}
body {
	background-color: #FFF;
	color: #000;
	font-family: Verdana,proportional;
	font-size: 9px
}

As you can see, the borders are correct on the bottom screen and not the top.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Jonas?  Is this an XSLT problem?

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

it could very well be a XSLT problem, however this testcase is HUGE so it'll
take some time before i'll be able to figure out what's going on unless someone
makes a smaller testcase.

Comment 28

[Greg K.]

kevlSYC, is this bug's summary still in line with what you're demonstrating with
your XML+XSLT testcases?

Comment 29

[kelvSYC]

No, it has changed somewhat, with new information available.  It seems that

border-collapse: collapse;

is ignored by Mozilla when applying a CSS stylesheet over the output of an XML
document transformed into XHTML through the use of XSLT, and the separated table
border model is always used.

When not using XSLT, the borders render as they should.

Comment 30

[Greg K.]

Okay, we need to try to make sure that's as simple as it can get. Are you sure
you have to start with XML? Can you start simply with XHTML? The idea is to try
to generate the problem using the simplest code possible.

Also, can you re-do the testcase attachments so they all link to each other?
(See Boris' comment 24.)

Comment 31

[kelvSYC]

Attachment: (REPOST) pathbar.xsl

This is a remade pathbar.xsl in which all the unnecessary code have been cut
out.

Comment 32

[kelvSYC]

Attachment: (REPOST) title.xsl

This is a repost of title.xsl, with the paths fixed and all the unnecessary
code cut out.

Comment 33

[kelvSYC]

Attachment: (REPOST) toolbar.xsl

This is a repost of toolbar.xsl, in which all the unnecessary code have been
stripped and the paths are made to work.  Simply take all the reposted files,
put them in one folder, and open with Mozilla.

Comment 34

[kelvSYC]

Attachment: (REPOST) kelvsyc.xsl

This is a continuation of the reposts.

Comment 35

[kelvSYC]

Attachment: (REPOST) main.css

Yet another repost.

Comment 36

[kelvSYC]

Attachment: (REPOST) index.xml

This is the test XML document that will transform with the edited XSL/CSS
documents above.

Comment 37

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

is it impossible to get a *single* xsl file? i can't imgagine that the bug is
only triggerd when the stylesheet is this big. And you can put the css in the
stylesheet by outputting a <style>...</style>

Sorry to ask you to minimize the stylesheet again, but debugging something this
complex is a pain

Comment 38

[kelvSYC]

Attachment: Combined kelvsyc.xsl

I've retested the files above.	After putting all my XSL scraps into one, the
bug persists.  But after putting in the CSS in <style> tags, the borders render
as they should.  To test this out for yourself, you can comment/uncomment the
<xsl:processing-instruction> that includes main.css (as posted above) and the
<style> tags.

So that means that for some reason, the bug shows up when the stylesheet is
included from the output result...

Comment 39

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

->XSLT

Comment 40

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: minimal testcase css

Comment 41

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: minimal testcase xslt

Comment 42

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: minimal testcase xml

attached a minimal testcase. If the

table {
  border-collapse: collapse;
}

css-rule is moved from the linked stylesheet to the embedded one everything
works fine.

I suspect that the reason this doesn't work for XSLT generated pages, but works
for plain pages is that for XSLT-generated pages layout is started before the
linked stylesheet has finished loading, but for plain XML/XHTML we wait with
starting layout until all stylesheets are loaded. 

I need to confirm this theory though

Comment 43

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: minimal testcase xslt

Comment 44

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: minimal testcase xml

forgot to replace & with & in the urls

Comment 45

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: minimal testcase xhtml

This is a xhtml-only testcase that reproduces the bug. The page inserts a
linked stylesheet during the load-event. The link points to attachment 110230 [details]
that contains a rules that sets collapsed borders.

Note that adding a similar rule through the DOM-inspector works.

Comment 46

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

over to layout since this can be reproduced without XSLT.

To reproduce:
1. Load attachment 110239 [details]
2. Look at the stylesheet-list using the DOM-Inspector
3. Look at the computed style of the table-element using the DOM-Inspector

in step 2 you can see that there are two stylesheets, one linked and one embedded
step 3 shows that the computed style of the border is collapsed.

Expected results:
The table should have collapsed borders

Actual results
The two cells have separate borders.

Comment 47

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

in bug 186835 i've attached a patch that fixes this bug when the page is
generated through XSLT. Not sure if you want to keep this bug open anyways,
since that patch is more of a wallpaper-fix (it holds off layout until all
stylesheets are loaded) then a full-fledged fix for the underlying problem.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Patch in bug 191794 fixes this, sorta.  The repaint is not quite correct, but at
least the border-collapse changes...

Comment 49

[Bernd]

the painting issue is bug 155955, adding a 1px margin around the table fixes
painting.

Comment 50

[fantasai]

Is this bug still there? If so, could someone summarize the problem? (Also, is
it really MacOS X specific?)

Comment 51

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The testcase in attachment 110239 [details] works fine so this bug seems to have been
fixed now

Comment 52

[Jason Bassford]

Fixed by what?  The bug fix from bug 191794 of over a year ago?  If not, then it
should be re-resolved as WORKSFORME since we don't know what fixed it...

Comment 53

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

No, FIXED means that we actually fixed it, which was the case here, most likly
by bug 186835 and bug 191794. WORKSFORME is for bugs being errorously filed for
stuff that actually worked, which wasn't the case here.

If you care which patch actually fixed it feel free to track down the date it
was fixed and we can most likly dig up the actual patch.

Comment 54

[Jason Bassford]

So long as it was one of those two then that's sufficient.

> WORKSFORME is for bugs being errorously filed for stuff that actually worked

That's also true, but not complete. FIXED is only applicable if a patch can be
identified.  If something wasn't working a month ago and now is (for some reason
that isn't known, i.e. by "something checked in somewhere") then it's still
WORKSFORME.  If you mark a bug as FIXED then you have to be able to say *what*,
specifically, fixed it.

Comment 55

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> FIXED is only applicable if a patch can be
> identified.  If something wasn't working a month ago and now is (for some reason
> that isn't known, i.e. by "something checked in somewhere") then it's still
> WORKSFORME.  If you mark a bug as FIXED then you have to be able to say *what*,
> specifically, fixed it.

Care to provide a url to where you find this definition? Or did you just make it up?

Comment 56

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

It's a definition that we've been using pretty consistently in Layout, at least.

Comment 57

[Boris Zbarsky [:bzbarsky]]

Sicking, what Jason is saying is in fact the party line for QA to keep people
from marking bugs FIXED when they have no idea whether a patch actually went in
or not (which is sorta required by the definition of FIXED that we have).

That said, when a module owner/peer resolves a bug in his own module, I don't
think we should be applying standards designed to keep people who don't know any
better from doing the wrong thing.