Closed
Bug 227031
Opened 17 years ago
Closed 17 years ago
table includes inline alternate stylesheets which cause the original style to not be applied
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: will, Unassigned)
References
()
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Comment 3•17 years ago
|
||
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.
Reporter | ||
Comment 4•17 years ago
|
||
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•17 years ago
|
||
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....
Depends on: 4510
Comment 6•17 years ago
|
||
Seems to be fixed. But the test case is unclear to me.
![]() |
||
Comment 7•17 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•