Actually we've got the attribute direction := ltr | rtl already , the "hasdirectionallayout" flag is an additional boolean attribute to tell which class of sprite textfield to make (the old native TextField or my new TLF back-compatible implementation).
But I could make the logic be that if direction == "rtl" at construct time, that means what "hasdirectionallayout=true" currently means. If I wasn't worried about performance I'd make the TLFTextField be the default for all text. I was also worried about subtle differences in behavior do didn't want to switch everything over to it all of a sudden. There's still a single pixel padding issue for the text location in buttons that I need to look at that I noticed when I run the components_sampler. On Mon, Nov 1, 2010 at 4:18 PM, P T Withington <[email protected]>wrote: > 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] > >> > > -- Henry Minsky Software Architect [email protected]
