support `transparent` color keyword

[hrj]

Quoting from CSS3-color spec:

CSS1 introduced the ‘transparent’ value for the background-color property. CSS2 allowed border-color to also accept the ‘transparent’ value. The Open eBook(tm) Publication Structure 1.0.1 [OEB101] extended the ‘color’ property to also accept the ‘transparent’ keyword. CSS3 extends the color value to include the ‘transparent’ keyword to allow its use with all properties that accept a value. This simplifies the definition of those properties in CSS3.

Some of the CSS tests depend on it. For example, this test

Currently, jStyleParser doesn't recognize transparent as a value in the node data; it has to be accessed as a property. I am not sure if this is intentional; but I think it causes unnecessary overhead: because the client code has to first try getting a value, and if null, then try getting the property. I can see a noticeable slowdown (30%) in the tests.

[radkovo]

It seems to me that the transparent keyword is already supported by the parser for all the background-color, border-color and color properties. However, the expected way of retrieving the style is the following:

• First, the property value should be obtained using getProperty()
• If the obtained property value is a keyword (e.g. TRANSPARENT or BASELINE) then you should have all the necessary information. The value returned using getValue() is not relevant.
• If the obtained property value is color, length, percentage, etc., the exact value of the length, percentage or whatever may be obtained using getValue().

I believe this behavior is consistent for all the properties (see vertical-align or font-size for a typical example). In some cases, we could map the keyword to some resulting value as well but generally, the exact behavior should be implemented by the client application. E.g. with the background-color property, it makes sense not to paint the background at all instead of using a transparent color.

[hrj]

Ah ok.. We couldn't use the NodeData API to its full extent in gngr, because we are accessing it through multiple layers: the CSS OM api and our own internal RenderState API. And at that time, we took a simpler path of just brute-force trying the getValue() first, followed by getProperty().

Will have a deeper look at this on our side; thanks!