227031 - table includes inline alternate stylesheets which cause the original style to not be applied

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Will Holcomb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718

The page includes a couple of different alternate stylesheets which attempt to
remove columns from the table. One uses setting the column (via a col element)
to display = none. The other uses a class on the td's and th's to set their
display to none.

When the page is first displayed some styles are not applied to the email and
home columns. (These are columns affected by the alternate stylesheets, but all
the stylesheets do is set the display to none.)

Changing the stylesheet to the alternate stylesheet with no cols causes the
email and home column to disappear (as expected). There is a space in etween the
name and phone number though.

Changing the stylesheet to display inline causes columns to be redrawn
erratically when items are moused over.

The rel attribute is not legal on a style element. I tried using links with
hrefs referring to the original document, but changing them has no effect. (I.e.
a link with href=#localsheet.)

Reproducible: Always

Steps to Reproduce:
1. Load the page
2. View the non-styled columns
3. Change the stylesheet in the View Menu

Actual Results:  
The style should have been properly applied to all elements in the first place.
Subsequent stylings should not leave a space in between elements.

Expected Results:  
In my opinion it should be possible to inline alternate stylesheets and link to
their id with an alternate stylesheet. A choice to change to that stylesheet at
display time should cause it to take the highest precedence. This is basically
like allowing the rel attribute on a stylesheet, but is XHTML compliant.

Comment 1

[Will Holcomb]

Attachment: file referenced in report

Comment 2

[Will Holcomb]

Attachment: screen shot after some mouseovers with display set to inline

Comment 3

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7]

There seem to be a lot of issues mentioned in this bug.  Please try to keep one
issue per bug.

It's worth noting that making a column 'display: none' is not supposed to hide
the contents of the column, since it just means that the next column element
corresponds to what that column element would have corresponded to. 
'visibility: collapse' should work, though.

Comment 4

[Will Holcomb]

Yeah, there were several. I didn't really aim to, I just made the page and there
were a whole bunch of things wrong with the display. Pretty much all the parts
are related to one another so I didn't want to remove information that could be
useful to someone bug hunting.

As for the cols removing the info from the display, the behavior I describe is
the exhibited behavior. I didn't figure it would do anything at all, but tried
it while searching for a way to get the desired behavior. I thought it was a bit
strange as well. Setting visibility to collapse has the same affect as setting
display to none in 1.5a.

Comment 5

[Boris Zbarsky [PTO through Aug 25, :bzbarsky, bz on IRC]]

So... the alignment style is not applied because text-align does not apply to
elements with display "inline".  The background not being painted is a bug; I
suspect the patch in bug 4510 will fix that.

Are there other styles that are a problem?  The "expected results" and "actual
results" are not very clear....

Comment 6

[Anne (:annevk)]

Seems to be fixed. But the test case is unclear to me.

Comment 7

[Boris Zbarsky [PTO through Aug 25, :bzbarsky, bz on IRC]]

Yeah, the background issues that existed here are fixed by bug 4510.

Will, could you please file followup bugs on the remaining issues if any?  One
bug per issue, please.