[Laszlo-dev] Adding default style attribute values

[P T Withington]

On 2009-10-07, at 11:26, Henry Minsky wrote:

> A question about this approach,  there is some set of 'styleable'  
> attributes
> on view, maybe a dozen or more? (width, height, fontsize, font,  
> bgcolor,
> align, resource, etc)
>
> Are all these defaults going to come from a default LFC stylesheet now
> instead of being hardcoded into LzView?
>
> If we use a constraint for each place we want to bind
> an attribute default value to a style value, does this mean that  
> when you
> instantiate an LzView,
> say, you will have to instantiate one delegate per attribute that is  
> bound
> this way? Seems like
> that could the memory footprint and instantiation time noticably  
> larger for
> vanilla views, if we have
> more than a handful of these stylable attributes?

See my reply to myself about a better approach, where you will see  
that despite the $style bindings being classified as 'constraints'  
they do not actually install any delegates (unless the CSS itself  
specifies a constraint, as in, the `attr()` value, which ties one CSS  
value to another), they are just evaluated at initialization time.  
Also, in the revised implementation, we have a 'fallback' or 'default- 
default', where if there is no CSS property found, you install that  
default instead.  I guess you could consider that fallback to specify  
the default LFC stylesheet, but I don't think we have to actually  
implement any such thing.

Also, the idea is that these are defaults that will be overridden by  
subclasses and instances.  Only if the subclasses and instances do not  
specify values will these defaults be consulted.  But, yes, if we go  
crazy and make every possible attribute CSS styleable, there will be  
an increase in the instantiation time of a view, so we should be  
judicious about what we make styleable in this way.

The goal here is that we think users expect to be able to use CSS to  
style their applications, but because we don't have any default  
bindings for <view> attributes, the user has to do this all by hand.   
This way, there will be default bindings all set up and they can just  
add a stylesheet.

We should obviously evaluate the overhead of this change.  There are  
already some pretty good caches that optimize the CSS lookup, but  
perhaps we can make a further optimization that creates a cache on the  
class to avoid re-looking up (non-existen) default CSS bindings for  
each instance of the class.

Finally, someday we _will_ have to have at least one more delegate for  
each instance that has CSS style bindings so that we can implement  
dynamic CSS styles.  I.e., when the user wants to change a stylesheet  
dynamically and see the change propagate to all the views with  
attributes bound to the changed style.  We'd need at least one  
delegate to re-evaluate the style bindings when the style sheets change.