The features listed in this section have been introduced in this module.

STATIC METHODS

Uize.Fx.xShadows.toShadow

STATIC PROPERTIES

Uize.Fx.xShadows.moduleName | Uize.Fx.xShadows.pathToResources

No features have been overridden in this module.

This module has no inherited features.

There are no modules directly under this namespace.

There is no dedicated unit tests module for the Uize.Fx.xShadows module.

While the shadow parsing code can technically support an arbitrary number of box shadows per boxShadow value, as with text shadows, the browsers that support box shadow only support a single shadow per DOM node.

At the time of this writing, there is still debate regarding whether or not multiple box shadows per DOM node should be supported.

Neither IE6, IE7, nor IE8 support text shadow or box shadow, and it is not yet clear whether or not IE9 will support shadows.

We hope that IE9 will support both text shadow AND box shadow, because shadows can be very compelling in providing rich visualizations. Hopefully Web developers will strongly express their desire for full CSS3 support, and hopefully Microsoft will rise to the challenge.

Given the reality that shadows will take a while to become universally supported in a majority of installed browsers, it is important to employ the principle of graceful degradation when using shadows.

Quite often an element that is styled using shadows can also look satisfactory when shadows are not present. At the very least, color choices should be made that ensure that text remains legible when text shadow is not supported. Don't rely on text shadow, in other words, in order for text to be visible against a background that has a similar lightness. The best way to achieve gracefuly degradation is to simply test your content in browsers that don't support shadows and tune text and background colors accordingly to make sure the fallback is acceptable.

While the units for different properties of a shadow don't all have to be the same, all spacial properties for the start value of a shadow should have the same unit as the corresponding properties of the end value of a shadow.

For textShadow values where there are multiple shadows (see Supports an Arbitrary Number of Shadows), this rule applies to each one of the shadows in the start value and the corresponding shadow in the end value. Also, the start and end values should also have the same number of shadows in such cases.

All this is best illustrated with an example...

INCORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#fff',
    backgroundColor:'#000',
    textShadow:'#000 0em 0 0em, #000 0px 0 0px'
  },
  {
    color:'#000',
    backgroundColor:'#045',
    textShadow:'#0ff -30px 0 .5em, #0ff 30px 0 .5em'
  },
  500
);

In the above example, the horizontal offset for the first shadow is specified as 0em in the start value and as -30px in the end value. The units should match. Similarly, the blur radius for the second shadow is specified as 0px in the start value and as .5em in the end value. Once again we mismatching units. It doesn't matter that 0em is practically the same as 0px. In order to not confuse the interpolation code, the same unit should be used for both start value and end value.

CORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#fff',
    backgroundColor:'#000',
    textShadow:'#000 0px 0 0em, #000 0px 0 0em'
  },
  {
    color:'#000',
    backgroundColor:'#045',
    textShadow:'#0ff -30px 0 .5em, #0ff 30px 0 .5em'
  },
  500
);

Now the units match for corresponding properties of corresponding shadows, between the start value and the end value.

When no unit is specified for a spatial property, its unit defaults to "px", so the rule to use all the same units for start and end values applies in this case as well.

So, for instance, you should not omit the unit for a spatial property of a shadow in the start value if the unit specified for the corresponding property of the corresponding shadow in the end value is not "px". Consider the following example...

INCORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#fff',
    backgroundColor:'#666',
    textShadow:'#0 .3em .3em .3'
  },
  {
    color:'#000',
    backgroundColor:'#6a9',
    textShadow:'#f 0 0em .3em'
  },
  500
);

In the above example, the horizontal offset of the text shadow is being specified as .3em in the start value and as just 0 in the end value. The unit for the end value's version is defaulted to "px", and so the units for horizontal offset don't match. Similarly, the blur radius of the text shadow is being specified as .3 in the start value and as .3em in the end value. The unit for the start value's version is defaulted to "px", and so the units for blur radius don't match.

CORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#fff',
    backgroundColor:'#666',
    textShadow:'#0 .3em .3em .3em'
  },
  {
    color:'#000',
    backgroundColor:'#6a9',
    textShadow:'#f 0em 0em .3em'
  },
  500
);

Now the units match for corresponding properties of corresponding shadows, between the start value and the end value.

For textShadow values where there are multiple shadows (see Supports an Arbitrary Number of Shadows), both the start value and the end value should contain the same number of shadows.

INCORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#fff',
    backgroundColor:'#000',
    textShadow:'#000 0px 0 0em, #000 0px 0 0em, #000 0px 0 0em, #000 0px 0 0em'
  },
  {
    color:'#000',
    backgroundColor:'#045',
    textShadow:'#0ff -30px 0 .5em, #0ff 30px 0 .5em'
  },
  500
);

In the above example, the start value for textShadow contains four shadows, while the end value contains only two.

CORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#fff',
    backgroundColor:'#000',
    textShadow:'#000 0px 0 0em, #000 0px 0 0em, #000 0px 0 0em, #000 0px 0 0em'
  },
  {
    color:'#000',
    backgroundColor:'#045',
    textShadow:'#0ff -30px 0 .5em, #0ff 30px 0 .5em, #0f0 -20px 0 1em, #0f0 20px 0 1em'
  },
  500
);

Now we have four shadows for the start value as well as the end value.

While the Uize.Fx.xShadows module supports flexible arrangement of shadow properties, with some properties being optional and having defaulting behavior, whatever properties are specified for a shadow in the start value, those same properties should all be specified for the corresponding shadow in the end value.

This is best illustrated with an example...

INCORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#000',
    backgroundColor:'#888',
    textShadow:'-1 0 #fff, #fff 1 0 0,0 -1 #fff, 0 1 0 #fff'
  },
  {
    color:'#000',
    backgroundColor:'#000',
    textShadow:'-1 0 0 #f95, 1 0 0 #fc0,0 -1 #ff0, 0 1 0 #f00'
  },
  500
);

In the above example, the problem is with the way the properties of the first shadow are specified in the start and end values. While the optional blur radius property does default to 0 when not specified, if you specify it in a shadow in the start value, then you must specify it in the corresponding shadow in the end value. Looking at the second shadow, you'll notice that the order of the properties is different between the start and end values. This is fine, because the Uize.Fx.xShadows module supports flexible arrangement of shadow properties, as long as all the same properties are present for any given shadow in both the start and end values. Looking at the third shadow, you'll notice that the blur radius is not specified in either the start value or the end value. This is fine as well, since it will default to 0.

CORRECT

Uize.Fx.fadeStyle (
  'myNode',
  {
    color:'#000',
    backgroundColor:'#888',
    textShadow:'-1 0 0 #fff, #fff 1 0 0,0 -1 #fff, 0 1 0 #fff'
  },
  {
    color:'#000',
    backgroundColor:'#000',
    textShadow:'-1 0 0 #f95, 1 0 0 #fc0,0 -1 #ff0, 0 1 0 #f00'
  },
  500
);

Looking at all the shadows now, you'll notice that each shadow has all the same properties between the start and end values.