fix(general): restore classic thumbnail metadata under renamed YouTube classes

[rascal-sl]

Summary

Restores the Classic thumbnail metadata feature on the watch page sidebar. Closes #4278.

YouTube renamed its content metadata view-model classes from the hyphenated yt-content-metadata-view-model-wiz__* form to camelCase. The rule in general.css still targeted the old names, so the play-triangle icon in front of the view count came back.

Root cause, measured on a live watch page

Counted in the console on youtube.com/watch:

Selector the CSS targeted	Matches	Current equivalent	Matches
.yt-content-metadata-view-model-wiz__metadata-row	0	.ytContentMetadataViewModelMetadataRow	11
.yt-content-metadata-view-model-wiz__metadata-text	0	.ytContentMetadataViewModelMetadataText	12
.yt-content-metadata-view-model-wiz__metadata-icon	0	.ytContentMetadataViewModelLeadingIcon	4

Every one of the 4 leading icons sits directly inside a metadata row, and the row it belongs to reads 18M 5y ago, which is the views and age row from the report.

The fix

One added selector. The old selectors stay, so any surface still served the previous markup keeps working.

html[it-classic-thumbnail-metadata='true'] .ytContentMetadataViewModelMetadataRow .ytContentMetadataViewModelLeadingIcon

It targets the leading icon by name rather than every icon in the row. The channel verified badge is a separate .ytAttributedStringImageElement inside the metadata text, so it is not hidden.

Verification

Applied the exact rule to a live watch page and measured getComputedStyle before and after:

• 4 leading icons: flex to none
• 3 verified badges: inline-flex to inline-flex, unchanged

To reproduce, paste this in the console on a watch page:

document.documentElement.setAttribute('it-classic-thumbnail-metadata', 'true');
const s = document.createElement('style');
s.textContent = "html[it-classic-thumbnail-metadata='true'] .ytContentMetadataViewModelMetadataRow .ytContentMetadataViewModelLeadingIcon{display:none !important}";
document.head.appendChild(s);

npx jest passes: 24 suites, 113 tests.

What I could not check

The home feed did not render for me while signed out, so I confirmed the watch page only. Keeping the old selectors means that surface cannot regress either way.

The block comment above the rule mentions accompanying JS that expands the shortened time-ago text and restores the interpunct delimiter. I found no such JS in the repo, so 1mo ago stays short and the delimiter stays absent. That looks like a separate gap and I left it out of this change.

---

Tisankan Jeyakumar

[wahajahmed010]

Code review

Small and focused fix. Adding the new ytContentMetadataViewModelMetadataRow .ytContentMetadataViewModelLeadingIcon selector to extend the existing rule to YouTube's renamed camelCase view-model classes is the right approach — and the decision to target the leading icon by name (instead of yt-icon) instead of all icons is well-considered, because it preserves the channel-verified badge rendering in the row. The expanded comment block above the selector explains the trade-off clearly; that's the kind of context that ages well.

A few small things:

1. No regression coverage

The PR is a CSS-only change, so no unit test would land here, but YouTube's HTML mutates frequently and this is exactly the kind of selector that silently regresses. Worth either:

• adding a snapshot/visual check in the existing e2e flow that visits a watch page and asserts the leading icon is hidden when the feature toggle is on, or
• at minimum, a comment in general.css near the selector with the date and a link to YouTube's HTML release notes.

2. !important proliferation

The new selector inherits the existing display: none !important; rule. Both old and new selectors are now in the same rule body, which is fine. But once YouTube ships yet another rename (they do this every few months), this rule will keep growing. Consider whether it's worth splitting into two named rules with the shared !important — easier to grep and to remove selectively when old selectors are no longer needed.

3. Specificity parity

.ytContentMetadataViewModelMetadataRow .ytContentMetadataViewModelLeadingIcon matches the existing class-class specificity of the other selectors in the rule, so there are no specificity conflicts. Confirmed.

4. The new selector assumes the leading icon is always present

If YouTube ever omits ytContentMetadataViewModelLeadingIcon from a row layout (e.g., in a future "compact metadata" variant), this selector will silently no-op and the play-triangle icon will reappear. Consider adding a fallback to .ytContentMetadataViewModelMetadataRow yt-icon:first-child or similar so the rule degrades gracefully.

Overall: ship-it once the visual smoke check confirms the play-triangle is hidden and the verified badge is preserved in both the legacy and the new markup.

Automated review posted via the open-source-contributor pipeline.

[rascal-sl]

Thanks for reading it closely. Taking the four points in turn.

1. No regression coverage. Fair, and taken. The comment above the rule now carries the month the camelCase names were observed and an instruction for the next person: read the row markup and add the new name, rather than widening the rule to every icon. Pushed in 466c125. A visual check in the e2e flow would be better still, but that belongs in its own PR rather than bolted onto a one-selector fix.

2. !important proliferation. Leaving it. Splitting the rule into two named blocks touches four selectors this PR did not otherwise change, and the split only pays off when the legacy names are actually retired. That is the right moment to do it, and it is a separate change.

3. Specificity parity. Agreed, nothing to do.

4. Fallback to yt-icon:first-child. This one I would push back on, because it undoes the thing you identified as correct in your opening paragraph.

The rule already carries a broad legacy selector:

html[it-classic-thumbnail-metadata='true'] .yt-content-metadata-view-model-wiz__metadata-row yt-icon,

That hides every icon in the row on the old markup. Targeting the leading icon by name in the new markup is a deliberate departure from that, and adding yt-icon:first-child alongside it puts the broad behaviour straight back for anything that happens to render first in the row.

The scenario is also hypothetical. I have not seen a compact-metadata variant that omits ytContentMetadataViewModelLeadingIcon, so a fallback for it would be a guess at markup that does not exist yet. If it silently no-ops later, the play triangle reappears and is visible immediately, which is a better failure than quietly hiding the wrong icon. That is the trade the dated comment now records.

Happy to add the fallback if you can point me at a page serving that variant.