text-field: allow floating label to be outside of notched-outline markup

[devversion]

Currently 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:

1. 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.
2. 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.

[asyncliz]

Thanks for the issue!

I'm not entirely sure I understand why the label's position would be related to prefix or suffix. No matter how wide a prefix is, the label's position does not change. Prefix and suffix are considered "part of" the input. In your diagram, #prefix and #suffix should be inside #input.

Outlined Prefix/Suffix https://material.io/components/text-fields/#outlined-text-field

The only time a label's horizontal position changes is if there's a leading icon.

We are actively working on prefix/suffix in #1892, the DOM structure will look something similar to this:

<span class="mdc-text-field__prefix">$</span>
<input class="mdc-text-field__input" value="42">
<span class="mdc-text-field__suffix">.00</span>

Would it be possible to incorporate our prefix/suffix work into mdc-form-field?

[devversion]

@asyncliz Thanks for the quick reply!

I think my graphic was most likely confusing. The actual text-field is the whole container surrounded by the red border. The red border should actually be the outline of the text-field. So we actually consider prefix and suffix as part of the input, but just in a perspective of how it will be composed in the DOM, the native <input> element is in between two containers for prefix and suffix (demonstrated in the drawing)

In our implementation of the Angular Material form-field, we use the prefix and suffix containers for both icons and text and consider a leading icon as prefix. That's probably wrong though in terms of the spec since leading icons and prefixes have different semantics (i.e. label needs to shift horizontally for icons as you explained).

So let's just talk about this issue in in terms of leading icons where the label needs to be shifted (as you said). In that case, consider that the leading icons have an unknown width. How would one be able to ensure that the floating label does not overlap the icon in the non-floating state? I see that MDC achieves this by just adding more horizontal padding to the input, and by shifting the floating label by x pixels. (enforcing that icons have a certain width). This won't work for us since we do not know the width of the icon / nor enforce a certain icon width.

So to make this work, we want the label to be a children of #infixContainer (blue-border box). The MDC floating label uses absolute positioning and is usually positioned relatively to the text-field box (red in the graphic). We take advantage of this, and just make it so that the label is positioned relatively to the #infixContainer. That way the label will never exceed the boundaries of the infix container and always align properly next to the leading icon with unknown width (in the graphic the icon is in #prefix).

Does this somehow make sense to you? If it's still somewhat unclear please let me know 😄 Thanks!

[asyncliz]

I would definitely recommend treating prefix/suffix and icons differently instead of as the same container. I think you'll run into quite a few problems. Off the top of my head, prefix/suffix padding between them and the input is different than icons, and changes if the text is end vs start aligned.

How close is your implementation following the spec? I can talk with design and see if there's capability for icons to be wider than 24px.

I think the biggest problem we'll run into is that the notched outline requires the label to be a child, so that it can querySelector it. I'll do some experiments this morning and see if I can think of a way that would be possible.

[devversion]

We think of the prefix and suffix as simple containers where people can put in arbitrary elements. I think we have a ambiguous naming for this though since it's technically not necessarily matching the prefix/suffix semantics explained in the Material Design specification.

For things like icons we'll have some additional default styling inside prefix/suffix containers to ensure there is proper spacing. I totally realize that this might have downsides but we mostly need to do that for backwards compatibility with our old implementation of the form-field and I think in general it makes sense to give users the flexibility to put in anything they want (e.g. some people put in icons wrapped by buttons). In any case though, for icons the goal is to be visually the same as the current leading icon support available in MDC text-field (just with providing the flexibility and backwards compatibility)

I think the biggest problem we'll run into is that the notched outline requires the label to be a > child, so that it can querySelector it. I'll do some experiments this morning and see if I can think of a way that would be possible.

Indeed. That is the problem I ran into. If the label would be decoupled from the notched-outline, then this issue would be solved for us. It should be possible to just keep the current behavior, but provide a possibility to pass in a label element. (It might be necessary to modify how the necessary styles are applied to the label though; could be through a class that is added to the label element)

Also thanks for looking if this is possible!

[asyncliz]

Hi @devversion, I'd like to take another look at this issue now that I understand what Angular is doing with MDC a little better.

The tl;dr is that we probably won't support using the label outside of the notched outline anytime soon. It breaks a few critical things, such as the default width gap in the notch of the outline (which is important for SSR to avoid a FOUC).

However, I'm not entirely unconvinced that what you're wanting cannot be achieved. You need the label to be relative the infix container for the filled text field variant, but I do not believe you need it for the outlined variant.

Take a look at how the spec describes leading icons for the two:

The label is displaced in the filled variant, but not the outlined variant.

I would argue that any arbitrary leading content in an outlined text field would also not displace the label. With that assumption, it's no longer necessary to have a notched label inside the infix container.

The downside is that you'll need one more *ngIf statement to hide the label in the infix container when using the outlined variant, but I think that'd be a good compromise.

What do you think?

[devversion]

@asyncliz Thanks for looking into this. I think that you are right in saying that for the outline appearance, the label doesn't need to be displaced if the floating label is active.

Though, what happens if there is no content inside the text-field and the text-field is not focused? In those cases, the label still needs to be relative to the infix container, as otherwise the label would overlap the leading icon/prefix. MDC doesn't have this issue since they known that the prefix/icon has a fixed width. Due to this limitation, my proposal was to always have the label relative to the infix container, while the outline wraps the prefix, input and suffix elements.

I think the issue we are facing here is somewhat special. Ideally, we'd not allow arbitrary prefix/suffix content, but just have fixed sizes as in MDC. This isn't an option for us right now due to backwards compatibility. In the future, we should definitely get rid of this.

Regarding SSR: why is that? Couldn't the default width gap be still determined? The reference to the label still exists. Just the CSS selectors which should apply to the floating label need to be adjusted. I will experiment more with this. In general, it feels more like something we need to address on our side since it's an issue specific to our old implementation of the text-field.