[Enhancement]: Cross-app — 172 body-text TextBlocks still write their size instead of using Caption/Subtle/SectionTitle, blocked on those five tokens missing BasedOn

[laurentiu021]

Problem

Rewritten 2026-09-16 against current source. Every number below is re-derived from Views/*.xaml +
MainWindow.xaml with XAML comments stripped, counting <TextBlock> start tags only and excluding
elements that already name a Style or use an icon font (Segoe Fluent / Segoe MDL2, where a FontSize
is a glyph box rather than typography). 934 TextBlocks inspected. The original body counted every
FontSize="…" in the files, including icon glyphs, TextBox/ComboBox and style definitions, which is why
its totals cannot be compared with these.

The number half of this issue is finished. The body-text half is not, and it turns out to be blocked
on a prerequisite that has to be settled first.

What shipped

The scale now has twelve named styles, and all of them are used:

Token	Size	Uses
Subtle	12	200
Display	28	59
Body	13	59
SectionLabel	11 SemiBold	52
SectionTitle	14	44
Caption	11	19
MetricCompact	16	13
Metric	22	12
MetricLarge	26	8
Heading	20	5
MetricSmall	20	4
MetricHero	30	1

Metric rungs at 16 / 20 / 22 / 26 / 30, text at 28 / 20 / 14 / 13 / 12 / 11. Zero bare TextBlocks remain at
13, 18, 26, 28, 30 or 32. ArchitectureTests.EveryMetricRungSize_IsReachedThroughItsRung holds that line
and also asserts every rung a view names is actually defined, which a compile cannot tell you because
{StaticResource} inside a DataTemplate resolves at runtime.

Corrections to the original body

• Heading was never dead. It has 5 uses today, and the claim was wrong when filed: the grep behind it
  searched for StaticResource Heading where the markup writes {StaticResource Heading}.
• Metric did not "match no shipped value". It had 10 uses when filed and has 12 now. It was never
  re-pointed; instead the sizes the views actually drew got their own rungs, which is the change that made
  the scale describe the app rather than the reverse.
• The 499/18 figures are not comparable to anything measurable, for the population reason above.

What is left

172 bare TextBlocks are drawn at a size that already has a token:

Raw size	Token it should use	Count	Files
11	Caption	83	28
12	Subtle	67	26
14	SectionTitle	22	11

41 distinct view files are involved.

A further 48 sit at a size with no token at all: 10 (×24), 15 (×16), 9 (×7), 24 (×1 — About's product name,
deliberately left; no text rung sits within two points of it).

The prerequisite that blocks the sweep

Caption, Subtle, SectionTitle, SectionLabel and Display do not carry
BasedOn="{StaticResource {x:Type TextBlock}}". They restate Foreground and FontFamily instead. In WPF a
keyed style replaces the keyless <Style TargetType="TextBlock"> rather than merging with it, so applying
one of these five to an element that currently has no style silently drops the two setters they do not
restate:

<Setter Property="TextOptions.TextFormattingMode" Value="Ideal"/>
<Setter Property="TextOptions.TextRenderingMode" Value="ClearType"/>

So "swap FontSize="11" for Style="{StaticResource Caption}"" is not the no-op it looks like. Doing all
172 today would change the text-rendering mode on 172 elements.

The fix is one attribute on each of the five styles. It is also the one edit in this issue that is not free:
adding BasedOn to Display moves 59 tab titles from TextFormattingMode=Display (the WPF default they get
today) to Ideal. At 28px that is the mode you want — Ideal uses fractional glyph advances and is what the
rest of the app already renders with — but it is a real change on every tab's title, so it wants a look on a
machine that runs the app rather than a silent merge.

Proposed order

1. Add BasedOn="{StaticResource {x:Type TextBlock}}" to Caption, Subtle, SectionTitle, SectionLabel
   and Display, and drop the setters that BasedOn then supplies. Verify with
   SysManager.IntegrationTests.TypographyTokenTests, which reads the resolved FontSize / FontWeight /
   Foreground off a real TextBlock on the STA thread — XAML compiles either way, so nothing else can tell.
   Screenshot check on the tab titles.
2. Convert the 148 whose rendering the swap cannot change, so the edit is a size-attribute removal and
   nothing else: 78 at 11, 55 at 12, 15 at 14. Either they name their own Foreground (which beats the
   token's) or the token's colour is the TextPrimary they already inherit.
3. Handle the remaining 24 individually, because each is a visible change and not a cleanup:
   • 17 name no Foreground and the token's differs from the inherited TextPrimary: 12 at 12 would become
     TextSecondary, 5 at 11 would become TextMuted.
   • 7 at 14 name no FontWeight, so SectionTitle's SemiBold would bolden them.
4. Decide whether 10, 15 and 9 deserve tokens or should move onto 11 / 14. 24 stays raw unless the product
   name is up for discussion.

Step 1 is the merge-blocker for step 2. Steps 3 and 4 are per-site judgement, not a sweep.

Affected area

Cross-app — App.xaml typography block; 34 views.

[laurentiu021]

Re-measured: 402 over 17 values, not 499 over 18 — and #2134 is why

Same command as the Evidence section, run against current source:

grep -rhoE 'FontSize="[0-9.]+"' Views/*.xaml MainWindow.xaml | wc -l      -> 402   (was 499)
grep -rhoE 'FontSize="[0-9.]+"' Views/*.xaml MainWindow.xaml | sort -u    ->  17   (was 18)

The missing 18th value is 48, which no longer appears anywhere.

The distribution has also reordered, which matters more than the total because the proposal is built on it:

size	then	now
11	88	99
12	87	90
13	150	63
14	37	39
10	31	31
16	42	15
15	18	20

13px is no longer the de-facto body size. It was the plurality at 150 and is now third at 63. 16px fell from 42 to 15. So part (c) — "add the two missing tokens the data demands, Body at 13 and BodyLarge at 16" — rests on a distribution that no longer holds. 11 and 12 are now the top two, and both already have tokens: Caption at 11 and Subtle at 12.

The cause is #2134, the elevation-banner extraction. Measured on its own diff: it removed 118 raw FontSize attributes from views and added 4 back, a net −114. 499 − 114 = 385, and the 17 between that and today's 402 came back from work merged since. Thirty views each carried two hand-rolled banner blocks, and the sizes inside them were counted here as thirty independent decisions when they were one decision copied thirty times.

That is worth separating out, because it changes what this issue is about. Roughly a quarter of the original count was duplication that an unrelated refactor deleted, so what remains is closer to genuine per-view drift — a smaller job, and a more honest one.

What still holds, re-verified

• Heading (App.xaml) is still dead: grep -rho 'StaticResource Heading' Views/*.xaml MainWindow.xaml returns nothing.
• Metric is still 22px and no view ships a raw 22. The drifted hero numbers are still 20, 24, 26, 28 and 30, with 26 still the plurality at 6.
• The fractional 12.5 (×5) and 11.5 (×2) are unchanged at 7 uses.

So parts (a) and (b) are untouched by the recount and are still the high-signal half. Part (c) wants re-deriving from the current distribution before anyone writes a Body style for a size that is no longer the body size.

Filed rather than acted on: the numbers in the title and body are what a reader will quote next, so they should be corrected at the same time as the work, not before it.

[laurentiu021]

Re-derived against current source before acting. The headline numbers have all moved, and all three named defects are stale.

This issue says	Measured now
499 raw FontSize attributes over 18 distinct values	410 over 14
(1) Heading has zero references — a dead style	Has a user. It was deleted once for being dead, then deliberately restored alongside the sidebar wordmark, with the condition for its return written into App.xaml
(2) Re-point Metric at 26, the plurality (×6)	There are zero 26s. Also zero 20s and zero 30s — MetricLarge/MetricSmall/MetricHero were added and every raw site repointed
(3) 13px ×144, 16px ×42	13px ×68, 16px ×15
48, 32, 30, 20, 26 among the distinct values	48, 30, 26, 20 all gone; 32 survives as an EmptyState icon glyph

So the premise "the one token meant for metrics matches none of the drifted values" no longer holds: Metric (22) has 10 call sites, and the rungs above it exist.

Part (c) is shipped — #2330

That was the part still standing, and it was the largest: 13 really is the size the app writes in. Added Body (13, 54 sites) and MetricCompact (16/SemiBold, 9 sites) and repointed all 63. Appearance-neutral — the sizes are what those views already rendered.

Two things worth recording from doing it:

• BasedOn is the whole ballgame. An explicit style replaces the keyless <Style TargetType="TextBlock">, so without BasedOn="{StaticResource {x:Type TextBlock}}" a repointed TextBlock silently loses ClearType and — at the 24 sites that name no colour — its foreground. TypographyTokenTests now reads the resolved values off a real TextBlock on an STA thread, because XAML compiles either way.
• Metric was a latent trap. It was the one keyed TextBlock style that neither set Foreground nor inherited one, so it handed its user the WPF default brush. Invisible so far only because all ten call sites set a colour locally; the eleventh would have been black text on a dark surface. Fixed, and EveryTypographyStyleUse_ResolvesAColour now pins the invariant at the call sites.

The global-FontSize-on-TextBlock option in part (c) was not taken. It is the riskiest single edit in this issue and Body makes it unnecessary — an explicit token that a guard can enforce beats an implicit default that silently restyles everything inheriting WPF's 12.

What remains, and why I stopped here

Only changes that alter a visible size:

• 18/SemiBold ×7 (System Logs ×3, Ping, Standby Memory ×3), 18/Bold ×1 (System Health) — below MetricCompact (16), no rung between.
• 24/Bold ×2 (Battery Health), 24/SemiBold ×1 (About) — between Metric (22) and MetricLarge (26).
• 28/Bold ×2 (Battery Health's charge, Dashboard's health score) — Display's size, but these are numbers.
• 7 fractionals: 12.5 ×5 (all warning-banner body text), 11.5 ×2.
• Display's own BasedOn gap. Unlike Metric it sets its own colour and family, so it never had the foreground half — closing it would change the rendering mode on 59 tab titles. Separate call.

Each of those is either "add a rung" or "make this number a different size", so each needs a mockup and an explicit go-ahead, not a guard. Narrowing this issue to that remainder, and #1630's identical remainder folds into it.

grep -rhoE 'FontSize="[0-9.]+"' Views/*.xaml MainWindow.xaml | wc -l → 410, | sort -u | wc -l → 14, re-run today.

[laurentiu021]

Shipped in v1.109.1 — the number half of this issue is closed out, and the body has been rewritten
against current source because most of its original figures were not reproducible (see the "Corrections"
section there: Heading was never dead, and Metric was never unused).

Fifteen call sites moved onto an existing rung: Standby Memory ×3 and System Health 18 → MetricCompact,
Battery Health's capacity and wear 24 → Metric, Battery Health's charge and the Dashboard health score
28 → MetricLarge, and seven banner bodies off half-point sizes (12.5 → Body, 11.5 → Subtle). Five metric
rungs, none added.

Two places went beyond a plain size-snap, both because the size alone did not say what the element was:

• Four of the eighteens were text, not numbers — System Logs' event detail header (×3) and Ping's
  connection headline. Snapping those to MetricCompact would have made a sentence smaller than the body
  text beneath it, so they took Heading (18 → 20) instead.
• About's 24/SemiBold product name is left raw. No text rung sits within two points, and resizing the
  app's own name is a branding call.

BatteryHealthView's wear figure already owned an inline <TextBlock.Style> for its colour triggers and
Style can only be set once, so the rung reaches it through BasedOn on that inline style.

What this issue is now about, and why it is not a sweep

172 bare TextBlocks are drawn at 11, 12 or 14 — sizes that already have Caption, Subtle and
SectionTitle. The obvious edit is to swap the size attribute for the token. It is not safe yet.

Those three styles, plus SectionLabel and Display, do not carry
BasedOn="{StaticResource {x:Type TextBlock}}"; they restate Foreground and FontFamily instead. A keyed
WPF style replaces the keyless <Style TargetType="TextBlock"> rather than merging with it, so applying
one drops the two setters it does not restate — TextFormattingMode=Ideal and TextRenderingMode=ClearType.
Converting all 172 today would change the text-rendering mode on 172 elements while looking like a
whitespace-level cleanup in the diff.

Adding BasedOn to those five is one attribute each and fixes it, but it is not free either: on Display it
moves 59 tab titles from TextFormattingMode=Display to Ideal. That is the correct mode at 28px and what
the rest of the app already renders with, so it is very likely an improvement — but it changes every tab's
title, so it wants a look on a machine that runs the app rather than being folded silently into a sweep.

Order is now in the body: tokens get BasedOn first, then the 148 whose rendering the swap provably cannot
change, then the 24 that each alter a colour or a weight, then the question of whether 10 / 15 / 9 deserve
tokens at all.