T358921 was not linked above. While doing QA for this task, please try undoing this change in https://en.wikipedia.org/wiki/Template:Quote_box/sandbox to see if the spacing at the bottom of the quote box remains the same.

Signatures should definitely need to confirm Linter errors. That is by design, and it took us years to get it rolled out. See T355462 and its predecessors.

Also see https://www.mediawiki.org/wiki/Talk:Reading/Web/Accessibility_for_reading#Signature_disabled which illustrates a different kind of nesting.

This might be difficult to find, since the italics on either side of the URL may be marking up text that is outside of the link.

In what way is this a wikitext syntax error?

In T344378#9612102, @bvibber wrote:

In T344378#9611682, @Jonesey95 wrote:

If this condition is to be tracked and the communities do not get a say about whether it should be done at all, it should be done with a normal MediaWiki tracking category at Special:TrackingCategories. Tracking categories can be documented locally by editors from each community, hidden if desired, and ignored if necessary. That makes them a much better tool for this purpose.

Tracking categories don't include the location and target file information we have here.

In T344378#9612102, @bvibber wrote:

In T344378#9611682, @Jonesey95 wrote:

Using Linter to track missing alt text is a Bad Idea. Missing alt text is not a syntax error. Please learn from your big mistake in the "wide table" Linter tracking fiasco. Linter tracking is for syntax errors that can and should be fixed in all cases; missing alt text, like "wide tables", does not meet any of those criteria.

Note that linters don't track *errors* per se, they track potential issues which you might need to fix up with manual intervention.

Using Linter to track missing alt text is a Bad Idea. Missing alt text is not a syntax error. Please learn from your big mistake in the "wide table" Linter tracking fiasco. Linter tracking is for syntax errors that can and should be fixed in all cases; missing alt text, like "wide tables", does not meet any of those criteria.

In T358921#9609778, @Jdlrobson wrote:

It looks like the development team working on these vertical spacing issues needs a much more varied set of test cases.

MediaWiki engineers cannot possibly test every single template across all our projects - that doesn't scale well. I think in general it's a good idea to specify in the template exactly how it should be rendered and not rely on browser or skin defaults which can change any time. That ensures the design is future proof to changes.

Task T358921 was closed as a duplicate of this one. Please ensure that any test cases related to fixing this problem include the multiple situations described in that bug report.

This is happening for me today at https://en.wikipedia.org/wiki/Template:Random_slideshow on the English Wikipedia. If I switch to non-Parsoid, two normal categories and two hidden categories are shown. If it matters, I am using Vector 2022.

Additional vertical spacing problems, this time excessive padding around blockquote tags, has been reported at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&curid=3252662&diff=1211600813&oldid=1211518868#Excessive_indentation_of_block_quotations

Reported at https://github.com/wikimedia-gadgets/shortdesc-helper/issues/17 just to cover my bases. I am not a programmer, so submitting a pull request with modified code is probably beyond my skills.

I posted it a month ago with no response. It is unclear to me who maintains this gadget. I do not see a link to an official bug-reporting venue at the gadget's page, but I may have missed it.

Something possibly related to this series of changes messed up the symmetry of the padding at two en.WP templates. See https://en.wikipedia.org/w/index.php?title=Template_talk:Quote_box&oldid=1209709062#bottom-of-box_sizing and https://en.wikipedia.org/w/index.php?title=Template_talk:Talk_quote_block&oldid=1209711889#Ugly_bottom_padding

Yes, and thanks to the bug fixer!

Nothing appears to have been fixed. I just opened https://en.wikipedia.org/wiki/John_Dalton in Chrome for Mac OS, logged out, and when I inspect the "Special pages" link in the Tools sidebar on the right, I get this:

One way to start the discussion would be to create a wiki page listing all of the current Linter errors. For each one, figure out whether it can cause real rendering problems on pages (e.g. link-in-link errors cause real display problems every time; some unclosed tags cause all subsequent text to be smaller or cause subsequent sections to be nested inside an unclosed div). For obsolete tags, figure out whether support for obsolete tags is going to be removed. And so on.

This enhancement has caused Linter "span wrapping div" errors in pages transcluding some Special pages. See T275230 and https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1199067000#Possible_WP:ITSTHURSDAY_change_causing_Linter_errors

This appears to be happening with Special:RecentChanges/25 as of today. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1199013916 for an example.

Thanks for making that extra effort. The screen shots are nicely comparable now by switching two tabs back and forth.

It is difficult to compare the two screenshots, because they appear to have been taken with different screen resolutions. Also, one is logged in and one is logged out, so I can't tell if any user-specific CSS is being applied. Would it be possible to take two comparable screen shots. The second one does look promising, but without the same environment in each, I can't say for sure. Sorry to be so picky.

This bug description does not appear right to me. It seems like the bottom margin for the p tag is the problem, not the top margin for lists. I suppose the overall problem could be addressed from either direction.

It looks like this patch is waiting for someone to "schedule the change for one of the available backport windows". I read the relevant wikitech page, but it is way beyond my skills.

Another one, to help with tracking down the cause of this bug:
https://en.wikipedia.org/w/index.php?title=Cunobeline&diff=1192840869&oldid=1187335708

I also see the large, downward-facing black triangle after clicking directly on https://en.wikipedia.org/wiki/User:AnomieBOT/TPERTable when it is listed in my Watchlist as having changes.

Done =)

I guess I should have said that this is probably a zombie process, since the bot has not edited (on en.WP) in seven years.

This problem does not appear to be fixed in the Zebra redesign (see screen shot).

Same. Maybe the Zotero engine has been tweaked since the initial report. OK to close the ticket, I guess.

This bot is long-dead. I helped with getting it set up on the user specification side.

The OP's problem, as illustrated in the image uploaded on 7 December, is fixed at en.WP now. Thanks!

In T350833#9363957, @Sarai-WMDE wrote:

After some investigating, the Design System Team settled on initial values for the small text style of 0.75em with a line-height of 1.5 (translates to 12px/19.2px under 16px).

Like the rest of Codex's typographic scale, this is a work-in-progress style, and we were hoping to test the appropriateness of its values with help from the Web team.

Something to keep in mind: we went for such a small size in order to generate contrast with the default UI and body size of 14px.

Interesting. I don't know why all of that process would be needed for a serious error that can leak into the rest of the page, including the TOC, the right-hand sidebar in Vector 2022, the title, and just about everything else on the page. See https://en.wikipedia.org/w/index.php?title=User:Robertgreer/sandbox/NYCB/Saratoga&oldid=962070708 for an example.

It seems like it should be a relatively quick fix to get this to appear on the list of errors at Special:LintErrors. Is there anything that regular Wikipedia editors can do to move this ticket along?

It appears that the "signature too long post substitution" detection is not working properly. As an example, user Adam Cuerden is listed at https://signatures.toolforge.org/reports/en.wikipedia.org but their expanded sig is fine. The problem may be that the tool does not fully expand the signature before testing it. See https://signatures.toolforge.org/check/en.wikipedia.org/Adam%20Cuerden

Was it intentional that this change also applied to other text of lesser importance (and therefore semantically smaller in the design until this change) such as the text output by the short description gadget?

In T346062#9308576, @jhsoby wrote:

I'm sorry to be "that guy", but I'm not a big fan of this change. Having these elements (especially everything in #contentSub) a smaller font-size made it more immediately apparent that these elements are not part of the page content and are something else. Now everything sort of just blends together visually. Any chance of restoring the 13px size?

mw:Help:Images specifically says that images using the "right" option are supposed to float right, but the VPT thread contains a screen shot showing the header text overlaid on the image. I don't think "thumb" should be required to stop that from happening, unless mw:Help:Images needs to be corrected.

It appears that the WMF may be on the hook for updating the format of the link called "View detailed information on the lint errors" on the "Page information" page for any page having Linter errors. See https://en.wikipedia.org/w/index.php?title=User:WOSlinker/lint14&action=info for a current example of one of these links. The results show pages in two namespaces instead of just the page in question.

Thanks for the quick reply. We will see about getting the links updated. Thanks for this new namespace selection feature. I have already used it a couple of times to narrow the list of results, and it seems to work fine.

It appears that this change has been rolled out to en.WP. Is the breakage of existing links like https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag?namespace=0 (missing end tag errors in article space) intentional?

Please note that the above screen shots do not show the right-side toolbar.

Is this task related to a strange new development that we are seeing at en.WP? When we click an "edit" link from https://en.wikipedia.org/wiki/Special:LintErrors/deletable-table-tag?namespace=0 we get "action=parsermigration-edit" at the end of the URL instead of "action=edit".

Please don't revert the changes, which have been helpful overall. I have been adding line breaks before the noinclude tags to a few hundred template pages, and that seems to resolve this false positive error without changing the table's display.

Here is a similar case that was causing a Linter false positive error:

This is affecting dozens, possibly hundreds, of template pages. If it could be fixed soon, that would be helpful.

I found and fixed similar (and different, but still undetected) cases at:

• https://en.wikipedia.org/w/index.php?title=Catholicity&diff=1178578750&oldid=1176889179
• https://en.wikipedia.org/w/index.php?title=Eug%C3%A9nie_Foug%C3%A8re&diff=1178583792&oldid=1173473263
• https://en.wikipedia.org/w/index.php?title=Flying_Blind_%28film%29&diff=1178584874&oldid=1173845460
• https://en.wikipedia.org/w/index.php?title=HMS_Pilote&diff=1178612036&oldid=1124674850
• https://en.wikipedia.org/w/index.php?title=Pelargonium&diff=1178681708&oldid=1174661287 (this one is inside an sfn template, which is maybe a little different)
• https://en.wikipedia.org/w/index.php?title=KkStB_269&diff=1178675475&oldid=1070681481

Here's another pair of similar instances that are not detected:

If the 25em set in the above patch is not narrow enough, addressing one or more of the following might help:

This is still happening (diff from 23 September 2023). There are no more "link in link" errors in article space on en.WP. Please prevent the bot's code from making new ones.

It is challenging to have this conversation in this venue, because the back and forth is so slow. In your second example, you removed the padding, but that moved the TOC text to the left, and now it doesn't align with the left margin. That is undesirable. The content didn't adjust to the left as it should have. The goal of this padding reduction is to make more space for content and reduce readers' and editors' need to scroll vertically.

Possibly related:

In T344534#9174713, @Ladsgroup wrote:

In T344534#9174273, @hgzh wrote:

Should't the category be named wikihiero-usage-tracking-category?

Thanks for catching that, it doesn't matter that much as we hopefully undeploy this extension and this will be temporary.

I agree with Sj's comment above. In my browser window, which has 1,228 pixels of width for content, the space for content in this Zebra prototype is just 605 pixels, less than half of the available screen width. I came to Wikipedia for the content, and it is being served to me through a straw. In Vector 2010, the content is delivered in a box that is 1,032 pixels wide (84% of the available width), and there is still enough padding around elements to feel comfortable.

I'm still seeing double padding when I look at e.g. https://en.wikipedia.org/wiki/John_Dalton?safemode=1 in Firefox for Mac when I am logged in or logged out.

Can you please turn off this linter condition while it this task is stalled and on the backlog? The false positives for this linter condition result in a lot of noise on quarry reports that ask for pages with any linter condition on them.

In T306205#9115467, @ssastry wrote:

This is something I had once asked back in the day after Tidy had been replaced but didn't act on it - I think we should retire some of these linter issues. These existed to give editors a chance to fix up content that might have changed rendering. Given that Tidy is long gone, the rendering we see is what exists and if someone wants to change the appearance, they can do so without needing a linter category.

My proposal is to retire this and also examine all the other tidy-centric issues after examining which of those still have value in a post-Tidy HTML5 world.

Close as invalid (or no longer valid).

Either something has changed or I was wrong in my analysis. It looks like the bot/WPCleaner edit was technically incorrect, but understandable. This bug report can be closed.

Could this have been replag-related?

If a bot is deliberately programmed to use a template like Template:Ping or Template:U, a ping notification should be sent to the pinged editor. If a bot wants to link to a user page without using one of those templates, various kinds of wikilinks, including template-based links, are available.

This is by design, AFAIK. The documentation at https://www.mediawiki.org/wiki/Help:Images#Syntax has been updated since 2014 to explain how this works.

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!

See also T336316.

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?

A check for values of this kind could probably be added as a Linter "bogus file option".

Thanks for that. It appears that a bug fix has revealed this new bug. That's software development for you.

T327732 was closed, and the vertical spacing between items and the font sizing in Zebra is still a mess. See also T327718 for details. I was sent to this ticket from that ticket.

I guess we could, but T327732 was closed, and the vertical spacing between items and the font sizing in Zebra is still a mess. Is there a ticket that is still open to address these problems?

This Linter tracking should be disabled and refined via queries and reports until the actual problem conditions and criteria are understood.

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.

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

I don't see how having an image in the first column, or not, is relevant to the width of a table. If this test is going to work, it needs to test for the actual conditions that make a table too wide for mobile or for a reasonable width of a content column in the most prevalent skins.

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.

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

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

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.