Re: Porting fill/stroke (and -opacity variants) to plain CSS

Hello Tab,

Wednesday, January 23, 2013, 11:55:04 PM, you wrote:

> On Wed, Jan 23, 2013 at 2:52 PM, Doug Schepers <schepers@w3.org> wrote:
>> Hi, Tab-
>>
>> Just one thing for consideration (there are surely many others):
>>
>> When using stroke with text, typically authors would prefer to have the
>> stroke underneath the fill, rather than on top of it, as it is now.
>> Otherwise, it gets too muddled.

It also wildly changes the  perceived shape of the glyphs.

> Strongly agree - I think it's extremely easy to show by example why an
> "outside" stroke is much more pleasing than a "both sides" stroke,

Yes

>  and
> you can simulate the former by painting the fill over the stroke.

Which works as long as the fill is fully opaque. Otherwise, you get an
unusual double stroke effect that may not be desirable.

However,  we have also talked about a property that allows the size of
the  inner and outer portions of stroke to be separately adjusted (the
initial  values would be 50% of stroke-width in each case) or having a
property  that  shifts the stroke inside or outside (the initial value
would be no shift). Either option would give correct stoked and filled
text, even with non-opaque fill or stroke.

>> We plan to add the capability to SVG 2 to allow the stroke to be under the
>> fill, along with other stroke properties. The mechanism we're using is
>> ultimately Vector Effects, but I think many of us see value in having some
>> "canned effect" properties for common things like stroke-under-fill,
>> multi-stroke, non-scaling-stroke, and other things. I'd like to see this
>> explored as part of CSS.

Yes.

Since  this  is  such  a  common  requirement  it should certainly be
exposed  in a convenient syntactic sugar way. And since there may be a
need  to  tweak  the  defaults, sometimes substantially, its better to
have this be a shorthand for vector effects.

> This is actually exposed already as part of the paint-order property,
> right?  You can just specify "paint-order: stroke fill" and it'll
> work.

Sort-of  work.  I  would  prefer  to  see a more robust solution going
forward, that doesn't depend on opaque fill mostly obscuring the artifacts.




-- 
Best regards,
 Chris                            mailto:chris@w3.org

Received on Thursday, 24 January 2013 13:30:26 UTC