At the time I wrote that, I was on whatever esr was released sometime in June or July. Between whatever you just changed and my updating to 115.13.0esr (released today), it now looks correct. Thanks for diagnosing the CSS support history!

It is still not fixed on my desktop-Mac Firefox. There is no longer a scrollbar, but the box is still the same fixed size it was (not sized to fit the content), so the right portion of the message is cut off.

This icon is used by a bunch of deletion-related templates, , so its absence creates visible breakage. For example, when an admin looks at a page tagged with {{SD}}, it displays a broken-icon instead of the trashcan for the delete function.

I agree a warning would be useful in this context. There have been at least two sock-drawers that have taken advantage of innocent third-parties to evade commons blocks in this manner. I would even support a prohibition (not just warning) because it is evasion-by-proxy (at best) and does literally appear to be evasion in the edit-history on commons. But unlike some wikipedias, commons does not seem to take a strict stance based on the *spirit* of evasion, only the letter of "this account is blocked, so this *account* cannot itself make edits".

I have need for "limit search results to non-redirects" and was directed to this phab. The use-case is when trying to resolve page-naming controversies (or more mildly, how to name new pages) I want to look at precedent. And that means the actual pages alone. Conceptually, it would be an option I could add to intitle:, so an additional token in the search-box or a checkbox in the advanced-search mode or an include/exclude-redirects toggle in the results page.

Browser-diving, Chrome (Mac) does the same thing, even without being logged in (therefore it's not user .js bug). Safari (Mac) instead does break at the whitespace (*despite* the nowrap tag). That makes it seem like HTML subject to the "tidy-whitespace-bug" lint-error, where indeed edge whitespace within a nowrap span is subject to varying behaviors. I'm uncertain why out-of-hand rejection to addressing something that looks confusing into something that is not as confusing and that affects multiple current-release popular browsers, even if "it's a browser effect". What's the drawback?

In T286705#7214749, @Aklapper wrote:

Account-name should either be made nowrap

Which actual underlying problem would this solve? Please provide a specific use case.

Here's the HTML:

<td><a href="/wiki/User:Smiley.toerist" class="mw-userlink" title=""><bdi>Smiley.toerist</bdi></a><span style="white-space: nowrap;"> <span class="mw-usertoollinks">(<a href="/wiki/User_talk:Smiley.toerist" class="mw-usertoollinks-talk" title="">talk</a> | <a href="/wiki/Special:Contributions/Smiley.toerist" class="mw-usertoollinks-contribs" title="">contribs</a> | <a href="/wiki/Special:Block/Smiley.toerist" class="mw-usertoollinks-block" title="Special:Block/Smiley.toerist">block</a>)</span></span></td>

There is no nowrap around the account-name. There is a whitespace between the account-name and the links-set, but it is part of the nowrap , and there is a whitespacea space between the account-name and the links-set, but it's part of the nowrap along with the links.

At [[commons:Commons:Deletion requests/File:Why Can't You Download Videos on YouTube How a 20-Year-Old Law Stops youtube-dl Users AND Farmers.webm‎]], we have a case where the auto-selected image is a nonfree frame. It's likely de minimis within the video, but it's not appropriate as the default thumb. And if we blur/blank it out for stricter license compliance, then we have blurred or blank image as the default thumb.

When looking at a category, we already have a gadget for displaying only a certain filetype. When searching in other ways, we have selectors for namespace. I wonder if we could have a search-selector for filetype?

My use-case is when a long-term protection such as a BLP-related semi or extended-confirmed needs a short-term upgrade due to an unrelated issue (few days' fullprot due to a heated content dispute). When that latter protection expires, it silently becomes completely unprotected. Having the alert would let me know to re-set the previous semi/EC.

I just noticed this for https://commons.wikimedia.org/wiki/Category:4-Hydroxy-TEMPO that has no subcats but is listed as having "3C" at https://commons.wikimedia.org/wiki/Category:Aminoxyls and other parent cats of it. That's another "starting with a number" cat, part of the pattern Ghouston mentioned.

As far as terminology, "conical flask" is sometimes used as a synonym for "Erlenmeyer flask". But a flask (of which these are other shapes also) and a beaker are totally different profiles.

I'd also like to recurse "up" from a given IP or range (larger enclosing ranges of the given one rather than subranges). So if I look at https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3A2601%3A586%3A400%3A833A%3AFD78%3A71BE%3A47B5%3A5110 (specifically [[:en:User:2601:586:400:833A:FD78:71BE:47B5:5110]], I would also see that [[:en:User:2601:586:400:833a::/64]] is rangeblocked. And this would still be visible once the blocks have expired, unlike [[Special:BlockList]] that only displays active ones.

This seems to be mostly resolved. Looking at 1.33.0-wmf.18 (rMW3456bc65792b), narrowing the window allows breaking between each option in a set but checkbox+option-text remains together. If I narrow the window so much that even one full option does not fit on a line, it side-scrolls because no breaking is allowed within the text of any one option. I'm not sure if that is good/bad, but given how extremely narrow one has to get to observe it, and that the alternative (allowing breaking within an option) is a worse problem, I would call this RESOLVED.

Original bug report on en.wp.

I was just about to post to [[:en:VPT]] wondering about this. At least on en.wp, the § symbol is already used in several places to represent a section (as delimited by a header) of an article. We already do that in the semi-niche https://en.wikipedia.org/wiki/Template:Section_link but also the widely used https://en.wikipedia.org/wiki/Template:Main for example. ~~~~

There appears to be a typo in the gerrit 421125 change. In the inserted line 3675:

Some broken signatures are now triggering [[Special:LintErrors]], including "high priority" ones. If it's a prolific talk-page user, that means lots of talkpages and other discussion namespaces get flagged. See for example [[:en:User talk:Milonica#Signature HTML bug]]. I don't know how much of a Big Deal lint errors are, but given they're called "high priority errors", it seems important.

I envision the result to look like:

That seems to work if I download the generatged page and manually edit the HTML.

Confirmed working for me also.

Got a comparable error just now trying to delete (not undelete) at https://en.wikipedia.org/wiki/File:Airborne_Assault_entrance.jpg

And now