TemplateStyles generates a "general" marker (to, among other things, prevent T67258) that contains the style tags, with the actual content inside the style tags being hidden inside a "nowiki" marker (to prevent it from being mangled by Parser->doBlockLevels()).

Normally this is handled fine: Parser::internalParseHalfParsed() unstrips the "general" marker, does some stuff, and then unstrips the "nowiki" marker.

But in the case where the "general" marker is inside a link's text, the link is hidden by a LinkHolderArray marker. The first unstrip of "general" markers therefore doesn't see it. There's a second "general" unstrip, but that doesn't happen until after the "nowiki" unstrip so the contained "nowiki" marker never gets unstripped.

There are a few fixes I can think of, but I don't know whether any of them might break other assumptions.

• Have LinkHolderArray unstrip general markers when replacing the link holders.
• Have LinkHolderArray take an option to unstrip general markers when replacing the link holders, and use that option from Parser::internalParseHalfParsed().
• Replace either the unstripNowiki or the second unstripGeneral call with unstripBoth.

Thanks to @Jonesey95's report at en:Template talk:Noitalic: The same thing is happening inside navboxes at en. Apparently, whether the noitalic is inside a link or not.

Edit: never mind, bug occurs if first instance of inner templatestyled template is in a link.

This doesn't happen with plain external links like [https://example.com {{sfrac|3|2|1}}] which was surprising to me.

For some reason, the bug isn't present here: https://es.wikisource.org/wiki/Usuario:Ignacio_Rodr%C3%ADguez/Testpage2

Despite being inside a link and all.
I haven't been able to reproduce it

This is really annoying for the Wikisourcen since their formatting needs follow whatever the text they are reproducing used, rather than a project-specific manual of style. It is very common to have typical linkable phrases (names of authors, say) formatted with multiple styles (i.e. multiple formatting templates) such that the template(s) cannot be moved outside the link.

Random contrived example: [[Author:William Shakespeare|{{all-small-caps|Shakespeare,}} {{letter-spacing|.2em|William}}]].

The workarounds being employed is stuff like {{all-small-caps|[[Author:William Shakespeare|Shakespeare,]] {{letter-spacing|.2em|[[Author:William Shakespeare|William]]}}, which… EWWW!

If one of the possible fixes Anomie sketched out above are feasible, even if not entirely architecturally clean, it would be very helpful to have that fix for now while we wait for the "perfect and correct" fix down the road.

In T200704#8434598, @Xover wrote:

The workarounds being employed is stuff like {{all-small-caps|[[Author:William Shakespeare|Shakespeare,]] {{letter-spacing|.2em|[[Author:William Shakespeare|William]]}}, which… EWWW!

Yeah, that's one work around. The other is something like this currently-unused monstrosity.

In T200704#8434598, @Xover wrote:

If one of the possible fixes Anomie sketched out above are feasible, even if not entirely architecturally clean, it would be very helpful to have that fix for now while we wait for the "perfect and correct" fix down the road.

I was thinking this might be something that could be fixed when the extension is "fixed" for T272941: Make TemplateStyles extension compatible with Parsoid as the ideal point, since I assume these qualities will be looked at in that context.

In T200704#8434598, @Xover wrote:

If one of the possible fixes Anomie sketched out above are feasible, even if not entirely architecturally clean, it would be very helpful to have that fix for now while we wait for the "perfect and correct" fix down the road.

The issue isn't that it's not architecturally clean (it's not really possible to do architecturally clean changes to the parser anyway), but whether it create new breakage because something somewhere implicitly relies on the current sequence of unstrips.

In T200704#4506999, @Anomie wrote:

• Have LinkHolderArray take an option to unstrip general markers when replacing the link holders, and use that option from Parser::internalParseHalfParsed().

I guess this would be the least risky of the three options.

In T200704#8434629, @Izno wrote:

I was thinking this might be something that could be fixed when the extension is "fixed" for T272941: Make TemplateStyles extension compatible with Parsoid as the ideal point, since I assume these qualities will be looked at in that context.

This bug is an artiface of the exact way stripping/unstripping is used in the parser. AFAIK Parsoid has no concept of stripping/unstripping (not being regex-based, it does not have a need to hide non-wikitext that matches regexes targeting wikitext syntax behind text markers). So I guess one way to fix this is to just wait for parser unification.

In T200704#8440436, @Tgr wrote:

I guess one way to fix this is to just wait for parser unification.

Given this problem is currently being used to veto conversion of templates to use TemplateStyles on-wiki, I would really rather not wait for The Great Parser Unification™ (real soon now, I'm sure).

Real-world occurrence at en-wiki here; css font-variant:small-caps (diff) is an effective workaround. Discussion at Template talk:Smallcaps#Unaccountable failure.

Real world example on enWS: Page:Posthumous works, in prose and verse - Ann Eliza Bleecker.djvu/19 (the word "MEMOIRS")