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]
