W3C home > Mailing lists > Public > www-style@w3.org > July 2013

Re: [css-text] text-shadow and inset

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sat, 27 Jul 2013 23:02:34 -0700
Message-Id: <3E1AFEA5-1C43-4030-B7A6-658F744E9B5D@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
To: Simon Fraser <smfr@me.com>


Sent from my iPad

On Jul 27, 2013, at 2:03 PM, Simon Fraser <smfr@me.com> wrote:

> On Jul 27, 2013, at 1:29 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
>> On Jul 27, 2013, at 1:03 PM, Simon Fraser <smfr@me.com> wrote:
>> 
>>> On Jul 26, 2013, at 10:16 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> 
>>>> Due to persistent developer requests, we're planning on implementing
>>>> 'inset' for text-shadow in Blink.  Does anyone have any strong
>>>> objections?  If not, can we update css-text (either level 3 or 4, I'm
>>>> not picky) to allow the keyword?
>>>> 
>>>> (It turns out that Skia has some features that make this not too hard
>>>> to implement in a performant manner, at least upon initial review.)
>>> 
>>> I object unless you can specify the behavior of inset in terms of bezier path manipulations
>>> that can be performed by most graphics libraries.
>> 
>> Why? It isn't specified that way for non-inset, where you are more likely, I'd think, to have problems with how corners are handled.
> 
> That¡¯s exactly the problem. ¡®inset¡¯ already has ambiguity with corners,

I'm not aware of it. I recall we spent a lot of time defining how corners would work in inset box shadows. What is the ambiguity?

> and this will be even more apparent when attempting to apply it to complex paths like glyph outlines, with shape features like narrow throats and acute angles.
> 
> I don¡¯t want implementations to have to run a per-pixel algorithm to compute inset for text. It has to be specified in terms of path manipulation.

I'm not against specifying how path manipulation would work for high fidelity choking and spreading of text shadow, either for inset or outset. But for some implementations, I expect it to be simpler and less expensive to do a raster operation for good enough results.

But I don't see how, absent any spread value, that inset is any more ambiguity or difficulty than outside text shadows. For outer shadows, you offset a copy of the glyph, apply the blur, then knockout the shape and position of the original glyph. With inner shadows, it is exactly the same, except you reverse the alpha of the copy and knockout everything _outside_ the shape and position of the original glyph. 
Received on Sunday, 28 July 2013 06:03:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC