HomePhabricator

Slightly increase wikitable padding

Authored by MZMcBride.

Description

Slightly increase wikitable padding

A friend of mine suggested that increasing the wikitable padding improves
readability and looks cleaner. Leaving the print padding untouched.

Change-Id: I7f6f8850ab47bed5e158b3aa8c6b49170ce6e910

Details

Auditors
Edokter
Committed
oriFeb 13 2015, 1:02 AM
Parents
rMW147196cdaeee: Merge "backupTextPassTest: Disable checkpointHelper test"
Branches
Unknown
Tags
Unknown
ChangeId
I7f6f8850ab47bed5e158b3aa8c6b49170ce6e910

Event Timeline

Edokter raised a concern with this commit.Feb 26 2015, 2:40 PM
Edokter added a subscriber: Edokter.

Where is the task discussing this? This is not a "slight" increase, it's doubled, and it is very noticable. It also messes up table based templates like infobox that rely of default wikitable styling.

I'm not sure this ever had an associated Phabricator task; discussion largely took place on Gerrit at https://gerrit.wikimedia.org/r/188311.

What's messed up? I don't believe the "infobox" class should have been affected here.

Can't find any off-hand, but there are template relying on it. Also tables are known to fight for space, and this doesn't help. Regardless, such a visual change should have been initiated as a bug/task.

In general, I agree about filing a task. I actually thought you were added as a reviewer to https://gerrit.wikimedia.org/r/188311, but there are so many changesets, I'm probably just confusing this one for another.

I think it's a better idea to fix broken templates as we see them than to revert this patch, at least for the horizontal padding.

The change in padding is also causing some minor issues with RJLs (road junction lists, or the exit/junction list tables in highway articles). On some RJLs, it is necessary to specify that an intersection or interchange is located on the line dividing two counties or two municipalities. In doing so, the county or location is listed as "Foo–Bar county line" or "Foo–Bar city line:, etc. The text already won't wrap at the en dash, so the column gets a bit wider. Toss in a case with a complicated situation at one of the interchanges requiring slightly verbose notes, and https://en.wikipedia.org/wiki/U.S._Route_23_in_Michigan#Exit_list gets a RJL table where the Destinations column is squished on non-widescreen displays due to the extra padding.

The change also messed with the formatting of project statistics at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Germany/Sidebar. A very crowded table, which is used by a lot of en-Wiki projects as statistical overview - albeit with different formats and styles of embedding it.

As someone who works with wikitables all the time I am very unhappy with the padding change. Most of the time I am working on wikipedia I work on results tables (Most of the time motorsport results tables). Those result tables need to be tight so you can put 20-sometimes 56 or more races in one table. Example: https://en.wikipedia.org/wiki/Dave_Marcis. Now that the padding has changed (doubled) these result tables are way bigger than they should be. This makes them harder too reed and untidy. I really don't understand why the padding has doubled. This affect every single table on wikipedia. I am really disappointed and upset that this affects all the hard work I have put in to create all these results tables. What's going to happen next? I mean the padding being doubled is'nt a minor change. Particularly when this affects almost all the tables on wikipedia. Is their a possibility that this change is going to be reverted?

If this is so bad that it can't be fixed for individual tables (and I'm not convinced it is--Imzadi1979's link looks fine to me, and would inevitably have line breaks at smaller resolutions even without the padding change, anyway), please just add an override in common.css on wikis that don't want this change, rather than reverting this. The new value is better where the table isn't absolutely packed, and wikis without such a large body of existing tables would benefit from it.

The bigger padding is not necessarily better for all tables. I think this is a way to big change that affects way too much tables. All the result tables I added to wiki are now way to big than they should be. Maybey an induvidual table code with they old padding is an idea?

GOIII added a subscriber: GOIII.Mar 1 2015, 7:46 PM

The more uses of the wikitable class I come across, the worse this change looks. Putting the "doubling" point aside, cell-padding has always been uniform for all 4 quadrants (top, right, bottom, left) since the early days of HTML 3.0 and the old cellpadding="#" attribute [now deprecated]. Switching to top & bottom vs. left & right differing values is contrary to that initial logic as well current css rationale that superseded it. In short, all cell-padding "should" be 0.2em or 0.3em or 0.4em; not some combination of those three units of measurement.

Plus the wikitable class doesn't live in a vacuum -- other defined classes do seem to augment/supplement it more than I previously would have thought. Throw in the use of ''vertical-align: top ( or bottom) to deviate from the default middle and that improved readability rationale starts to evaporate fairly quick.

Isarra added a subscriber: Isarra.Mar 1 2015, 7:51 PM

As a general rule, tables that expect a specific padding, font-size, or page width are poorly designed and need to be re-examined. No table will necessarily display consistency across different devices, skins, or even browsers; that's just something that needs to be considered when making them in the first place.

A prime example is the sidebar GermanJoe linked - it will not display properly in vector even with the original .2em padding; it seems it was designed with either monobook or another similar skin in mind, or at least pre-typography refresh vector. But even on those, people may increase text size for legibility or wind up with wider fonts due to different operating systems or visual needs (eg dyslexia), so making assumptions about the size of the content text is not a valid approach.

I'd appreciate any advice on my en-talkpage to improve that 8-years old sidebar, but am no expert table editor myself (not even close). But that's a bit beside the point: the implemented padding change provides little measurable benefit and causes unnecessary problems in several common use cases.

In https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Germany/Sidebar
Even if I reduce the table padding back to 0.2 (or even 0.1) it still goes off the edge of the page, creating horizontal scrollbars: https://i.imgur.com/mmsIrL6.png

+1 to what Isarra wrote. We can never assume visual consistency. Things like customized window-size, font-size, monitor-brightness, and interface-language, can create huge changes for large percentages of users. Plus of course all the browser/OS inconsistencies, and font-availability issues. WYSINEWEEWS (what you see is not exactly what everyone else will see) !

On the change itself, I don't have fully-thought through views yet. I'd like to see more examples of pros/cons (ideally in screenshot + live-link). Perhaps we should move this onwiki?

Risker added a subscriber: Risker.Mar 1 2015, 11:09 PM

I'm disturbed that this "improvement" was made without any attempt to identify the impact of the change. As it stands, about half of the tables I've viewed on English Wikipedia have been affected negatively by this change. That is suboptimal for both editors and readers. Readers wonder why our tables look so awful and even less professional than they did before, and the majority of editors have no idea how to resolve the problems, since only a small minority of active editors work on templates.

It's all well and good to say "well, they were badly written tables in the first place". Their format produced the desired result beforehand, and it doesn't anymore. When this happens in other WMF-controlled modules (q.v. VisualEditor), pitchforks are sharpened and torches lit. Telling people to apply special scripts to their user css in order to "solve" the problem created by a patch is not a solution.

Ahecht added a subscriber: Ahecht.Mar 1 2015, 11:34 PM

I still don't see what problem MZMcBride and their friend were trying to solve. There was no real problem with the way tables had been displayed for years on Wikipedia, and while some tables might be improved by this change, a large number have become difficult to view for readers with smaller or lower-resolution screens. For most font sizes, a padding of 0.2em is already larger than the 1px HTML default.

wctaiwan removed a subscriber: wctaiwan.Mar 1 2015, 11:46 PM

I can see how the new padding makes reading tables easier, but this adds too much space. I'm more concerned with the vertical padding than the horizontal.

@Risker: Regarding "affected negatively," do you have links to what you're discussing? https://test.wikipedia.org/wiki/Wikitable_padding has a before and after comparison, by the way.

I'm still interested to hear specifically how you think this change should have been proposed. If you could document such a process, that would be even better!

@Fredddie: Do you mean the change from 0.2em to 0.3em for the vertical padding? There was a concern about too big a difference between the vertical padding and horizontal padding. I would have preferred 0.4em (or 0.3em) all around.

@GOIII: I don't believe anybody touched vertical-align in this change... I'm not sure what you mean. I agree with you that more uniform padding would be nice; 0.3em 0.4em was a compromise between 0.2em 0.4em and 0.4em.

@Ahecht: You can see a comparison at https://test.wikipedia.org/wiki/Wikitable_padding. A padding of 0.2em all around is pretty tight. Increasing the padding seems to improve readability in many cases.

Krenair added a subscriber: Krenair.Mar 2 2015, 3:09 AM

@MZMcBride I like the 0.2em 0.4em option the best

ori added a subscriber: ori.EditedMar 2 2015, 7:40 AM

Readers wonder why our tables look so awful and even less professional than they did before

The number of mobile internet users rose from four hundred million in 2007 to 1.6 billion last year. Readers with even a modest amount of exposure to the web will have seen content awkwardly compressed and dilated before, as the diversity of form-factors, screen resolutions and color depths have increased sharply. The notion that a substantial number of readers are perplexed by quirks of layout is not credible to me. Our readers probably just expect us to fix things, which I believe we can do by rewriting templates so that they make fewer assumptions about the exact properties of the technology used to display them.

Ahecht added a comment.Mar 2 2015, 4:02 PM

Jahn1234567890's example can be seen at https://en.wikipedia.org/wiki/User:Ahecht/Dave_Marcis

The new table requires horizontal scrolling, but the old table fits on my screen.

GOIII added a comment.Mar 2 2015, 10:00 PM

GOIII: I don't believe anybody touched vertical-align in this change... I'm not sure what you mean. I agree with you that more uniform padding would be nice; 0.3em 0.4em was a compromise between 0.2em 0.4em and 0.4em.

All I meant was the "test bed" supposedly used either had all short, single line content per table cell or 1 long wrapped content in a single cell. There was no mixing of the two where the left table cell needed to be top aligned to make its larger sister cell make "sense" is all I was trying to say (the lack of uniformity would more prevalent then).

Moving on & bit off topic, the crux of this issue starts with the current state of 1st generation skins overall (imho). CSS3 affords some new solutions to old deficiencies &/or previous work-arounds plus the previous browser disparities and levels of support are diminishing with every new release/update. A compete review and overhaul -- not a "refresh" -- might be in order.

Edokter added a comment.EditedMar 7 2015, 6:13 PM

Continued at T91891 T91890.

Edokter accepted this commit.Apr 28 2015, 2:16 PM

Closing, as padding has been adjusted.