Sure, fine. It's just that if we are planning to phase out this inheritance style in favor of CSS, it seems unfortunate to layer on one more.
Can I make the suggestion that we call the attribute `direction` (with values `ltr` and `rtl`) to align with CSS? Probably better to give new stylable attributes their standard names and values, don't you think? Otherwise we end up having to insert a layer of translation. On 2010-11-01, at 15:37, Henry Minsky wrote: > I'd like to check it in as well, it's not a big change, and then we can > revisit when it's needed to use via CSS. > > > On Mon, Nov 1, 2010 at 1:33 PM, Max Carlson <[email protected]> wrote: > >> Just to play devil's advocate... What if we just put in Henry's bidi >> cascading (based on my hacks) in for now, and see how it performs? We could >> defer the optimization phase until later. I'm concerned we may be >> overthinking this and it's delaying forward progress on other things... >> >> >> On 11/1/10 9:35 AM, Henry Minsky wrote: >> >>> That's a major issue I agree. I'm working on pushing the sprite creation >>> to init() method, but just moving all the stuff out of the >>> LzText.construct method had a number of bugs; there's some stuff that >>> happens in the LzText.construct method that can side-effect the sprite >>> (via setters) , and I'm trying to figure out which calls break as >>> they're moved into the init method, and how to defer them. >>> >>> >>> On Mon, Nov 1, 2010 at 11:41 AM, P T Withington <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> My big concern is that in a large application, you'll start up, >>> create a zillion text sprites, then the style sheet bindings will be >>> applied/cascade/inherit, and all zillion will have to be >>> re-created/garbage-collected (or possibly leaked, if we are not real >>> careful, due to the complexity of gc-ing across the runtime DOM API). >>> >>> On 2010-11-01, at 11:24, Henry Minsky wrote: >>> >>>> I'm trying out just swapping out the textfield object inside the >>> sprite >>>> first, to see if that will work, because it's been proving to be >>> pretty >>>> messy trying to move the actual creation of the LzTextSprite to a >>> later >>>> phase. >>>> >>>> On Mon, Nov 1, 2010 at 8:23 AM, P T Withington >>> <[email protected] <mailto:[email protected]>>wrote: >>> >>>> >>>>> It's not so much that we want to change it at runtime, just to >>> have it >>>>> inherit. >>>>> >>>>> But even if we are not supporting changing it at runtime, to have >>> it >>>>> inherit, especially to be able to style it with CSS, we have to >>> defer the >>>>> creation of the sprite. CSS bindings don't happen until just >>> before init() >>>>> time, whereas normally we are creating the sprite at construct() >>> time. >>>>> <inputtext> very often creates the wrong kind of sprite at >>> construct(), >>>>> only to have to re-create it, once the value of `multiline` is >>> finally >>>>> known. >>>>> >>>>> The solution Henry and I are favoring, since <text> nodes cannot >>> have >>>>> children (LPP-1218), is just not allocating the sprit for text >>> until init(). >>>>> That way, any inherited or CSS-bound setting for `direction` >>> (the CSS >>>>> property for text direction) will be known. >>>>> >>>>> As a bonus, it may fall out that you can change the setting of >>> `direction` >>>>> at runtime and just create a new sprite, the same way we do in >>> <inputtext> >>>>> for `multiline`. >>>>> >>>>> On 2010-11-01, at 00:19, Max Carlson wrote: >>>>> >>>>>> We've had font styling attribute inheritance from parent nodes >>> for a long >>>>> time. The canvas always has a default value that's inherited. >>> One thing >>>>> that was really annoying was not being able to set the canvas >>> font styling >>>>> attributes and have the values update... >>>>>> >>>>>> I'm torn on this one - it seems like we really need the same >>> behavior for >>>>> the common case of inheriting from the canvas. Not sure about >>> being able to >>>>> change the TLF attribute at runtime... >>> >>> [snip] >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] <mailto:[email protected]> >>> >>> >>> > > > -- > Henry Minsky > Software Architect > [email protected]
