How do you increase the text size in the TabViewItems header?

[Going-Gone]

I set
FontSize to a number, and the size stays the same. Is there something I'm missing?

FontSize="500"

[Felix-Dev]

@Going-Gone You can override the TabViewItemHeaderFontSize resource to set the FontSize for the header.

@StephenLPeters Should we template bind the TabViewItem's FontSize property here to its internal ContentPresenter? We alreay template bind the TabViewItem.FontWeight API and with #2653 we will also template bind the Foreground and Backgroundproperties. So we should likely respect TabViewItem's FontSize property as well.

[StephenLPeters]

Yup, I agree. We need to be better about remembering to bind these inherited properties. @ranjeshj

[StephenLPeters]

@MikeHillberg is FontSize Inherited? Should we need to template bind this to the template parts?

[StephenLPeters]

@Felix-Dev I think that the FontSize is intended to propagate to the tab's content, and the perscribed way of setting the header font size is through that light weight style. If so, template binding the font size property to the header would be incorrect.

[MikeHillberg]

@MikeHillberg is FontSize Inherited? Should we need to template bind this to the template parts?

FontSize inherits, but a lot of controls set it in their default style, which will override anything that comes from a parent.

[Felix-Dev]

I think that the FontSize is intended to propagate to the tab's content, and the perscribed way of setting the header font size is through that light weight style. If so, template binding the font size property to the header would be incorrect.

@StephenLPeters It does not have any effect at all on the Tab's content from what I can see:

<muxc:TabView>
    <muxc:TabView.TabItems>
        <muxc:TabViewItem Header="Tab 1" FontSize="80">
            Some tab content
        </muxc:TabViewItem>
    </muxc:TabView.TabItems>
</muxc:TabView>

I also think if we have the TabViewItem.FontWeight property affecting the TabViewItem's header, so should TabViewItem.FontSize. Anything else would be unexpected API behavior to me. Alternatively, FontWeight. which is currently template bound, should be looked at again.

TabViewItem.FontFamily is inherited for the header:

<muxc:TabView>
    <muxc:TabView.TabItems>
        <muxc:TabViewItem Header="Tab 1" FontFamily="Segoe Script">
            Some tab content
        </muxc:TabViewItem>
    </muxc:TabView.TabItems>
</muxc:TabView>

So from the way I see it - given the current API design - TabViewItem.FontSize should affect the font size of the tab's header - and only that. The way as it stands now, we are currently looking at inconsistent API behavior.

[Going-Gone]

The TabView control has a FontSize property as well as the TabViewItem. Sort of confusing to what font it affects.

[StephenLPeters]

Hmm, @Felix-Dev your points are convincing, as the other API's are currently set up I agree I would expect font size to effect the header. Unfortunate then that we already have a resouce which is driving this. Template binding the FontSize property would break anyone that was using the resource to customize this...

[StephenLPeters]

@Going-Gone I agree the scenario is confusing... @Felix-Dev if you set the FontSize property on the TabView does it do anything? Does setting the FontFamily on the TabView propagate to all of the TabViewItems?

[robloo]

I don't think we should be afraid of making breaking changes to fix template bindings. It just requires calling out clearly at the top of the release in a breaking changes section what apps need to update. This is especially true since upgrading WinUI is optional.

More generally, accumulation of errors is a problem that makes things tricky to use 10 years in the future. I brought this up in the past if we could setup a system were major releases were allowed breaking changes (like WinUI 4.0) where there is clear benefit (such as adopting ItemsRepeater across the board, etc.)

[StephenLPeters]

I agree this shouldn't block us fixing the issue. Just wanted to get the issue on the books.

[Felix-Dev]

@StephenLPeters The existing resource (TabViewItemHeaderFontSize), while not needed any longer if we template bind FontSize, would not cause a breaking change, if I add

<Setter Property="FontSize" Value="{ThemeResource TabViewItemHeaderFontSize}"/>

to the style of the TabViewItem.

Will check TabView.FontSize behavior soon.

[StephenLPeters]

I think that is true, but it would break the propagation behavior of FontSize, maybe that is okay though..

[Felix-Dev]

@StephenLPeters The TabView.FontSize is inherited by the ContentPresenter (TabContentPresenter) of the TabView:

<muxc:TabView FontSize="80" >
    <muxc:TabView.TabItems>
        <muxc:TabViewItem Header="Tab 1">
            Some tab content
        </muxc:TabViewItem>
        <muxc:TabViewItem Header="Tab 2"/>
    </muxc:TabView.TabItems>
</muxc:TabView>

TabView.FontFamily affects both the tab content and the TabViewItem's header:

<muxc:TabView FontFamily="Segoe Script">
    <muxc:TabView.TabItems>
        <muxc:TabViewItem Header="Tab 1">
            Some tab content
        </muxc:TabViewItem>
        <muxc:TabViewItem Header="Tab 2"/>
    </muxc:TabView.TabItems>
</muxc:TabView>

[StephenLPeters]

hmm, in that case these font properties feel a bit broken, I suspect we have this issue in a few places across the framework..

[ranjeshj]

@stmoy as FYI.

[stmoy]

Thanks for the CC - I'll add this to the small pile of "TabViewItem customization doesn't work quite right" issues 😉

[michael-hawker]

I actually had hit this just before this issue was filed, glad one was filed.

I believe the FontSize of the ContentPresenter being template bound could fix this issue, L690:

microsoft-ui-xaml/dev/TabView/TabView.xaml

Lines 682 to 693 in c6c8d08

	<ContentPresenter x:Name="ContentPresenter"
	Grid.Column="1"
	HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
	VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
	Content="{TemplateBinding Header}"
	ContentTemplate="{TemplateBinding HeaderTemplate}"
	ContentTransitions="{TemplateBinding ContentTransitions}"
	FontWeight="{TemplateBinding FontWeight}"
	FontSize="{ThemeResource TabViewItemHeaderFontSize}"
	Foreground="{ThemeResource TabViewItemHeaderForeground}"
	OpticalMarginAlignment="TrimSideBearings"
	HighContrastAdjustment="None" />

FontWeight works fine as you can see it's template bound above, so it's odd the other font properties weren't done in the same manner. E.g. FontStyle and FontStretch are missing completely.

[hawkerm]

I just noticed a similar problem for the parent containers like TabView and ListView. If you set the Font properties on the parent ListView it has no effect on the child ListViewItems as I may expect...

[atiyka]

So couldn't anyone fix this issue in the last more than one year?

[hawkerm]

@bkudiess why did you covert this to a discussion from issue #3047? Based on the discussion there was a legitimate/issue/bug even though the original post was a question. It should be re-labeled, maybe have the title changed, but seems like it should still be tracked as an issue?

[kmgallahan]

@hawkerm I think they just took every existing Issue with the Question tag and made them Discussions - even though many of the issues like this one evolved into actionable tasks...

@gabbybilka @ranjeshj

[ranjeshj]

@hawkerm @kmgallahan you are right. This started as a discussion/question but looks like a legitimate issue. Can you file a separate issue? Converting the discussion to an issue seems like we might lose the discussion.

[kmgallahan]

@ranjeshj The Discussions Q&A section is full of issues like one. Manually recreating ~100 new issues doesn't seem like the best approach.

I wasn't even involved in this issue before now - just pointing out the overall problem here.

https://github.com/microsoft/microsoft-ui-xaml/discussions/categories/q-a

[PeterHevesi]

So can you please finally fix this? It is not very user friendly, that some properties that should work are not working... I can't understand how come you just let this situation be for almost 4 years... That is crazy indeed. Please make WinUI better, and fix all these issues