On Sun, Oct 31, 2010 at 9:15 AM, P T Withington <[email protected]>wrote:
> [Promoting to laszlo-dev] > > We need to make a decision here, because this is also related to > http://jira.openlaszlo.org/jira/browse/LPP-9493 > > Just to clarify terminology a bit, CSS uses the term 'inherit' to mean a > property value is take from the parent DOM node if it is missing; they > distinguish this from the 'cascade' of style rules, which has the pattern > 'last/most-specific wins'. Seems we need to align our terminology and that > the mechanism you are working on here is an 'inherit' mechanism. > > In CSS, each property defines whether or not it inherits its value from > enclosing nodes, although you are also allowed to specify the keyword > `inherit` as the value of any property and force that property to get its > value from enclosing nodes. > > We currently have two mechanisms for nodes to inherit attribute values from > their parent node. This mechanism that you are extending, where the > attributes are specified as LZX attributes and are looked up (and > constrained) at construct time; and a second mechanism in LzCSSStyle where > (incorrectly right now) _all_ CSS property values are copied from the parent > node. > > I think we should have only one or the other, but I expect there will be > fallout (since CSS is inheriting all properties right now, probably someone > will be disappointed when we make it work according to spec). The CSS > mechanism is also broken in another way: inherited property values will not > dynamically update. > > The mechanism you are working on handles dynamic updates, but is more > inefficient than the CSS mechanism. The CSS mechanism copies down all the > inherited property values at once, whereas this mechanism is looking each > one up individually, hence having to chase up the parent chain for each > inherited property. > > I _think_ this mechanism is the one that should prevail, and the CSS one > should go away, because the LZX attribute is the basic principal that CSS is > overlaid on. But I wonder if there is a way to make this mechanism more > efficient and more general so we don't have to create multiple hand-coded > setters, cascade setters, delegates, etc.? > > Opinions or ideas? > > On 2010-10-30, at 19:43, 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. 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.
