Dashboard 2 CSS - Text input. More space for labels in 1x1 widgets

Dashboard
1

I have a 1 x 1 text-input (number) node on my dashboard which looks like this:

image
image331Ă—113 1.61 KB

And with the cursor in the field:
image
image339Ă—120 1.4 KB

But if the dashboard side bar is visible the label is truncated

image
image627Ă—115 1.07 KB

The label font size is 1rem so no surprise it doesn't change as the group shrinks, but if I change it to eg 1vw it still doesn't change with the group width.
Is there another CSS font size setting which does change with the group width?

The margins of this label seem to be fixed width. --v-field-padding-start and -end are 16px:

margin-inline-start: var(--v-field-padding-start);
margin-inline-end: var(--v-field-padding-end);
max-width: calc(100% - var(--v-field-padding-start) - var(--v-field-padding-end))

image
image419Ă—143 2.39 KB

Shouldn't the margins shrink when things are tight to try and maintain the label visibility?

Is this possible?

2

You might want to look at CSS container queries - CSS: Cascading Style Sheets | MDN

1vw considers the width of the full viewport/screen, not the container/parent of the element.

3

Of course, good point.
So the font size is probably best specified in rem units.

I have been playing with the hints in your link (thanks).
It turns out that the margins and max-width are more significant than font-size for fitting the label into a 1x1 widget, so maybe the cq.. units are best for these. I arbitrarily picked cqw.

On my PC screen at full resolution (1920 x 1080), a 1x1 widget is roughly 86 pixels wide when the sidebar is not shown, roughly 65 when it is.

With default settings, the label "Percent" gets truncated.

image
image313Ă—167 1.6 KB

My CSS to prevent this:

/* Use custom class 'shrink' to give a container I can set as inline-size */
.shrink {
container-type: inline-size;
container-name: oneunit; /* Name is optional */
background-color: honeydew;
}
/* Change default settings to use cqw units such that "Percent" is not truncated */
.shrink .v-field-label {
margin-inline-start: 10cqw; 
margin-inline-end: 10cqw;
max-width: 80cqw;
}
/* Different styling if the container is < 85px wide */ 
@container oneunit (max-width: 85px) {  /* note container name */
.shrink .v-field{
background-color: lightgreen; /* just to make it stand out */ 
} 
.shrink .v-field-label { 
margin-inline-start: 5cqw; /* Smaller margins */ 
margin-inline-end: 5cqw; 
max-width: 90cqw; /* Proportionally larger max-width */ } 
}

And the result with/without the sidebar (Only the green text-input widget has class 'shrink')

image
image652Ă—338 10.3 KB

While this does give more room for labels in all widgets, particularly smaller ones, it does not eliminate truncation, it just happens to work on my screen for this particular label.
An undesirable effect is that the left hand of the label no longer aligns with other widgets.
I could get round this by adjusting the start/end margin sizes.
Or maybe all label positions should be styled using cqw? I'm sure there are very good reasons why it's currently done with px.
Alternatively I can retain the default margins for > 85px but slightly reduce the font-size.

4

Is D2 using container queries? Watch out for browser compatibility, especially if using older mobiles. Full compatibility seems to have arrived in early 2023.

5

Yes, I probably should have said " it just happens to work in my browser, maximised, on my screen, for this particular label.

caniuse says that @container is not supported by Firefox*, but it works for me :slightly_smiling_face:

  • A recent survey found that Firefox is the preferred browser of 100% of PC users
6

Caniuse says that @container size querys is supported for firefox.

@container oneunit (max-width: 85px)

What is not supported for firefox is style queries for custom properties .

1 Like
7

Which demonstrates quite nicely that 100% of surveys produce 96.453% of incorrect results! :smile:

I generally try to target early 2019 browsers for generic support as this still includes some slightly older tablets and phones which people may be using, especially for IoT and Home Automation.

So my comment was simply to remind folk to remember that not everyone can be on a current browser. Know your users. :slight_smile:

8

New features should be used as much as possible I'd say...

BUT

the one must understand what happens if there's no support and include them only so that it does not affect the outcome in a way that makes it unusable or unreadable