RE: Possible text-shadow enhancements

Elika:
> > My concern is entirely about implementability. If we have
> > implementations for the full <box-shadow> syntax, then I'm happy to
> > leave that for text-shadow. Else, I would rather trim down the feature
> > to what UAs are willing to support.

Simon:
> My point is that implementing 'spread' for text-shadow is entirely different
> to implementing it for text-shadow. For box-shadow, WebKit just inflates the
> rounded rect by the spread (possibly adjusting the corner radius in the
> process). There's no equivalent for text-shadow because the shapes are no
> longer just rounded rects.

I presume he meant...

> ... implementing 'spread' for text-shadow is entirely different
> to implementing it for box-shadow. 


On the larger point...

Simon's assessment applies for IE as well.

We have a specific algorithm for applying spread that is designed specifically for rectangles and "rounded rectangles" based on the various discussions we've had previously here regarding the desired effect for box-shadow spread. 

While conceptually the effect can be applied to other shapes, the approach isn't just "plug in an arbitrary font glyph and the same algorithm just works" -- even if the glyph data arrives in vector form.

From a parsing and OM perspective, code re-use does apply -- with the caveat that exclusion of 'inset' requires adjustments (mostly simplification).


Regarding Brad's samples...
 http://www.bradclicks.com/cssplay/text-shadows.png

I'm curious which, if any, of the shape modification effects is literally equivalent to just using a larger font size.  For non-blurred text-shadow a spread that simply does "grow the font size" might be significantly cheaper on some platforms and yield most of the desired result.  Such an approach is also interesting in that it allows font authoring to have some control in how text-shadow is applied.

- Brian

Received on Wednesday, 2 March 2011 19:42:16 UTC