text-field: allow floating label to be outside of notched-outline markup
See original GitHub issueCurrently the floating label always needs to be wrapped inside of the notched-outline
structure. e.g.
<div class="mdc-notched-outline">
<div class="mdc-notched-outline__leading"></div>
<div class="mdc-notched-outline__notch">
<!-- Needs label here! -->
</div>
<div class="mdc-notched-outline__trailing"></div>
</div>
The use case of allowing that the notched-outline is decoupled from the floating label structure-wise is that prefixes and suffixes can have flexible dimensions. To make the outline work properly with flexible prefixes and suffixes, the following things are necessary:
- The floating label needs to be inside of a container that is matches the boundaries of the input. This ensures that the floating label “looks” like a placeholder in the docked state, and in the floated state it won’t be in the prefix container.
- The notched-outline needs to overlap the whole text-field. i.e. including prefix and suffix container.
Doing these things allows for flexible prefix and suffix containers (which is a requirement for our MDC-based implementation of the Angular Material form-field).
The problem currently is that we can only do (1) while (2) is not possible when (1) is solved. This is because the floating label cannot be a child of the notched-outline as it would mean that the label is no longer relative to the input container. Both actions/requirements are mutual exclusive at the time of writing.
To make this work the best would be if the notched-outline does not need the label as children, but rather can just accept it through a foundation/adapter method.
Issue Analytics
- State:
- Created 4 years ago
- Comments:14 (14 by maintainers)
Top GitHub Comments
It works because the label element is a child of the
mdc-notched-outline__notch
element. The notch gets its width from its child element: the label. The label gets its length from the width of the text.As the width of the label increases, the width of its parent notch increases.
I do think one important distinction needs to be made: arbitrary leading content vs true prefixes. A true prefix (for example, “+1” in front of a phone number, or “$” in front of a monetary input) is text only and should be part of the #infixContainer in your diagram, not the #prefix container.
Prefixes are aligned with the floating label for filled text fields. They do not change the floating label’s horizontal position.
Arbitrary leading content would include things such as leading icons. They do move the horizontal position of a filled variant’s label and the outlined variant’s unfocused label. Those should be part of the #prefix container in your diagram.
I think it’s critical that this distinction be made in the API instead of putting prefix and leading content together in the same container.
This example, taken from https://material.angular.io/components/form-field/overview, would be an incorrect way of using a prefix and suffix.
The prefix is not aligned under the floating label, and both the prefix and suffix are not using the correct secondary color to distinguish them from the input’s color.
It may be necessary to introduce a new ng-content selector for this distinction. For example:
You could keep
[matPrefix]
for leading content to avoid a breaking change, but encourage[matPrefixText]
and[matSuffixText]
for Material-themed prefixes and suffixes.I’m going to close this issue for now. I think we’ve come up with a valid workaround offline and using the suggestions above.
It’s unlikely that the workaround will be implemented into MDC since we do not support arbitrary prefix content, but it should work for Angular.