Hi @Tol, thanks for taking the time to report this!
As things in the task description look all the same here, I'll attach a screenshot:

Thanks, @Aklapper! I added separator characters, which correctly formatted the text description on my end, but apparently this is inconsistent even between browsers/OSs/etc. (effectively the same problem as this task, but on a different scale; haha). Here's what my description was supposed to look like:

Problem with API and not the extension so retagging accordingly. Thanks for the report!

Figuring out the exact unicode sequence here would be helpful, as my guess would be that someone is aggressively stripping "weird" unicode characters, which happen to be necessary for correct display in this case.

Figuring out the exact unicode sequence here would be helpful,

What does that mean? Going to https://en.wikipedia.org/api/rest_v1/page/mobile-html/Diamond_Is_Unbreakable its HTML is a usual 3 followed by TemplateStyles noise followed by Math markup for ½:

for a little more than 3<style data-mw-deduplicate="TemplateStyles:r1020198016" typeof="mw:Extension/templatestyles mw:Transclusion">.mw-parser-output .frac{white-space:nowrap}.mw-parser-output .frac .num,.mw-parser-output .frac .den{font-size:80%;line-height:0;vertical-align:super}.mw-parser-output .frac .den{vertical-align:sub}.mw-parser-output .sr-only{border:0;clip:rect(0,0,0,0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}</style><span class="frac" role="math"><span class="num">1</span><span>⁄</span><span class="den">2</span></span> years, from May 4, 1992

This is a problem with the on-wiki template, not Math or the summary endpoint: https://en.wikipedia.org/wiki/Template_talk:Fraction#Fractions_are_not_readable_in_page_previews
Pinging @Izno to work out how to resolve this one.

Copying from wiki...

Please see phab:T334273. In the case of page previews, TemplateStyles do not get applied to previews, as the preview appears outside the context of the page.

This isn't true? The styles are applying. The numerator and denominator would not otherwise display as vertical-align: super and vertical-align: sub as defined in the TemplateStyles output.

I think this is likely a browser bug in the context of the JavaScript element, potentially related to the sr-only styles that are applied here, which are the more-or-less standard sr-only styles you can find on the rest of the web (c.f. the canonical copy at here). Obviously this displays fine without JavaScript implicated.

Doesn't look like the styles are applying to me (see screenshot)? The page preview intentionally does not use .mw-parser-output but even if I add that class, they don't apply as there are no uses of the Math template inside the JoJo's Bizarre Adventure page.

In T334273#8851714, @Jdlrobson wrote:

Doesn't look like the styles are applying to me (see screenshot)? The page preview intentionally does not use .mw-parser-output

That's frankly a bug in page previews then, even if intentional (please point to the design rationale that would indicate it is intentional or provide the rationale directly so that can be discussed). It would require all inline templates not to be used in the first half-dozen sentences, which is not an appropriate requirement to place on template makers. Never mind nearly impossible to identify uses. (That this task is the most evident issue of it is luck, as Template:Fraction is one of the few inline templates using TemplateStyles at this time that has an impact in the mainspace, likely as a result of the failure to fix T200704.)

but even if I add that class, they don't apply as there are no uses of the Math template inside the JoJo's Bizarre Adventure page.

Two things: I don't see where you added .mw-parser-output in this screenshot (less relevant of course). Secondly, this screenshot makes clear that the relevant <style> has been ripped out of the response from the relevant REST API, so yes, the styles would not apply. That does seem like a Page Previews problem (and perhaps is why you say above it is intentional -- that still doesn't explain why it's intentional.)

Multiple other JavaScript systems support TemplateStyles now. I can think of no reason Page Previews should not as well.

As for "31⁄2", yes, that is indeed caused by the use of the Unicode fraction-slash by a misuse of the fraction template on that page. Fraction needs to have the whole number inside because it accounts for the case using the hidden +.

This of course causes the following problem, which is perhaps why it was misused (and again, why the extension should appropriately support TemplateStyles):

You can argue that there shouldn't be a hidden plus there -- that's marked up as the referenced .sr-only -- but I think it semantically makes sense (3 + 1/2). The alternative is a space to work around using the correct Unicode character, which is not much better. Still also could toss out the Unicode character but as it's the correct one....

On this dimension there have been some other discussions, and yeah, those, would be appropriate to have onwiki. https://en.wikipedia.org/wiki/Template_talk:Fraction/Archive_2#Integrity , https://en.wikipedia.org/wiki/Template_talk:Fraction#Unwanted_plus_sign , and I referenced the first of those when I added it in Template:Convert https://en.wikipedia.org/wiki/Template_talk:Convert/Archive_2#Module_version_25_%28see_May_2021_for_release%29

I could probably fix locally how this impacts Page Previews, but I return to "Page Previews should support TemplateStyles regardless" as a strong motivation on my part for not wanting to "fix" it.

please point to the design rationale that would indicate it is intentional or provide the rationale directly so that can be discussed)
Multiple other JavaScript systems support TemplateStyles now. I can think of no reason Page Previews should not as well.

The specification for the API can be found here: https://www.mediawiki.org/wiki/Page_Previews/API_Specification#Markup_allowed_in_an_intro
Originally the API was text-only, but this got expanded to include certain HTML tags. We are extremely specific about what HTML can be included and style tags is not one of them (as otherwise you'd be able to do all sorts of weird things to break the display of a page preview). Imagine for example what would happen to absolute positioning inside a summary, so no we are certainly not goin to load template styles for displaying what is meant to be a summary of an article.

Page previews are also used outside Wikimedia, e.g.Wordpress so portability is also really important here. Content should be consumable without the styles≥

Sup and sub are intentionally supported for this reason, so I'm not 100% sure why this can't use those HTML elements?

In T334273#8851983, @Jdlrobson wrote:

please point to the design rationale that would indicate it is intentional or provide the rationale directly so that can be discussed)
Multiple other JavaScript systems support TemplateStyles now. I can think of no reason Page Previews should not as well.

The specification for the API can be found here: https://www.mediawiki.org/wiki/Page_Previews/API_Specification#Markup_allowed_in_an_intro

Thanks. The requirement does seem clear to remove everything, but the background that <style> is deliberately considered as a must-also go isn't obvious to me on that page.

Originally the API was text-only, but this got expanded to include certain HTML tags. We are extremely specific about what HTML can be included and style tags is not one of them (as otherwise you'd be able to do all sorts of weird things to break the display of a page preview). Imagine for example what would happen to absolute positioning inside a summary

I don't think this specific objection regarding absolute positioning carries merit. If something is that obstructive in Page Previews, then it's probably also an issue in the live article, which is reasonably fixed. Separately, that would be an issue for any inline styling added as well, which you have proposed as an alternative above. Which leaves the vandalism case for absolute positioning, which we already don't design for, here and elsewhere. (Well, besides coordinates. :^)

I am sure there are other potential disruptions, but all I can conceive of are ultimately bad faith. And the CSS itself is sanitized.

summary of an article
Content should be consumable without the styles≥

Content is consumable without the styles. However, a choice not to support TemplateStyles will also cause the page previews to not accurately reflect the article. That's a tradeoff you can make, but then you get this task where the issue is clearly the JavaScript representation of Page Previews.

Page previews are also used outside Wikimedia, e.g.Wordpress so portability is also really important here.

I think you need to distinguish between the JS view and the PHP view here. If the PHP view of the extension matches the output of the REST API, this isn't pertinent I don't believe, as they will apparently get the styles.

Even if we consider 3rd party consumers as generally relevant to the extension, they certainly are not the primary point of the JavaScript being displayed in the Page Preview on English Wikipedia, where this task is relevant. And then we also return to expectations regarding every other inline template that might appear in the beginning of the page.

Sup and sub are intentionally supported for this reason, so I'm not 100% sure why this can't use those HTML elements?

My read of the specification is that sub/sup aren't appropriate for fractions, but regardless I think at best for your case this is an edge case where people could reasonably disagree. (Consider if you would use sub/sup to represent stacked fractions as with Template:Sfrac and if so why; consider how the spec reads on the point.)

sub and sup aren't fundamentally the problem here anyway either on-wiki or off, so I'm not sure what bearing that has on anything.