My first working (sort of) dashboard has a single group size 12 x 1 [sic] units.
There is a chart size 12 x 3 units at the top.
Floating to below that: a table 3x2 [sic] and a text input field 2x1 [sic]
And below that a static text field 8x1
The dashboard appearance varies according to the size of the table (?)
Why does the group size include height? It certainly seems to ignore this.
Why is a box drawn around the text input?
Why does the height of the text input change to match the table alongside it even though I specified a height for this widget?
Why is this extra space apparently split between inside and outside the box?
A different topic: Is there any way to get rid of the horizontal lines and vertical padding between the table rows? Sure it's pretty but it means I get 5 lines visible without scrolling versus maybe 12.
Why are the tops of the table and text input not horizontally aligned?
It's a good point, you are correct it's mostly ignored. It was inherited from Dashboard 1.0, and we've never really done anything with it. Some legacy work that needs attention.
We are using the "outline" variant as standard for our implementation of Vuetify/Material Design - you can see the raw component here: Text field component — Vuetify
That makes the label inline with the border. It's made worse in your case here because the strange height issue.
Definite bug, this shouldn't be happening at all. I actually think it's a problem with the ui-table, rather than the ui-text-input. I had this issue yesterday when creating the Dashboard Flowviewer. If content extends the height too much then the row heights get stretched, trying to accommodate and that causes anything else in the same row to stretch too.
Well they are dumb in the sense of I made minimal efforts to find previous questions/answers on these topics.
Maybe if there was a forum category for dashboard 2 I would have, but it's a lot of posts to scan!
Yes the label on top of the border is interesting. But should it be the default?
It is surely a good thing for the default dashboard to have a decent appearance but I think that decoration such as rounded corners borders is better left under the control of the flow designer.
It was very easy with Dashboard 1 CSS to draw a border around a group or individual widgets.
I might well want a gauge with a text input field immediately below it, appearing to the user as a single entity. A border reinforces the impression of discrete, possibly unrelated widgets.
On my dashboard this "standard" is applied to the text input but not the chart, table or text widgets!
I am not at all sure how to word such an issue.
The whole way that widgets are arranged confuses me.
The text field decides for itself how tall it should be, and has vertical alignment to the centre (align-items: center)? This inevitably borks horizontal alignment between widgets.
The text input also decides for itself how tall it should be and puts a border round just part of it's space.
Though the text input value is horizontally aligned with the table column headers, having a border and title around it borks the alignment of the tops of the two widgets.
Edit- Actually I'm not sure these are horizontally aligned.
I don't understand how these indicate an issue with the table, except perhaps that it does not have the same outline box.
I know the dashboard has to accommodate viewing on different width devices.
Maybe in constructing a dashboard to be viewed on a PC I should be using a different layout?
And as per DCJ's recent announcement anything tagged "Dashboard" can be assumed to mean Dashboard 2
This was a design decision I made as I thought it gave the cleanest and most modern appearance of the options available. We can surface this as a configuration option for sure.
For all the Dashboard's I'm building on PC, I'm using "Grid", I still find it the best option. You are hitting bugs here though, so please don't think the mis-alignment is by design.
Even just opening an issue saying "table next to text input, and they;'re not vertically aligned" is plenty enough. It's not on you to provide any more detail than the frustration you're hitting - it's for us (or another community member) to investigate the why
I see value to keep (and enforce) the group height. There may be scenarios where the group content is big, but I would still like to limit its size on the page and scroll internally
