Approved!
That said, I'm concerned about the other ways strings might be tweaked
by the CSS compiler. Can you file a bug about the gradient parser not
dealing with ', ' separators?
On 11/5/10 4:25 PM, P T Withington wrote:
Ok, those colors _would_ be accepted, but the gradient parser is unforgiving of
whitespace.
This parses:
#xxxxxx 0,#xxxxxx 20
This does not:
#xxxxxx 0, #xxxxxx 20
I'll crush out the extra whitespace in the compiler, but seems like we need to
make the gradient parser more robust...
I've updated the change package. Could you re-review?
On 2010-11-05, at 19:07, Max Carlson wrote:
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
