Second -- Accessibilty; Shmackcessibity -- I prefer consistency before opening that can of worms any day. The infobox further up the same page that the snapshots were taken from has a border-color: of #DDD. So, unless there is some other "standard" when it comes to border-color in mobile mode or something, it reasons the .wikitable class for border color should also be changed from #EEE to #DDD to match (or vise-versa at the worst).

The same reasoning can go towards the question of setting a default background color for non-header table cells. I know its a long shot but I'll mention it anyway -- rather than setting the background-color at the TABLE element level, please consider applying at TBODY instead. That way, when border-collapse is separate, one can still create borders between cells without invoking the border attribute at all just by setting an inline back-ground-color for the table element (or a parent div wrapper, whatever the case might be).

.content table.wikitable thead,
.content table.wikitable tbody,
.content table.wikitable tfoot {
	background-color: #F9F9F9;
}

Finally -- a question of my own.

Shouldn't we be "testing" any per project desired changes to Mobile View via their local Mobile.css file before jumping right to proposing skin-wide changes? Seems a bit 'unfair' to other projects no?

@GOIII, I agree with your notion on the infoboxes. And of course, no objection to testing before deploying changes.

I see there are some styles for this in resources/src/mediawiki.legacy/shared.css that add the backgrounds.

Minerva avoids using anything marked as 'legacy' so these do not get loaded.

Would it make sense to move these styles into a separate module and enable them on mobile conditionally when a .wikitable table is added?

@Jdlrobson, that does make sense to me.

Does anyone know why they are marked as legacy..?

This are "old" common styles added to all skins and they were migrated to RL as legacy (see commit 32377424b9492bca276d6f8036ed297bef726ed3, maybe because there is a plan to discountinue styles not associated to a skin?

In T105596#1475455, @Florian wrote:

This are "old" common styles added to all skins and they were migrated to RL as legacy (see commit 32377424b9492bca276d6f8036ed297bef726ed3, maybe because there is a plan to discountinue styles not associated to a skin?

That would make sense if the .wikitable was class was simply the .css equivalent to the current specs for HTML tables plus the correction(s) for any post v. 2.0, 3.0, 4.0 & 4.01 deprecated attributes (&/or usage) -- which is the way I use to think of the .wikitable class originally. The .prettytable class was then the definition set that defined any local variances in border or background colors, cell-padding and similar tweakings which augmented the "universal" .wikitable-set values from project to project in the final table rendering (or at least that's how I found things to be on en.wikisource at least).

At some point, it seems this notion to first insure the w3.org's "unaltered" table element specs matched the wiki mark-up for tables (.wikitable) foundation wide so that certain aspects of that universal default could -- if need be -- be overridden on a project-by-project basis by defining .prettytable afterwards locally was dropped for a single, customized, mash-up set of just .wikitable defs. Apparently, most projects just followed en.wikipedia's settings and, over time, started to use those definitions exclusively; completely dropping the .prettytable approach in the process.

Now, it feels like the defs in .wikitable have risen to the level where folks think its part of (or should be part of) the default stylings of skin(s). And so, the current .wikitable values are more about reproducing a specific type of table including a repetitive fixed set of customizations rather than simply insuring our mark-up is the same as w3.org's html table specs (e.g. - a 'universal' baseline).

I'm confused about what you mean by w3c specs. There are no specs for how things should be styled.

I suspect you are confusing default browser styles (which minerva resets via a CSS reset)?

Sorry if I wasn't clear - table elements do have default attributes with corresponding values -- some of them now long deprecated (such as cellpadding=, valign= and the like ) -- in the spec. Now, I don't consider all of those stylistic in nature though some do construe them that way -- as in the case of the "old" cellspacing=2 now a proper inline style amounting to border-spacing: 2px or the "old" cellpadding=1 is now padding:1px for table cells for example.

Change that padding:1px; to padding: 2px 3px;, its no longer the browser default (which are, for the most part, the same as the those defined in the spec). And when padding: 1px; was replaced (more technically; padding: 3px 2px; is added to the .css defs for that element) under the .wikitable class of defs, every project has that setting as well.

My understanding is at some point in the past, .prettytable would hold such 'deviations from the norm' and that is all that I hoped to point out.

Change 230957 had a related patch set uploaded (by Jdlrobson):
Make tables visible

https://gerrit.wikimedia.org/r/230957

Should be an improvement:

@Jdlrobson, yeah that is a massive improvement. Thank you very much.

Change 230957 merged by jenkins-bot:
Make tables visible

https://gerrit.wikimedia.org/r/230957