"Other formatting" should include support for font size and line height, so that tables like the ones seen at https://en.wikipedia.org/w/index.php?oldid=608813235#Early_years will display with the correct row height.

(In reply to WhatamIdoing from comment #1)

"Other formatting" should include support for font size and line height, so
that tables like the ones seen at
https://en.wikipedia.org/w/index.php?oldid=608813235#Early_years will
display with the correct row height.

No, that's a bug caused by VE assuming that table cells' paragraphs should be styled like other paragraphs. That's a fix to styling rules, nothing to do with editing them to have custom styles. Could you file a new bug?

This issue of table cell paragraph formatting is now Bug 65416.

In terms of the scope for this item: I'd like (Howie) to be able to create this table in VisualEditor: https://www.mediawiki.org/wiki/File:Product_stages_and_players.jpg

I'm not entirely sure how to do it in wikitext, but that's what I want to be able to do.

There's a strong use case to not let this be something people do. The colour in your example adds almost no value but massively distracts from the readability, accessibility and utility of the information being conveyed.

Note that standardised styles (by the software or by local wikis) for tables can be developed and provided through program code (instead of through article content) by declaring them in CSS stylesheets (such as MediaWiki:Common.css).

I'd say it'd be an improvement if VisualEditor has an interface that can apply certain css classes to a table. Especially ones provided by MediaWiki core, such as wikitable, sortable, and mw-collapsible. (Though ideally through an intuitive interface, and not a free-form text field; which requires users to know internal software class names.)

And potentially a few other class-name / label combinations provided by the local wiki. There's definitely a use case for having more than one type of table for all of Wikipedia.

The colour...distracts from the readability, accessibility and utility of the information being conveyed.

Making it possible and even moderately easy to render this image in a table instead of in an image would IMO be a significant improvement in the readability, accessibility and utility of the information. For example, someone with a screen reader could actually read it, and anyone could edit the contents.

I'm not looking for fruit salad in encyclopedia articles, but when someone wants to create a table like this, I want them to think "Oooh, I can do that in VisualEditor", not "I'll draw this in Adobe Illustrator, export it as a jpeg, upload it to Commons, insert it on a page in mediawiki.org, and every time someone needs to have a simple typo fixed, I'll repeat that process."

In T54180#966351, @Jdforrester-WMF wrote:

There's a strong use case to not let this be something people do. The colour in your example adds almost no value but massively distracts from the readability, accessibility and utility of the information being conveyed.

Probably strong case not to use it in Wikipedia, but what about Wikiversity. You may need to highlight cells just to be more atractive for the students or to be able to count someting better. I thing advanced MS Excell of Google Tabs already allow to search by table cell bg color.

I wonder if it could be a feature that is configurable per-wiki, or ideally per-namespace at each wiki. Then you could get (for example) teaching materials at WIkiversity that use it, but keep it out of the article namespace at the English Wikipedia. (It would still need to accept copied/pasted tables, and maybe have a 'remove this background color' button—which we need anyway, because of tables copied from other websites.)

So the option per wiki is the best choise I guess. Namespaces are not standardized yet on some wv projcects.

In T54180#971085, @Whatamidoing-WMF wrote:

I wonder if it could be a feature that is configurable per-wiki, or ideally per-namespace at each wiki. Then you could get (for example) teaching materials at WIkiversity that use it, but keep it out of the article namespace at the English Wikipedia. (It would still need to accept copied/pasted tables, and maybe have a 'remove this background color' button—which we need anyway, because of tables copied from other websites.)

So should I understand your statment like we need community consensus for that?

In T54180#966571, @Krinkle wrote:

Note that standardised styles (by the software or by local wikis) for tables can be developed and provided through program code (instead of through article content) by declaring them in CSS stylesheets (such as MediaWiki:Common.css).

I'd say it'd be an improvement if VisualEditor has an interface that can apply certain css classes to a table. Especially ones provided by MediaWiki core, such as wikitable, sortable, and mw-collapsible. (Though ideally through an intuitive interface, and not a free-form text field; which requires users to know internal software class names.)

...

Agreed. One of the most common "deviations" made to table element defaults is changing the vertical-align of all (or nearly all) of the table cells in a table to render top rather than default middle.

Most folks assume this requires changing the default vertical-align value per every TR or per each TD within a table but the default is actually ''inherit'' for these elements - set by tbody, thead or tfoot which actually has the vertical-align:middle setting.

Understanding the tbody element is not 'shown but always present' we can still simplify the table rendering of cell content throughout an entire table by making a simple .css addition to the default stylesheets such as...

.valign-td-top > tbody {
	vertical-align: top;
}

... in turn, setting table class="valign-td-top" is all the user needs to add (either manually or by design in a VE table option) to accomplish top rendering of content.

Worst case scenario is the user needs to [re]adjust the TH header row's vertical-alignment back to middle - far less work than applying inline styling to each TR or every TD as is the case now.

In T54180#969564, @Juandev wrote:

In T54180#966351, @Jdforrester-WMF wrote:

There's a strong use case to not let this be something people do. The colour in your example adds almost no value but massively distracts from the readability, accessibility and utility of the information being conveyed.

Probably strong case not to use it in Wikipedia, but what about Wikiversity. You may need to highlight cells just to be more atractive for the students or to be able to count someting better. I thing advanced MS Excell of Google Tabs already allow to search by table cell bg color.

This looks like a (really) strong use case for a class to be applied to a row/cell, not random style, if in fact "highlighting" is being used in multiple places.

I would tend to agree that random color should not be "doable" in VE, while permitting the addition of classes may be valuable (especially .wikitable if no others).

If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit: https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704 But he did, and therefore there is a reasonable use case to be made for having that ability.

In T54180#2169644, @Whatamidoing-WMF wrote:

If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit: https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704 But he did, and therefore there is a reasonable use case to be made for having that ability.

Please re-read my comment, where I accepted highlighting, as in a table, as a valid use case. But I'm also going to point out that the same information can and should be conveyed by a class, so that we can better enforce accessibility, if no other reason.

See also T37704: Drop support in wikitext for inline styles and T89134: Removing inline CSS/JS from MediaWiki.

This was requested again at https://www.mediawiki.org/wiki/Topic:Vcflv3wnvk90yycr by @Guarapiranga. I think that this or similar requests appear a couple of times each year.