Not a good first task. It is not agreed much less known what the intended end state is.

Yes, the new category was noticed and quickly ignored since this pile of false positives exists.

Algebraic data type.

Or perhaps a [[Special:NewPage]] with a dropdown would also be fine? This would also help us get out of having to tell new users "make a red link and then click the red link" type of discussion that often occurs.

I thought about something like this a couple weeks ago. I'm sympathetic to the desire, but also generally agree that we shouldn't have such a dropdown.

It's a bit of outdated thinking here (not necessarily your fault): CSS content is now announced in many cases by accessibility agents (and not in others). Moving it into CSS isn't necessarily going to fix away whatever we think the arrow is doing here and whether it's actually necessary.

Usually better to use our own stats.

do away with date-based headings?

This is the subject of T10681: Do not group changes by day in enhanced recent changes with attendant linked tasks of interest, all more or less focused on "I want one diff, not 2-N". (Probably one not linked there is something like T21247.)

Could probably do this by extending the Javascript that adds the +x to quick add/remove pages from the changes view of watchlist.

No, it's not the same problem

Yes, it is precisely the same problem. But since you don't seem interested in moving forward on the point, I'll just move on.

The descriptions clearly discuss the same problem: I would like to know what the diff is since the last time I viewed a page. Whether that ends up being fixed with method A or B is not the point of a task, which should discuss the problem first/foremost and not necessarily specific solutions to the problem. That's why they should be merged even if I agreed that the two descriptions differ sufficiently not to be the same description of functionality intended. Which I don't. The distinction you see in your reading is not one I see in mine.

I'm going to decline this boldly. It opens a new path for non-obvious vandalism to be added to pages for at-best marginal benefits. The stated reason for reopening in 2008 was to adjust the appearance of text at an anchored target, but that has its own task for "redirects to sections don't always make a ton of sense".

Some skins do style the redirect arrow e.g. for dark mode, which appears to be inserted with CSS. So that will need to be reviewed as part of a change.

This message is suboptimal in multiple ways, and it's not just the original filer's confusion:

I think it just needed a title change, but wasn't sure since the original filing wasn't totally clear on the distinction.

I think it makes sense to scale what IP info provides relative to the permissions held.

The other shouldn't have been done by its lonesome, but yes, they probably should be merged at this point.

I'll close. Eyeballing the extension seems to indicate there is some HTML modernization to be done given the wide use of tables as well. One of which is for the diff view (which in core uses divs and CSS grid these days), and at least one other table use looks like it's presentational. A separate task identifying those issues seems more apropos.

It is already possible to use the suggested markup.

Edit block reasons

I'd still suggest dropping that regardless of the other link, but not? if parity with the old interface is the internal expectation. Users can search for the block rationale message if they absolutely must edit it for whatever reason.

This is template:Navbox, the styles are in Common.css or in TemplateStyles depending on the project, Navbox is copied everywhere. It's also ambox. Which is also copied everywhere.

Oh, looks like T378591: wikimedia/css-sanitizer 5.4.0 release did this.

Should file a task for that if we want it, that will maybe get the attention of the right users (or they can be pointed to such). I'll close the other one too.

Users might expect that the 'move to sidebar' button permanently moves the toolbars

They do if you're logged in but I'm not sure about readers. Are you requesting this for logged in users or readers?

@awight I think this request is covered by something or another in the T370027: [Epic] Parsoid CSS counter reset footnote numbering mechanism should be dropped in favor of plain text pile?

If I'm reading this right, I think this issue will be corrected once Cite-Extends is done.

Actually, not sure you need the "|-" before the caption -- so it can simply be deleted.

And in fact you shouldn't have it, as I stated above - leading at minimum either to Parsoid-should-fix-this for wt->html (I'm a bit agnostic going the other way) or Parsoid-should-lint-this. Again, this feels like something that may be common out and about, so one of those may be preferable.

And this change fixed the issue (you can verify that the lower table is still broken, it has the same setup as the old version).

The table has an extra empty <tbody> placed before the <caption>. Deleting that node in console causes the borders to reappear. You can also delete the tbody with the content in it to get the borders inside the thead to reappear. I think the thead is inserted by the table sorter Javascript (don't think that's particularly relevant to the bug but don't want to cause confusion with 'where does the parser insert a thead? - it steals the rows of column header ths from the tbody the parser does insert).

I think that should be good.

The issue with start and end without inline is that now you're forgetting there are languages that aren't just rtl/ltr but also top to bottom (I don't think there are any bottom to top languages). That's why they have the name 'inline', as in, the inline direction.

background-color-base is the closest token I think, but doesn't match #000, no. This is a task for Design-System-Team to decide I think.

Hmm, one other thing I've been mulling:

On the other hand, the fact that you can suppress all errors in a certain namespace by hacking "just" the cite-error message, instead of separately adjusting the dozen-ish cite-error-* messages, seems to be a feature.

I don't think it's a big deal if English Wikipedia has a few more messages/categories to customize such that it needs full on Community Configuration first. And as one might be able to see in that global search above, there's only about a half dozen wikis similar to en.wp on the point. I'd suggest just fixing what needs fixing.

I think the issue here is not that the table has many columns but that there is content up the way that is floating in this view and the table is narrow enough to be situated next to it instead of below it.

Another one that needs fixing: T377533: Recent changes doesn't have space after target title and before the reason part

In T377658#10244351, @Reedy wrote:

I suspect the fix for this is to import updated templates from the non beta projects

Also observable in Firefox on Windows. Removing the

@media screen and (min-width: 640px) {
  .client-js body.skin-minerva .mw-parser-output .ambox .ambox-learn-more {
    left: 32px;
    right: 0;
    background: none;
  }
}

block would fix it and align it where it is on mobile. On the other hand, this isn't something that is reproducible on English Wikipedia, so I wonder what Simple is doing particularly differently.

There is feedback on VPT that looping with only one image is a confusing user interaction. Buttons probably shouldn't be usable in that case.

In T377043#10240829, @awight wrote:

I'm not sure I get what you're thinking about here for class though, even after coming to know what a ChipInput is.

My idea here is that VE might show a "class" field when you click to edit a reference list, and that field can be used to add or remove additional styles defined by Cite, or defined by the wiki. Something like this:

The field could include some auto-completion when VE can figure out which CSS classes are applicable, but free-form names are also allowed and these might rely on class rules defined in Common.css or in TemplateStyles.

SpecialMobileEditWatchlist.php still appears to exist, with several other hangers on in codesearch. I think this is currently inaccessible except by any prior links that might be lying around?