Setting size of vaadin-date-picker > input inside a form ?

Flow
1

I can control the size of the DatePicker input when it is outside form/grid with this:

vaadin-date-picker > input {
width: 9ch;
background-color: pink;
}

When it is inside a form, it reverts to its default size.
I’ve tried to be very specific, and use !important, but I’m unable to control the width this way inside form
The selector works, as I can set the background-color just fine

I can also set the size of the vaadin-date-picker itself, but I’d like to set a size that doesn’t depend on the chrome.

2

The FormLayout works by setting widths to the components placed into it, so overriding the width of the field basically breaks the layouting in FormLayout.

You can force the width of the inside DatePicker to a certain size by also setting flex-grow:0 on it, but that won’t affect the size of the field’s chrome, because as noted above, that is set by the layout.

The only way to override the width that Formlayout sets to a field is to set the max-width and/or min-width of the field. This will prevent the width set by FormLayout from going outside of those bounds. But it will also mess with the way FormLayout is intended to work.

3

Perhaps also worth pointing out that nothing forces you to use FormLayout for a form if you want the layout to work differently.

4

so setting the max-width to the FormLayout is the best approach instead of individually setting on the fields ?

5

Well, FormLayout sets widths to the fields with inline styles, so they’ll override whatever you set. Thus, max-width/min-width is the way to override that.

6

Haven’t decided yet if we want to use FormLayout. We want to use as much standard functionality as possible, and I really like how it automatically adapts to different screen widths. However, the app I am upgrading has fields organized in columns instead of in rows, so even when it looks ok with FormLayout, the tab order is wrong. I might be forced to generate a

after all.

But… The real target for the question was the Grid Editor. I had the same issue there. I assumed the underlying cause was the same, so I left it out of the original question.

As I said, I get around the issue by setting size of the field itself. I was just surprised that the way I did it outside FormLayout / Grid editor didn’t work.

In any case, now that it “works”, I see that it looks shit in a Grid, so I’ll have to go back to do date and time in separate columns
image.png

7

I don’t think GridPro does anything similar by default. Usually you’d want to setWidthFull on editors though, so that they fit into the cell. And if you do that, you cannot also set the width via the input.

8

So, I’m assuming what you want to do with these input-sizing tricks is to set the width of input fields based on a certain number of em or ex units, so that they fit that number of characters, without having to account for the toggle button, paddings etc that add to the total width of the component?

I’ve been tinkering with that too (and thought about how we might build that as a feature).

The solution I’ve used is to set the default width of the field to auto with --vaadin-field-default-width: auto; so that it just accommodates the size of its contents, and then setting the width of the to a number of ex units. And of course not setting a width on the component itself in any way. There’s no way to make that work with FormLayout, however.

9

So if you anyway have a form whose field order is column-by-column rather than row-by-row, I’d just do that as a VerticalLayout for each column, and wrap those in a FlexLayout set to wrap. That way you get a responsive layout where the fields stay grouped by column and the tab order is correct.

10

@useful-whale, in Grid, when I generate the editor, I do hasSize.setWidthFull() on all, but it would be better if grid did that itself.
But, that would only make sure the input + chrome was visible. Since we fit columns to their text, the editor chrome would normally mean that the input content is clipped, so, especially for DatePicker, TimePicker, DateTimePicker I have to set column width in pixels anyway.

In other places, I’d prefer setting the input width in chars, partly because it is “cleaner”, but it also part of another issue: For any kind of field, when we have label above the field, make sure label is not clipped.
This is especially an issue in our “navigator”, where we want the fields to be narrow, but not too narrow.
Earlier I calculated a pixel width for all fields as max(label width in pixels, input field + chrome in pixels). That was calculated from a letter-width lookup table I had in code. Ugly as f, and not accurate, so I got some minor label clipping.
Discussing it with your expert chat some time back, I got the following suggestion:

code:
field.getStyle().set(“–length”, Integer.toString(charWidth) + “ch”);

css:
.navigator {
–vaadin-field-default-width: min-content;

& vaadin-text-field > input {
    width: var(--length, 10ch);
}

}

So… based on that I thought I could set width on “> input” everywhere. However, it looks like I have to accept that each context has its own requirements.

Back to FormLayout - Having each column in a separate VerticalLayout would break two things; colspan and aligning fields in the two columns.
If we wanted to be “mobile first”, we’d switch to laying out fields in rows and having the label above.
That would be a huge change, and would make the desktop version worse, and we are definitely “desktop first”.
So, I don’t like it, but I’m leaning towards generating a

. Thankfully you’ve made it trivial to add support for any tags that you’ve left out.
image.png

11

So… based on that I thought I could set width on “> input” everywhere. However, it looks like I have to accept that each context has its own requirements.
Well, in the sense that, if the component itself has a defined width, the field part automatically scales to fit that, ignoring whatever you set on the , yes. If the field doesn’t have a width set, it should work fairly universally.

12

As for the FormLayout:

  • If I remember correctly, table elements are getting their own Flow classes in 24.4
  • Rather than a , I think a css-grid based layout would be better. (But that depends on what your form is like)
13

I know table is (was?) considered “bad” for doing layout, and is why we’ve gotten all these annoying css ways of doing things that seem to always fall a bit short.
I like table :slightly_smiling_face:

14

If it’s truly tabular in the sense that both rows and columns are semantically meaningful, it’s probably the best option, but the big plus with css-grid is that you only need the layout container element (instead of that plus rows plus cells), and that it can be made responsive if needed

15

I could make some recommendations if you can share a screenshot or mockup of the form layout you want to achieve

16

OK, Rolf. I’ll give css-grid a shot :slightly_smiling_face:

Looking for an example screen reminds me that we have another issue: Yes, we are “desktop first”, but we’re still assuming 1280*1024… We do not take advantage of today’s big and wide screens.
We might have to consider changing to row-layout anyway, at least for our most busy forms.

Here is the first half of a fairly simple form. It renders mostly fine with FormLayout, except that the tab order is the wrong way.
You see that for the date+time fields, it makes sense to have them stacked vertically and tabbing from one to the next. Fields like these would be worse if they were laid out horizontally.
The “In” and “Out” sections a the bottom are supposed to align. If you count the lines I assume they do, but because lines have varying height they do not line up,
If we continue using FormLayout, I’ll probably change my generator to start a new FormLayout at places like this.
image.png

17

Thanks. And the In and Out sections are more fields then I presume?
Do the fields in the In/Out sections need to line up row-by-row?

18

Yes, it is the same information on each side, only one is for “in” and the other is for “out”, so they should line up.
For reference, here is the Vaadin8 version
image.png

19

Since there is no multi-column Form in Vaadin8, it is rendered as a generated

20

ah, I see.

And in the top part of the form, does the natural order of fields go like this?
image.png