On Aug 26, 2006, at 6:02 PM, Adam Wolff wrote:
> On Aug 23, Jim Grandy wrote:
> [snip]
>> I guess my preference is to choose simplicity over symmetry, and
>> declare
>> that $style constraints are always interpreted as strings.
> This would make the $style feature almost useless. Most LFC functions
> (like setWidth) behave erratically if you hand them strings. We
> could have
> a policy of trying to convert strings to numbers, but it might produce
> unexpected behaviors with, say, hex values.
Yeah, you are right. After thinking about this over the weekend, I
think I was pushing CSS-purity a bit too far into the client side.
After all, HTML "user agents" reinterpret CSS values as e.g. color
values, single font names, etc., so we should be able to do the same
at the intersection between the CSS engine and LZX. (I'm also now
fine with $style being an expression constraint, especially if (as
ptw asserts) all constraints are currently expressions. Again, I was
carrying CSS-ness too far into the client.)
I haven't gone and tracked down the source of the constraint syntax
(does anyone have a reference?), but it seems to me we could add a
type declaration to all constraints and solve this problem as well as
the bigger problem of constraint type coercion. Perhaps using a colon?
$style:number{'font-size'}
Then for ordinary constraints it would collapse:
$:color{"#" + parent.red + parent.green + parent.blue}
Just throwing out a possibility; maybe someone already has a proposal
for constraint type coercion that we could revive?
But for style constraints, there's a verbosity problem: we know that
e.g. font-size is always going to be a number, so maybe there's a way
of declaring the default type of a CSS property. Not sure where that
would be declared, unless we only support it for built-in style
properties and it's internal to the compiler.
Thinking out loud here...
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
