Inactive input-message adds white-space below a label

[nwhittaker]

Actual Behavior

Given a <calcite-label> that contains a <calcite-input> and an inactive <calcite-input-message>, its bottom white-space is greater than a <calcite-label> that only contains a <calcite-input>.

Expected Behavior

Given a <calcite-label> that contains a <calcite-input> and an inactive <calcite-input-message>, its bottom white-space is the same as a <calcite-label> that only contains a <calcite-input>.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/QWmBoEe
Updated codepen - https://codepen.io/mac_and_cheese/pen/BaxMBmm

Reproduction Steps

1. Visit the code sample
2. Note how the boxes around each <calcite-label> are different heights

The height of the 2nd box should match the height of the 1st box.

Reproduction Version

beta.86

Relevant Info

This inconsistency adds difficulty to maintaining a vertical rhythm within a form that includes only some inputs with an assoc. input message.

A quick fix could be to give <calcite-input-message> a display: none style when its active attribute is absent.

Regression?

No response

[alisonailea]

The demo of the buggy behavior of Calcite Input Message is out of date. There has been some major changes to Calcite Input Message between .557 and .675. @benelan please update the demo or make a comment for Nathan describing how the component works now.

[benelan]

I'm still able to reproduce on next, none of the changes effected the repro sample:
https://codepen.io/benesri/pen/oNyrqLY

Edit:
as mentioned in the changelog

input-message: removed deprecated properties

• Removed active property, use the global hidden attribute instead.
• Removed type property, "floating" is no longer supported.

[driskull]

@eriklharper @macandcheese @benelan wasn't it the plan for this component to go away and be rolled into input?

If so, should we deprecate it?

[macandcheese]

I know it has been mentioned before, although I can't find an issue for it. I think it might have to be rolled into label if possible, since it is applicable to a lot of form components, not just input.

It might be good to re-evaluate this as part of the larger form / validation story. I'd imagine that will be a larger epic for another major release, so not sure if we are quite ready to deprecate it?

[benelan]

I honestly thought we were going into the opposite direction by splitting up input. If we roll input-message into input do we just delete input-text and input-number?

[macandcheese]

By rolled into, I just meant having a slot within label for the component to reside. Right now input-message as a name is a bit misleading, really it should be / can be used for any form related component messaging, IMO. form-message or label-message, etc. seems more general / fitting. But I don't know if we need to change this until the next large breaking release after 1.0.

[benelan]

Yeah I think that one should wait. Input needs a lot of work; it's all over the place right now. Besides the validation/input-message items you mentioned:

• Assuming we want to keep splitting up Input into separate components, we need to
  • start removing types from calcite-input. Right now you can do calcite-input-number and calcite-input type="number". We need to pick one. †
  • decide if we are creating a component for every type, which seems excessive to me. If we are keeping some types in the calcite-input component, we need to define which ones stay (and why)
  • create interfaces/utils to cut down on the duplicate code
• Autofill/autocomplete doesn't work well and we will likely need to "unshadow" Input(s). At least until there is better browser support for forms with custom elements
• The lifecycle methods need a refactor

I think it would be better to get all/most of those changes into a single major release if possible.

---

† It may make sense to remove input-text and input-number before v1 and then add them back when we have time to split the rest of the components, if that's the route we choose. I'll bring that up with Franco when he gets back

[macandcheese]

I think that’s a fair summary, although I do think this particular issue scope is much smaller - just fixing the white space with our current component - #6037

Maybe an issue with the above thoughts would be good?

[benelan]

Yeah I agree that we should fix this white space issue now. But deprecating/moving the input-message component should wait until we sort out our Input plans.

[driskull]

Adding it as part of label might make the most sense. Or at least a slot of label.

If we do keep it then we should consider renaming it. It's really a form or label message

[benelan]

Yeah I like the idea of making it part of label. Input isn't the only form component that can benefit from validation messages

[driskull]

Agreed. It should not be tied to just input

[alisonailea]

@driskull @benelan the issue with the whitespace "bug" here is two fold. The components involved here use margin which is pushing around content they don't personally have control over (child controlling the layout of it's parent which is a design system anti-pattern) and that the label itself is using flex-gap to simultaneously layout it's children which adds a gap between input and input-message unless input-message's styles are set to "display: none" which can only be achieved by either setting the attribute on the Host or by a user setting the "hidden" attribute themselves. A full fix will require a refactor of label as well as input and input-message. OR documentation instructing users to simply add "hidden" attribute to empty input-message which seems like a better solution at this time.

[driskull]

Agreed. Lets hold off on this one until Franco is back. Maybe we can deprecate this component and build it into label after 1.0.

[alisonailea]

where should the documentation go?

[benelan]

Yeah agreed. I'd put it on the component's documentation page (source) under a new Overview/Usage section. Copying the format from other component doc pages, e.g. alert.

@geospatialem do you have bandwidth to help add the doc?

[geospatialem]

@geospatialem do you have bandwidth to help add the doc?

Definitely, can add it to the doc page today, assuming we're adding a deprecation to the input-message component?

[alisonailea]

Definitely, can add it to the doc page today, assuming we're adding a deprecation to the input-message component?

No deprecation yet. But we need to alert users that they must add a "hidden" attribute to an empty input-message or there will be weird extra spacing.

[geospatialem]

Added to the doc site, which will go live next Wednesday. Updating to the Stalled milestone and Franco's list for consideration for his 1.0 and/or post-1.0 thoughts.