On 2010-10-31, at 10:05, Henry Minsky wrote: > I agree we should be using the term 'inheritance' for the mechanism of child > views copying an attribute value from the closest parent that has it set. > > I didn't know about CSS having an "inherit" flag for properties.
There's two things: 1) properties get to declare whether they are inherited or not. In general text properties are inherited, so for instance you can set the text style the entire body of a web page and have that be inherited by individual paragraphs. I think this is the same "right thing" that led us to make the font properties of <text> be inherited. In general box-model properties are _not_ inherited, and this is the bug that I filed on Fred's behalf (http://jira.openlaszlo.org/jira/browse/LPP-9493) where padding/border/margin are being inherited by an enclosed node. In general you don't want that, because enclosure does not imply you want the same box-model styles. There is a comprehensive list at (http://www.w3.org/TR/CSS21/propidx.html) that says, for the defined CSS properties, whether they inherit or not. But, since we allow adding arbitrary CSS properties with our attribute `style` property, it seems we need to expose another flag that says whether or not these non-standard properties should inherit or not. (http://jira.openlaszlo.org/jira/browse/LPP-9495) 2) There is a CSS keyword, `inherit` that can be used as a value for _any_ CSS property in an CSS style rule, to specify that you want that property to inherit from the enclosing nodes, where the CSS rule applies. (http://jira.openlaszlo.org/jira/browse/LPP-9496) This is a way of creating case-by-case inheritance when a property does not inherit by default, and also a way to build rule sets that control explicit vs. inherit values on a more fine-grained basis. --- Right now, our CSS does not do either of these right. For 1), it is inheriting all properties, it needs to filter and only inherit properties that are declared to inherit. For 2), we just don't implement this feature of CSS yet. > I can't think of a more efficient mechanism right now than the one that Max > put in, and I am also concerned about the efficiency if we did this with a > lot of properties, but > I will think about it some more. > > Note that in the specific case I was trying to fix, setting > the "bidirectional" arg very very early (first thing in the construct > method, before __makeSprite is called), I think we still > need that to be hand coded, or else I need to implement properly the code > that lets you dynamically switch a text view from normal to "bidirectional" > at any time. I'm adding this comment to LPP-9487: > The CSS property that controls this is called `direction`, it's possible > values are `rtl`, `ltr`, or `inherit`. The default value is `ltr`, and the > property inherits (meaning it looks up the parent chain, i.e., enclosing DOM > node, to find the value if there is no applicable CSS rule. > > It's clear we have a timing issue to solve here, because CSS bindings happen > just before init(), not in construct, so we either have to process the > `direction` property specially, or we need to be able to dynamically update > the sprite to handle `direction` not being known or changing after > construct() time. I think it is inevitable that we will need to somehow defer the makeSprite call until we know the setting of `direction` (and that if we do that, we will also be able to handle the unlikely case that direction is changed at runtime).
