At least, the self links shouldn't be blue, using some a:not([href]) CSS as it has been done for Minerva.

By the way, I checked on Timeless, and the self links are blue, as regular links. That is wrong for sure.

I mean that the bold removal and the underline on hover are by design ;) But I may be mistaken.

I think it is by design.

@MusikAnimal I figured it out exactly at the same time ;)

@MusikAnimal I've noticed your revert. Actually, there might be something missing in the extension implementation in MediaWiki. Compare the two following sets of Lua debug outputs:

Yes, please uncomment it, so you can at the very same moment check if it is running fine.

@MusikAnimal I have implemented this extension in the module.

I made the patch, but the Gerrit Patch Uploader currently fails to submit it (and there is no error message).

One week already, I got no more messages about this. If there is no one willing to nonetheless fix it, I think this ticket can just be closed.

Just to clarify, the patch that has just been merged is not for the issue of this ticket, but for a related issue.

This needs more than the single rule above. I had to add the following to fr.wiki: https://fr.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&diff=prev&oldid=143649876

Thank you for this addition. But as I stated a bit above, these missing styles are simply an overlook from T160480. There is just no reason not to add them.

If template returns #ccc and is used as style="color:{{template}}", {{#balance:inline}} would break the template, as it wraps the output with <span>...</span>.

For convenience, refs https://phabricator.wikimedia.org/T31157 (relocation of bugzilla 29157).

Phabricator's Contributing Code:

Even in this "Browse Projects" modal, there is no link to go to the tag page!

Fixed by this edit, yet I have removed this code just after as it's no longer needed.

Has been fixed in this edit (search setTimeout).

Should be working again, see notably this edit.

Any news on this?

For the demo above, note the CSS has been fixed locally.

How about just escaping all ! characters? It would escape more than necessary, but the code would be much simpler (in particular the PHP one).

So, you don't think there is the same issue with the 2nd do/while of the for loop? I haven't checked it thoroughly, but it just looks very similar, with these n+2 steps. That's why I added the "overflow fix" after the for loop in my demonstration patch, to cover the two do/while's.

Thank you for your work on this.

I was about to completely agree with Jdlrobson, but actually such links are HTML5's "placeholder links" and seem to be the recommended way…

Code references:

• non-live preview, PHP: https://github.com/wikimedia/mediawiki/blob/master/includes/diff/DifferenceEngine.php
• live preview, JavaScript: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.action/mediawiki.action.edit.preview.js

There are two different points:

• Texts "Latest revision" and "Your text" are always missing. They should be added, for consistency with the "non-live preview" mode.
• When there is no difference (i.e. empty ajax diff content) the text "(No difference)" should be added.

Also, documentation needs to be updated: https://www.mediawiki.org/wiki/API:Revisions

The JavaScript of "live preview"[1] gets deprecation warnings and has to be updated.

Thanks :) @grey-bright variable is #eee. It's a bit too light in my opinion. The next one, @grey, is #ccc, which in turn is a bit too dark. Something between the two would have been optimal.

I just noticed this border's color is varying across the skins…

I would suggest "normal" priority. This issue gives template editors many headaches, and often results in template codes much more complex than necessary. Thus, let's not forget this issue even further than now.

Yes, please do something about this issue, even (for the time being) just adding a magic word to configure behaviour of the template, would be helpful.

Indeed, the error happens only on invalid input. Still, there is a clear possibility of overflow here, fixing it is good to do. You should consider as luck it resulted in just a php notice :)

Yes, for ensuring consistency (there can be different parsers, across Special:ExpandTemplates, preview mode, etc.)

Possible fix, inserting near line 484:

Test case: JavaScriptMinifier::minify('*/');

Thanks, I had a look at the javascript code, and I'm not really a fan of this solution.

Just to mention the mobile version has this issue on all browsers actually, not only Firefox 57. Tried Chrome and Pale Moon. So maybe the mobile version has a related, but different, issue that would need to be investigated.

Looks like this feature is currently missing. (if I recall correctly, maybe it has been removed at some time)

TBH, the fault is in Firefox 57, and the same issue happens on a shitload of websites. So I don't think there is any fix or workaround to consider for MediaWiki, the issue has to be fixed in Firefox.

Here it is: T160480 (gerrit). Also, along this patch the mobile styles were probably forgotten, their omission wasn't on purpose.

Just noticed this: apparently, in the past, the generated elements were <strong class="selflink">, then at some point it has been changed to <a class="selflink">.

What I'm suggesting:

• First, just add my CSS,
• Then possibly, in a new ticket, transform <a class="selflink"> to <strong class="selflink">, for both desktop and mobile. At the source, not in a post-process layer.

I think returning a modified, different markup on mobile version is quite surprising, and a wide open door for bugs.
As visible on your Gerrit patch, the markup is litteraly hacked (your patch code is clean though, I'm talking about the principle, of this one, and of the other ones that are already stacked...).

It also happens on the mobile version: https://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal

I can also reproduce it with Firefox 57, even without throttling network speed (VDSL2).

Yes, it would require manually adding margin-left: 0; and margin-right: 0; to the custom toggles, in addition to the already needed float: none;.
That's why I'd still bend to favor my patch 9, which has a "whitelist" approach.

(by the way, having the username in URL of preferences pages isn't very smart)

Please have a look at T155347 (and Gerrit patches 9 and 10), also please try your code on https://test.wikipedia.org/wiki/Test_suite_for_mw-collapsible, and especially on https://test.wikipedia.org/wiki/CollapsingTestpageMw (custom toggle).

0.3em is a pretty frequent value on mediawiki, and it fits great here.

Yes, it's a duplicate. Though it got lucky and got more attention. Its CSS patch is less evolved, but note it has a workaround for the parser issue I mentioned earlier.

@Jdlrobson requested more discussion (* I wouldn't have guessed that such an obvious, simple and straightforward issue would require discussion…),

I have just tried to reproduce this bug, and I got the expected, correct value: "[]".

Oh, they were local rules… Thank you very much matmarex for noticing this. I have removed these blameworthy rules.

Any feedback about my comment above?

Here is a test case: https://en.m.wikipedia.org/w/index.php?title=Draft:Sandbox&oldid=812613209

Note these links already have a caret on hover, as it should be.

As suggested on Gerrit, I added a patch that implements a similar change in core wfEscapeWikiText().

New patch, that searches for \n[ \t]*!

Mmmm, wait. Table code would also accept such leading spaces/tabs:

@Reedy Indeed. My first patch was:

data.canTalk = ns.talk ~= nil

The changes should be quite robust as of now. I'd favor patch #9, it works on a specific "whitelist" set so it should be pretty safe, and more importantly, the space added by javascript in patch #10 really tickles me (see my comments above).

Thank you!

Still, for inline toggles in table captions, I would favor a margin over a space:

• It's an UI widget, so that "natural spacing [of exactly one space]" doesn't really make sense. A bit more spacing wouldn't hurt, actually.
• It doesn't create a space which would get selected with the rest of the text. (I hate so much these extraneous spaces in text selections!)

@Krinkle Please see my the additional notes in my comment above.

The issue is mainly about configurability: the code implements objects to manage options, yet the end-user cannot reach these options.

Patch #7 was changing only the two "Collapsible table with caption" examples, which is fine and the expected behaviour.
Updated (#8) the patch, adding th .mw-collapsible-toggle to fix the "Collapsible table" example as well.

Nope, narrowing the addition of the float was wrong.

Uploaded a new patch to https://gerrit.wikimedia.org/r/#/c/338045/

Changing the selector from .mw-collapsible-toggle to the narrower caption .mw-collapsible-toggle would fix the case pointed out by @Krinkle on Gerrit, and I guess would be robust enough to avoid the false positives.