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