This tracking "category" is called "Big Tables that are hard to view on mobile" because it was motivated by degradation of the mobile view, but it currently contains many pages like https://en.wikipedia.org/wiki/Template:HBO_Max, which is a navbox. Navboxes are famously not visible on the mobile site. Please filter navboxes and other "nomobile" pages out of this Linter error check.

https://www.mediawiki.org/wiki/Help:Extension:Linter/large-tables needs to be filled in by knowledgeable WMF staff.

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1154302884 lists this tracking flag even though there is only one infobox on the page, and it is 240px wide in Vector 2022 on my computer.

In mobile view on my computer, the infobox is 404px wide, and the medal templates do not display properly (the table cell for the bronze and gold medal icons is too wide). It is unclear whether this is a problem that should be fixed in the medal templates or in the mobile skin.

I removed the medal templates, resulting in https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1154303937 which is 320px wide on mobile and does not trigger the tracking flag.

https://en.wikipedia.org/wiki/Template:WPBannerMeta is also causing this tracking flag to be applied, even though it does not display in mobile.

@Jonesey95 thanks for the examples we'll look into them as part of this spike. (We were expecting false positives when building this).

The name "mobile" in the title however is misleading. We're also worried about how they cooperate with the limited width, so navboxes are very much in scope.

In T336316#8845156, @Jdlrobson wrote:

@Jonesey95 thanks for the examples we'll look into them as part of this spike. (We were expecting false positives when building this).

The name "mobile" in the title however is misleading. We're also worried about how they cooperate with the limited width, so navboxes are very much in scope.

If the name "mobile" in the tracking flag descriptor is misleading, let's change it. Let's not lock in a bad descriptor at this early stage when other refinements also need to be made.

What is meant by "limited width" in this context? When I shrink a flagged page like https://en.wikipedia.org/wiki/List_of_American_films_of_2022 in Vector 2022 logged-out view to a 690px content-column width, the page's tables and navboxes look fine to me. (If I view the page on my iPhone (14, large but not giant), the navboxes are obviously not an issue because they do not display, but the page's tables are truncated on the right, so the tracking flag is probably correct, but not because of the navboxes.)

What are the criteria for navboxes working in limited-width view? How do we filter out pages where the navboxes are fine in limited-width view?

DISREGARD. This comment was added during a time when the deployment train had been backed out. Detection of this table works properly. DISREGARD.

This six-column table does not trigger this new Linter flag in LintHint or on Page Information:

{| class="wikitable"
|+ Caption
! Header cell 1!! Header cell 2 !! Header cell 3 !! Header cell 4 !! Header cell 5 !! Header cell 6
|-
| Content cell 1 || Content cell 2 || Content cell 3|| Content cell 4 || Content cell 5 || Content cell 6
|}

See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1154319881

[Note: This comment was added after the latest train had been backed out, I believe. This may end up being a false report.]

The name of this flag should probably contain "wide table" instead of "large table". The length of tables is not an issue, AFAICT.

Yeh wide table seems like a good name!

For Vector 2022 as a logged in user make sure main menu and toolbox on right (might need to expand more menu) are open. The criteria is that the table should fit in the middle without overlapping the toolbox on the right.

Thanks for flagging the example not working. Sounds like something might be going wrong there. I know there were some last minute changes so maybe they didn't make the train cut.

In T336316#8845128, @Jonesey95 wrote:

https://en.wikipedia.org/wiki/Template:WPBannerMeta is also causing this tracking flag to be applied, even though it does not display in mobile.

An example of this can be seen at https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Categories/uncategorized where the page displays just fine on mobile (it has no tables in the mobile display) and shrinks perfectly in the limited width of Vector 2022.

When I run ExpandTemplates on that page, I am unable to find a table that is more than two columns wide. The current test is supposed to look for tables that are more than five columns wide. I may be missing something.

Navboxes in general do not appear to cause width problems, but https://en.wikipedia.org/wiki/Template:Public_transport_in_Bangkok is a navbox that, in its expanded state, overlaps into the right toolbar, even with a Vector 2022 content column that is 860px wide.

The lead section of https://en.wikipedia.org/wiki/Lake_Lemuria is flagged, even though the widest table row I could find has two cells, and the infobox renders for me at 288px wide. The Multiple issues template also shrinks down just fine.

hiero tags appear to cause this tracking flag to appear: https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1154873518

A nested table with just four columns triggers this flag: https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1154910671

Thanks for the thorough review @Jonesey95 I've created T336679 which seem to cover all the cases you've flagged above.

My review was not at all thorough, but thank you for noticing my contributions. There are far too many false positives in the lists right now to do a careful review.

I think that the refining process for flagging these wide tables should be more like query development than normal MW code development: run the query, identify a few false positives, fix the query, run it again, and keep iterating somewhat quickly until the number of false positives is low.

Only then should a report be exposed to a wider audience, and not through Linter, which identifies actual syntax errors, which this is not.

Drop a note on my talk page if you or someone else would like to work on a query for identifying wide tables that cause problems.

Here's another pretty minimal nested table, using [[:en:Template:Clade]], that is definitely not wide but that triggers this new flag:

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1155021495

On my screen, this content is about 48 pixels wide.

This very buggy new Linter tracking tag (which does not appear to have anything to do with invalid or deprecated syntax) has seen no modifications in the weeks since its deployment. It is increasingly getting in the way of editors who are trying to fix actual syntax errors. See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Linter&curid=55873426&diff=1156282913&oldid=1154879111 for a current discussion.

Can this check please be disabled until better criteria have been developed and tested? We have worked to deliver plenty of feedback, including that this "wide table" tracking should happen somewhere other than under the Linter umbrella. Queries and reports should suffice until the true nature of this condition is understood and there is a plan for addressing it.

Thanks for considering this request.

The crux of the issue here is that the original task was not implemented per the specification. The expectation was that the lint was meant to be flawed initially, and that it wouldn't be shown to editors. The latter part of the contract hasn't been uphold, so this needs to be fixed ASAP. That will be done in T337275 - let's continue any conversation about the lint's existence there.

This task should hopefully be started week of 5th June, provided it's estimated and I'm not expecting anyone to spend more than a day identifying the common problems with the lint and create tasks to fix those and improve the lint overall.

https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag-in-heading errors appear in LintHint and on Page Information, but the error does not appear in the list at https://en.wikipedia.org/wiki/Special:LintErrors. Is this intentional? If not, can someone please add the error to the LintErrors page?

Also, I created a stub Help page at https://www.mediawiki.org/wiki/Help:Extension:Linter/missing-end-tag-in-heading, but if the creator of this new error type wants to describe the error and its fixes in a better way, please do so.

@Jonesey95 that does seem like a mistake. Can you open a new Phabricator ticket to get that enabled?
Thanks in advance!

In T336316#8998038, @Jdlrobson wrote:

@Jonesey95 that does seem like a mistake. Can you open a new Phabricator ticket to get that enabled?
Thanks in advance!

Created at T341369.