I see the problem. The CSS compiler was canonicalizing color values to rgb format, and I guess the gradient parser is only accepting #-format. I don't have any way of passing through the original without ripping out the CSS compiler altogether, so I will adjust the canonical form to be #-format. But really, we need to use the color presentation type for parsing colors whenever we expect a color, so that any format will work. E.g., I assume a gradient should also be able to be specified with rgba(), instead of # and &?
I'll have another version for review as soon as I have passed your test case. On 2010-11-05, at 17:48, Max Carlson wrote: > Not approved. This doesn't fix components/demos/house.lzx when I remove the > quotes from around the gradient string values. I checked, and the > 'gradient-fill' attribute is type 'string'... > > On 11/4/10 2:11 PM, P T Withington wrote: >> Change ptw-20101104-S8x by [email protected] on 2010-11-04 14:04:07 EDT >> in /Users/ptw/OpenLaszlo/trunk-3 >> for http://svn.openlaszlo.org/openlaszlo/trunk >> >> Summary: Pass custom CSS property values as strings >> >> Bugs Fixed: LPP-9490 CSS Parser should default to delivering unknown >> attributes as strings to be presentation-type parsed at runtime >> >> Technical Reviewer: [email protected] (pending) >> QA Reviewer: [email protected] (pending) >> >> Release Notes: >> >> The CSS parser passes through most property values unchanged (but >> as strings, so they are valid Javascript). We only need a few >> special properties, e.g., the keyword `inherit` will be passed as >> a unique value, to distinguish from the string "inherit" (so if >> you wanted to specify the content of a node as the literal value >> "inherit", not have it inherit a value from it's parent). For >> backwards compatibility, color specifications are still >> canonicalized at compile-time and output them as hex numbers -- >> this may go away in the future. If you want a color specification >> to come through unparsed, you can use `rgba(...,...,...,1)`, >> because that will _not_ be converted at runtime. Any values that >> appear as "arguments" to a function (e.g., url(), rect(), >> linear-gradient()) will be passed straight through. The >> attribute's presentation type is invoked when the attribute is >> bound to a CSS property value; it's job is to convert that value >> to the appropriate internal representation. >> >> Overview: >> Rewrote the compile-time CSS parser to do nearly no compile-time >> conversion of property values, and to pass any custom (unknown) >> values through as strings, so the runtime can use the presentation >> type system to parse arbitrary values. >> >> Details: >> >> neighborhoodclasses, designerview: Fixed up the specification of >> some attributes to be more modern for testing. >> >> LzNode: Use acceptAttribute to install style property values. >> >> CSSHandler: Rewritten to do minimal compile-time processing. >> >> Tests: >> >> Files: >> M test/style/neighborhood/neighborhoodclasses.lzx >> M test/style/designerview.lzx >> M WEB-INF/lps/lfc/core/LzNode.lzs >> M WEB-INF/lps/server/src/org/openlaszlo/css/CSSHandler.java >> >> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/ptw-20101104-S8x.tar
