[Infra] Consistency in directive/component selectors

[dev054]

Bug, feature request, or proposal:

I'm not sure what it's. Maybe a proposal?

What is the expected behavior?

Maybe explain why some selectors are camelCase and others not?

What is the current behavior?

Currently there are kebab-case selectors, such as: md-button, md-icon-button and selectors in camelCase: mdInput, mdPrefix, mdSuffix.

I'm just wondering about the standard here. Why not make everything kebab-case or camelCase? Is there any reason behind the scenes?

---

Still about consistency, currently we use the native input (for inputs type text, number, etc.), native textarea and native button with their respective directives, but... for inputs type radio, checkbox, "slide-toggle" and also for select, option, etc, we have to use a, let's call it, non-native way. Have you ever considered allowing us to use the native elements for them also?

As an example, for radio, we could have something like:

<div md-radio-group>
  <label><input type="radio" name="rad" value="0" md-ratio-button>0</label>
  <label><input type="radio" name="rad" value="1" md-ratio-button>1</label>
</div>

[willshowell]

IIRC the plan is to use kebab-case for component selectors and camelCase for directives. Unfortunately I can't find where I read that - this is the best I found #2636 (comment)

[jelbourn]

@andrewseguin is already in the middle of making sure all of the selectors are consistent.

It is true that @Component selectors are dash-case and @Directive is camelCase... with a couple of caveats:

• Some @Directives pretend to be components (e.g., they would be a @Component but don't have a template)
• Some directives have both an element selector (which must be dash-case) and an attribute selector.

[michael-lang]

For consistency as a developer using the angular material framework, why does it matter if it is a component or a directive? That's an implementation detail most user's won't care about. Isn't what matters when you are writing html code is weather or not it is an element or an attribute?

<button md-button [mdMenuTriggerFor]="optionMenu">Menu</button> <md-menu #optionMenu="mdMenu"> <button md-menu-item (click)="option1()">Option 1</button> <button md-menu-item (click)="option2()">Option 2</button> </md-menu>

It feels like md-button should be mdButton, and md-menu-item should be mdMenuItem.

Also, md-list-item is a component with selector 'md-list-item, mat-list-item, a[md-list-item], a[mat-list-item]'. Wouldn't this fit into the developer mindset better as:
'md-list-item, mat-list-item, a[mdListItem], a[matListItem]'?

[abdulhaq-e]

In my humble opinion, I think everything should be consistent regardless if it's a component or a directive. Otherwise, it would be very confusing.

[SchnWalter]

In 2.0.0-beta.10, there is a deprecation notice for dash-case directives, it it isn't linked to any document explaining why:

All dash-case @Directive selectors are deprecated in favor of the camelCase equivalent. The
dash-case selectors will be removed in a subsequent release. Some examples include:

And you find comments like this throughout the repository issues and PRs:

• Why are some attribute selectors dash-cased? #6720 (comment)

The picture is incomplete:

• there are directives that can only have HTML attribute selectors, like the ones that style the native <button> tag; this is because you can not fully replace the native button tag
• there are cases with no clear guidelines on what to do.

For example, take a look at the card module, you have directives that have different kind of selectors:

• MatCardContent, MatCardFooter, MatCardActions, etc -- that can only be used as HTML tags
• and MatCardTitle, MatCardSubtitle -- that can also be used as a HTML attributes.

There should be some clear guidelines on how to choose between using an HTML attribute and an HTML tag or between @Component and @Directive decorators... and then you have dash-case vs camelCase and all those other exceptions for the <form> and related elements. Some guidelines should be written in a document somewhere and have people discuss about them (in public).

@jelbourn, are there publicly available notes from discussion that you talk about in the linked comment?

[SchnWalter]

Realted: #3125