MatTabGroup height is always dynamic

Bug, feature request, or proposal:

Bug

What is the expected behavior?

According to the documentation,

By default, the tab group will not change its height to the height of the currently active tab. To change this, set the dynamicHeight input to true. The tab body will animate its height according to the height of the active tab.

What is the current behavior?

As far as I can tell, the height of the mat-tab-group element is always dynamically set according to the height of the currently active tab. The only difference is that when dynamicHeight = true there is a smooth height transition when switching tabs. What I want in my own app is for the height of the group to be fixed and for the content to scroll when necessary, which I assumed would be the case if dynamicHeight = false. Maybe I am misunderstanding the documentation - if so then I think its meaning should be clarified.

What are the steps to reproduce?

Here is a plunkr showing what I mean: http://plnkr.co/edit/gI0A56uTDzoLjYAosbDR?p=preview

Toggle the dynamicHeight property using the slide toggle. The height of the md-tab-group element will change regardless of the value of this property.

What is the use-case or motivation for changing an existing behavior?

Implementation should be aligned with documentation or documentation should be unambiguous.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular 4.4.3/Master, Material beta 11/Master, Windows 10, Chrome 61

Is there anything else we should know?

[willshowell]

Agreed, there is an inconsistency between the following

1. Overview description

   Dynamic Height

   By default, the tab group will not change its height to the height of the currently active tab. To change this, set the dynamicHeight input to true. The tab body will animate its height according to the height of the active tab.

2. API reference

   dynamicHeight | Whether the tab group should grow to the size of the active tab.

3. @benelliott’s plunker

   http://plnkr.co/edit/gI0A56uTDzoLjYAosbDR?p=preview

IMO, the behavior makes sense per @josephperrott’s explanation (particularly the no overflow part), but the docs suggest a different behavior.

[josephperrott]

Closing as this is working as expected.