Replies: 4 comments
-
Easily worked around btw by scoping all of the second Screen CSS to screen-specific classes (or continuing to use a top-level-widget that contains the CSS) |
Beta Was this translation helpful? Give feedback.
-
Hey @ndevenish, we have something in the works that will make |
Beta Was this translation helpful? Give feedback.
-
This is the expected behaviour at the moment. The solution, as you discovered, is to scope the CSS to your screen. I guess it was just a test, but you would be unlikely to style a The advice may change when we implement "nested" css. |
Beta Was this translation helpful? Give feedback.
-
The actual literal implementation to style the Static that triggered this case wasn't far off; a loading screen: class LoadingScreen(Screen):
CSS = """
Screen {
align: center middle;
layers: bottom top;
}
Static {
content-align: center middle;
text-align: center;
offset: 0 -200%;
layer: top;
}
LoadingIndicator { layer: bottom; }
"""
def compose(self):
yield Static("Message")
yield LoadingIndicator() (update/removal logic stripped here). Unfortunately an offset isn't as obvious as a background and caused lots of weird behaviour.
What does having |
Beta Was this translation helpful? Give feedback.
-
Screen CSS taints the CSS for the whole app, even after the screen is removed from the screen stack. This doesn't seem like it should happen.
It looks like support for
Screen.CSS
was added in #2744, which did identify this footgun. Applying CSS that continues to apply after the screen no longer exists definitely feels like a bug, because it doesn't give any different effects from Application-wide applied CSS.I encountered this when I wanted to add a loading screen so promoted my topmost widget to a screen.
Textual 0.29.0. The
Static
on screenUnder
continues to have a green background, even when the other screen is removed. I'd expect it not to.Beta Was this translation helpful? Give feedback.
All reactions