126543 - dynamically changing to/from collapsed borders and rules attribute not working

Status: RESOLVED WORKSFORME

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

Description

[karnaze (gone)]

This is from bug 41262. The reframe style hint doesn't appear to be working when
javascript changes from separate borders to collapsed borders. A better way to
implement this is with a reflow hint and then rebuild the cell map if need be.
The same is true when changing the rules attribute through javascript.

http://bugzilla.mozilla.org/attachment.cgi?id=70097&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=70106&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=70107&action=view

Comment 1

[Jacob Kjome]

Well, those testcases do not contain valid html nor do they use the proper css
attributes when doing setAttribute('style', [value]).

See:
http://validator.w3.org/check?uri=http%3A%2F%2Fbugzilla.mozilla.org%2Fattachment.cgi%3Fid%3D70097%26action%3Dview&charset=%28detect+automatically%29&doctype=Inline

I have a corrected testcase for testcase #1 already done which I will attach
shortly.  Note that using setAttribute('style', [value]) from javascript sets
the value and reflows the page just fine.  However, using style.borderCollapse =
[value] only sets the value and does not reflow.  Curiously, exactly the
opposite behavior can be observed in IE5.5.  You can check the current value in
the DOM by clicking on the "Display Current Style Value" button in the testcase.

Jake

Comment 2

[Jacob Kjome]

Attachment: replacement for the first mentioned testcase in comment 1

this is a corrected testcase to show what is really happening with setting the
border-collpse css property.  The previous testcases were totally invalid
markup and scripting.

Comment 3

[Jacob Kjome]

Attachment: replacement for the 2nd mentioned testcase in comment 1

Comment 4

[Jacob Kjome]

Attachment: replacement for the 3rd mentioned testcase in comment 1

the only difference between this testcase and the 2nd testcase is that this one
adds a border="1" attribute to the table.  Otherwise, they are exactly the
same.

Jake

Comment 5

[Jacob Kjome]

Attachment: this is just like testcase 3, only it uses a css set 1px border

notice the difference in behavior when pressing the "separated" button on this
tescase compared to the behavior in testcase 3.  With border="1" attribute on
the table, pressing "separated" keeps the rules in-tact whereas when setting
the border on the table using css, when pressing "separated", all the rules
disapear.  

Is this expected behavior?  I'm not sure what is correct???

jake

Comment 6

[Jacob Kjome]

woops, never mind.  I see what is happening.  The rules were also removed in the
3rd testcase.  It is just that setting a border as an attribute on a table gives
borders to the table and all its cells (which I mistook for rules) and in css,
settingt the border on the table is limited to having a border on the table, not
also its cells.  So, I answered my last question.

Anyway, these testcases actually work and now you should be able to better
evaluate what works and what doesn't in the collapsed/separated borders model on
tables.

jake

Comment 7

[Jacob Kjome]

Can this be fixed by 1.0?

Notice that using:

setAttribute('style', [value])

works just fine in every way while:

style.borderCollapse = [value]

works to change the value in javasscript, but this is not realized in layout.

for instance, when querying the value for style.borderCollapse after setting 
style.borderCollapse = 'separate', you will get the expected 'separate' value, 
but you will not see that in the layout of the table.  However, if you do the 
same thing above, only you set the borderCollpse value like 
setAttribute('style', [value]), javascript will report the expected value *and* 
you will see the change in layout.

I'm no Mozilla code-monkey, but this seems like a straightforward fix.  Just 
make the style.borderCollapse = 'separate' do what 
setAttribute('style', 'border-collapse:separate') is doing and this is fixed.  
If it is that easy, I can't see a reason to make this wait until after 
release.  If I'm wrong, just let me know.

Jake

Comment 8

[Boris Zbarsky [:bzbarsky]]

This worksforme in a current Mozilla build. (linux trunk 2003-02-01-22). 
Marking so, and adding dep on the bug that needs to be fixed preemptively before
we change inline style resolution....