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

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

From: Simon Fraser <smfr@me.com>
Date: Sat, 27 Jul 2013 14:03:35 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-id: <333C3E54-5747-4B99-9BB9-A228289CC1FD@me.com>
To: Brad Kemper <brad.kemper@gmail.com>
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, 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.

Simon
Received on Saturday, 27 July 2013 21:04:04 UTC

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