Styling compound widgets confuses me

[UlrichGoebel]

Trying to style a Compound Widget I went in some trouble.

Styling a normal Input without border and just one line works quite nice.

But when I use an Input inside a Compound Widget, the border: none seems to get lost if this Input gets focus.

Here my small code which should demonstrate this:

#!/usr/bin/env python3

from textual.app import App
from textual.widget import Widget
from textual.widgets import Input, Label

class LabelInput(Widget):
    DEFAULT_CSS = """
        LabelInput {
            layout: horizontal;
            }
        
        .labelinput {
            border: none;
            height: 1;
            background: magenta;
            }
        """
        
    def compose(self):
        yield Label('Label für MyInput: ')
        yield Input(classes='labelinput', placeholder='LabelInput')

class Test(App):
    CSS = """
        .input {
            border: none;
            height: 1;
            background: blue;
            }
        """
    def compose(self):
        yield Label('Label für Input')
        yield Input(classes='input', placeholder='Input')
        yield LabelInput()

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

The Input at App-level does what I want: it has no border, just one line and blue background. Doesn't matter wheter is focused or not.

The LabelInput does too - as long as it doesn't have focus: it has no border, just one line and magenta background. But if it is focused, it becomes a border and is shown over two lines; no input is shown; but as soon as it losts focus it comes back to one line without border and shows the input if there was entered any.

As you can see in the code the LabelInput is styled inside its class definition using DEFAULT_CSS. This styling seems to work, as you can see from the background color. But what about the border?

May be the Input inside the LabelInput becomes a child from another, invisible container which has to be styled too?

With the devtools in a textual console there comes up this line, as soon as the second Input gets focus:

Resize(size=Size(width=138, height=2), virtual_size=Size(width=138, height=2), container_size=Size(width=132, height=0)) >>> Input() method=None

May be that could be helpful because of the height=2. I didn't find anything about border is in the textual console output.

As soon as I define the CSS rule for .labelinput at the App-level (that means in the CSS-Variable inside class Test(App)) everything woks perfectly. But that wouldn't solve my problem, because later on I will put a number of Compound Widgets in a module so it can be imported in different applications; and, of course, I want to give them a default style.

I would be glad to get some hint.

[davep]

I'm not seeing any styling of the :focus pseudo class in your code. Something like Input has separate styling for the focus state.

See https://textual.textualize.io/guide/CSS/#pseudo-classes for more background.

[TomJGooding]

I think perhaps what is confusing here is that the .input class in the App CSS doesn't handle the :focus pseudo class either, yet that works as Ulrich expects without any border when it is focused.

It looks like the DEFAULT_CSS above was missing the parent selector, after adding this here:

class LabelInput(Widget):
    DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;
    }
    
    LabelInput .labelinput {
        border: none;
        height: 1;
        background: magenta;
    }
    """

Or using nested CSS like this:

class LabelInput(Widget):
    DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;
    
        .labelinput {
            border: none;
            height: 1;
            background: magenta;
        }
    }
    """

Then the styling works like the .input class and doesn't have any border when focused.

I confess I'm also struggling to understand exactly how this rule is working? I've seen similar issues come up before (e.g. #4187 (comment) and #4332 (comment)), but not sure if this is the expected behaviour or might have revealed a bug?

[davep]

Now I'm back at a desk rather than trying to suggest a thing while squinting at my phone while on the way to bed (I should know better)...

I suspect this is a specificity thing. I've not dived too deeply into this but my initial assumption would be:

1. A class in CSS (CSS ... .input) wins over...
2. ...a pseudo class in DEFAULT_CSS (see the source for Input).
3. ...but LabelInput.DEFAULT_CSS doesn't win over the styling for Input for specificity reasons.

The upshot here really being: this isn't a "compound widget" issue so much as it's a "where does DEFAULT_CSS sit when it comes to specificity" issue; and DEFAULT_CSS should be thought of as being very low on the ranking.

For what it's worth, if I were writing the above, I'd probably write the DEFAULT_CSS for LabelInput like this (no need for the labelinput class on Input either):

    DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;

        &> Input {
            border: none;
            height: 1;
            background: magenta;

            &:focus {
                border: none;
            }
        }
    }
    """

[UlrichGoebel]

Wow, all these three variants work fine. In each case the DEFAULT_CSS sits inside the class LabelInput(Widget):

Vaiant 1:

DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;

        &> Input {
            border: none;
            height: 1;
            background: magenta;
            
            &:focus {
                border: none;
            }
        }
    }

Variant 2:

DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;
    }
        
    LabelInput .labelinput {
            border: none;
            height: 1;
            background: magenta;            
    }

Variant 3:

DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;
        
        .labelinput {
            border: none;
            height: 1;
            background: magenta;
        }
    }

For now I would prefer variant 2 or 3. There I easily can overwrite the .labelinput rule in the CSS of the App or, respectively, in an CSS file (using CSS_PATH). May be for other usecases variant 1 is the better choice - or I don't see its advantages.

The only thing is that I had to repeat the border: none and height: 1 in the overwriting rule in the CSS, even if I just want to change the background or something else.

So it could be a good idea to separate more essential rules from less importend ones like this:

DEFAULT_CSS = """
    LabelInput {
        layout: horizontal;
            
        .oneline {
            border: none;
            height: 1;
        }
        
        .labelinput {
            background: magenta;
        }
    }

Of course, in this case both of the classes must be passed to the Input, like this:

Input(classes='labelinput oneline')

Now I can configure colors or other things overwriting .labelinput in CSS without messing up the border and height.

That looks good for me. Again: Thank you very much for patient assistance.

[UlrichGoebel]

Well, as TomJGooding pointed out, one thing remains confusing:

I think perhaps what is confusing here is that the .input class in the App CSS doesn't handle the :focus pseudo class either, yet that works as Ulrich expects without any border when it is focused.

I don't have to understand this, but possibly others would like to...

[davep]

For now I would prefer variant 2 or 3. There I easily can overwrite the .labelinput rule in the CSS of the App or, respectively, in an CSS file (using CSS_PATH).

Note that overriding the styling from the main CSS or app would just be LabelInput > Input, in the case of the first approach. As for advantages... to some extent I would say it's a matter of personal taste. For me I view CSS classes as being orthogonal to the type of the widget being styled; so if I'm just styling one particular type (in this case "an Input contained directly within a LabelInput") I'd simply go with that, rather than introduce classes which could end up clashing with something else.

[davep]

Well, as TomJGooding pointed out, one thing remains confusing:

As I mention in the 3 bullet points a couple of items above: I suspect this is down to CSS having greater specificity than DEFAULT_CSS, and the :focus pseudo-class is in Input's DEFAULT_CSS whereas your styling was done for your class for Input in CSS. So Your .input styling won out.