refactor!: baseline alignment #10320
Conversation
The container element is no longer meaningful.
jouni
force-pushed
the
refactor/baseline-alignment
branch
from
8e954af to
d0f6061
Compare
Use the same name as in custom-field
This reverts commit c66b4b8.
| --_has-helper: ; | ||
| --_no-error: initial; | ||
| --_has-error: ; | ||
| display: inline-grid; |
There was a problem hiding this comment.
General question: would this also help to get us common features like "help-icon" next to the label or field? It's a pretty common UX pattern seen where people want to place an (i) icon on the right side of the label or on the right side of the field which people could click or hover to get more informations.
There was a problem hiding this comment.
I suppose it might, as the label isn't restricted to one line and truncated with an ellipsis, so it should be easier to render custom content in the label slot. But I don't know how feasible that is in general, regarding accessibility.
There was a problem hiding this comment.
Yeah.. I'm also talking more about a slot next to the label.. ;) I don't think it would be a good fit within the label
There was a problem hiding this comment.
Right. I don't see why that couldn't be a similar thing as the required indicator, sitting inside the part=label element.
|
| .vaadin-custom-field-container { | ||
| width: 100%; | ||
| } | ||
| const customField = css``; |
There was a problem hiding this comment.
We don't need empty customField, IMO it can be removed so that we could use this instead:
export const customFieldStyles = [field];There was a problem hiding this comment.
Just to double check, is this screenshot change intended (empty space below inputs)? The custom field with only native inputs isn't the most common use case so it's probably not a blocker.
There was a problem hiding this comment.
Yeah, it’s intended, although maybe not desired. It’s the alignment pseudo element that creates that space, assuming the minimum input field height of the Vaadin components.
| </div> | ||
| <div class="slots"> | ||
| <div part="input-fields"> |
There was a problem hiding this comment.
Could be extracted into separate PR marked as feat: so that we could mention this in release notes.
| grid-template-rows: | ||
| var(--_helper-below-field, var(--_has-label, auto 0) 1fr var(--_has-helper, auto) var(--_has-error, auto)) | ||
| var( | ||
| --_helper-above-field, | ||
| var(--_has-label, auto) var(--_has-helper, auto) var(--_has-label, 0) 1fr var(--_has-error, auto) | ||
| ); |
There was a problem hiding this comment.
As discussed in the daily, we might try to use grid-template-areas instead, see if that makes the code easier to understand.
There was a problem hiding this comment.
Another thing we discussed is to use margins instead of gap for the space between the parts. Then we wouldn't need to worry about empty grid cells creating unnecessary gaps, and could reduce the "logic" with the internal custom properties.
.vaadin-*-containerelements irrelevant withdisplay: contents.This change removes the ability to globally set "helper-above-field" variant on all fields with the
--vaadin-input-field-helper-orderproperty. Might still be possible with the new custom properties, but might require two properties instead of one.Before
After