Last modified: 2012-04-16 09:15:33 UTC
Vector and Monobook contains /* Tables */ table { /* we don't want the bottom borders of <h2>s to be visible through * floated tables */ background-color: white; } Bug 26449 added h1, h2, h3, h4, h5, h6 { overflow: hidden } to all skins. So the bottom border of h2 can not go through floating tables. table { background-color: white; } is no longer necessary. a lot of more specific table { background-color: transparent; } can be removed.
removing the white background color of a simple and wide selector like 'table' will most certainly break layouts for many users that depend on the fact that when they started their fancy main page with {| |} it would be white. And since using tables for layouts is cool they probably used the following as a border for the 'white' table: {| style="background:black" | {| |content here | content here |} |} Result if we remove the background color: black text on black backround. Anyway, that's just a doom, but realistic, scenario. I don't think it's a big problem though as long as people are notified of it in advance and should be very clear as a breaking change. It's hard to imagine for some but many people depend on these styles of which most dont realize why the styles are that way nor how or where it's coming from.
I agree this should not be done; plain tables are expected to be white (even if for the wrong reasons). Perhaps only changing the comments is enough.
There may be some places in existing projects where the white background color is implicitly assumed. But there are more places where the white background color is not needed and a transparent background is not defined. Normally this is no visible difference, unless there are namespace-specific background colors or other background colors. And there are more uses for automatic transparent background then for automatic white background. The skin Modern also doesn't have white background color for tables. I think the table background color should not defined in core skins. When there are problems in existing project they may define this in their local skin definition.
At the moment we have inconsistency between skins: Monobook and Vector have table { background-color: white; } Modern and all other skins have no definition and therefore table { background-color: transparent; } Since bug 26423 the white border around pictures is removed. Since bug 26449 the bottom border of h2 can not go through floating tables and doesn't connect to floating pictures. The white background color is the last important point which duplicates the default background color.
Alright sounds reasonable. I'll do this tomorrow and announce it so wikis have sufficient time to fix any potential problem.s
This would be a more difficult situation to find: {| align="right" border="1" cellpadding="20" | Box |} Text <pre>pre text</pre> A transparent background color for table is consistent to <div style="float:right; border:1px solid black; padding:20px"> Box </div> Text <pre>pre text</pre>
(In reply to comment #6) > This would be a more difficult situation to find: > > {| align="right" border="1" cellpadding="20" > | Box > |} > Text > <pre>pre text</pre> > > A transparent background color for table is consistent to > > <div style="float:right; border:1px solid black; padding:20px"> > Box > </div> > Text > <pre>pre text</pre> Those would be the same after this fix is applied and live on a wiki. The following can be used on either to make make it white again: style="background-color:white" Does that answer the question I didn't see ? Not sure what you were trying to say (although I must say that people use way too many tables (which is semantically wrong and slower for the client and server: (<table><tbody><tr><td>content</td></tr></tbody></table> vs. <div>content</div>)
(In reply to comment #7) Sorry, I hadn't a question. I just want to give an non-nesting example of a table where the white background color is implicitly assumed. Of course style="background-color:white" is the solution and div is better then table in this example.
Fixed in r80495.
