Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
The label truncates earlier because the input now reserves two characters of width, which reads as blank here since this case has no value.
There was a problem hiding this comment.
The label truncates earlier because the input now reserves two characters of width, which reads as blank here since this case has no value.
| // Characters wider than the `0` glyph can still clip. Widening the floor to | ||
| // fit them leaves too little room for the label, and typing scrolls the | ||
| // caret into view regardless. | ||
| $form-control-min-width: 2ch; |
There was a problem hiding this comment.
Input, textarea and select all make the same trade against their label, so a single value keeps them from drifting the way select's untraceable magic 16px already had.
brandyscarney
left a comment
brandyscarney
left a comment
There was a problem hiding this comment.
Looks good! Left some comments about the skipped tests.
| }); | ||
|
|
||
| // TODO(FW-7682): unskip once the selected text is no longer clipped away by .native-wrapper | ||
| test.skip(`should not have visual regressions with a start-positioned label, a value and a wide ${slotName} slot`, async ({ |
There was a problem hiding this comment.
Should we just take the screenshots anyway? They will be updated by FW-7682 but that's fine.
| }); | ||
|
|
||
| // TODO(FW-7682): unskip once the selected text is no longer clipped away by .native-wrapper | ||
| test.skip(`should keep two characters of the value visible with a start-positioned label and a wide ${slotName} slot`, async ({ |
There was a problem hiding this comment.
I removed the skip here and ran it locally and it doesn't fail, do we need the skip?
There was a problem hiding this comment.
Shouldn't this have been failing though if the Select isn't sizing properly, or no?
2 participants
Issue number: resolves internal
What is the current behavior?
With a start-positioned label and a wide start or end slot, the editable area of
ion-inputandion-textareacollapses to 0px. The value is not merely cramped, it is gone, so the user cannot see what they are typing.ion-selectlooks like it already solves this, because.select-textcarries amin-width. It does not..native-wrappercollapses to 0px and clips the text away, so the selected value is invisible too and that floor has never had any effect.What is the new behavior?
ion-inputandion-textareanow keeps a minimum width, so the value stays visible however wide the slotted content is.2chrather than a pixel value, so the same two characters stay visible as text scales. A pixel floor degrades to roughly 1.2 characters at a 24px base font.ion-textareaalso needed its.native-wrapperfloored. Themin-width: inheritit carried computed to0px, so the textarea kept its width but spilled outside the field border.ion-selectreads the same variable so the three cannot drift. Its only visible change is 2px on thefit-contentsnapshot.ion-selectstill shows no selected text when slotted content is wide, and this PR does not change that. Sharing the variable is not enough for select, because.native-wrappergives up all of its width to the label and hides its overflow, so any floor on.select-textis clipped to nothing. Fixing it means changing how that wrapper trades width with the label, which is FW-7682. The two select tests added here are skipped withTODO(FW-7682)and are the ready-made coverage for it, so once the wrapper keeps its width, select picks up the shared floor and the tests can be unskipped.Does this introduce a breaking change?
Other information
Material solves this differently, and its approach does not port. It caps the leading and trailing slots so oversized content contributes no width, then floors the container at
min-contentso the field overflows outward instead of collapsing inward.min-contenton our input measures0px, so the floor has to sit on the editable element instead. Capping the slots is FW-7650, and it is the change that actually removes the pressure here: it takes the worst case budget from 46px to about 148px.Wide glyphs can still clip an unfocused leading character, since
chmeasures the0glyph. Fitting them needs 24px out of a 46px budget shared with the label, which costs the label its ellipsis, and typing scrolls the caret into view regardless.Previews: