That's fine. If the values are the same, it's ok by me if the attribute and style name are different, for a good reason.
On 2010-11-01, at 16:08, Max Carlson wrote: > I'm worried about 'direction' colliding with other attributes. Can we make > the attribute 'textdirection' and add a style declaration for 'direction' > later? I agree about the attribute values... > > On 11/1/10 1:03 PM, P T Withington wrote: >> 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] >>
