No, I think we understand that. The value of the $style expression is
a string representing the CSS property name, a string, which is then
used to derive the CSS property value, also basically a string (with
a hint as to type) stored as a CSSValue.
My original concern was that $style constraints be expressions at all
-- I wasn't sure the generality was worth the extra runtime overhead
and potential for code complexity and programmer confusion. You and
Adam convinced me otherwise, since all other constraints in LZX are
currently expressions.
Adam's secondary concern was that there be a way to coerce the
*value* of a style constraint -- the CSS property value, aka the
CSSValue instance -- from string to something more immediately
useful. (The workaround, to use a second constrained attribute, would
definitely be cumbersome in a CSS context.) It sounds like we agree
that some form of constraint value coercion would be useful here. I
do have a concern that certain CSS property value coercions don't
quite look like type conversion -- e.g. the coercion from the list of
font and meta-font names in font-family to a chosen font name -- but
perhaps we can work that out.
It would be great if Adam's bug were converted to a proposal on the
wiki...
jim
ps. By the way, speaking of confusion, CSS uses the term "property"
instead of "attribute". I find it clarifying to say "property" when
discussing CSS and "attribute" when discussing LZX.
On Aug 28, 2006, at 12:57 PM, P T Withington wrote:
> 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
