Material-components-web: mdc-top-app-bar--fixed not working in demo?

[Download]

What MDC Web Version are you using?

Version used in demo

What browser(s) is this bug affecting?

Any

What are the steps to reproduce the bug?

In the demo, here:
https://material-components-web.appspot.com/top-app-bar.html
open element inspector and add class mdc-top-app-bar--fixed to the header id="demo-top-app-bar". Scroll the page. Observe: the top app bar is not fixed.

What is the expected behavior?

The docs state that:

Top app bars can be fixed at the top of the page:

<header class="mdc-top-app-bar mdc-top-app-bar--fixed">
   ...
</header>

So I expect the topbar to become fixed when adding this class.

What is the actual behavior?

After adding the class, the top bar still scrolls with the content.

Sorry if I'm completely missing something obvious here. Should we call some JS to 'activate' the change?

[pgbross]

The demo will be using the last released version of MDC (v0.34.1 as I write this), but the mdc-top-app-bar--fixed variant has been added since then in this PR. This feature looks like it has been merged, so I assume it will be in the next release of MDC (at a guess v0.35.0).

[Download]

I'm looking at the code for the demo, specifically the listeners for the checkboxes at the bottom... They use a Javascript object and element and add the class (as expected) but also sometimes destroy the component and recreate it. Is this needed?

E.g.:

shortCheckbox.addEventListener('change', function() {
  appBarEl.classList[this.checked ? 'add' : 'remove']('mdc-top-app-bar--short');
  appBarEl.classList.remove('mdc-top-app-bar--short-has-action-item');

  appBar.destroy();      //  <-- here
  appBar = mdc.topAppBar.MDCTopAppBar.attachTo(appBarEl);
  // ...
});

[Download]

I also notice that when you check the Short checkbox, the text at the top of the page is hidden behind the toolbar. Not sure if that has been reported as an issue yet.

[williamernest]

@Download This feature is not yet in the released version of the top app bar. It should come out shortly with v0.35.0.

We destroy and recreate the top app bar for cleanup. You wouldn't normally switch between different variants of the top app bar on a real site. This is just so we can clean up listeners from the old variant before we instantiate the new variant. For a normal site, you'd just add the class for the variant you want and instantiate the component.

We've added classes to offset for the fixed position of the toolbar that should also come out in v0.35.0. We'll be pushing out a new release shortly.

[Download]

Thanks @williamernest for clarifying.

[bonniezhou]

v0.35.0 is now released!

[Download]

Is the demo site updated? The header still scrolls away.

[williamernest]

@Download It is updated.
https://material-components-web.appspot.com/top-app-bar.html

[kfranqueiro]

To clarify, you need to check "Fixed" at the bottom right to see the fixed top app bar.

[Download]

you need to check "Fixed" at the bottom right

Yes indeed, that makes it work.

But:

What about this? With the 'Fixed' checkbox unchecked, paste these two commands in the console:

var appBarEl = document.getElementById('demo-top-app-bar');
appBarEl.classList.add('mdc-top-app-bar--fixed');

Am I wrong in expecting the header to become fixed here? Because it doesn't. This code seems to have no effect.

Trying to re-enact the code executed when we click the checkbox, I come up with this:

var appBarEl = document.getElementById('demo-top-app-bar');
var appBar = mdc.topAppBar.MDCTopAppBar.attachTo(appBarEl);
appBarEl.classList.add('mdc-top-app-bar--fixed');
appBarEl.classList[window.pageYOffset > 0 ? 'add' : 'remove']('mdc-top-app-bar--fixed-scrolled');
appBar.destroy();
appBar = mdc.topAppBar.MDCTopAppBar.attachTo(appBarEl);

But still, this seems to have no effect. So what am I missing here?

Also I am surprised by the 'mdc-top-app-bar--fixed-scrolled class being added based on the scroll offset... why is this needed? Does using 'mdc-top-app-bar--fixed' require a listener on onScroll?

[williamernest]

The --fixed variant does have a scroll listener. It's applied so that when the top app bar begins to scroll the elevation is added to appear above the content. The design guidelines state that the top app bar should appear on the same level as the content in it's initial state. When scrolled, the top app bar should elevate above the content so that the content appears to go underneath the top app bar. The class needs to be added before the top app bar is instantiated. An application shouldn't change the top app bar styles dynamically, so we didn't add the ability to do so.

The --fixed-scrolled class is used to apply the elevation change.

[Download]

Thanks I think I understand now. 👍