Material-components-web-components: mwc-top-app-bar-fixed ??

[eskan]

Hi,
why this component ? instead of an attribute on mwc-top-app-bar. Any technical reason ?
Thanks in advance for explanation

[dfreedm]

The reason is mostly around the idea that anything attribute based must be dynamic, and the "scrolling" and "fixed" top app bar variants require switching out Foundation controllers: https://github.com/material-components/material-components-web-components/blob/bb1ad7f281bc10b2820b71b20a7c09707037c266/packages/top-app-bar/src/mwc-top-app-bar-base.ts#L31-L37

https://github.com/material-components/material-components-web-components/blob/bb1ad7f281bc10b2820b71b20a7c09707037c266/packages/top-app-bar/src/mwc-top-app-bar-base.ts#L129-L135

It seemed more likely that the top app bar behavior is going to remain the same for an individual bar, rather than switching back and forth.

If you have use cases where you need to be able to switch between a "scrolling" and "fixed" top app bar, I'd be open to merging them back together.

[eskan]

Hi @azakus , thanks for explanation.
I understand the fact an attribute should be dynamic but it looks like a technical constraint create this component. I'm not a fan at first glance and still not.
Is this use case are matching the fact fixed could be an attribute:
https://codepen.io/JGallardo/pen/lJoyk
Regards,

[Sebastianhex]

If you have use cases where you need to be able to switch between a "scrolling" and "fixed" top app bar, I'd be open to merging them back together.

This would come in handy for extra screen real-estate according to the user's device size.
For example, switching to "scrolled" for mobile (where screen real-estate is limited), then back to "fixed" for desktop.

[JosefJezek]

@dfreedm @aomarks please reopen the issue. I have same use case as @Sebastianhex