@Edokter, I tried to take a fresh look at the discussions related to wikitable padding on Gerrit, on Phabricator Diffusion, and on the English Wikipedia.

I'm still a bit unclear on your views here. Looking at https://en.wikipedia.org/w/index.php?title=User_talk:Edokter&action=info, do you think 0.2em padding is best? In my browser, it feels cramped and I think it improves readability to increase the amount of padding. Others seemed to agree when I asked them on Gerrit and in real life.

Do you have any thoughts on increasing (doubling, perhaps!) the wikitable padding to 0.4em or 0.3em or 0.2em 0.4em? I want to try to understand your point of view so that I can figure out if there's a chance for agreement.

Created a duplicate task (T91891) shortly after this one. So copying key point here:

The actual change increases the spacing in wikitable cells. Table real estate is already tight and increasing the padding makes tables even bigger in height and width. Templates that rely on standard wikitable metrics ase affected. Editors seeking to minimize the padding are forced to do so with inline CSS in every table cell.

I'm seeking to revert this change, or otherwise at least discuss this change as if it were proposed here. It that would result in approval, then so be it. My biggest concern is that a change like this which has major visual impact was merged with minimum review.

I know the horizontal padding is tight, but I believe that is because real estate in tables is premium in most uses. So any increase will cause a number of tables to be wider that the display window, necessitating horizontal scrolling.

Vertical padding now seems overdone as well; the line-height is already 1.6em (on Vector). It is the vertical padding that mostly affect templates based on wikitable, and it is also the biggest visual change. Long tables no takes more scrolling.

At least the vertical padding should be reverted to 0.2em, as that was never really a problem. Having tested with horizontal padding a bit, I'm willing to give 0.4em a try, as it doesn't interfere with line-heights, and it does seem to even out both vertical and horizontal padding. So 0.2em 0.4em would be acceptable, barring we don't hear any complaint about exceeding table widths.

From the other one:

Aside from looking better in the base case (wikis with a lot of hacks tend to have exceptions to this), basically it seems to boil down to issues with scanability due to the density of the text, especially in tables with very consistent amounts of text per cell. Less padding means all the text is much closer together, which means it becomes potentially significantly more difficult to quickly scan through a table and find individual cells, even if you already know what you're looking for. Even with isolated cells, having a left/right borders right next to the text, because it messes up with how we scan text based on the shapes of words; the nearby lines look like they're part of the words, changing the shape.

Having more padding does raise potential issues with screen space, but this applies far more to the vertical padding than the horizontal; extra horizontal padding is generally equivalent to having a few more characters in the line, whereas vertical will make the entire table feel much taller, especially on top of the already significant line-height. Unfortunately having only increased horizontal padding causes it to look bloody strange when using images in the table, however I have no idea how common a use case this is in practice.

What I am seeing here is a lot of highly subjective opinion about what "looks better". On poking around on a few text-based software programs that permit table creation, the default seems to be 0.2 em pretty consistently. Tables that are in existence now were designed with the pre-existing defaults in mind (either finding them acceptable for the table design, or including variants from the default in the design), and any that used those defaults in their design will now have to be reviewed for formatting problems.

What I don't see is any objective information (reference sources, studies, established design principles) that supports the change in default sizing. It does seem counterintuitive that, at a time when readers are moving more to smaller and less flexible screen sizes, we'd want to take up more screen real estate in tables. Wide tables were hard to read on small-screen smartphones before, and they're at least as hard to read now.

Frankly, I'm rather astonished that there doesn't seem to have been any comment about this change from design specialists. At the end of the day, this comes across as a couple of people who have the ability to get their design preferences incorporated into the project doing so with almost no feedback and no actual objective evidence of the value of the change.

In T91890#1098647, @Risker wrote:

Frankly, I'm rather astonished that there doesn't seem to have been any comment about this change from design specialists. At the end of the day, this comes across as a couple of people who have the ability to get their design preferences incorporated into the project doing so with almost no feedback and no actual objective evidence of the value of the change.

And to think, we allow these non-specialists to build Wikimedia. ;-) MediaWiki is as much a volunteer project as Wikipedia. I think we try to evaluate ideas based on merit, not based on author (or author relationships).

What do you think about 0.2em 0.4em? There's a demo here: https://test.wikipedia.org/wiki/Wikitable_padding.

Too much Wikimedia staff control over MW development, too little Wikimedia staff control over MW development. Can anyone win here?

@Risker: There are separate wikitable CSS rules for mobile. Mobile is still using "padding: .2em;".

@ kaldari, lots of people use the desktop view on mobile, especially on tablets - some of those screens are as big as a laptop's.

@MZM, looking at that test page:

• I see absolutely zero difference in the "large block of text" test in the bottom. (yeah, there should be some, but absent having a little ruler up against the screen, I'm not seeing it.)
• For the other two, I see no difference in text legibility. The extra space around the image in the top example looks as though you put in the wrong sized image, and makes it more obvious that the left and right margins are not the same size. The selected image doesn't allow comparison of the top margin because of the lack of contrast.

I'll note in addition that I don't necessarily expect that the design folks should have control over this particular item, but I am surprised that (a) they weren't consulted for actual studies on white space margins in tables or pinged to ask for their expertise/knowledge and that (b) there were no comments at all from the team (whether pro, con, or indifferent) on an area where I'd fully expect them to have some opinion, especially since this is tagged with a "design" label.

@Risker, Hello! The Design tag on phabricator has over 600 tasks in it, and the list grows every day. To triage, formulate rational thoughts, reply, much less create mockup for each one would require a team 3-10x the size we have. I'm very happy and thankful so many users care so much about design to log issues like this, and other similar ones, but the reality is that we don't have the bandwidth to address each one.

I do feel "Padding 0.3em 0.4em" is the most readable of the proposals, but I also think this should be a skin specific value, I'd also push for increased semantic markup of tables, and infoboxes that that designers and developers (community and foundation alike!) are able to have more control over how these elements are displayed in different contexts.

I have incorporated 0.2em 0.4em for testing on enwiki. Any progress here?

In T91890#1120760, @Edokter wrote:

I have incorporated 0.2em 0.4em for testing on enwiki. Any progress here?

I'm obviously quite biased, but I think almost every other wiki is fine with the new default value (0.3em 0.4em). Maybe the English Wikipedia would be willing to give it another try?

That is not much of an argument... I could say no one has made an issue of 0.2em either. 0.3em is just too high and unbalances the horizontal/vertical padding. I conceded to the horizontal padding being too tight, but there was nothing wrong with the vertical padding. So unless there is an actual case for the vertical padding... don't change what's not broken.

I think you could submit a patch for core for "0.2em 0.4em" and it would be accepted/merged. There was support for that in https://gerrit.wikimedia.org/r/188311. Though I'd still urge considering 0.3em or 0.4em on all sides. And I still like the compromise position (0.3em 0.4em), as much as one can like a compromise. :-)

Noted and considered. 0.3em vertical is still too high. I'll submit a patch shortly.

Change 198557 had a related patch set uploaded (by Gerrit Patch Uploader):
Partially revert increased wikitable padding

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

Change 198557 merged by Bartosz Dziewoński:
Partially revert increased wikitable padding

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

Change 202907 had a related patch set uploaded (by Bartosz Dziewoński):
Partially revert increased wikitable padding

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

Change 202907 merged by jenkins-bot:
Partially revert increased wikitable padding

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