On 11/5/10 3:58 PM, P T Withington wrote:
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&?
Yes, rgb(), rgba() and # colors should be accepted... This is also true
for bgcolor/background-color...
I'll have another version for review as soon as I have passed your test case.
Okay, thanks!
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
