[Laszlo-dev] For Review: Change 20070102-ptw-s Summary: Better typing for styles

[P T Withington]

Oy.

I see why CSS does not permit 0xffffff.  In CSS, numbers followed by  
letters are 'dimensioned values', so `0xffffff` is `0.0 'xffffff's`  
(cf., `0px`).  Now, I can kludge it so `0xffffff` will pass through  
as `"0xffffff"`, but then we are right back where we started, with a  
string instead of a number.  [The handler for dimensioned values  
currently passes them as strings.  Probably we should have some  
dimension types built in to LZX, so they can be passed more  
accurately.  Perhaps we are not using any dimensioned attributes in  
our CSS yet?]

Ben:  Perhaps the most dangerous thing I did in this change is to  
make identifiers pass through as symbols, so:

   bgcolor: black

comes out in Javascript as

   bgcolor: black

(and will thus evaluate black, which will 'just work').  Previously  
it would have come out in Javascript as:

   bgcolor: "black"

which would not have worked.  But, perhaps there is some other code  
that is relying on identifiers being strings?

On 2007-01-02, at 16:09 EST, P T Withington wrote:

> Since we are using (thanks to Pablo's great work) the batik CSS  
> parser, I don't hold out high hope for being able to tweak that to  
> accept hex numbers.  Blame w3c for inventing #FFFFFF instead of  
> using the familiar old 0xFFFFFF.
>
> OTOH, you do get, for free, yet _another_ way to express your colors:
>
>   bgcolor: rgb(255, 255, 255);
>
> or:
>
>   bgcolor: rgb(0xff, 0xff, 0xff);
>
> or:
>
>   bgcolor: rgb(100%, 100%, 100%);
>
> [I just made %'s work in Pablo's parser, in my playpen.]
>
> We could possibly wedge in hex values by doing something like:
>
>   eval(0xFFFFFF)
>
> (Using the fact that CSS allows you to have arbitrary 'functions'  
> for future expansion.  We could define eval to just pass arbitrary  
> Javascript to the style builder.  It would get evaluated at load  
> time (aka, immediately), so you'd be playing with fire to use  
> anything but a constant.  But maybe that is more palatable that  
> using "0xFFFFFF"?)
>
> The trouble with `bgcolor="${#FFFFFF}"` is that `#FFFFFF` is not a  
> valid javascript expression.  If you meant instead `bgcolor="$ 
> {'#FFFFFF'}"`, that is what LPP-2610 is all about.
>
> On 2007-01-02, at 14:06 EST, Sarah Allen wrote:
>
>> Thanks for taking a look at this -- it will be great to be able to  
>> support setting bgcolor to null (transparent) with CSS!  It would  
>> be nice if the css files could specify 0xFFFFFF as well as  
>> #FFFFFF, just because it's hard for folk to remember where to use  
>> which format.  It is bad enough that in LZX we can say :
>>
>> bgcolor="#FFFFFF" or bgcolor="0xFFFFFF" or bgcolor="${0xFFFFFF}"
>> but not
>> bgcolor="${#FFFFFF}"
>>
>> On Tue, Jan 2, 2007 at 10:20 AM, P T Withington wrote:
>>
>>> Change 20070102-ptw-s by ptw at dueling-banjos.local on 2007-01-02  
>>> 10:14:51 EST
>>>      in /Users/ptw/OpenLaszlo/trunk
>>>
>>> Summary: Better typing for styles
>>>
>>> Bugs Fixed:
>>> LPP-3356: 'can't make bgcolor transparent with css'
>>>
>>> Technical Reviewer: ben (pending)
>>> QA Reviewer: adam (pending)
>>> Doc Reviewer: jsundman (pending)
>>>
>>> Documentation:
>>>
>>> It seems that people want to write CSS colors as 0xFF00DD.  But that
>>> is not valid CSS.  So they wrote them as "0xFF00DD" and then were
>>> disappointed that the runtime did not recognize those strings as
>>> numbers.  So a kludge was added to the style applicator to convert
>>> strings to numbers.  But this kludge did not consider that the  
>>> string
>>> "null" would coerce nicely to the number 0, which for a color is
>>> black.  And thereby hangs a tale.
>>>
>>> Release Notes:
>>>
>>> You will get a warning if you use "OxXXXXXX" to specify a color in a
>>> CSS style sheet.  You should be using #XXXXXX instead.
>>>
>>> Details:
>>>      LzCSSStyle.js: Consider the case where the value of the  
>>> property
>>>      may be 0, or null, which coerce to false in a boolean context.
>>>
>>>      LzNode.as: Only do the string->int conversion if the string is
>>>      really parseable as a number.  Warn the user that there is a
>>>      better way.
>>>
>>>      LaszloView.as: Fix the code that was trying to warn you when  
>>> you
>>>      set bgcolor to a non-number to actually detect and report that.
>>>
>>>      StyleProperty.java: Add a toString method to support
>>>      ScriptCompiler.writeObject
>>>
>>>      CSSHandler.java: Use the LexicalUnitType information to  
>>> store the
>>>      value as an appropriate Javascript literal (i.e., encode the  
>>> type
>>>      information).
>>>
>>>      StyleSheetCompiler: Use ScriptCompiler.writeObject to write the
>>>      style map, so that type information encoded in the literals is
>>>      preserved.
>>>
>>> Tests:
>>>      Bug test and failing cases both pass now.  That is, once I
>>>      corrected the failing test case to specify CSS bgcolor as the
>>>      token `null`, rather than the string `"null"`.
>>>
>>> Files:
>>> M      WEB-INF/lps/lfc/services/LzCSSStyle.js
>>> M      WEB-INF/lps/lfc/core/LzNode.as
>>> M      WEB-INF/lps/lfc/views/LaszloView.as
>>> M      WEB-INF/lps/server/src/org/openlaszlo/css/StyleProperty.java
>>> M      WEB-INF/lps/server/src/org/openlaszlo/css/CSSHandler.java
>>> M      WEB-INF/lps/server/src/org/openlaszlo/compiler/  
>>> StyleSheetCompiler.java
>>>
>>>
>>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20070102- 
>>> ptw- s.tar
>