Yes, red linked contribs will work.

It does not. The content gets stuffed into a data-mw attribute value.

Yes, there's effectively no way to fix that without introducing templates that output the set of styles for a table and then changing all the template uses to manually added classes.

This task looks like it might have adjusted the vertical spacing unintentionally; the preview line was more attached to the form below it than the form above it before today's deploy.

In T409187#11413983, @Krinkle wrote:

In T409187#11343199, @Izno wrote:

There are uses of data-mw in mainspace […]

These are not "uses". [...]

That's good to know. The main point of that comment was actually the second half of the sentence i.e that they're probably there due to bugs in CX/VE (and so perhaps not something to care about in this context).

In T410636#11408855, @Dreamy_Jazz wrote:

Personally I think just displaying the last IP used in most cases is at best confusing and at worst misleading. [snip]

This task (or at least attributed to this task) has been noticed onwiki and not in the intended way. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.mw-userlink_now_applied_to_non-interface_parts_(edit_summaries)

then the most recent IP address by which the temporary account is blocked for the same duration as the temporary account.

You may make this feature request on Commons wiki. The location of the ds is subject to editor consensus and not a feature of the MediaWiki software.

Would need verification that mixing and matching in the children didn't suffer ill effect, but using the child combinator > should work.

In T14302#11398485, @doctaxon wrote:

for German Wikipedia and error page for: https://de.wikipedia.org/Navire I don't know the right place of the code, but by PHP I suggest: [snip]

This color, and some others, are set in https://fr.wikiquote.org/wiki/MediaWiki:Common.css#L-33 . This is something for the local wiki to fix.

It also makes it a pain to debug some styles in production, such as I had to do for T409488. Having to turn off 4 rules times 3 selectors isn't fun. :)

I'd probably trim the link text to suggested investigation #36 since investigation and case are the same intent.

Code search: A bunch of false positives, and then a handful of nots:

The other aspect that is implied in the title but isn't explicit is when the TA is deliberately logged out of.

In T409488#11351721, @Izno wrote:

I am not sure there's a way to do that in CSS. In CSS content we have access to attribute values.

Yeah, nixing the display: flex on the container also half-fixes it (it doesn't fix at least one aspect which is the borders looking odd).

And in general, that line is simply wrong I think for what it's intending to do, which is relying on the value set in the size attribute to set the width of the item. I am not sure there's a way to do that in CSS. In CSS content we have access to attribute values.

I've corrected Help:Extension:Media Viewer to reflect the current state of the software.

Yes, that looks like it to me also. Probably should just also check isTemp() also.

In T354228#11338860, @Bawolff wrote:

I'd propose that we abandon following specific specs, and instead use baseline of -3 years ago (So right now that would be baseline 2022). This would roughly correspond with what mediawiki's browser compatibility is for grade A browsers - https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

I see a couple gadgets on he and hu wiki also that seem to care about the property.

There are uses of data-mw in mainspace (never mind others) but I would guess all of it is being pooped out of ContentTranslation or VisualEditor via copy-paste bugs or similar.

In T318176#11324486, @cscott wrote:

I'd specifically like to know how the .mw-editsection-bracket and .mw-editsection-divider elements are read, and whether there is anything we could/should do to improve that.

Well, the button role is there to indicate that there is an interaction that can take place for people who otherwise wouldn't learn. Maybe it doesn't matter for a screen reader for whom it probably does not provide a jump-to-next-section anyway, which is approximately what collapsing a section intends for sighted users?

The sign-up at auth.wikimedia.org to report a bug has a field for "Email address (optional)" but later in the process an email address becomes mandatory.

As for this issue, I believe the reason you are being asked for an email later in the process is due to an entirely separate rollout taking place intended to limit abuse, which is WE4.2 Bot detection (WE4.2 hCaptcha editing trial) .

You don't need a screenshot to see that en.m.wikipedia redirects to en.wikipedia.

It is generally not a good idea, when asking for help, to be snarky.

And potentially also T177128: Librarization of HTML and Sanitizer class.

This is basically T25932: Allow use of semantic HTML5 elements in wikitext.

In T200704#10146657, @Izno wrote:

Testing this in user space today yields this output in the old parser for the first and following link text:

I can't tell from Google Translate but this request looks like T331906: Add Lua function to read out previous section heading. Is it?

I think Parsoid is doing the correct-er thing here, even if it's not what the users obviously intended. You need to be able to access new page names with apostrophes in them somehow at the end of the day. There are several examples of red links on the same page where someone did the due diligence of marking them up as link text rather than as link target.

One cell in Parsoid:

Does this not run into the same security issue as described in T5593: [Epic] SVG client side rendering regarding scripts potentially uploaded before the dawn of sanitization?

In T318176#11287640, @Graham87 wrote:

The only other ones I know on here are @KaraLG84 and @codeofdusk. They use NVDA as their primary Windows screen reader.

In T268900#8256603, @matmarex wrote:

Latest spec allow alternative text to be specified in content: https://www.w3.org/TR/css-content-3/#alt but browser support is poor so far: https://caniuse.com/mdn-css_properties_content_alt_text (only Chromium and friends).

This task feels like it should be considered by someone who actually uses accessibility technology because it would be adding some repetition to someone navigating by section (e.g. heading -> next link -> next link and each of those next links would post-change read out as the same text as the heading which I anticipate would be annoying). I would be surprised if these links are navigated to differently (for example, navigating by all links would be surprising, but in the realm of possible).

In T378906#11286762, @ssastry wrote:

Ah, I had the fix narrowly target divs for navboxes. Can't do the same for tables because of fostering reasons. Short of hoisting deeper -- into the "last" <td> -- which feels very ugly, I don't have a good Parsoid-side solution at this point.

Yeah, it was a super-big parenthetical. (The infobox template does something similar to that kind of hoisting today but it's ugly and I plan to get rid of it at some point when that gets rewritten.)

I've added amboxes to the same page. (They are tables currently and probably a good chunk of the fleet, but I am incidentally working on making them divs. Which still doesn't fix the whole fleet.)

This is a browser issue; Firefox is happy to style those directly. This is on top of what I think is a gadget providing the support for the button in the first place, since buttons are not normally allowed in wikitext (and where they are allowed, they already use OOUI/Codex everywhere IIRC).

In T378906#11286249, @ssastry wrote:

https://www.mediawiki.org/w/index.php?title=User:Izno/Sandbox/Category_holder&diff=prev&oldid=7945477 fixes it for example. I'm going to close this as resolved. Please leave a comment if you disagree. Since the patch is kind of a mild hack, we mostly want to keep it as narrow as possible.

The fundamental fix is to use media query range syntax from Media Queries Level 4. Problem is that implementation is only about 3.5 years old (Safari is a little younger at about 3 years old), though Firefox has partial support for the past 7.

That was done some time ago, and isn't particularly related to this task. T198949: Add navbox links to mobile page HTML There's other still-open friends in that context.

I didn't know search had a thesaurus!

I think this is simple suffix stripping and it is part of the language support for stemming.

Here I'm making the not-funny that crying also results in sob trains. I fully understand that stemming is how we're ending up at sob trains for the sobbing case.

In T404454#11274457, @CCiufo-WMF wrote:

I'm not sure if all the major browsers we support have a native "desktop mode" setting.

FYI: I went and documented all the range calculators in the movement these days at https://en.wikipedia.org/wiki/Template:IP_range_calculator#Other_versions , of which that template is but one.

Ok, the adjustment of the title makes the suggested lint make sense.

I'm confused by the description? Parsoid does a better job making list items out of extension content and editors are already intending them to be lists so we want to add a lint so people stop using them as lists....?

You should ask these questions on the module's home wiki's talk page. They may be able to assist better than the audience usually-unfamiliar with modules on Phabricator, but beyond that this module appears to be quite complicated.

The second of those bullets appears to be validated in production based on https://en.wikipedia.org/w/index.php?title=MediaWiki:BlockedExternalDomains.json&diff=prev&oldid=1316015275 occurring.

I haven't settled on an opinion for this task, but:

It also doubles up on roles, which is no longer allowed

Multiple roles are allowed actually. The consuming system must treat the element as if it were of the first "non-abstract" role per ARIA 1.2 (2023). This hasn't changed in the editor's draft for 1.3. (Authors are required not to use the abstract roles. The same section in ARIA 1.1 [2017] indeed had little to say regarding multiple roles.)