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 >>
