Confusion around width: auto and too-small widgets

[mon]

I'm trying to make a grid layout be just the right size to hold all its elements, but I always find setting any width to auto shrinks my custom widgets to be size 0, and I have to go down the entire widget tree and set width: auto on all of them before it fixes itself.

This also happens with the inbuilt Select widget, an example of which is below:

from textual.app import App, ComposeResult
from textual.containers import Vertical
from textual.widgets import Select, Static


class Test(App):
    DEFAULT_CSS = """
    Test {
        Vertical {
            layout: grid;
            grid-size: 3;
            grid-columns: auto;
        }
    }
    """

    def compose(self) -> ComposeResult:
        with Vertical():
            yield Static("Label")
            yield Static("Input")
            yield Static("Final")

            yield Static("It's a select")
            yield Select([("Option 1 is quite long", 0), ("Option 2", 1)])
            yield Static("The end")


if __name__ == "__main__":
    app = Test()
    app.run()

You can see in this example, the Select is way too small:

Changing Select to have a width of auto itself doesn't help, but in my "usual" complex layout trees, adding width: auto over everything usually fixes things up.

What fundamentals have I missed here? I'd consider myself pretty proficient in Web CSS, and elements are usually pretty good at being their minimal size unless told otherwise, but this seems the opposite, as textual seems to have a default width of 1fr everywhere.

[davep]

As I read it there seems to be two rather different questions in here: something about "custom widgets", which could mean a few different things and suggest a few different causes for various issues that might play into the above, as well as something relating to how to include Select in a specific layout?

I wonder if, if that's the case, you could break the various issues down into their own questions with their own examples?

However...

While it might not be the cause of whatever you're seeing, I wanted to point to one issue in your example code above. In it you're styling any Vertical that appears in your application so that it will then have a grid layout, pretty much turning it into a specific version of a Grid container instead. Many compound widgets will use containers, including Vertical, to control their layout. One such example is Select, which inherits from Vertical.

So, while I don't think it's the cause of what you might be asking about, you will have additional problems where some widgets won't behave correctly because you've made fundamental and likely unintentional changes to their layout.

To solve that problem you'd want your CSS to look more like this:

Test {
    &> Vertical {
        layout: grid;
        grid-size: 3;
        grid-columns: auto;
    }
}

or probably more ideally you'd give the Vertical a unique ID and style based on ID (or start off with a Grid container anyway; although the same issues still apply if you do a blanket styling of Grid).

[mon]

Aha! That was my fundamental misunderstanding - I'm a Svelte native, so I'm used to component styling being limited to the component that uses those styles. Textual, on the other hand, will apply it to the whole sub-tree. That's consistent and easy to understand.

When I said "custom widgets" I really meant "compound widgets", just didn't have the right term, thanks.

I didn't notice the Grid container, that's much better semantics, so I'll replace my use of that. For the sake of continuity, I'll keep using Vertical in this discussion.

Test {
    &> Vertical {

In my example, this doesn't seem to work (styles not applied). Using an ID instead, to "protect" any children that use vertical (and removing the previous styling of Select) is an even stranger result:

Re-adding the Select > SelectCurrent {width: auto;} rule gets the text to return, but it still wants to be very thin:

Manually setting a width works fine, but I still wonder if it's possible to let it be calculated automatically.

[mon]

I replied too soon - Select Static {width:auto;} gets most of the way there, sizing the Select to the size of the current value:

I tried applying a few different styles to get the ScrollView inside of a Select to auto-size, but couldn't find success. My main gripe was the selected box being the wrong size, so I think this is a fine compromise for now.

It is a little unintuitive, and I see there's already #3207 with similar thoughts.

[davep]

Using an ID instead, to "protect" any children that use vertical (and removing the previous styling of Select) is an even stranger result

Sure, as I say, I think there's a couple of issues here (one of them being that Select might be tricky to style here); but I just wanted to point out that there was this underlying thing happening that would throw off any other attempt to find a solution, because no matter how Select got styled, the act of turning Vertical into a Grid was going to cause some mayhem. ;-)

I don't have a good answer for how to solve the Select issue off the top of my head; unless someone else steps in with one I'll try and look more into it when I get some spare time.

[mon]

Yeah - in my actual app, I had top-level styles set on Static. Making that into a non-global thing suddenly fixed a bunch of weird rendering bugs I'd been trying to fix 😅

What I ended up doing, since my select options are static, is to just do something along the lines of select.styles.width = 7 + max(len(opt) for opt in options)) at the time of compose. 7 in this case was enough to account for padding/margins etc and leave me with a perfectly sized control every time!

A CSS solution would be great, but I wouldn't prioritise it.