We're still conflating two issues.
1) $style specifies a CSS attribute NAME. As currently implemented,
$style is an expression that _must_ yield a string, because CSS
attribute names are strings.
2) CSS attributes have VALUEs, which, as you have pointed out before,
are interpreted by the site where they are applied. The DOM CSS
interface always returns CSSValue, which consists of a string textual
representation of the value and an integer that encodes the CSS
'type' of the string (i.e., how the particular site interprets the
string).
As to the issue of constraints vs. type conversion, Adam already has
a bug filed on this for $path constraints, which is to convert
strings at runtime to the declared type of the attribute. I keep
putting this off, but maybe I need to really do it now. It will make
Max and several other users very happy...
On 2006-08-28, at 12:00 EDT, Jim Grandy wrote:
> 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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
