[audit] overlay extra classes

[willshowell]

Bug, feature request, or proposal:

Suggesting library-wide audit

Currently

Overlay components all accept extra classes differently:

• Dialog: string | string[]
• Snackbar: string[]
• Tooltip: NgClass
• Select: NgClass
• Menus: class only
• Datepicker: none
• Autocomplete: none (tracking feat(autocomplete): add input for adding classes to the panel #6618 or feat(autocomplete): add md-autocomplete classes to overlay panel #7176)

Ideally

Consistent NgClass compatibility would be awesome. If not possible, string | string[] support would be good.

Additionally, consistent naming would be nice. Snackbar uses extraClasses, whereas select uses panelClass. Also, select and dialog both use panelClass, but the class is added to different elements.

[jelbourn]

Agreed, they should all be consistent. I would want to use panelClass everywhere

[amcdnl]

@jelbourn - So to clarify, update all the inputs to panelClass with NgClass as the interface? Do we need to deprecate as well?

[jelbourn]

The template-based components can have NgClass mechanics, but dialog.snack-bar would just stay as strings because there's no binding context

[jelbourn]

Also this would be a good candidate for a mixin

[amcdnl]

@jelbourn -

1. I played around with a mixin but the implementations varied so much, it was tricky. I ended up making a utility parser instead.
2. Do you want me to rename matTooltipClass to matPanelClass or just leave it for that one?

Before I make a PR up, can you give this a once over and see if this is on track with what you were thinking? https://github.com/amcdnl/material2/tree/overlay-class-6372

[jelbourn]

Tooltip can stay as matTooltipClass

[jelbourn]

If you make a PR it's easier to leave comments; you can mark it as WIP

[jelbourn]

One thing I will say is that we don't want to add additional cdk packages for utility methods; each one is a public API that a user would potentially need to know about (such as when adding to a systemjs config)

[josh18]

Would it make sense (maybe in another issue / PR) to add a similar input for the .cdk-overlay-container element?

I guess another option would be to have only one class at the top (.cdk-overlay-container) and then devs can use nested styles to control all parts of the overlay. With the current implementation I don't think there is any way to edit an overlay background from a component?