You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is one I run into now and again with my own apps, and I keep meaning to check if this is intended behaviour, or if this is a bug. Consider this code:
fromtextual.appimportApp, ComposeResultfromtextual.containersimportContainerfromtextual.widgetsimportLabelclassLotsOfPadding(Container):
DEFAULT_CSS=""" LotsOfPadding { border: dashed blue; padding: 7; } """classNoLeftPadding(LotsOfPadding):
DEFAULT_CSS=""" NoLeftPadding { padding-left: 0; } """classNoRightPadding(LotsOfPadding):
DEFAULT_CSS=""" NoRightPadding { padding-right: 0; } """classPartialStylingApp(App[None]):
CSS=""" Label { width: 1fr; height: 1fr; background: red; border: solid white; } """defcompose(self) ->ComposeResult:
yieldLotsOfPadding(Label("This should be 10 all round"))
yieldNoLeftPadding(Label("This should have no padding to the left"))
yieldNoRightPadding(Label("This should have no padding to the right"))
if__name__=="__main__":
PartialStylingApp().run()
The idea is that there's a container that has a padding value, which is inherited by any container that inherits from it. There are a couple of containers that do inherit from it, and they seek to make the padding a little more specific by use of padding-left and padding-right (in each case removing the padding on one particular side). It feels like a reasonable expectation that padding-left (for example) means "whatever all the current padding-* values are, with this applied on top.
In other words, my expectation would be that the above code ends up looking like this:
what actually happens though is I get this:
with the padding-left and padding-right removed from the child containers, we can see that the padding is inherited from the parent:
so it would appear that if you override (for example) padding-left of a widget that inherits from a widget that has set padding, all of the individual padding values get reset (presumably because of the specificity of DEFAULT_CSS?).
So, initially at least, this issue asks: is this a reasonable expectation and as such is a change needed here, or is this intended behaviour?
The text was updated successfully, but these errors were encountered:
This is one I run into now and again with my own apps, and I keep meaning to check if this is intended behaviour, or if this is a bug. Consider this code:
The idea is that there's a container that has a
padding
value, which is inherited by any container that inherits from it. There are a couple of containers that do inherit from it, and they seek to make thepadding
a little more specific by use ofpadding-left
andpadding-right
(in each case removing the padding on one particular side). It feels like a reasonable expectation thatpadding-left
(for example) means "whatever all the currentpadding-*
values are, with this applied on top.In other words, my expectation would be that the above code ends up looking like this:
what actually happens though is I get this:
with the
padding-left
andpadding-right
removed from the child containers, we can see that thepadding
is inherited from the parent:so it would appear that if you override (for example)
padding-left
of a widget that inherits from a widget that has setpadding
, all of the individual padding values get reset (presumably because of the specificity ofDEFAULT_CSS
?).So, initially at least, this issue asks: is this a reasonable expectation and as such is a change needed here, or is this intended behaviour?
The text was updated successfully, but these errors were encountered: